From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-097 Date: Mon, 8 May 1995 18:38:11 +0200 (MET DST) C.S.M.P. Digest Mon, 08 May 95 Volume 3 : Issue 97 Today's Topics: Answer to your SetDeskCPat Woes Here Extended Disk Initialization Manages woes How do UPP's work? Memory Allocation Question QuickDraw GX Fan Club Page (correct address !) Quicktime Musical Instruments Threads and Stacks 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 newsgroups comp.sys.mac.programmer.help, csmp.tools and csmp.misc. It is designed for people who read news 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. ------------------------------------------------------- >From fizzbomb@aol.com (FizzBomb) Subject: Answer to your SetDeskCPat Woes Here Date: Sun, 23 Apr 1995 13:58:04 -0400 Organization: Zyfno Zyne, Inc. Well, I don't know if you guys got your SetDeskCPat problems straightened out, but I have the answer right here. It comes to us from Craig Marciniak (templardev@aol.com), author of shareware sensation Before Dark. I tried it and it works! Enjoy! FizzBomb <--> fizzbomb@aol.com "And here it is" - ----------- The Trap is very stable - just poorly documented! here's what you need to do: SetZone(SystemZone()); sysdeskPixPat = GetPixPat(theID); if(sysdeskPixPat) { DetachResource((Handle)sysdeskPixPat); SetDeskCPat(sysdeskPixPat); } SetZone(ApplicZone()); Also make sure that the right bits are set on the ppat resource (sys and purge) so other applications that count on those attribute won't puke on your patterns - AND DON'T use your own compression method on standard ppat resources - make your own type... Craig Marciniak --------------------------- >From gspnx@di.unito.it (Fabrizio Oddone) Subject: Extended Disk Initialization Manages woes Date: Sat, 22 Apr 1995 12:05:35 +0200 Organization: Computer Science Faculty, Torino I got the File System Manager SDK a while ago and browsing around I found a useful chapter documenting a set of new system calls, namely: DIXFormat, DIXZero, etc. Problem: the Universal Headers (I am at 2.0a4) don't contain the function prototypes of the Extended Disk Initialization Manager calls. I am especially interested in calling DIXZero. I have tried lots of undocumented _Pack2 selectors, but haven't found the right one (and no, I don't want to spend days disassembling _Pack2 or trying selectors one by one ;-) ). Can some good soul point me towards some newer headers/docs? (Please use also private e-mail, besides posting) TIA, -- Fabrizio Oddone http://www.di.unito.it/pub/WWW/www_student/apple/FabrizioOddone/ +++++++++++++++++++++++++++ >From jumplong@aol.com (Jump Long) Date: 23 Apr 1995 12:46:41 -0400 Organization: America Online, Inc. (1-800-827-6364) >I got the File System Manager SDK a while ago and browsing around I >found a useful chapter documenting a set of new system calls, namely: >DIXFormat, DIXZero, etc. > >Problem: the Universal Headers (I am at 2.0a4) don't contain the >function prototypes of the Extended Disk Initialization Manager calls. I know. I asked to have them added back before the FSM SDK shipped, but there didn't get added until recently. Until then, these will work for 68K code development: extern pascal OSErr DIXFormat(short drvNum, Boolean fmtFlag, unsigned long fmtArg, unsigned long *actSize) THREEWORDINLINE(0x700C, 0x3F00, 0xA9E9); extern pascal OSErr DIXZero(short drvNum, ConstStr255Param volName, short fsid, short mediaStatus, short volTypeSelector, unsigned long volSize, void *extendedInfoPtr) THREEWORDINLINE(0x700E, 0x3F00, 0xA9E9); extern pascal OSErr DIReformat(short drvNum, short fsid, ConstStr255Param volName, ConstStr255Param msgText) THREEWORDINLINE(0x7010, 0x3F00, 0xA9E9); It should be easy enough to build routine descriptors and call these from PPC code, too. WARNING: DIXZero has a bug in current versions of the Disk Initialization Package. If you pass a non-zero value in the mediaStatus to DIXZero, it will call the Dialog Manager with a NULL DialogPtr (and that will likely crash your system). Until you see something telling you how to determine the problem has been fixed, don't call DIXZero with a non-zero mediaStatus value. - Jim Luther --------------------------- >From rba26@cas.org (Brad Andrews) Subject: How do UPP's work? Date: Wed, 19 Apr 1995 12:16:29 GMT Organization: Chemical Abstracts Service Could someone either explain to me exactly how UPP's work, or where I can find documentation on such? Do both 68K and PPC programs work well with such, or will I have to #ifdef my code for each processor? - - Brad Andrews randrews@cas.org All opinions are strictly mine +++++++++++++++++++++++++++ >From soori@netcom.com (Mahesh Sooriarachchi) Date: Wed, 19 Apr 1995 14:53:10 GMT Organization: Netcom Online Communications Services (408-241-9760 login: guest) In article <1995Apr19.121629.9113@chemabs.uucp> rba26@cas.org writes: You would create a UPP by calling NewRoutineDescriptor() or a bunch of different flavors of it, which ultimately calls NewRoutineDescriptor(). For instance, if you want a sound completion proc for playing sound from a file, you would call FilePlayCompletionUPP(yourProc). This would return you a FilePlayCompletionUPP which you can pass into SndStartFilePlay(). Once the sound has finished playing you can dispose the routine descriptor by calling DisposeRoutineDescriptor(). You should get the New Inside Mac book "PowerPC System Software" of something like that. >Could someone either explain to me exactly how UPP's work, or where I can find >documentation on such? Do both 68K and PPC programs work well with such, or will >I have to #ifdef my code for each processor? > >--- > >Brad Andrews >randrews@cas.org >All opinions are strictly mine > > -- MicroSloppy - Making it all make half ass sense. Where do you want to go today? None of your f$#*ing business. Mahesh Soori. My openions are mine, not of my employer! +++++++++++++++++++++++++++ >From jaks@netcom.com (Eric Jackson) Date: Thu, 20 Apr 1995 02:20:15 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) In article , Mahesh Sooriarachchi wrote: >In article <1995Apr19.121629.9113@chemabs.uucp> rba26@cas.org writes: > >You would create a UPP by calling NewRoutineDescriptor() or a bunch of >different flavors of it, which ultimately calls NewRoutineDescriptor(). >For instance, if you want a sound completion proc for playing sound from >a file, you would call FilePlayCompletionUPP(yourProc). This would return >you a FilePlayCompletionUPP which you can pass into SndStartFilePlay(). >Once the sound has finished playing you can dispose the routine >descriptor by calling DisposeRoutineDescriptor(). You should get the New >Inside Mac book "PowerPC System Software" of something like that. > > >>Could someone either explain to me exactly how UPP's work, or where I can find >>documentation on such? Do both 68K and PPC programs work well with such, or will >>I have to #ifdef my code for each processor? >> Also I don't know if you have found this out yet but you don't really need all that many UPP's in your code. One place that you will need one is in making a native call to TrackControl, and another place is in AEInstallEventHandler, but its only in places where you are passing a pointer to a procedure to another procedure that goes into the tool box that you even need to worry about UPP troubles. On the other hand when you are making a call from one procedure to another inside of your own code you can do this just the same way you always did. When you recompile your program with the universal headers you will get compiler errors because of the type changes so you just use the right functions to create your UPPs and your one your way. Good Luck Eric +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Fri, 21 Apr 1995 16:04:21 +1200 (NZDT) Organization: (none) rba26@cas.org (Brad Andrews) writes: > Could someone either explain to me exactly how UPP's work, or where I can find > documentation on such? Do both 68K and PPC programs work well with such, or will > I have to #ifdef my code for each processor? read Inside Macintosh: PowerPC System Software. UPP code works on both 68K and PPC because it is already #ifdef'd to do nothing on the 68K, unless you're using the 68K Code Fragment Manager (which you aren't, yet). UPP's work by always assuming that a proc ptr points at 68K code, and if it isn't really 68K code then it will start with a special A-trap opcode that switches you into the appropriate code type -- PPC or MIPS or PA-RISC or whatever (up to 256 different processor types can be used in a "fat" program). You could implement a "CallUPP" routine by simply switching to 68K mode and jumping to the ProcPtr, but of course it's much faster to check for the special opcode first to see whether you'd just get switched right back. -- Bruce --------------------------- >From dwilliss@tnt (Dave Williss) Subject: Memory Allocation Question Date: 11 Apr 1995 14:25:51 GMT Organization: MicroImages, Inc. I have a problem with the way the Macintosh allocates memory. It sucks! I have no idea how much memory the program will need. It depends entirely on what the user tries to do at runtime. If the user wants to process a really large image, they have to bump up the "Preferred Size" I looked into the possibility of using "Temporary Memory", but the Inside Macintosh section (2 pages) on this is rather vague. It says you can't leave a block of temporary memory locked when calling WaitNextEvent or GetNextEvent. Why not? Is there a simple memory allocation scheme that behaves more like malloc() under Unix? Also, is the malloc() in MPW slow? Is there a faster replacement? I have heard of faster malloc's that would allocate a larger chunk and manage them, but I havn't found one. -- David C. Williss #include Software Engineer -- MicroImages, Inc. dwilliss@microimages.com WWW: http://tnt.microimages.com/~dwilliss dwilliss@csealumni.unl.edu -- PGP Public Key available via finger from: dwilliss@csealumni.unl.edu -- +++++++++++++++++++++++++++ >From Alex Rosen Date: 11 Apr 1995 21:38:52 GMT Organization: Pro CD, Inc. In article <3me3hf$bfd@westie.mid.net> Dave Williss, dwilliss@tnt writes: > I looked into the possibility of using "Temporary Memory", but the > Inside Macintosh section (2 pages) on this is rather vague. It says > you can't leave a block of temporary memory locked when calling > WaitNextEvent or GetNextEvent. Why not? Is there a simple memory > allocation scheme that behaves more like malloc() under Unix? There are two reasons not to leave a temporary handle locked: (1) it can fragment the entire Mac memory, preventing the user from launching programs, and (2) Apple Says It's A Bad Thing, meaning it's likely to break with future System Software. If you're just developing in-house and don't mind fragmentation problems, it's probably not horrible, but if you're releasing this I would advise against it. > Also, is the malloc() in MPW slow? Is there a faster replacement? > I have heard of faster malloc's that would allocate a larger chunk and > manage them, but I havn't found one. All implementations of malloc and the C++ new operator use this technique already. They allocate 15K chunks of memory, then dole them out as needed. They do this because NewPtr (which they call to actually do the allocation) is slow. This whole mess is an unfortunate byproduct of the simplicity of the MacOS. Learn to live with it, and be glad it's not DOS! --Alex +++++++++++++++++++++++++++ >From grobbins@znet.com (Grobbins) Date: Sat, 15 Apr 1995 12:42:11 -0700 Organization: Skunkworks In article <3mestc$j3i@sundog.tiac.net>, Alex Rosen wrote: >In article <3me3hf$bfd@westie.mid.net> Dave Williss, dwilliss@tnt writes: >> I looked into the possibility of using "Temporary Memory", but the >> Inside Macintosh section (2 pages) on this is rather vague. It says >> you can't leave a block of temporary memory locked when calling >> WaitNextEvent or GetNextEvent >There are two reasons not to leave a temporary handle locked: (1) it can >fragment the entire Mac memory, preventing the user from launching >programs, and (2) Apple Says It's A Bad Thing, meaning it's likely to >break with future System Software. Temporary memory is not an evil or dangerous thing, but you should observe a number of rules when using it. - Use blocks from within the application partition for static needs. Any memory usually required by the application should be accommodated within the application partition. The user should be guaranteed that if the application can be launched, it has enough memory to at least run properly. Program code, window records, dialog contents, scratch space and necessary small buffers are examples of items that should all be held in normal blocks from within the application heap. The minimum partition size should also be able to accommodate at least one document with a moderate amount of data. This is necessary to keep the promise that if the application can be launched, it can be used. - Use temporary memory for documents and other dynamic needs. The primary use of temporary memory is for dynamic data. Documents are "temporary" in the sense that the space they occupy is not always needed when the program is running. Temporary memory is also useful for large buffers, such as might be used for copying files. Remember to provide adequate minimal space within the application partition so that these functions can be carried out even when no temporary memory is available. - Be prepared to reallocate handles. Sometimes adequate space will be available in the application heap when it is not available in temporary memory. Sometimes the opposite will be true. If an attempt to grow a handle with SetHandleSize fails, try reallocating the block so the user will be able to take advantage of any available memory. - Never require temporary memory. Prior to the introduction of MultiFinder, applications were restricted to the memory available in their own heap zone. This wasn't a problem because the application heap occupied most of the Mac's memory. Down the road, temporary memory may become unavailable or unnecessary under future system software. For example, if each application were to be allocated its own unique address space, then it would again offer no advantage for applications to request space from outside of their partition. Applications should never require the presence of temporary memory. When Gestalt indicates that temporary memory is not available, an application should continue to make the best use of the memory available to it. - Unlock temporary memory handles across calls to WaitNextEvent. Temporary memory occupies space which might be needed by the System or by other applications. Good citizenship demands that temporary memory handles be unlocked whenever an application calls WaitNextEvent to avoid unnecessarily restricting the memory available to other applications. - Reduce or dispose of temporary memory handles whenever possible. A key element to giving users natural control of memory usage is that, when documents are closed, more memory should become available to all applications. This requires that applications not hold on to temporary memory handles which are not currently needed. When the data in a handle is no longer absolutely necessary, the application should immediately dispose of or empty the handle. Similarly, users will expect that closing a document should free up memory for other applications. When a user closes a document which is being kept in the application's heap, and that frees up enough space to move data from temporary memory into the application heap, the application should do so. This gives the user the benefit of the additional free space for other applications. - Remember that temp memory handles come from a different heap. Some rare toolbox calls or code libraries may check which heap a handle is in and operate in an unexpected manner if the handle is from a heap other than the application heap. Unfortunately, there is no list of System calls which expect handles to be in the application heap. Under System 7, the Memory Manager is fully compatible with temp memory handles. Beware when passing a temp memory handle to any code which might make inappropriate assumptions about the handle. - Do not allocate a large number of temporary handles. The Memory Manager uses relatively simple algorithms to manage heaps. Allocating too many handles in one heap can have a noticeable, adverse affect on performance. Because the heap from which temporary handlers are allocated is shared, applications should allocate only a reasonably small number of temporary handles. One temporary handle for each open document, up to several dozen, is not excessive, but a hundred or more temporary handles probably is too many. When a large number of handles is necessary, create a new heap in either a non-relocatable block in the main application partition or in a locked temporary block. Grobbins grobbins@znet.com --------------------------- >From kenneth.trueman@residences.ulaval.ca (Kenneth Trueman) Subject: QuickDraw GX Fan Club Page (correct address !) Date: Mon, 24 Apr 1995 05:13:11 GMT Organization: Laval University Hi everybody ! I recently setup the QuickDraw GX Fan Club Page on the WWW. It's a page devoted to all things GX (the technology, compatible applications, utilities, drivers, etc.) Since everybody here is a programmer (? :-), I figure most of you know about GX, etc. The problem is that Apple doesn't promote GX much to The Rest Of Us. My page tries to fill that void. ;-) If you have any info about GX that you'd like to share, if you have a GX based product you want to let people know about, etc, let me know. I'd be very happy to put it on my page, or provide a URL to it elsewhere ... If you see info on my page that is incorrect let me know, and I'll change it ... We've already converted one guy to GX (I've got the e-mail to prove it), and we can convert more, if enough people know about it. So come on by and let me know what you think. :-) I really want to make this the best page possible ! Here's the URL for the QuickDraw GX Fan Club page ... This a totally non-profit, independant thing by a guy who digs GX ! :-) Thanks :-) Kenneth -- Kenneth Trueman kenneth.trueman@residences.ulaval.ca Laval University ktrueman@eworld.com Quebec City, Canada KTrueman@cmq.qc.ca QuickDraw GX Fan Club: The Trueman Files : easy Have a nice day ! ?8-) --------------------------- >From suhieber@cln.etc.bc.ca (Susan Hiebert) Subject: Quicktime Musical Instruments Date: Mon, 17 Apr 1995 03:45:20 GMT Organization: Education Technology Centre of B.C. Hi. My program uses QuickTime 2.0 & QT Musical Instruments to play MIDI files. I have never used the Gestalt Manager before. How do I use it to determine if QT 2.0 & QT Musical Instruments are installed? +++++++++++++++++++++++++++ >From mhl@icf.hrb.com (mark) Date: 17 Apr 95 13:12:36 EST Organization: HRB Systems, Inc. In article <1995Apr17.034520.28107@news.etc.bc.ca>, suhieber@cln.etc.bc.ca (Susan Hiebert) writes: > Hi. My program uses QuickTime 2.0 & QT Musical Instruments to play > MIDI files. I have never used the Gestalt Manager before. How do I > use it to determine if QT 2.0 & QT Musical Instruments are installed? Better yet, how do we get a chance to look at you code? I have been trying to figure out how to use QTMI && MIDI for a while. -- Hope this helps. Mark H. Linton ____________________________________________________________________ mark \'mdrk\ n [ME, fr. OE mearc boundary, march, sign; akin to OHG marha boundary, L margo] 1 a : a conspicuous object serving as a guide for travelers 2 : A standard or criterion of quality 3 : An object or point that serves as a guide --idiom. mark time. 1 : To make little or no progress +++++++++++++++++++++++++++ >From sandvik@apple.com (Kent Sandvik) Date: Mon, 17 Apr 1995 23:37:03 -0800 Organization: Apple Computer, Inc. Developer Technical Support In article <1995Apr17.034520.28107@news.etc.bc.ca>, suhieber@cln.etc.bc.ca (Susan Hiebert) wrote: > Hi. My program uses QuickTime 2.0 & QT Musical Instruments to play > MIDI files. I have never used the Gestalt Manager before. How do I > use it to determine if QT 2.0 & QT Musical Instruments are installed? [could someone FAQ this, thx?] Get the DTSQTUtilities kit from the following URL: ftp://ftp.info.apple.com/dts/quicktime/dtsqtutils.Apr95.hqx The documentation, QuickTime 2.0 Developer Guide for Macintosh: ftp://ftp.info.apple.com/dts/quicktime/QT_MAC.PDF.hqx (Acrobat format). Sneak preview of the DTSQTUtilities kit (test for QT, test for the PowerPlug file, test is musical instruments are available). Cheers, Kent/DTS: - --- /*______________________________________________________________________ QTUIsQuickTimeInstalled - Test if QuickTime is installed. pascal Boolean QTUIsQuickTimeInstalled(void) DESCRIPTION InitQuickTime will test if QuickTime is present. We are not interested in the QuickTime version. */ pascal Boolean QTUIsQuickTimeInstalled(void) { long qtVersion; OSErr anErr; anErr = Gestalt(gestaltQuickTime, &qtVersion); DebugAssert(anErr == noErr); if (anErr != noErr) return false; // no QT present else return true; } /*______________________________________________________________________ QTUIsQuickTimeCFMInstalled - Test if the QuickTime CFM libraries are installed and in the right place. pascal Boolean QTUIsQuickTimeCFMInstalled(void) DESCRIPTION QTUIsQuickTimeCFMInstalled will test if the CFM QuickTime libraries are present (QuickTime PowerPlug, for instance), and if the libraries are still present (this because the libraries are registered once when Gestalt finds then during runtime, and the end user might delete these, or move them to another location later)(. */ #ifdef powerc pascal Boolean QTUIsQuickTimeCFMInstalled(void) { OSErr anErr; long qtFeatures; // Test if the library is registered. anErr = Gestalt(gestaltQuickTimeFeatures, &qtFeatures); DebugAssert(anErr == noErr); if (!( (anErr == noErr) && (qtFeatures & (1 << gestaltPPCQuickTimeLibPresent)) )) // not true return false; // Test if a function is available (the library is not moved from the Extension folder), this is the // trick to be used concerning testing if a function is available via CFM. if ( ! CompressImage ) return false; else return true; } #endif powerc /*______________________________________________________________________ QTUGetQTVersion - Return the current QuickTime version number. pascal long QTUGetQTVersion() DESCRIPTION QTUGetQTVersion is a simple function that will return the current QuickTime version number, and if QuickTime is not installed it will return 0L. The high order word defines the version number, for instance 0x0161 defines version 1.6.1. You could also directly assign a boolean value stating if a certain version is true by using this kind of an expression: Boolean gHasQT2.0 = (( QTUGetQTVersion() >> 16) & 0xFFFF) >= 0x200; EXAMPLE if( (QTUGetQTVersion() >> 16) < 0x150 ) return; // need to work with QT 1.5 or higher. */ pascal long QTUGetQTVersion() { long version; if(Gestalt(gestaltQuickTime, &version) == noErr) return version; else return 0L; } /*______________________________________________________________________ QTUAreQuickTimeMusicInstrumentsPresent - Test if the Musical Instruments Extension is installed. pascal Boolean QTUAreQuickTimeMusicInstrumentsPresent(void) DESCRIPTION QTUAreQuickTimeMusicInstrumentsPresent tests if the QuickTime Musical Instruments extension (actually a component) is registered. If this is not the case, then most likely the extension was never placed into the extension folder, and the end user should be informed about this. */ pascal Boolean QTUAreQuickTimeMusicInstrumentsPresent(void) { ComponentDescription aCD; aCD.componentType = 'inst'; aCD.componentSubType = 'ss '; aCD.componentManufacturer = 'appl'; if(FindNextComponent((Component)0, &aCD) != NULL) return true; else return false; } -- Kent Sandvik sandvik@apple.com Working with Multimedia stuff... Apple Developer Technical Support. Private activities on Internet. +++++++++++++++++++++++++++ >From suhieber@cln.etc.bc.ca (Susan Hiebert) Date: Thu, 20 Apr 1995 02:02:24 GMT Organization: Education Technology Centre of B.C. > > Hi. My program uses QuickTime 2.0 & QT Musical Instruments to play > > MIDI files. I have never used the Gestalt Manager before. How do I > > use it to determine if QT 2.0 & QT Musical Instruments are installed? > Better yet, how do we get a chance to look at you code? I have been > trying to figure out how to use QTMI && MIDI for a while. Actually that part was very easy. I converted the MIDI files with MoviePlayer, then I took the 'moov' resource out of the file, and stored it as a resource in my program's resource fork, under a different, custom resource type. Then I also stored the data fork of the file as a different type of resource in my program. Then, to play a movie I: * call EnterMovies() at startup * copy my resource to my preference file in the system folder (sneaky, eh?) and change the resource type back to 'moov' * copy the other resource to the data fork of my pref file * I have a global variable of type Movie declared (as moovy) * I call OpenMovieFile() on my pref file, and then NewMovieFromFile(), then CloseMovieFile() * to play the movie I call GoToBeginningOfMovie(moovy); MoviesTask(moovy, 0); StartMovie(moovy); then to keep the music going during game play, every once and a while I call MoviesTask() again. To stop the movie, I call (what do you know) StopMovie(), and before I load a new movie, I call DisposeMovie(). * Then before my program quits, I delete all the movie stuff from my pref file, so no one will find it. Thus, I can play movies and protect the MIDI files written by a friend specifically for the game, from being copied around It was quite easy. I learned everything I need to know in order to do this in one afternoon, from the header file, and a code example off the CodeWarrior CD. Hope this helps. Good luck! Btw, if any QT gurus notice anything wrong I am doing, let me know please! It works for me though. P.S Not my account, so E-mail should go to Regulus240@aol.com --------------------------- >From bentley@crenelle.com (Michael Brian Bentley) Subject: Threads and Stacks Date: Fri, 21 Apr 1995 16:14:22 -0500 Organization: Crenelle Incorporated 1) What is the default stack size for a Thread Manager (non-main) thread? 2) Does anyone have a deterministic procedure for calculating a thread's stack requirements? 3) Do any MacOS debuggers provide a tool for recording the maximum stack usage of threads during stress testing? -Mike Bentley Crenelle Inc. -- Michael Brian Bentley - Crenelle Incorporated - bentley@crenelle.com 1935 West Pratt Boulevard Suite One, Chicago Ill 60626-3133 AOL: crenelle CIS: 75026,315 GIS: BENTLEY Alink: Crenelle +++++++++++++++++++++++++++ >From oster@netcom.com (David Phillip Oster) Date: Sat, 22 Apr 1995 03:05:08 GMT Organization: Netcom Online Communications Services (408-241-9760 login: guest) In article bentley@crenelle.com (Michael Brian Bentley) writes: >2) Does anyone have a deterministic procedure for calculating a thread's >stack requirements? allocate a 10k stack. Fill the first 9k with 0xDEADBEEF. On termination, search from the end toward the beginning looking for the first word that isn't DEADBEEF. That will give you the stack usage. Remember the sp points to the high address end of the stack! -- - ------- ---------- Ahh! The thorazine is wearing off and the odinazine is coming on... --------------------------- End of C.S.M.P. Digest **********************