From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-039 Date: Sun, 26 Jun 1994 23:30:56 +0200 (MET DST) C.S.M.P. Digest Sun, 26 Jun 94 Volume 3 : Issue 39 Today's Topics: API-headers for Control Strip Modules? Apple Event Question Are NewPtr() and malloc() different? (source included) Closing Down the FINDER Fat-stripping Finder Comments and Finder Info Updating MacTech's ftp site now available! QuickDraw GX Display Devices SEMI-SUMMARY: Reading JPEGs (with code) VBL interrupt & Stack Sniffer Writing dcmd with Think C (Q) The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier (pottier@clipper.ens.fr). The digest is a collection of article threads from the internet newsgroup comp.sys.mac.programmer. It is designed for people who read c.s.m.p. semi- regularly and want an archive of the discussions. If you don't know what a newsgroup is, you probably don't have access to it. Ask your systems administrator(s) for details. If you don't have access to news, you may still be able to post messages to the group by using a mail server like anon.penet.fi (mail help@anon.penet.fi for more information). Each issue of the digest contains one or more sets of articles (called threads), with each set corresponding to a 'discussion' of a particular subject. The articles are not edited; all articles included in this digest are in their original posted form (as received by our news server at nef.ens.fr). Article threads are not added to the digest until the last article added to the thread is at least two weeks old (this is to ensure that the thread is dead before adding it to the digest). Article threads that consist of only one message are generally not included in the digest. The digest is officially distributed by two means, by email and ftp. If you want to receive the digest by mail, send email to listserv@ens.fr with no subject and one of the following commands as body: help Sends you a summary of commands subscribe csmp-digest Your Name Adds you to the mailing list signoff csmp-digest Removes you from the list Once you have subscribed, you will automatically receive each new issue as it is created. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest. Questions related to the ftp site should be directed to scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP digest are available there. Also, the digests are available to WAIS users. To search back issues with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html. ------------------------------------------------------- >From Gordie Freedman Subject: API-headers for Control Strip Modules? Date: 8 Jun 1994 07:17:19 GMT Organization: Kaleida Labs, Inc. Anybody know where the API is documented to write control strip modules? I also wasn't sure if there were any header files you used with this stuff, or if you had to roll your own. Thanks in advance, Gordie Freedman -- gordie@kaleida.com - Kaleida Labs, Inc. - Mountain View, CA +++++++++++++++++++++++++++ >From tgaul@halcyon.com (Troy Gaul) Date: Wed, 08 Jun 1994 21:42:50 -0700 Organization: Infinity Systems In article <2t3r9v$3mr@golden.kaleida.com>, Gordie Freedman wrote: > Anybody know where the API is documented to write control strip modules? > I also wasn't sure if there were any header files you used with this > stuff, or if you had to roll your own. Thanks in advance, They're in the PowerBook 500-series technical notes, which were included on the June Developer CD. As far as a header file goes, I didn't see anything included. _troy //////// //////___Troy Gaul_________________________tgaul@halcyon.com__ // // // Infinity Systems ; Redmond, Washington // // // // "Insert witty quote here." // // //////________________________________________________________ // +++++++++++++++++++++++++++ >From jonpugh@netcom.com (Jon Pugh) Date: Sat, 11 Jun 1994 09:12:12 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Gordie Freedman (gordie@kaleida.com) wrote: > Anybody know where the API is documented to write control strip modules? > I also wasn't sure if there were any header files you used with this > stuff, or if you had to roll your own. Thanks in advance, For that matter, can you get the software any way without buying a 500? Not that I don't want a 500... Jon +++++++++++++++++++++++++++ >From tgaul@halcyon.com (Troy Gaul) Date: Sat, 11 Jun 1994 22:46:33 -0700 Organization: Infinity Systems In article , jonpugh@netcom.com (Jon Pugh) wrote: > Gordie Freedman (gordie@kaleida.com) wrote: > > Anybody know where the API is documented to write control strip modules? > > I also wasn't sure if there were any header files you used with this > > stuff, or if you had to roll your own. Thanks in advance, > > For that matter, can you get the software any way without buying a 500? > > Not that I don't want a 500... I tried a copy of Control Strip, grabbed off the hard drive of a 500, and tried it on a desktop Mac, and it wouldn't function, but it worked fine on a PowerBook 140. I certainly hope that they allow it to work on desktop Macs as well soon. I'd like to use it for a few things myself (like volume and monitor depth-switching), and its modular architecture makes it easy for third parties to write modules that would be useful for users of desktop machines. _troy //////// //////___Troy Gaul_________________________tgaul@halcyon.com__ // // // Infinity Systems ; Redmond, Washington // // // // "Insert witty quote here." // // //////________________________________________________________ // +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Sun, 12 Jun 1994 14:54:34 +0800 Organization: Department of Computer Science, The University of Western Australia In article , jonpugh@netcom.com (Jon Pugh) wrote: >For that matter, can you get the software any way without buying a 500? Yes. Get a 280 (: -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Sun, 12 Jun 1994 23:08:17 +0800 Organization: Department of Computer Science, The University of Western Australia In article , tgaul@halcyon.com (Troy Gaul) wrote: >I tried a copy of Control Strip, grabbed off the hard drive of a 500, and >tried it on a desktop Mac, and it wouldn't function, but it worked fine on >a PowerBook 140. The guys at the WWDC session said they would consider moving it to the desktop Macs depending on how it was received on the PowerBooks. Personally I think it's a TOE (Thing Of Evil (tm)). That won't stop me using it of course (: -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia Now if only the 280C I have on order would arrive ): --------------------------- >From jml16@po.CWRU.Edu (Jonathon M. Lipsky) Subject: Apple Event Question Date: 2 Jun 1994 20:01:16 GMT Organization: Case Western Reserve University, Cleveland, Ohio (USA) I would like to know if anyone has created their own AppleEvents to pass data between two programs. What I would like to do is impliment an event similar to an OpenDocument, but I would like to pass a string that the recieving program that would give it the needed information. All of my attempts at implimenting this have not succeeded, so any examples would be greatly appreciated. Jon Lipsky (jml16@po.cwru.edu) +++++++++++++++++++++++++++ >From Here@There (Someone) Date: 10 Jun 1994 17:29:50 GMT Organization: Large Fuzzy Room There's lots of samples around, adapting a 'real' AppleEvent to your private needs will be easiest. Here's one way you might want to implement the send and recieve functions (VERY simple here) // a coupla defines #define kMyPrivateEventClass 'MYEV' #define kOpenFileStringEvent 'OPFS' #define typeMyPString 'MPST' // Get the address (through PPCBrowser or elsewhere) and the // file string and pass them in OSErr SendFileNameString(ConstStr255 theFullPath,AEDesc * theAddress) { AppleEvent theEvent; OSErr theError = noErr; // create the event theError = AECreateAppleEvent(kMyPrivateEventClass,kOpenFileStringEvent, theAddress,kAutoGenerateReturnID,kAnyTransactionID,&theEvent); // if no error, add our string if(theError == noErr) theError= AEPutParamPtr(&theEvent,keyDirectObject,typeMyPString,(Ptr)&theFullPath[1],theFullPath[0]); // send the event if(theError == noErr) theError = AESend(&theEvent,nil,kAENoReply,kAENormalPriority,kAEDefaultTimeout,(IdleProcPtr) nil,nil); return( theError ); } // and on the recieving end, get the thing out pascal OSErr HandleMyOpenFileStr(AppleEvent *messagein, AppleEvent *reply, long refIn) {OSErr theError = noErr; Str255 fileString; DescType returnedType; Size returnedSize; // get the string from the event theError = AEGetParamPtr(messagein, // from this event keyDirectObject, // get the direct object typeMyPString, // as a pstring &returnedType, (Ptr)&fileString[1], // put it here 254, // max size &returnedSize); if(theError == noErr){ fileString[0] = returnedSize; theError = FSOpen(fileString, nil,&fileRefNum); // fileRefNum is somewhere, whereever you need it } return ( theError); } --------------------------- >From cr@cs.strath.ac.uk (Chris Reid) Subject: Are NewPtr() and malloc() different? (source included) Date: Mon, 06 Jun 1994 12:15:52 +0000 Organization: University of Strathclyde Hi everybody, I have written some code that implements Radix Sort (it sorts an array of longs in linear time). It seems to work well enough, but one thing is really strange: when I replace the NewPtr() calls with calls to malloc(), the corresponding free() doesn't seem to work. Here's roughly what happens: // RadixSort implemented using NewPtr() and DisposPtr() mem = FreeMem(); // We've got amount 'mem' bytes in the heap RadixSort(someArray, numItems); // Do the sorting waste = mem - FreeMem(); // Is there a memory leak? waste is always zero (just as it should be), BUT: // RadixSort implemented using malloc() and free() mem = FreeMem(); // We've got amount 'mem' bytes in the heap RadixSort(someArray, numItems); // Do the sorting waste = mem - FreeMem(); // Is there a memory leak? waste is non-zero, a very disturbing fact. But it gets even better, because on consecutive calls, waste IS zero. It looks as if malloc() remebers what it's done before. By the way, I need to use malloc() because the code has to be (sort of) platform independent. The source is attached (hence the cross-posting to alt.sources.mac). It works, so feel free to use it. Something must be going wrong somewhere, I can't see it, can anybody else? I'm using THINK C 6.0.1 with Objects. Thanks in advance folks! Chris PS: a description of Radix Sort can be found in almost any books on algorithms /********** Radix Sort Source *************************/ #define MAC #ifdef MAC #define BYTE0 3 #define BYTE1 2 #define BYTE2 1 #define BYTE3 0 #endif // for PC's or any other Big Endian... #ifdef PC #define BYTE0 0 #define BYTE1 1 #define BYTE2 2 #define BYTE3 3 #endif #define kNumElements 500 // allocate space for 500 longs at a time #define kNumPasses 4 // 32 bit longs - split into 4 * 8 bits #define kNumBuckets 256 // require 256 buckets #define kMaxBuffer 100 // sort at most 100 * 500 = 50000 items typedef long Buffer[kNumElements]; // we don't want to hammer the memory manager typedef Buffer *BufferPtr; // so we allocate space for 500 longs typedef struct { BufferPtr theBuffers[kMaxBuffer]; // hold the items as they are added long numItems; // how many (filled) buffers have we got? long current; // where does next item go? } Bucket, *BucketPtr; static BucketPtr theBuckets[kNumBuckets]; // our buckets... // allocate space for the buckets and init void SetupBuckets(void) { long i, k; for (i = 0; i < kNumBuckets; i++) { theBuckets[i] = (BucketPtr) NewPtr(sizeof(Bucket)); for (k = 0; k < kMaxBuffer; k++) theBuckets[i]->theBuffers[k] = NULL; theBuckets[i]->numItems = 0; theBuckets[i]->current = 0; } } // We're done, release memory void ClearBuckets(void) { long i, k; for (i = 0; i < kNumBuckets; i++) { for (k = 0; theBuckets[i]->theBuffers[k] != NULL; k++) { DisposPtr((Ptr) theBuckets[i]->theBuffers[k]); } DisposPtr((Ptr) theBuckets[i]); } } // Stuff what we've put into the buffers back into the array and release mem. void CopyBuckets(long theArray[]) { register long i, j, k, l, count; count = 0; for (i = 0; i < kNumBuckets; i++) { for (j = 0; j <= theBuckets[i]->numItems; j++) // number of filled buffers { if (j < theBuckets[i]->numItems) l = kNumElements; //full buffer else l = theBuckets[i]->current; //partially full for (k = 0; k < l; k++) { theArray[count] = (*theBuckets[i]->theBuffers[j])[k]; count++; } if (theBuckets[i]->theBuffers[j]) { free((void *) theBuckets[i]->theBuffers[j]); theBuckets[i]->theBuffers[j] = NULL; } } theBuckets[i]->numItems = 0; theBuckets[i]->current = 0; } } void RadixSort(long theArray[], long numItems) { register long i, k; register unsigned char c; short Offset[kNumPasses] = {BYTE0,BYTE1,BYTE2,BYTE3}; unsigned char *p; long mem, waste; mem = FreeMem(); SetupBuckets(); for (i = 0; i < kNumPasses; i++) { for (k = 0; k < numItems; k++) { p = (unsigned char *) &theArray[k] + Offset[i]; c = *p; if (!theBuckets[c]->theBuffers[theBuckets[c]->numItems]) { theBuckets[c]->theBuffers[theBuckets[c]->numItems] = (BufferPtr) malloc(sizeof(Buffer)); theBuckets[c]->current = 0; } (*theBuckets[c]->theBuffers[theBuckets[c]->numItems])[theBuckets[c]->current] = theArray[k]; theBuckets[c]->current++; if (theBuckets[c]->current >= kNumElements) { theBuckets[c]->numItems++; theBuckets[c]->current = 0; } } CopyBuckets(theArray); } ClearBuckets(); waste = mem - FreeMem(); } +-----------------------------------------------------------------+ |Chris Reid e-mail: cr@cs.strath.ac.uk | |Dept. Computer Science, Strathclyde University, Glasgow, Scotland| +-----------------------------------------------------------------+ +++++++++++++++++++++++++++ >From pcastine@jake.prz.tu-berlin.de (Peter Castine) Date: Mon, 6 Jun 1994 14:42:31 GMT Organization: PRZ TU-Berlin cr@cs.strath.ac.uk (Chris Reid) writes: > >Hi everybody, > >I have written some code that implements Radix Sort (it sorts >an array of longs in linear time). It seems to work well enough, >but one thing is really strange: when I replace the NewPtr() >calls with calls to malloc(), the corresponding free() doesn't seem >to work. Here's roughly what happens: > [stuff deleted] Well, as I remember, malloc() calls _NewPtr, but free() (at least in the THINK C implementation) does not (necessarily) call _DisposPtr. The malloc/free implementation does some of its own store management. So, what you're seeing is not (ahem, necessarily) a memory leak. Check the sources of malloc() and free() for details. BTW, I've seen some code that checks the endian-ness of the machine at runtime. This might be a better idea than depending upon MAC or PC being #defined. The trick is to store an arbitrary value (like 0x1234) into a short, and looking at the first byte (by typecasting the address of the variable to a char*). Just a suggestion. Cheers, -- Peter Castine | Dr. Who quote du jour: pcastine@prz.tu-berlin.de | Have you noticed the way people's ===========================| intelligence capabilities decline sharply ``Have Mac, will travel'' | the minute they start waving guns around? +++++++++++++++++++++++++++ >From isis@netcom.com (Mike Cohen) Date: Mon, 6 Jun 1994 17:05:40 GMT Organization: ISIS International cr@cs.strath.ac.uk (Chris Reid) writes: >// RadixSort implemented using malloc() and free() >mem = FreeMem(); // We've got amount 'mem' bytes in the heap >RadixSort(someArray, numItems); // Do the sorting >waste = mem - FreeMem(); // Is there a memory leak? >waste is non-zero, a very disturbing fact. But it gets even better, >because on consecutive calls, waste IS zero. It looks as if >malloc() remebers what it's done before. By the way, I need to >use malloc() because the code has to be (sort of) platform independent. In most implementations of malloc/free, rather than simply calling NewPtr & DisposePtr directly, they will allocate a larger pool calling NewPtr as necessary and then manage the space in that pool. In most cases, this pool storage won't be returned to the mac memory manager, but will remain available for future malloc() calls. Therefore, FreeMem() will report that storage was lost. -- Mike Cohen - isis@netcom.com NewtonMail, eWorld: MikeC / ALink: D6734 / AOL: MikeC20 Home Page: file://ftp.netcom.com/pub/isis/home.html +++++++++++++++++++++++++++ >From Jens Alfke Date: Mon, 6 Jun 1994 21:11:22 GMT Organization: Apple Computer Chris Reid, cr@cs.strath.ac.uk writes: > waste is non-zero, a very disturbing fact. But it gets even better, > because on consecutive calls, waste IS zero. It looks as if > malloc() remebers what it's done before. By the way, I need to > use malloc() because the code has to be (sort of) platform independent. This is a very Frequently Asked Question. malloc and free as implemented by the ANSI library (on all know Mac development systems) grab large blocks of memory via NewPtr, then suballocate those blocks for successive mallocs. These large blocks don't get returned -- it would be difficult to figure out when to return them. But the memory in them does get re-used by malloc if you free it. Think of it as if malloc and free create a new heap from which to allocate memory. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From hall_j@sat.mot.com (Joseph Hall) Date: Mon, 6 Jun 1994 18:48:45 GMT Organization: Motorola Inc., Satellite Communications Seems it was cr@cs.strath.ac.uk (Chris Reid) who said: >Hi everybody, > >I have written some code that implements Radix Sort (it sorts >an array of longs in linear time). It seems to work well enough, >but one thing is really strange: when I replace the NewPtr() >calls with calls to malloc(), the corresponding free() doesn't seem >to work. Here's roughly what happens: It used to be that THINK C's free() just didn't free blocks. It was meant to work that way. I don't recall whether it didn't free any blocks or whether it only freed blocks larger than a certain size. MPW's malloc(), on the other hand, was busted around 3.0 or 3.1. Do some malloc-ing and some free-ing and eventually it would crash. I don't know whether that was ever fixed, though I reported it. I suggest that you use NewPtr() on the Mac to obtain memory, then manage it with a memory allocator of your own. The Aho/Hopcroft/ Ullman algorithms book has a section on allocators, or you could just make allocations of the desired size with NewPtr(). You can always obtain a separate zone to work with, too, which makes it easy to free a whole bunch of stuff en masse. -- Joseph Nathan Hall | Joseph's Law of Interface Design: Never give your users Software Architect | a choice between the easy way and the right way. Gorca Systems Inc. | joseph@joebloe.maple-shade.nj.us (home) (on assignment) | (602) 732-2549 (work) Joseph_Hall-SC052C@email.mot.com +++++++++++++++++++++++++++ >From Mark Hanrek Date: Wed, 8 Jun 1994 00:53:17 GMT Organization: The Information Workshop It seems to me that one should be able to copy the source code for malloc() and free() into their project, and then determine how to modify it to actually free the memory that was originally malloc'd. This is what I figure I am going to have to do, because I just discovered that when I made this routine into a code resource (XCMD) which will run within HyperCard, it used malloc, and I absolutely must return that memory, and there is no way I could possibly convert the source code to using NewPtr without opening a Pandora's Box. It's just too complex. Mark Hanrek +++++++++++++++++++++++++++ >From ray@sfu.ca (Ray Davison) (Ray Davison) Date: Fri, 10 Jun 1994 22:34:46 GMT Organization: Simon Fraser University In article , Mark Hanrek wrote: > It seems to me that one should be able to copy the source code for > malloc() and free() into their project, and then determine how to modify > it to actually free the memory that was originally malloc'd. > > This is what I figure I am going to have to do, because I just discovered > that when I made this routine into a code resource (XCMD) which will run > within HyperCard, it used malloc, and I absolutely must return that > memory, and there is no way I could possibly convert the source code to > using NewPtr without opening a Pandora's Box. It's just too complex. I once needed to use some Unix code and also didn't want it to use malloc and free. All I did was include the following in the source: #define free(p) DisposPtr((Ptr)(p)) #define calloc(s,n) ((void *)NewPtrClear(s*n)) #define malloc(s) ((void *)NewPtr(s)) Worked fine for me. -- Ray Davison ray@sfu.ca +++++++++++++++++++++++++++ >From pcastine@tubprz.prz.tu-berlin.de (Peter Castine) Date: Sun, 12 Jun 1994 15:28:36 GMT Organization: PRZ TU-Berlin ray@sfu.ca (Ray Davison) (Ray Davison) writes: > >I once needed to use some Unix code and also didn't want it to use malloc >and free. All I did was include the following in the source: > >#define free(p) DisposPtr((Ptr)(p)) >#define calloc(s,n) ((void *)NewPtrClear(s*n)) ~~~~~ >#define malloc(s) ((void *)NewPtr(s)) > >Worked fine for me. Just on principle, it might be a better idea to put parentheses around s and n in the macro {to wit: NewPtrClear((s)*(n)) }. It is, admittedly, a little rare to have complicated expressions as parameters to calloc, but 't can happen. Picky me ;-} -- Peter Castine | Dr. Who quote du jour: pcastine@prz.tu-berlin.de | Have you noticed the way people's ===========================| intelligence capabilities decline sharply ``Have Mac, will travel'' | the minute they start waving guns around? --------------------------- >From Jake_V._Bouvrie@bcsmac.org (Jake V. Bouvrie) Subject: Closing Down the FINDER Date: Sun, 5 Jun 94 11:52:50 EST Organization: (none) Is it possible to quit the finder from your app, so that there isn't a finder to go to ? +++++++++++++++++++++++++++ >From mclow@coyote.csusm.edu (Marshall Clow) Date: 5 Jun 1994 10:33:24 -0700 Organization: California State University San Marcos Jake V. Bouvrie (Jake_V._Bouvrie@bcsmac.org) wrote: >Is it possible to quit the finder from your app, >so that there isn't a finder to go to ? Sure, send it a 'quit' apple event. Under system 6 it's harder. Marshall Clow Aladdin Systems mclow@san_marcos.csusm.edu +++++++++++++++++++++++++++ >From kenlong@netcom.com (Ken Long) Date: Sun, 5 Jun 1994 18:19:43 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Do you mean in code or in practice? -Ken- +++++++++++++++++++++++++++ >From grobbins@apple.com (Grobbins) Date: 5 Jun 1994 17:03:01 -0700 Organization: Skunkworks In article <2st294$phj@coyote.csusm.edu>, Marshall Clow wrote: >Jake V. Bouvrie (Jake_V._Bouvrie@bcsmac.org) wrote: >>Is it possible to quit the finder from your app, >>so that there isn't a finder to go to ? >Sure, send it a 'quit' apple event. Not so fast; there are issues to consider. Pasted below is the discussion from the Finder Q&A tech note (TB 535). Grobbins grobbins@apple.com Usual disclaimers apply. ______ from Macintosh Technical Note TB 535 - Finder Q&As: Quitting System 7 Finder Date Written: 4/17/92 Last reviewed: 6/14/93 I've been thinking of shutting down the System 7 Finder. Is this a cool thing to do in my application? ___ We normally recommend that you don't quit the System 7 Finder application. Nevertheless, there may be a few good reasons to shut down the Finder. For example, the Installer (the only application Apple ships with a good reason to do so) sometimes needs to shut down the Finder and all other applications to make sure system resources aren't being used while they're being updated by the Installer. If you find yourself in a situation where you need to shut down the Finder, you should know about a few things: * Before you shut down the System 7 Finder, use the Process Manager to see if the File Sharing Extension is running. If so, you should shut it down before shutting down the Finder. The File Sharing Extension shouldn't be running without the Finder because the Finder is the only user interface the File Sharing Extension has. You shouldn't take away the user interface to file sharing. There's another good reason to shut down the File Sharing Extension before the Finder. The Network Extension (not the Network control panel) handles all the user interface transactions among the Finder, the File Sharing Monitor control panel, the Sharing Setup control panel, the Users & Groups control panel, and the File Sharing Extension (the file server). The Network Extension opens another file, the Users & Groups Data File, so that it can manipulate users and groups. When you shut down the Finder (with a kAEQuitApplication Apple event), the Network Extension and its connection to the Users & Groups Data File are also closed (almost). Because of a minor bug in the system, the File Manager thinks that the file is closed and that the FCB used by that access path is free for reuse; however, the File Sharing Extension thinks the access path to the Users & Groups Data File from the Network Extension is still open. When the File Manager attempts to reuse that FCB to open another file later, the file is opened, but because the File Sharing Extension thinks that FCB is still in use by the Network Extension, it won't allow access to the file and it returns opWrErr (-49) to the Open call. At this point, the file that someone was attempting to open can't be accessed or closed. * If the Finder is shut down and then eventually relaunched, there may be some fragmentation of the MultiFinder heap. This can occur because the Finder is the first application to be started, so it's always first in the MultiFinder heap. When you shut it down, that memory becomes available and other processes might occupy that space. When the Finder is restarted, if it can't get into its original space in the MultiFinder heap, it will get loaded somewhere else and probably won't be shut down again. * In System 7, the Finder is responsible for filling the Apple menu with the items in the Apple Menu Items folder. When the Finder is gone, so are the Apple menu items, including things that are important to most users (like control panels). * If the user has selected background printing with a LaserWriter or StyleWriter, nothing will print while the Finder is gone. That's because the Finder is responsible for monitoring the PrintMonitor Documents folder and launching the PrintMonitor application when necessary. +++++++++++++++++++++++++++ >From Jake_V._Bouvrie@bcsmac.org (Jake V. Bouvrie) Date: Sun, 5 Jun 94 21:31:29 EST Organization: (none) >Do you mean in code or in practice? Well, i mean in Code, like i call it in my program.... +++++++++++++++++++++++++++ >From David_B._Lamkins@bmugbost.uu.holonet.net Date: Wed, 08 Jun 1994 14:29:18 EST Organization: BMUG Boston Jake_V._Bouvrie@bcsmac.org (Jake V. Bouvrie) wrote: >Is it possible to quit the finder from your app, so that there >isn't a finder to go to ? Yes. Assuming you don't mind that it's not a nice thing to do, you can use Process Manager calls (see IM VI or whatever new world volume has it) to kill the Finder. You should also kill the background process that the File Sharing extension runs when sharing is turned on - to do otherwise risks corrupting the Users & Groups file. This won't get rid of the Finder forever - it will restart as soon as all other applications quit. Dave -BMUG Boston 617-721-5840, East Coast BBS of The World's Largest Mac User Group +++++++++++++++++++++++++++ >From wombat@claris.com (Scott Lindsey) Date: Wed, 08 Jun 1994 20:14:43 -0800 Organization: Claris Corporation, Vancouver WA In article <2stp3l$kf@apple.com>, grobbins@apple.com (Grobbins) wrote: > In article <2st294$phj@coyote.csusm.edu>, > Marshall Clow wrote: > >Jake V. Bouvrie (Jake_V._Bouvrie@bcsmac.org) wrote: > >>Is it possible to quit the finder from your app, > >>so that there isn't a finder to go to ? > >Sure, send it a 'quit' apple event. > > Not so fast; there are issues to consider. Pasted > below is the discussion from the Finder Q&A tech note > (TB 535). > Not to mention that PowerTalk has certain Finder dependencies. There's lots of things that don't work if the Finder isn't running (or even if it gets relaunched!) We ran into problems just using Apple's Installer. After the Finder restarts, PowerTalk gets in a funny state where it's basically useless. -- Scott Lindsey Std. disclaimer: my opinions, not Claris', not Apple's. --------------------------- >From "Andrew C. Plotkin" Subject: Fat-stripping Date: Thu, 2 Jun 1994 14:52:31 -0400 Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA Which is to say, cutting a fat binary down to a 68K executable, thus saving space. And the parallel operation of cutting a fat binary down to a PowerMac executable. Someone must have written a tiny app to do this. Someone? Anyone? I just downloaded JPEGview 3.3, which is wonderful, but it looks like I can save half the disk space it takes up. This situation will continue to aggravate as fat binaries catch on. (Reassurance: obviously, if I give anyone a copy of a shareware program which I have fat-stripped, I am obligated to tell them that fact and point them at an unadulterated version if they want it. Also, some shareware packages prohibit distributing altered copies at all, and this would certainly count as alteration. I think a well-behaved fat-stripper would append "68K" or "PMac" to the executable file name.) If nobody has written this thing, I guess I will. The fat->68K stripper, anyhow. Unless it's non-trivial (which I guess is the only reason for it not being written.) Can one just reduce the data fork of the APPL to zero length, or is it trickier? --Z +++++++++++++++++++++++++++ >From tgaul@halcyon.com (Troy Gaul) Date: Fri, 03 Jun 1994 00:04:49 -0800 Organization: Infinity Systems In article , "Andrew C. Plotkin" wrote: > Which is to say, cutting a fat binary down to a 68K executable, thus > saving space. And the parallel operation of cutting a fat binary down to > a PowerMac executable. > > Someone must have written a tiny app to do this. Someone? Anyone? I just > downloaded JPEGview 3.3, which is wonderful, but it looks like I can > save half the disk space it takes up. This situation will continue to > aggravate as fat binaries catch on. > > (Reassurance: obviously, if I give anyone a copy of a shareware program > which I have fat-stripped, I am obligated to tell them that fact and > point them at an unadulterated version if they want it. Also, some > shareware packages prohibit distributing altered copies at all, and this > would certainly count as alteration. I think a well-behaved fat-stripper > would append "68K" or "PMac" to the executable file name.) > > If nobody has written this thing, I guess I will. The fat->68K stripper, > anyhow. Unless it's non-trivial (which I guess is the only reason for it > not being written.) Can one just reduce the data fork of the APPL to > zero length, or is it trickier? I've written such a thing, mostly, anyway. This type of program is much more complicated than it may first appear. The main reason I haven't released/finished mine is that I'm somewhat worried about the liability if the stripping process damages someone's application. And it might be that the stripping will work fine, but if they try to run it later on the other type of machine, it might do something bad (rather than just fail to work). This could be a problem that would take months, even years to develop, so the original copy might have been around for easy restoration. Also, stripping 68K code is practically impossible to do safely for various reasons. _troy gaul infinity systems +++++++++++++++++++++++++++ >From tgaul@halcyon.com (Troy Gaul) Date: Sat, 04 Jun 1994 22:14:44 -0700 Organization: Infinity Systems In article , scouten@maroon.tc.umn.edu (Eric Scouten) wrote: > You don't really have that much to worry about. If you're writing to strip > PowerPC code, you only have to read the 'cfrg' resource, find out where the > PowerPC code is, and get rid of it. In almost all cases, it will be in the > data fork -- though it is possible to put it in resources (or a *part* of > the data fork). Such cases are *very* rare, and unsupported by at least two > of the three major PowerPC development systems. > > If you strip the PPC code properly, you can still launch the application on > a PPC machine; it'll just run in emulation mode instead. (Just be sure you > also remove the 'cfrg' resource!) My program actually parses the 'cfrg' resource, and it is aware of the types of the blocks, etc. (for instance, when the Code Fragment Manager is implemented on 68K, it won't remove those). The problem with stripping 68K code is that a PowerPC application might need some of the code resources if it has only been partially ported, and this is not described in the 'cfrg' resource or anywhere else. _troy //////// //////___Troy Gaul_________________________tgaul@halcyon.com__ // // // Infinity Systems ; Redmond, Washington // // // // "Insert witty quote here." // // //////________________________________________________________ // +++++++++++++++++++++++++++ >From "Andrew C. Plotkin" Date: Mon, 6 Jun 1994 10:41:25 -0400 Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA Thanks to everyone who replied. The generic answer seems to be "get IM-PPC System Software and look up the 'cfrg' resource," which I will do as soon as my other fifty-seven projects allow me some spare time. --Z "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..." +++++++++++++++++++++++++++ >From Ron_Hunsinger@bmug.org (Ron Hunsinger) Date: Sun, 12 Jun 94 08:55:52 PST Organization: Berkeley Macintosh Users Group scouten@maroon.tc.umn.edu (Eric Scouten) writes: >If you strip the 68K code properly, you can of course launch on a PPC >machine. If you attempt to launch such an app on a 68K machine, the Finder >will give you an error box saying something like "The application could not >be launched because an error of type -192 occurred." (-192 is resource not >found, probably the 'CODE 1' resource) This is harmless; it just means you >won't be able to use the app. (Unless they ever come out with PowerPC >emulation on 68K... snicker snicker!) Or, you could substitute for the 68k code a tiny 68k program that puts up an alert saying "This program will not run on your machine because it has been customized for PowerMac execution only." Then you don't have to explain what "an error of type -192" means. -Ron Hunsinger --------------------------- >From eshieh@volga.EECS.Berkeley.EDU (Eric Shieh) Subject: Finder Comments and Finder Info Updating Date: 9 Jun 1994 21:48:21 GMT Organization: University of California, Berkeley Hello all, there are a few minor quirks I'm trying to fix in my program. First, how do you get the comments off of a floppy disk???IM VI says it doesn't use the Desktop Manager for volumes < 2 megs, so you cant use PBDTGetComment...I tried using the Morefiles routine, but it doesn't seem to like floppies either... Second problem: Is there any way to have the Finder update a file's label? On a Powermac, whenever I set the label, then do a GetFInfo, the old label is still returned, only when I close and re-open the folder does the label get correctly set. I tried "touching" the folder (usually used for updating a file's icons) to no avail. This is annoying cuz my program can read the label, but if the user changes it, then immediately give it to my program, it'll read the old label still... Thanks, Eric eshieh@cory.berkeley.edu +++++++++++++++++++++++++++ >From leonardr@netcom.com (Leonard Rosenthol) Date: Sun, 12 Jun 1994 23:13:14 GMT Organization: Aladdin Systems, Inc. In article <2t82n5$9g0@agate.berkeley.edu>, eshieh@volga.EECS.Berkeley.EDU (Eric Shieh) wrote: > Hello all, there are a few minor quirks I'm trying to fix in my program. > First, how do you get the comments off of a floppy disk???IM VI says > it doesn't use the Desktop Manager for volumes < 2 megs, so you cant > use PBDTGetComment...I tried using the Morefiles routine, but it doesn't > seem to like floppies either... > Correct. Floppies (volumes < 2 meg) use the old Sys6 style DTDB for which there were no API calls for accessing the information. Your only option, if you MUST support it, is to figure out the format of the old DTDB files and then read/write them... > Second problem: Is there any way to have the Finder update a file's label? > Not w/o a bunch of weird trap patches, nope. The problem is that the Finder keeps certain things in an internal "cache" and doesn't go back to disk (or doesn't flush it to disk) that often. There is also no (easy/approved/documented) way to get the Finder to flush the cache, or reload the data. There is an Apple event in the new Scriptable Finder that allows you to force an "update" on a file, but that doesn't help in all cases. Leonard - ------------------------------------------------------------------------ Leonard Rosenthol Internet: leonardr@netcom.com Director of Advanced Technology AppleLink: MACgician Aladdin Systems, Inc. GEnie: MACgician --------------------------- >From Neil Ticktin Subject: MacTech's ftp site now available! Date: Thu, 9 Jun 1994 05:09:17 GMT Organization: MacTech Magazine/Xplain Corp. To all, By popular demand (mostly from you folks on comp.sys.mac.programmer), we've now established our ftp site. To get to our files, do an anonymous ftp to ftp.netcom.com and change directories to /pub/xplain -- there you'll see our latest files. In this site, we will regularly post the most recent 3 months of source code to accompany the articles in the magazine. That way, you can download the info and play with the code as soon as you get the magazine. This brings our Internet support inline with our support on America Online, CompuServe and AppleLink. Please let us know if you have any suggestions. Hope it helps, Neil Ticktin MacTech Magazine - --------------------------------------------------------------------- Neil Ticktin, MacTech Magazine (formerly MacTutor) PO Box 250055, Los Angeles, CA 90025 * 310-575-4343 * Fax: 310-575-0925 For more info, anonymous ftp to ftp.netcom.com and cd to /pub/xplain custservice@xplain.com * editorial@xplain.com * adsales@xplain.com marketing@xplain.com * accounting@xplain.com * pressreleases@xplain.com progchallenge@xplain.com * publisher@xplain.com * info@xplain.com --------------------------- >From Willie Abrams Subject: QuickDraw GX Display Devices Date: 6 Jun 1994 19:03:50 GMT Organization: OU Health Sciences Center In working with GX, I was wondering - When the graphics system gets loaded, I assume GX walks the list of GDevices known to QuickDraw, and creates viewDevices for them... Would it be possible to have GX draw to a display that was not known to QuickDraw? That is, can GX recognize "GX" only display hardware? And since GX does allow for the definition and storage of 48 bit per pixel data, could GX drive a special display board to help drive us past the 8 bit grayscale ceiling. Maybe 16 bit grayscale boards? :-) This does have an application, really. Many people in the medical imaging industry and some of our customers (radiologists, etc.) believe that even though we have been taught that the human eye can detect no more that 256 shades of any given tone, that the ability to see 12 bits to 16 bits of data is worthwhile and can make a difference on diagnosis. Willie Abrams Telemedicine Software Guy Internet: willie-abrams@uokhsc.edu OU Health Sciences Center AppleLink: Willie +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 8 Jun 94 16:39:22 +1200 Organization: University of Waikato, Hamilton, New Zealand In article <2svrum$dff@romulus.ucs.uoknor.edu>, Willie Abrams writes: > > When the graphics system gets loaded, I assume GX walks the > list of GDevices known to QuickDraw, and creates viewDevices > for them... > > Would it be possible to have GX draw to a display that was not > known to QuickDraw? That is, can GX recognize "GX" only display > hardware? GX can draw to offscreen ViewDevices, just like QuickDraw supports offscreen GWorlds. They're easy to set up. You can even set up offscreen ViewGroups (like the set of all screen devices is a ViewGroup), so you can draw a single shape to multiple offscreen ViewDevices with a single GXDrawShape call. > And since GX does allow for the definition and storage of 48 bit > per pixel data, could GX drive a special display board to help > drive us past the 8 bit grayscale ceiling. Maybe 16 bit grayscale > boards? :-) Unfortunately, last I checked in the (beta) documentation, GX cannot draw _to_ a destination that has more than 8 bits per pixel component. I think it can only read _from_ such a bitmap. In short, you can certainly create and manipulate such a structure yourself, no problem. And you can even get GX to display and print it (to within the limits of your output hardware) once you've done. But GX will only be of limited help with the manipulations. Lawrence D'Oliveiro fone: +64-7-856-2889 Info & Tech Services Division fax: +64-7-838-4066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 +++++++++++++++++++++++++++ >From Cary Clark Date: Wed, 8 Jun 1994 04:42:51 GMT Organization: Apple Computer, Inc. In article <2svrum$dff@romulus.ucs.uoknor.edu> Willie Abrams, willie-abrams@uokhsc.edu writes: >Would it be possible to have GX draw to a display that was not >known to QuickDraw? That is, can GX recognize "GX" only display >hardware? Yes. An application can create a device in with the gxScreenViewDevices viewGroup (1), and then it will be treated like all other physical devices. If nil is passed for the mapping to GXSetViewDeviceMapping, the device will be located adjacent to but not overlapping the other physical devices. >And since GX does allow for the definition and storage of 48 bit >per pixel data, could GX drive a special display board to help >drive us past the 8 bit grayscale ceiling. Maybe 16 bit grayscale >boards? :-) Sorry, but GX does not allow for pixel sizes greater than 32 bits. Nor does it provide for 16 bits/pixel grayscale. But both of these are fine enhancement requests for version 2.0. Cary Clark Apple Computer, Inc. --------------------------- >From kaltwasc@ucs.orst.edu (Chris Kaltwasser) Subject: SEMI-SUMMARY: Reading JPEGs (with code) Date: 8 Jun 1994 03:45:29 GMT Organization: Oregon State University, Corvallis Hello all, A while ago, I asked for a little help/advice on decompressing JPEGs from JFIF files using QuickTime, and I'm very pleased to be able to report success. For the benefit of the Mac programming community, here is the product of my efforts: This routine reads a JPEG file into an offscreen GWorld. It would not be too difficult to modify it to use an onscreen port instead. It assumes you've already checked for QuickTime and so forth. Permission is given to use this code for non-commercial purposes. Use at your own risk. - ------------------Cut Here-------------------- //______________________________________________________________________ // // Code for reading and writing JFIF files for SSConverter 1.4.1 // // Copyright (c)1994 by Chris Kaltwasser. All rights reserved. // //______________________________________________________________________ #include #include #define JFIF_ID_MARKER 0xE0 #define JFIF_INFO_MARKER 0xC0 OSErr ReadJPEGFile(FSSpec *spec, GWorldPtr *gw) { Rect srcRect; GDHandle gdh; PixMapHandle pix; ImageDescriptionHandle descH; CGrafPtr port; Byte *data = NULL, *s, id[5] = "JFIF"; long length, i; short j, refnum, err, width, height; if (*gw) DisposeGWorld(*gw); *gw = NULL; err = FSpOpenDF(spec, fsRdPerm, &refnum); if (!err) { err = GetEOF(refnum, &length); if (!err && length < 170L) err = kReadFailErr; if (!err) { data = (Byte*)NewPtr(length); if (!data) err = memFullErr; } if (!err) err = FSRead(refnum, &length, data); FSClose(refnum); } if (!err) { /* make sure data is JFIF data stream */ for (i = 0; i < length; ++i) if (data[i] == 0xFF && data[i+1] == JFIF_ID_MARKER) { for (s = &data[i+4], j = 0; j < 5; ++s, ++j) if (*s != id[j]) { err = kBadJFIFErr; j = 5; } i = length; } if (err) goto abortJPEG; /* read JPEG height and width from JFIF stream */ err = kBadJFIFErr; for (i = 0; i < length; ++i) if (data[i] == 0xFF && data[i+1] == JFIF_INFO_MARKER) { height = data[i+5]*256 + data[i+6]; width = data[i+7]*256 + data[i+8]; err = noErr; i = length; } if (!err) { srcRect.top = 0; srcRect.left = 0; srcRect.bottom = height; srcRect.right = width; err = NewGWorld(gw, 24, &srcRect, NULL, NULL, 0); GetGWorld(&port, &gdh); SetGWorld(*gw, NULL); ClipRect(&srcRect); ForeColor(blackColor); BackColor(whiteColor); descH = (ImageDescriptionHandle)NewHandle(sizeof(ImageDescription)); HLock((Handle)descH); (**descH).idSize = sizeof(ImageDescription); (**descH).cType = 'jpeg'; (**descH).resvd1 = 0L; (**descH).resvd2 = 0; (**descH).dataRefIndex = 0; (**descH).version = 1; (**descH).revisionLevel = 1; (**descH).vendor = 'appl'; (**descH).temporalQuality = 0; (**descH).spatialQuality = 0; (**descH).width = width; (**descH).height = height; (**descH).vRes = (**descH).hRes = Long2Fix(72L); (**descH).dataSize = length; (**descH).frameCount = 1; BlockMove("\pPhoto - JPEG", (**descH).name, 32L); (**descH).depth = 24; (**descH).clutID = -1; HUnlock((Handle)descH); pix = GetGWorldPixMap(*gw); if (LockPixels(pix)) { err = DecompressImage((Ptr)data, descH, pix, &srcRect, &srcRect, srcCopy, NULL); UnlockPixels(pix); } else err = memFullErr; SetGWorld(port, gdh); /* restore port and device */ DisposeHandle((Handle)descH); } } abortJPEG: if (data) DisposePtr((Ptr)data); return err; } --------------------------- >From euajgo@eua.ericsson.se (Joakim Grebeno) Subject: VBL interrupt & Stack Sniffer Date: 10 Jun 1994 07:53:37 GMT Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden I can't, over my dead body, find the information describing how to enable/disable the stack sniffer! It is supposed to be done by toggling a number of system globals but I can't find the info neither in IM 1-6 nor in the technotes! I have the same problem to find which slot in the exception table the VBL interrupt occupies! Any experiences? Thanks in advance! Joakim -- Joakim Grebenoe +++++++++++++++++++++++++++ >From bwade@graphics.cornell.edu (Bretton Wade) Date: 10 Jun 1994 12:24:44 GMT Organization: Program of Computer Graphics -- Cornell University I did this once, there is only one low mem global (try 0x0110?) and it used to have the name StackLowPt, but I can't find it in the headers anymore. anyway, just write a zero to that location to disable the sniffer. BTW, it seems that the thread manager extension from apple already disables the sniffer on a global basis. can anybody substantiate this? Protected mem would be a better scheme... -- _______________________________________________________________________________ Bretton Wade (bw16@cornell.edu) Program of Computer Graphics 580 Engineering and Theory Center Cornell University Ithaca, NY 14853 Voice: (607) 255-6704 Fax: (607) 255-0806 _______________________________________________________________________________ +++++++++++++++++++++++++++ >From ari@world.std.com (Ari I Halberstadt) Date: Fri, 10 Jun 1994 15:51:26 GMT Organization: The World Public Access UNIX, Brookline, MA In article <2t9661$fds@euas20.eua.ericsson.se>, Joakim Grebeno wrote: >I can't, over my dead body, find the information describing how to >enable/disable the stack sniffer! It is supposed to be done by toggling >a number of system globals but I can't find the info neither in IM 1-6 >nor in the technotes! Set the low-memory global StkLowPt to 0. -- Ari Halberstadt ari@world.std.com One generation passes away, and another generation comes: but the earth abides for ever. -- Ecclesiastes, 1:4. +++++++++++++++++++++++++++ >From ari@world.std.com (Ari I Halberstadt) Date: Fri, 10 Jun 1994 15:52:52 GMT Organization: The World Public Access UNIX, Brookline, MA In article <2t9m2c$e6a@merckx.graphics.cornell.edu>, Bretton Wade wrote: >BTW, it seems that the thread manager extension from apple already disables >the sniffer on a global basis. can anybody substantiate this? Protected mem >would be a better scheme... The last version of the TM (pre-2.0) that I checked just set StkLowPt to zero. -- Ari Halberstadt ari@world.std.com One generation passes away, and another generation comes: but the earth abides for ever. -- Ecclesiastes, 1:4. +++++++++++++++++++++++++++ >From brad@tazboy.jpl.nasa.gov (Brad Pickering) Date: 10 Jun 1994 17:59:29 GMT Organization: Jet Propulsion Laboratory, Pasadena, CA In article <2t9661$fds@euas20.eua.ericsson.se> euajgo@eua.ericsson.se (Joakim Grebeno) writes: Path: elroy.jpl.nasa.gov!lll-winken.llnl.gov!sol.ctr.columbia.edu!howland.reston.ans.net!EU.net!sunic!sics.se!eua.ericsson.se!eua.ericsson.se!euajgo From: euajgo@eua.ericsson.se (Joakim Grebeno) Newsgroups: comp.sys.mac.programmer Date: 10 Jun 1994 07:53:37 GMT Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden Lines: 16 NNTP-Posting-Host: euas66c13.eua.ericsson.se Keywords: VBL, Stack Sniffer I can't, over my dead body, find the information describing how to enable/disable the stack sniffer! It is supposed to be done by toggling a number of system globals but I can't find the info neither in IM 1-6 nor in the technotes! Set the low memory global called 'StkLowPt' to 0. #include *(long *)StkLowPt = 0; I have the same problem to find which slot in the exception table the VBL interrupt occupies! I think this depends on which mac you have. On the original macs it is handled by the autoint1 vector (0x64), which calls some code that dispatches through the second entry of the level 1 dispatch table (Lvl1DT + 0x04). Some of this is documented in IM II pg 197. Brad Pickering +++++++++++++++++++++++++++ >From cverret@vub.ac.be (Verret Chris) Date: 11 Jun 1994 06:56:00 GMT Organization: Brussels Free Universities (VUB/ULB), Belgium Joakim Grebeno (euajgo@eua.ericsson.se) wrote: : I can't, over my dead body, find the information describing how to : enable/disable the stack sniffer! It is supposed to be done by toggling : a number of system globals but I can't find the info neither in IM 1-6 : nor in the technotes! The following did the trick for me: Ptr stkLowPt : 0x110; Ptr savedStkLowPt; savedStkLowPt = stkLowPt; stkLowPt = NULL; stkLowPt = savedStkLowPt; +++++++++++++++++++++++++++ >From jumplong@aol.com (Jump Long) Date: 12 Jun 1994 15:44:01 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <2t9661$fds@euas20.eua.ericsson.se>, euajgo@eua.ericsson.se (Joakim Grebeno) writes: >I can't, over my dead body, find the information describing how to >enable/disable the stack sniffer! I put a code snippet on the Developer CD called "Switch Stack" that shows how to let interrupt code run on a private stack. It also disables and re-enables the stack sniffer correctly. - Jim Luther --------------------------- >From Patrick.Stadelmann@etudiants.unine.ch Subject: Writing dcmd with Think C (Q) Date: 8 Jun 94 15:04:44 MET Organization: University of Neuchatel Hi ! Is it possible to write a dcmd with Think C ? If I include the .0 librairies in my project, I get link errors (like DATA_INIT undefined, or something like that). Is there a Think C port of these librairies available somewhere ? Thanks for your help Patrick +++++++++++++++++++++++++++ >From egurney@vcd.hp.com (Eddy J. Gurney) Date: Wed, 8 Jun 1994 17:30:28 GMT Organization: Hewlett-Packard VCD Patrick.Stadelmann@etudiants.unine.ch wrote: > Is it possible to write a dcmd with Think C ? If I include the .0 librairies > in my project, I get link errors (like DATA_INIT undefined, or something > like that). > Is there a Think C port of these librairies available somewhere ? Even if you do get your 'dcmd' to build under Think, you'll STILL need MPW to run the "BuildDCMD" Tool which Apple kindly supplies only as an MPW tool, without any source. I was about to try the same thing as you when I realized this "gotcha". However, if someone has come up with a method for building dcmd's under Think, I would love to hear about it. -- Eddy J. Gurney N8FPW Hewlett-Packard Company, Vancouver (USA!) Division egurney@vcd.hp.com #include "Failures are divided into two classes-- those who thought and never did, and those who did and never thought." John Charles Salak +++++++++++++++++++++++++++ >From eascharf@u.washington.edu (Elizabeth Scharf) Date: 9 Jun 1994 04:21:53 GMT Organization: University of Washington, Seattle I managed to get TC 5 to build dcmds by using custom headers. The main file looked like this: void CommandEntry (void); void main (void); void main (void) { asm { @valid_A4: dc.w 2 dc.w 0 lea @valid_A4,a0 bra CommandEntry } /* asm */ } (remember, for a custom header, put NOTHING else in this file!) The main dcmd entrypoint looked like this: #include #include "dcmd.h" pascal void CommandEntry ( dcmdBlock *paramPtr) { /* begin CommandEntry */ RememberA0(); SetUpA4(); switch (paramPtr->request) { ... } /* switch */ RestoreA4(); } /* end CommandEntry */ (and you even get globals!) I think I used oconv on the dcmdGlue.Lib, but it was a while ago... Hope this helps. rmgw This is not my account: Please address replies to hawkfish@aol.com Disclaimer: All views expressed are entirely my own and do not reflect the opinions of Elizabeth Scharf or the University of Washington. - --------------------------------------------------------------------------- Richard Wesley | A Capitalist is someone who | "Intel Inside" hawkfish@aol.com | knows the price of everything | is a warning 71062.1711@compuserve.com | and the value of nothing. | label... - --------------------------------------------------------------------------- --------------------------- End of C.S.M.P. Digest **********************