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 **********************