[comp.sys.mac.digest] INFO-MAC Digest V6 #22

Moderators.Jon@SUMEX-AIM.Stanford.EDU, Dwayne@SUMEX-AIM.Stanford.EDU, (02/22/88)

INFO-MAC Digest          Monday, 22 Feb 1988       Volume 6 : Issue 22

Today's Topics:
                       Linking objects dynamically
                           Re: sprintf() bug?
                            Using C in Pascal
                               MACSBUG...
                     LightspeedC 3.0 Upgrade Policy
                      Re: INFO-MAC Digest   V6 #13
                         Opening windows in MPW
              QuickDraw global variables in an MPW C WDEF?
                                 Viruses


----------------------------------------------------------------------

Date: Mon, 15 Feb 88 16:43:44 MET
From: Norbert Lindenberg - U Karlsruhe <norbert@ira.uka.de>
Subject: Linking objects dynamically

I have another suggestion for the big MacApp wish list: I'd like to see
a mechanism that allows for dynamic linking of code that's written in an
object-oriented fashion. There are many kinds of resources or files on
the Macintosh that are dynamically loaded and launched by the toolbox or
by programs (e.g. DAs, FKEYs, MPW Tools, Apple File Exchange translators),
but most of them must be written as a single procedure. This approach
makes it difficult to group several related functions into one
piece of code (you must have a selector argument for AFE translators or
have to ask for command line parameters as MPW tools do), and I can't
see a good way to make this work for objects.

I think there are lots of tasks where one would like to program in an
object-oriented manner, using MacApp, but still has to be able to load
code dynamically from separate files. AFE is a good example: one could
write the AFE shell with MacApp, define the interface to the translators
as an abstract object type, and provide the translators thmselves as
external files. Other applications might be
- an integrated programming environment that defines an abstract
compiler object type, but still allows for separately distributed
compilers (with 'integrated programming environment' I mean something of
the Lightspeed type, not MPW)
- a word processor, that defines interfaces for spelling checkers or
hyphenators.

These examples have in common, that the designer of the shell wants to
provide a rich interface to some kind of tool, but cannot supply all
instances of that tool class or does not want to link all of these
instances into the application itself.

I don't know how to integrate dynamic linking into the complex mechanism
of method calls, but I hope that someone at Apple can figure out a
generic way to do it, and build it into MacApp.

-- Norbert

------------------------------

From: dudek@ai.toronto.edu (Gregory Dudek)
Subject: Re: sprintf() bug?
Date: 16 Feb 88 22:28:25 GMT
Reply-to: dudek@ai.toronto.edu (Gregory Dudek)


  Just to correct some apparent misinformation that has been propagated
on this subjec...

In article <5383@cit-vax.Caltech.Edu> palmer@tybalt.caltech.edu.UUCP (David Palmer) writes:
>In article <943@cadre.dsl.PITTSBURGH.EDU> cgw@cadre.dsl.pittsburgh.edu.UUCP (Gray Watson) writes:
>>>  sprintf(tempstring, "%s %f %s %f", "\pthe square of ", x, "is", (x *x));
>>>  DrawString(tempstring);

  [ etc, etc ]
>>
>
>The string produced by "\pthe square of " is NOT null terminated (it is
>a Pascal string, and so the length is specified by a byte at the beginning,
>...
>True, but the '\p' in "\pHello Dolly" is just a directive to tell the
>compiler to count the characters for itself, and the string is stored in
>memory as "\013Hello Dolly", with no null termination.
>

  Aztec C produces a C-string *WITH* a null terminator when it sees:
"\Pfoo".   In other words it's a legal Pascal string but has an EXTRA
character (null) that Pascal routines won't notice, thus making it a
legal C-string also.  This seems like a very sensible idea since C
routines invoked on it won't blow up & things like strcpy still work.
  I don't know what other complers do, but I would be seem reasonable if they
did the same.
  Of course, this doesn't solve the original poster's problem.  He should
use something like:
  sprintf(tmp,"%s %d ect",...);  DrawString(CtoPascal(tmp));
where CtoPascal is appropriately defined (most compilers include
a library routine that does this).

  As for glue routines, Aztec C uses them only for *some* ROM traps; most
are defined as straight ROM entries.

  Greg Dudek
--
Dept. of Computer Science (vision group)    University of Toronto
Reasonable mailers:  dudek@ai.toronto.edu
Other UUCP: {uunet,ihnp4,decvax,linus,pyramid,
		dalcs,watmath,garfield,ubc-vision,calgary}!utai!dudek
ARPA: user%ai.toronto.edu@relay.cs.net

------------------------------

Date: Wed, 17 Feb 88 12:58:07 MST
From: Major John Buono
From: <buono%asbf-imp.huachuca-em.arpa@HUACHUCA-EM.ARPA>
Subject: Using C in Pascal

This may sound like a novice question but I have not been able to find an
answer.  I am using both LightSpeed C and LightSpeed Pascal.  I need to find
out how I can use C routines in my pascal programs.  The LSC documentation
covers very nicely how to us pascal routines in C programs but the pascal
documentation makes no mention of how to use C functions in a pascal
program.  I now to some this would be sacreligious, but I do have my
reasons.  Can any one help?

Thanks

John Buono

[
Moderator's Note:

I was astounded when I called Think and asked them this question.  They said
that the object file formats of LSP and LSC are incompatible.  The man I spoke
with (I believe it was Steve) said that he had argued for compatibility and
lost.  How come the people with the correct ideas often lose?

At any rate, if you want C and Pascal, go with MPW or an MDS flavor setup.

Jon Pugh
]17-Feb-88 21:20:12-PST,1124;000000000001

------------------------------

Date: Wed 17 Feb 1988 23:16 CDT
From: Samir Kaleem <XSAK%ECNCDC.BITNET@forsythe.stanford.edu>
Subject: MACSBUG...

Hello all...

I am having problems using MACSBUG on Finder 6.0 and System 4.2. I am not
using Multifinder, but I do have at least 5 various inits out there.
Previously, when the Mac crashed, I could do a G EXIT, or ES at the
debugger prompt and usually I am able to recover. However, with the
new sys and finder, when the debugger comes up and I type something,
all that I get on the screen is garbage. Oh, I am using MACSBUG 5.2.
Has anyone else come across this problem? If so, what is the solution?
I'd greatly appreciate any help...

                                            -- Samir Kaleem
                                               XSAK@ECNCDC.BITNET

------------------------------

Date: Thu, 18 Feb 88 23:33:26 -0500 (EST)
From: Richard Siegel <rs4u+@andrew.cmu.edu>
Subject: LightspeedC 3.0 Upgrade Policy


This is an official policy statement as to the upgrade policy for LightspeedC:

	"LightspeedC users who purchased their copy of LightspeedC on
	or after February 1st, 1988 will receive the upgrade to
	version 3.0 of LightspeedC free of charge."

Please note that I still do not have a release date for LightspeedC or
Lightspeed Pascal. As I've said before, it's not far off, and I'll post
when I have more details.

PLEASE SPREAD THE WORD. If you know someone who doesn't follow the newsgroups
and uses LightspeedC, tell them of this policy; also, propagate this
message to other online services and BBSs.

That is all.

		--Rich

===================================================================
Richard Siegel
THINK Technologies, QA Technician (on leave)

The opinions stated here do not represent the policies
of THINK Technologies or of Carnegie-Mellon University.

Arpa: rs4u@andrew.cmu.edu
UUCP: {decvax,ucbvax,sun}!andrew.cmu.edu!rs4u
==================================================================

------------------------------

Date: Thu, 18 Feb 88 13:33:26 pst
From: Larry Rosenstein <lsr@apple.apple.com>
Subject: Re: INFO-MAC Digest   V6 #13

In article <8802142137.AA15897@ucbvax.Berkeley.EDU> you write:
>
>Date: Mon, 08 Feb 88 14:51:10 EST
>From: "William E. Williams"
>From: <BSQUARE%YALEVM.BITNET@forsythe.stanford.edu>
>Subject: Background process, new SE fan
>
>one process, namely laser printing, in the background, but it's a start.

Actually the Finder runs in the background as well, to process disks that
are mounted.  I have seen PD programs that also run in the background.  (I
wrote one called TimeKeeper.)

>Can someone point me to references on writing programs to run in the
>"background?"  I have a Mac + now dedicated to running some lab equipment, but

APDA has a MultiFinder developers package.

There is nothing much that you have to do specially.  One bit in the
application's SIZE resource controls whether the application gets NULL
events while in the background.

To be "friendly" a background application should yield the CPU as often as
possible.  You do this by calling GetNextEvent, or better yet,
WaitNextEvent.  WNE allows an application to sleep until (1) an event is
received, (2) a specified time has elapsed, or (3) the mouse pointer leaves
a certain region.  Until one of these things happens, the application won't
get any CPU time, leaving it all for other apps.


Larry Rosenstein

------------------------------

Date: Fri, 19 Feb 88 20:44:18 PST
From: Charles Dolan <cpd@CS.UCLA.EDU>
Subject: Opening windows in MPW

The documentaion for MPW tools say the opening windows and doing
graphics is a largely unexplored area.  Every time I try to open
a window or even draw in the shell window, I get a system bomb.  Has
anyone else experimented with this?  Does any body have any prototype
code they would share?

Thank
-Charlie Dolan

------------------------------

Date: Sat, 20 Feb 88 17:15 N
From: <FRUIN%HLERUL5.BITNET@forsythe.stanford.edu> (Thomas Fruin)
Subject: QuickDraw global variables in an MPW C WDEF?

Am I correct when I think there is  NO  way for a window definition
function written in MPW C to access the QuickDraw global variables?

I'm busy putting the finishing touches on a WDEF I've written,  and
want to set up the standard state - the rectangle  representing the
zoomed size of the window. For this I need screenBits.bounds, which
holds the size of the current  Macintosh screen.  No go.  The MPW C
manual mentions somewhere that  desk accessories and drivers cannot
use  (QuickDraw)  global variables, which probably means that WDEFs
cannot either.

( Btw, isn't it strange that _every_ development system goes out of
its way to tell you how to write DAs and drivers,  but consistently
ignores  definition functions and INITs?  If anyone is listening, I
think it's something that needs addressing. )

Has anyone  else solved this problem?   Suppose I write an assembly
language  function to get the  address of those globals: would that
work?  Any help appreciated!

-- Thomas Fruin

   fruin@hlerul5.BITNET                     Leiden University
   thomas@uvabick.UUCP                      University of Amsterdam
   hol0057.AppleLink
   2:500/15.FidoNet                         The Netherlands

------------------------------

Date: Wed, 17 Feb 88 21:21 EST
From: <TEMPLON%IUCF.BITNET@forsythe.stanford.edu>
Subject: Viruses


re:     posting by  eliot@cs.umass.edu   et al.  in v6 #14 :

        YES! I think we have to be on the lookout for this sort of
thing, because it is coming our way soon. I don't know what kind of
connection most of this list's readers has with the IBM world, but
there is a particularly virulent virus circulating amongst these guys
right now. There was an article in the 'TRIUMF Computing Newsletter'
last month about it: apparently the little bugger copies itself to a
system disk. Afterwards when another system disk is accessed from the
infected disk, the virus copies itself to the uninfected disk and
increments a counter. When the counter reaches 4, EVERY disk connected
to the machine gets COMPLETELY erased.

        This sort of thing can be quite an interference to getting
any sort of useful work done on a computer....

                                Jeff Templon

------------------------------

End of INFO-MAC Digest
**********************