From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-066 Date: Mon, 7 Nov 1994 16:29:31 +0100 (MET) C.S.M.P. Digest Mon, 07 Nov 94 Volume 3 : Issue 66 Today's Topics: #defines by the compiler (CodeWarrior) Announcement: New Mac C++ Programming Book Available Apple Guide: Styled text FUBAR Basic GWorlds and QuickDraw Newbie CW & Code Resources -- poor? Desktop Pictures Drag-and-drop to cdev window? Fastest way to fill memory with a given value? Gestalt Selectors List 2.6 Global storage in code resources How to execute MPW tools without MPW MacTCP Completion Routines & Async Nofification Memory Management within the Real World NewGWorld returns null pointer Pathnames? I don't think so... Q: Creating Variable sized structures? QuickTime + MIDI? Software volume locking: HELP! Some string routines for the PowerPC Tech Notes on the World Wide Web, and History Is Made 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 zobkiw@datawatch.com (joe zobkiw) Subject: #defines by the compiler (CodeWarrior) Date: Mon, 17 Oct 1994 13:45:40 GMT Organization: Datawatch Corporation I have been writing some Aladdin InstallerMaker extensions recently and have a nice little system that (using two projects and a "switch" in my main source file) allows me to compile the extension as an application for easy testing. Then, when I'm done, I can switch projects, switch the #define switch in my main source file, and compile it as the proper resource type. My question is, since CodeWarrior doesn't have a nice little "Prefix" type per-project option like THINK C had, is there another way? It would be great if the compiler knew what TYPE it was compiling the code as and I could get at this information in my code. Something like: #ifdef APPL // APPL is the TYPE of the project InitializeMacintoshManagers(); #endif #ifdef IBeg // IBeg is the RESOURCE TYPE of the project SysBeep(0); #endif Is there another way to accomplish this? Any thoughts? _______________________________________________________ ,,, Joe Zobkiw zobkiw@datawatch.com - - Senior Software Engineer Datawatch Corporation L ___________ Zeros and Ones will take us there __________ _ +++++++++++++++++++++++++++ >From mwron@aol.com (MW Ron) Date: 17 Oct 1994 12:22:03 -0400 Organization: America Online, Inc. (1-800-827-6364) In article , zobkiw@datawatch.com (joe zobkiw) writes: >>My question is, since CodeWarrior doesn't have a nice little "Prefix" type per-project option like THINK C had, is there another way? It would be great if the compiler knew what TYPE it was compiling the code as and I could get at this information in my code. The "Prefix File" option in the Languages Preferences lets you specify a file that gets automatically prepended to every file. Be default, it is set to the precompiled header for the Toolbox routines. However, you can specify your own file. For example, you could specify a Prefix File of MyPrefix.h, where the contents of MyPrefix.h was: #include // Included precompiled header // Define Symbols #ifdef APPL // APPL is the TYPE of the project InitializeMacintoshManagers(); #endif #ifdef IBeg // IBeg is the RESOURCE TYPE of the project SysBeep(0); #endif Your Prefix File can contain any valid C statements. Ron Liechty RonL@metrowerks.com Metrowerks Inc. --------------------------- >From danparks@aol.com (DanParks) Subject: Announcement: New Mac C++ Programming Book Available Date: 15 Oct 1994 16:56:04 -0400 Organization: America Online, Inc. (1-800-827-6364) //****************************************************** Apologies if this isn't the proper newsgroup for this message. I posted it to comp.sys.mac.announce, but it was returned as "not acceptable topic for this newsgroup" !! //****************************************************** To All: There's a new Mac programming book now available - "Symantec C++: Object-Oriented Programming Fundamentals for the Macintosh" by Prima Publishing. It should be at your bookstore by the time you read this. "Symantec C++: Object-Oriented Programming Fundamentals for the Macintosh" Dan Parks Sydow Prima Publishing ISBN: 1-55958-633-8 The book assumes the reader has a knowledge of a higher-level language - preferably the C language. It also assumes the reader has done at least a little programming on the Mac. No advanced-level programming skills are needed, and no previous knowledge of C++ is required. Like my previous Prima book, "Think THINK C", this book comes bundled with a disk that contains ALL of the source code examples presented in the book. It also has a tutorial software program that covers the major topics from the book, from a little different perspective. That program is called Simulator C++. The purpose of the software is to "bring to life" the concepts in the book through the use of text, graphics, QuickTime movies, and on-screen questions and answers. All examples in the book work with Symantec C++ version 6 or version 7. All examples run on either a 680x0 Mac or a Power Mac. There are a couple of dozen example programs - most of them short and covering just a single key topic. But there are also a couple of larger programs that incorporate many C++/object-oriented programming concepts. Earlier examples stress basic techniques, later examples stress programming C++ using Macintosh techniques - writing programs that make use of menus, dialogs, windows, resources, and graphics. As always, please feel free to send email to me ( addresses shown below) with any comments/suggestions/kind words/complaints/questions. *Note to CodeWarrior Owners* If you want to learn C++ programming for the Mac, this book MAY be for you. You'd have to be willing to skip one chapter of the book, and make minimal changes to the source code. You CodeWarrior owners shouldn't have too much trouble adapting the examples to your Metrowerks compiler. You'll need to create a new project, then add the included source code file to it. Most source code files need only one or two changes to compile with CodeWarrior. I'll be posting an errata sheet in this newsgroup next week for CodeWarrior users. It will detail the changes that need to be made. Internet: danparks@aol.com CompuServe: 73747,1401 America Online: DanParks Regards, Dan +++++++++++++++++++++++++++ >From zobkiw@datawatch.com (joe zobkiw) Date: Mon, 17 Oct 1994 13:38:50 GMT Organization: Datawatch Corporation In article <37pfl4$t91@newsbf01.news.aol.com>, danparks@aol.com (DanParks) wrote: > //****************************************************** > Apologies if this isn't the proper newsgroup for this message. > I posted it to comp.sys.mac.announce, but it was returned as > "not acceptable topic for this newsgroup" !! > //****************************************************** > How could the Macintosh programmers newsgroup not be the right place for an announcement about a new book about Macintosh programming? :) This damn info-super-highway has everyone afraid of getting flamed for the littlest thing, much like most kids in the inner-city are afraid to go to school because they'll get shot. So what do they do? Skip school and not post. Dan, it sounds like a good book. Thanks for the info. _______________________________________________________ ,,, Joe Zobkiw zobkiw@datawatch.com - - Senior Software Engineer Datawatch Corporation L ___________ Zeros and Ones will take us there __________ _ --------------------------- >From cwiltgen@mcs.com (Charles Wiltgen) Subject: Apple Guide: Styled text FUBAR Date: Sat, 22 Oct 1994 18:09:26 -0500 Organization: Muso Communications It's a major pain to use styled text in Apple Guide. Basically, I can't make any hypertext links stand out because Apple didn't think of including an "embolden" tag in the dang compiler. What is everyone using to create Apple Guide files with? SimpleText is out of the question. I'd like to use WriteNow, but the GuideMaker crashes when it tries to read it. Anyone have a solution? -- Charles Wiltgen "Love is a snowmobile racing across the tundra and cwiltgen@mcs.com then suddenly it flips over, pinning you underneath. (INTP) At night, the ice weasels come." - Nietzsche (Groening) The Apocalypso! http://www.mcs.net/~cwiltgen +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Sun, 23 Oct 1994 11:01:58 +0800 Organization: Department of Computer Science, The University of Western Australia In article , cwiltgen@mcs.com (Charles Wiltgen) wrote: >It's a major pain to use styled text in Apple Guide. Basically, I can't >make any hypertext links stand out because Apple didn't think of including >an "embolden" tag in the dang compiler. Yep, I've found this very annoying too. I basically gave up on hot text, at least for the moment. >What is everyone using to create Apple Guide files with? I use TexEdit. It's a pretty cool shareware styled text editor. [And yes, I have sent off my shareware payment.] Unfortunately there's no XTND filter for it, so the styles don't move across to AG. >I'd like to use WriteNow, but the GuideMaker crashes >when it tries to read it. I had *exactly* the same problem. I think (god forbid) that MS Word might be a good choice. As long as you restrict yourself to the core features it's fairly nice and the XTND filters are likely to be more stable. However my hard disk is Microsloth-free, which eliminates this option for me. Share and Enjoy. -- Quinn "The Eskimo!" "I wasn't the one who fired the heat seeking population annihilator out the window!" +++++++++++++++++++++++++++ >From cwiltgen@mcs.com (Charles Wiltgen) Date: Sun, 23 Oct 1994 12:43:14 -0500 Organization: Muso Communications In article , quinn@cs.uwa.edu.au (Quinn "The Eskimo!") wrote: > >It's a major pain to use styled text in Apple Guide. Basically, I can't > >make any hypertext links stand out because Apple didn't think of including > >an "embolden" tag in the dang compiler. > > Yep, I've found this very annoying too. I basically gave up on hot text, > at least for the moment. That's potentially one of the Best Thingsª about Apple Guide, and we can't use it because there's no way to find out what what's hot-clickable. I'm going to use Word on one of my smaller files (but I'm afraid!) or go to some sort of Çclick hereÈ notation for now. > >I'd like to use WriteNow, but the GuideMaker crashes > >when it tries to read it. > > I had *exactly* the same problem. I think (god forbid) that MS Word might > be a good choice. As long as you restrict yourself to the core features > it's fairly nice and the XTND filters are likely to be more stable. > However my hard disk is Microsloth-free, which eliminates this option for > me. Thanks for the confirmation. I got WriteNow for $12.95 when I ordered something from MacWarehouse (don't tell anyone about this special offer!) and thought it would be perfect for this. Alas, it was not to be. C'mon, Apple! Add those style tags!!! -- Charles Wiltgen "Love is a snowmobile racing across the tundra and cwiltgen@mcs.com then suddenly it flips over, pinning you underneath. (INTP) At night, the ice weasels come." - Nietzsche (Groening) The Apocalypso! http://www.mcs.net/~cwiltgen +++++++++++++++++++++++++++ >From cwiltgen@mcs.com (Charles Wiltgen) Date: Sun, 23 Oct 1994 13:41:56 -0500 Organization: Muso Communications In article , cwiltgen@mcs.com (Charles Wiltgen) wrote: > > I think (god forbid) that MS Word might > > be a good choice. As long as you restrict yourself to the core features > > it's fairly nice and the XTND filters are likely to be more stable. > > However my hard disk is Microsloth-free, which eliminates this option for > > me. Nope, Word doesn't work either (although Guide reads Word files fine). Can someone from Apple help? I've already started doing my hot words like «this»... -- Charles Wiltgen "Love is a snowmobile racing across the tundra and cwiltgen@mcs.com then suddenly it flips over, pinning you underneath. (INTP) At night, the ice weasels come." - Nietzsche (Groening) The Apocalypso! http://www.mcs.net/~cwiltgen --------------------------- >From jpo6@po.CWRU.Edu (Jared P. O'neal) Subject: Basic GWorlds and QuickDraw Newbie Date: 18 Oct 1994 21:28:47 GMT Organization: Case Western Reserve University, Cleveland, Ohio (USA) I've created a GWorld, at least I think I have. Then, I used the GetGWorldPixMap() call to get the handle of the PixMap. All I wanted to do was use CopyBits to take a picture I had put into the GWorld w/ DrawPicture onto a window I had created, but when I tried it, it didn't copy anything into the window. When I tried to debug it (just how do you debug a GWorld), I noticed that the baseaddr was 0, which doesn't seem right. Is there anything I did wrong here? (I left out the error handling stuff) GetGWorld(&origPort, &origDev); myErr = NewGWorld(&myGWorldPtr, 0, &myRect, nil, nil, 0); SetGWorld(myGWorldPtr, nil); myPixMapHnd = GetGWorldPixMap(myGWorldPtr); good = LockPixels(myPixMapHnd); wndoRect = myGWorldPtr->portRect; EraseRect(&wndoRect); if (PictID != 0) { myPic = GetPicture(PictID); DrawPicture(myPic, &myRect); } SetGWorld(origPort, origDev); SetPort(wp); CopyBits((BitMap *)*myPixMapHnd, (BitMap *)wp, &wndoRect, &(wp->portRect), 0, nil); where wp is the WindowPtr of the destination window. --Jared -- Philosophy: Master the colonel's secret blend of herbs & spices and all the secrets of the universe will be yours!?! Jared O'Neal aka jpo6@po.cwru.edu or oneale@ucsub.colorado.edu or JaredO@aol.co +++++++++++++++++++++++++++ >From first.ascent@mindlink.bc.ca (Alex Curylo) Date: 19 Oct 1994 07:43:58 GMT Organization: First Ascent In article <381emf$d5d@usenet.INS.CWRU.Edu> jpo6@po.CWRU.Edu (Jared P. O'neal) writes: > Is there anything I did wrong here? >CopyBits((BitMap *)*myPixMapHnd, (BitMap *)wp, &wndoRect, &(wp->portRect), 0, nil); Yes. (BitMap *)*myPixMapHnd is wrong. Changing that to &((GrafPtr)myGWorldPtr)->portBits should make it work just fine. And (BitMap*)wp is wrong too. You want &((GrafPtr)wp)->portBits. +++++++++++++++++++++++++++ >From gbolsinga@aol.com (GBolsinga) Date: 19 Oct 1994 15:24:02 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <382inu$idq@deep.rsoft.bc.ca>, first.ascent@mindlink.bc.ca (Alex Curylo) writes: >Yes. (BitMap *)*myPixMapHnd is wrong. Changing that to >&((GrafPtr)myGWorldPtr)->portBits should make it work just fine. And This is wrong! To quote NIM: Imaging With QuickDraw: "To ensure compatibility on systems running basic QuickDraw instead of Color Quickdraw, use GetGWorldPixMap whenever you need to gain access to the bitmap created for a graphics world--that is, do NOT dereference the GWorldPtr record for that graphics world." The funny thing is, all the code samples for CopyBIts in the book that I saw do the WRONG thing. So many manuals, so little time... :) The problem is with the second (destination) Bitmap: change it to: &((GrafPtr)wp)->portBits and thing should be fine. Greg Bolsinga MPI Multimedia +++++++++++++++++++++++++++ >From first.ascent@mindlink.bc.ca (Alex Curylo) Date: 24 Oct 1994 09:15:00 GMT Organization: First Ascent In article rac@intrigue.com (Robert Coie) writes: > A word of caution about GetGWorldPixMap -- it was severely broken in > pre-7.0 systems. I think it grabbed a half word instead of a full 32-bit > word. If you are certain to be running on a post-7.0 system, > GetGWorldPixMap should be OK. If you are certain that Color QuickDraw is > present and are concerned about System 6 compatibility, do the direct > dereference. Yes indeed. Version 1.2, to be exact. Like this: // GetGWorldPixMap doesn't work in 32CQD 1.2 gLameCQD = (qdVersion >= gestalt32BitQD) && (qdVersion < gestalt32BitQD13); // workaround for GetGWorldPixMap bug in CQD 1.2 PixMapHandle OurGetGWorldPixMap(GWorldPtr world) { if (gLameCQD) return ((CGrafPtr)world)->portPixMap; else return GetGWorldPixMap(world); } But in the particular case of CopyBits, &((GrafPtr)myGWorldPtr)->portBits really does always work. Up to 7.5, anyway. --------------------------- >From afrancke@netcom.com (Andrew Francke) Subject: CW & Code Resources -- poor? Date: Wed, 12 Oct 1994 03:00:02 GMT Organization: Netcom Online Communications Services (408-241-9760 login: guest) After perusing CodeWarrior C for a little Component Manager development, I've formed the following reactions. Please respond with the approriate answers. Is it just me, or: * is there no way to create a single-segment code resource that uses the MW ANSI libs? * does the faux-segment loader just plain not work when the code resource's resource fork isn't open? when there are multiple multi-segment resources in the same file? * is there no way to have the following declaration in an MW code resource: char *foo = "bar" If the answer to the first question is "yes," when will MW ship an intelligent linker? Yes, yes -- it's way better than the THINK/Symantec linker in its identification of dead code. That doesn't matter if it's convinced you need multiple segments based on the *un*stripped code/data size. If the answer to any part of the second question is "yes," when will MW either: document the secret inner-workings of the multi-segment glue? Heck, if the answer is *no,* when will MW document it? The third question is based on the fuzzy observation (i.e., I didn't ATFCO -- adjust the compiler options) that a struct with a char * member could not be initialized with a static string. Finally -- on an entirely unrelated note -- when will somebody prepare a runtime library for MPW C-generated .o files that need such fine symbols as _iob and LDIVU -- that can then be used in MW projects. +++++++++++++++++++++++++++ >From isochrome@aol.com (IsoChrome) Date: 13 Oct 1994 14:10:01 -0400 Organization: America Online, Inc. (1-800-827-6364) In article , afrancke@netcom.com (Andrew Francke) writes: > * does the faux-segment loader just plain not work when the code > resource's resource fork isn't open? when there are multiple > multi-segment resources in the same file? I've had the same problem with CW (we're writing 'cmm ' components). The component manager seems to cache the component code, so your resource fork isn't open when you are called. It looks like CW keeps some sort of jump table information in a separate resource ('cmmx' for 'cmm 's). The kiss of death is that the resource is loaded before a single line of your code is executed (to get the address of main maybe?), so there is no way you can open the resource fork yourself. I've had to punt and compile the 68K piece in Symantec and the PPC piece in CodeWarrior. John Sarapata +++++++++++++++++++++++++++ >From hanrek@cts.com (Mark Hanrek) Date: Sun, 16 Oct 1994 07:53:44 GMT Organization: The Information Worskhop In article , afrancke@netcom.com (Andrew Francke) wrote: Try posting your question in "comp.sys.mac.programmer.codewarrior" which you may not have known existed. It's new, and you may find an answer to your question already posted, as I remember reading something along these lines recently. Mark Hanrek +++++++++++++++++++++++++++ >From richardb@cocytus.demon.co.uk (Richard Buckle) Date: Tue, 18 Oct 1994 07:51:57 GMT Organization: none In article , afrancke@netcom.com (Andrew Francke) wrote: >* is there no way to create a single-segment code resource that uses > the MW ANSI libs? Not if you want to use any vaguely useful ANSI function, such as pow() or tolower(). The problem is the dead-code stripping can't see through libraries. I've repeatedly suggested that MW sort this out and in the interim either distribute cut-down ANSI libraries (string.lib, math.lib etc) without 32-bit links hard-wired in or at the very least distribute a 68020 build. I have got *nowhere*. >* does the faux-segment loader just plain not work when the code > resource's resource fork isn't open? when there are multiple > multi-segment resources in the same file? Basically yes. It can also crash horribly if your multi-segment resource is unlocked between calls to it and moves, as the 32-bit jumps do not get remade. UnloadA4Seg() does not help. I have asked MW to provide a way to tell the multi-segment resource to remake its jumps, such as calling UnloadA4Seg(NULL), but this too has fallen on deaf ears. Dammit, I feel strongly I should be entitled to unlock my code resources between calls to them. As I have no control over the third party app calling my code resource, I have been reduced to building a stub single-seg resource that calls the multi-seg resource, runs it and disposes of it to suit MW's brain-damaged segmentation scheme. Mail me if you want details. The whole segmentation thing on CodeWarrior *sucks*, on apps as well as code resources. See a thread by Steve Dorner a while ago for a description of the pure evil that is the application segment loader under CW. A dreadful shame, as this apart from this huge blind spot MW have a *very* fine product. Maybe some more net.pressure will do the trick. - ----------------------------------------------------- Richard Buckle richardb@cocytus.demon.co.uk Using this darned fine NewsHopper thingy. +++++++++++++++++++++++++++ >From Jens Alfke Date: Tue, 18 Oct 1994 17:26:12 GMT Organization: Apple Computer Andrew Francke, afrancke@netcom.com writes: > * does the faux-segment loader just plain not work when the code > resource's resource fork isn't open? when there are multiple > multi-segment resources in the same file? I believe it will work as long as you preload and detach the code segments. The loader obviously can't magically know how to open the resource file to get the code. > * is there no way to have the following declaration in an MW > code resource: > char *foo = "bar" Should work fine as long as A4 is set up properly at the time that the global data is referenced. I've directed follow-ups to c.s.m.p.codewarrior. --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From ejr@netcom.com (Erik J. Rogers) Date: Thu, 20 Oct 1994 01:59:30 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) In article <1994Oct18.172612.15440@gallant.apple.com> wrote: : > * is there no way to have the following declaration in an MW : > code resource: : > char *foo = "bar" : Should work fine as long as A4 is set up properly at the time that the global : data is referenced. Try using: char foo[] = "bar"; See "ReadMe Second" in WDEF sample of resource samples of CW CD for details. Erik J. Rogers --------------------------- >From jacobowi@crab.rutgers.edu (Howard Jacobowitz) Subject: Desktop Pictures Date: 16 Oct 1994 13:34:52 -0400 Organization: Rutgers University I know of at least three INIT/cdev's that replaces the standard desktop pattern with a PICT. HOW?!?!?!?!? I think it involves patching FillCRect/FillCRgn, althoug I've no idea why. +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Mon, 17 Oct 1994 11:09:43 +0100 Organization: Royal Institute of Something or other In article <37ro7s$5ki@crab.rutgers.edu>, jacobowi@crab.rutgers.edu (Howard Jacobowitz) wrote: >I know of at least three INIT/cdev's that replaces the standard >desktop pattern with a PICT. HOW?!?!?!?!? >I think it involves patching FillCRect/FillCRgn, althoug I've no idea why. This happens to do that, and also replace SysBeep() with a predetermined sound, and also play a sound at startup. This particular feature set was used for freshman education earlier this year :-) You can make it go faster by creating a GWorld and draw the picture into it, and use CopyBits, and also re-create the GWorld everytime the color environment changes. Cache the PICT to disk when you do, instead of keeping it, too, in memory. Compile with Think C 7 // Note: // Build this as an INIT; the resource flags HAVE to be System Heap, Locked and Preload // // Install two "snd " resources; 4000 for the system beep and 4001 for the // startup sound // Both these resources HAVE to have the System Heap and Locked bits set; // it helps if they also have the Preload bit set (in Resource info in ResEdit) // // Install a PICT resource; ID 4000. This PICT HAS to have the System Heap and Locked // bits set; it helps with the Preload bit as well (in Resource info in ResEdit) // This PICT will be drawn in the background (on the desktop) - note that the PICT // has to be rectangular (square) and the same size as your screen(s) to look best. // // Screen sizes are: // PowerBook 640x400 // 13"/14" 640x480 // 15" portrait 640x870 // 16"/17" 832x624 // 19" 1024x768 // 19"/21" 1182x870 // // ©1994 Jon Wätte h+@nada.kth.se #include #include #include Handle theBeep = NULL ; static pascal void DoBeep ( short time ) { SetUpA4(); if ( theBeep ) { SndPlay ( NULL , theBeep , false ) ; } RestoreA4(); } static void PlayStart ( ) { Handle h = GetResource ( 'snd ' , 4001 ) ; if ( h ) { SndPlay ( NULL , h , false ) ; ReleaseResource ( h ) ; } } pascal void ( * oldFillCRgn ) ( RgnHandle rgn , PixPatHandle pat ) ; PicHandle thePict = NULL ; static pascal void DrawDesk ( RgnHandle rgn , PixPatHandle pat ) { SetUpA4 ( ) ; if ( ! EmptyRgn ( rgn ) ) { // DeskCPat -- only works on color QD machines if ( ( pat == * ( PixPatHandle * ) 0xcd8 ) && ( thePict != NULL ) ) { RgnHandle clip = NewRgn ( ) ; RgnHandle temp = NewRgn ( ) ; Rect r = ( * * GetGrayRgn ( ) ) . rgnBBox ; GetClip ( clip ) ; SectRgn ( clip , rgn , temp ) ; SetClip ( temp ) ; DisposeRgn ( temp ) ; if ( r . top > 0 ) r . top = 0 ; DrawPicture ( thePict , & r ) ; SetClip ( clip ) ; DisposeRgn ( clip ) ; } else { ( * oldFillCRgn ) ( rgn , pat ) ; } } RestoreA4 ( ) ; } main() { // Some glue to safely install ourselves asm { move.l a0,-(a7) dc.w 0xa128 // _RecoverHandle move.l a0,-(a7) dc.w 0xa992 // _DetachResource move.l (a7)+,a0 } RememberA0(); SetUpA4(); PlayStart ( ) ; if ( ! Button ( ) ) { if ( ( thePict = ( PicHandle ) GetResource ( 'PICT' , 4000 ) ) != NULL ) { DetachResource ( ( Handle ) thePict ) ; oldFillCRgn = ( pascal void ( * ) ( RgnHandle , PixPatHandle ) ) GetToolTrapAddress ( 0xaa12 ) ; SetToolTrapAddress ( ( ProcPtr ) DrawDesk , 0xaa12 ) ; } theBeep = GetResource ( 'snd ' , 4000 ) ; if ( theBeep ) { DetachResource ( theBeep ) ; SetToolTrapAddress ( ( ProcPtr ) DoBeep , 0xA9C8 ) ; // SysBeep } } RestoreA4(); } -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden "Smart Friends ask no SCSI questions!" ‹ Apple employee at the Bash --------------------------- >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Subject: Drag-and-drop to cdev window? Date: 10 Oct 94 16:47:53 +1300 Organization: University of Waikato, Hamilton, New Zealand I'm writing this control panel which supports the Drag Manager. I've hit an odd problem: dragging Finder clipping files to my window doesn't seem to work. I stepped through my drag-tracking handler with MacsBug, and watched it check for a PICT item type, by calling GetFlavorDataSize. If there is no PICT type, I get badDragFlavorErr = -1852, which makes sense. If there _is_ a PICT type, I get cantGetFlavorErr = -1854 instead. If I drag a PICT item from another application to my control panel window, it works OK, so I figure a bug in my code is unlikely. :-) Anybody else encountered this? Maybe the problem is that control panels run in the Finder's context, and its peculiar uses of the Drag Manager don't allow for this. Any ideas welcomed. 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+13:00 +++++++++++++++++++++++++++ >From jumplong@aol.com (Jump Long) Date: 11 Oct 1994 01:03:03 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <1994Oct10.164754.34014@waikato.ac.nz>, ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >I'm writing this control panel which supports the Drag Manager. I've hit >an odd problem: dragging Finder clipping files to my window doesn't seem >to work. We had the same report at work and the answer is, it won't work. I can't remember the reason why, but Nitin tracked it down. - Jim Luther --------------------------- >From rej@chinook.halcyon.com (Randy Jones) Subject: Fastest way to fill memory with a given value? Date: 14 Oct 1994 17:58:54 GMT Organization: NWNEXUS, Inc. - We Make Internet Easy I want to fill a given block of memory with copies of a long. I'm guessing there has to be a faster way than a loop which sets each word in turn. BlockMove, for example, runs faster than a copy loop. But there's no Mac toolbox equivalent of memset that I've found. Are compilers smart enough to turn my loop of word writes into something faster, maybe involving the MMU? If not, then what am I missing? Think and/or MetroWerks C, BTW. --Randy Jones +++++++++++++++++++++++++++ >From relmore@halcyon.com (Richard Elmore) Date: Sat, 15 Oct 1994 01:54:09 -0800 Organization: Northwest Nexus Inc. In article <37mgsu$opv@news.halcyon.com>, rej@chinook.halcyon.com (Randy Jones) wrote: > I want to fill a given block of memory with copies of a long. > I'm guessing there has to be a faster way than a loop which > sets each word in turn. BlockMove, for example, runs faster > than a copy loop. But there's no Mac toolbox equivalent of > memset that I've found. The most common way to speed up mem copy/fill operations is to unroll your loop. That is, instead of copying one long word during each iteration of your loop copy several. This is in fact the approach taken by _BlockMove. Another thing that will make a difference is to make sure all of your moves are longword aligned (ever notice how Hypercard snaps its windows an invisible grid on the screen, thats why). -- Richard Elmore relmore@halcyon.com +++++++++++++++++++++++++++ >From Arnold Kim Date: 16 Oct 1994 20:26:04 GMT Organization: Nemesis Productions In article <37mgsu$opv@news.halcyon.com> Randy Jones, rej@chinook.halcyon.com writes: > I want to fill a given block of memory with copies of a long. > I'm guessing there has to be a faster way than a loop which > sets each word in turn. BlockMove, for example, runs faster > than a copy loop. But there's no Mac toolbox equivalent of > memset that I've found. If you want an only-68k solution, then probably the fastest you'll get is the "movem" command in 68000 assembly. What it does is move the contents of multiple registers into a desired memory location.... so.... initialize all registers as 0x11111111 set a7 as the pointer to where you're writing movem.l a0-a6/d0-d7,(a7)+ that'll blast out 15 longs where (a7) is... (that's probably not the exact syntax, and you'd want to preserve a7, amongst other things... but that's the gist of it - check a 680x0 assembly book) arnold +++++++++++++++++++++++++++ >From resnick@uiuc.edu (Pete Resnick) Date: Mon, 17 Oct 1994 01:26:18 -0500 Organization: University of Illinois at Urbana-Champaign In article <37s28s$5mi@apakabar.cc.columbia.edu>, Arnold Kim wrote: > In article <37mgsu$opv@news.halcyon.com> Randy Jones, > rej@chinook.halcyon.com writes: > > I want to fill a given block of memory with copies of a long. > > If you want an only-68k solution, then probably the fastest you'll get is > the "movem" command in 68000 assembly. Yes, both MOVEM, and MOVE16 on 68040's, are very good block move instructions. There are lots of ways to use them in creative ways. > initialize all registers as 0x11111111 > set a7 as the pointer to where you're writing > > movem.l a0-a6/d0-d7,(a7)+ Aside from the syntax being bad (you can only work with pre-decrement in this mode, not post-increment), even using that would be *very* bad. You don't want to use A7 unless you disable interrupts, since any interrupt that comes through will allocate space on the stack where A7 currently points. If you want to use this method, leave A7 alone completely, move the address of the end of the block into one of the other address registers, move the value you want into all of the other registers, and then do the MOVEM. Here's some sample code I wrote to do a block clear, 52 bytes at a time (4 bytes per register in 13 registers): ; Written in THINK C assembler, so some of the syntax is wierd ; Start with the address of block to clear in A0 and the length in D0 move.l d1,-(sp) ; 12 moveq #0,d1 ; 4 adda.l d0,a0 ; 8 cmpa.w #1,a0 ; 10 bcs.s @0 ; 8/10 move.b d1,-(a0) ; 8 subq.l #1,d0 ; 8 @0 cmpi.l #160,d0 ; 14 blt.s @5 ; 10/8 swap d0 ; 4 move.w d0,d1 ; 4 beq.s @1 ; 8/10 divu.w #52,d1 ;144 swap d1 ; 4 move.w d1,d0 ; 4 @1 swap d0 ; 4 divu.w #52,d0 ;144 move.w d0,d1 ; 4 clr.w d0 ; 4 swap d0 ; 4 movem.l d0/d2-d7/a1-a6,-(sp) ;112 move.l d1,d0 ; 4 moveq #0,d1 ; 4 move.l d1,d2 ; 4 move.l d1,d3 ; 4 move.l d1,d4 ; 4 move.l d1,d5 ; 4 move.l d1,d6 ; 4 move.l d1,d7 ; 4 move.l d1,a1 ; 4 move.l d1,a2 ; 4 move.l d1,a3 ; 4 move.l d1,a4 ; 4 move.l d1,a5 ; 4 move.l d1,a6 ; 4 bra.s @4 ; 10 @2 swap d0 ; 4 @3 movem.l d1-d7/a1-a6,-(a0) ;112 @4 dbra d0,@3 ; 14/10 swap d0 ; 4 dbra d0,@2 ; 14/10 movem.l (sp)+,d0/d2-d7/a1-a6 ;116 = 770 @5 bclr #2,d0 ; 14 beq.s @6 ; 8/10 move.w d1,-(a0) ; 8 @6 addq.b #1,d0 ; 4 lsr.l #2,d0 ; 12 bra.s @9 ; 10 @7 swap d0 ; 4 @8 move.l d1,-(a0) ; 12 @9 dbra d0,@8 ; 14/10 swap d0 ; 4 dbra d0,@7 ; 14/10 addx.w d0,d0 ; 4 bpl.s @10 ; 8/10 move.b d1,-(a0) ; 8 @10 move.l (sp)+,d1 ; 12 rts ; 16 = 252 + pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Doctoral Student - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet: resnick@uiuc.edu --------------------------- >From rgaros@bio.vu.nl (Rene G.A. Ros) Subject: Gestalt Selectors List 2.6 Date: Wed, 12 Oct 1994 07:53:12 GMT Organization: VU Biology, Amsterdam, The Netherlands Dear Mac-programmers, Today I released version 2.6 of the Gestalt Selectors List (GSL) This list celibrates its second anniversary today. It lists all sorts of information about the Gestalt Manager, but mainly about selectors and the meaning of the returned values. The Gestalt Manager is part of the Apple Macintosh System Software to enable programmers to determine the availability of certain software and hardware. You can obtain the latest version in several ways: - by sending an email to the mail archive server: gestalt-selectors-list-request@bio.vu.nl with as subject: archive get recent/gestalt-selectors.etx or to get the compressed version: archive get recent/gestalt-selectors.sit.hqx - FTP to the info-mac archives at sumex-aim.stanford.edu and get the file /info-mac/dev/info/gestalt-selectors-26.hqx You can also use any of its mirror sites. - World Wide Web The GSL is also available, together with other Macintosh FAQs, at: http://www.astro.nwu.edu/lentz/mac/faqs/source/gestalt.html - CompuServe members can find it at the Macintosh Developers Forum (GO MACDEV) in the Tools/Debuggers section. - Subscribers of the maillist have received their copy already. If you want to join this list you need to send an email to: gestalt-selectors-list-request@bio.vu.nl with in the subject line 'subscribe'. You will then also receive several updates before the next version is released. Please, be aware that it may take a couple of days before the new version is available at all these locations. It is available immediatly by using the mail archive server. Beside a large number of new and changed selectors, these are the major changes since the previous version: *************************************************************************** Added selectors Apple System : - Apple Add. : fsm , srta, srtb, ws 1 Third Parties : CsWT, FPUE, PPP Added unknown Apple Softw. : diag, jkbd, lang, mtem, ot Third Parties : *DC*, AlaC, Blad, Cafe, FW14, Mgc!, SNIT, SPAL, SPLO Changed selectors Apple System : a/ux, afps, cfrg, csvr, ctbv, cpnt, dplv, dply, easy, fndr, fs , gval, hdwr, help, hscd, icon, intd, kbd , mach, mbox, proc, qd , qdrw, sdev, sdvr, snhw, sysv, vm , xlat Apple Add. : cmta, cmtc, gfxa, grfx, ttsc Third Parties : jsm1, SAVR Changed unknown Apple Softw. : aslm, batt, bugx, bugy, dude, dudi, fnda, fnd*, fndc, port Third Parties : FWCP, ReSp Previously unknown Apple System : scsi Apple Add. : - Third Parties : Cafe Includes updates 2.5.1 up to and including 2.5.10, sent to subscribers of the mailing list. The new Inside Macintosh Operating System Utilities is available (at least electronically) and a few pieces of information in the GSL are corrected or added. I see no reason to change the basics for the GSL, new selectors and attribute bits will keep appearing as the system software develops... The note about the gestaltKeyboardType selector not being installed on the PowerMac 7100/66 was triggered by an Usenet posting by Marc Cooperman. His observation was confirmed by me because Gestalt! reports of the PM 7100/66 indeed do not list this selector, but I never noticed this when I received these reports! Other (Power)Macs don't seem to have this problem. The GSL has been made available by Robert Lentz on a World Wide Web server. It now has the latest version and a reference to it is included with the 'About This List/Availability' section. Included information from the: - Bookmark CD #18, - Bookmark CD #19, - WWDC 1994 CD, - Developer CD Series August 1994 Tool Chest CD and - Developer CD Series September 1994 Reference Library CD. Roland Mansson provided the information from the latest Gestalt & SysEnvirons TechNote (rev. September 1994). The most important news is that the machine ID's will be reused... The following selectors are now installed with software included with System 7.5 and are moved from the 'Apple Additional Software' to the 'Apple System Software' section: ascr, ascv, aucd, cpkr, drag, hscd, icmp, iscd, kpcd, mtcp, qtim, qtrs, scra, sdev, sdvr, snhw, teat, thds, ufox, xlat And these from the unknown 'Third Party Software' to the unknown 'Apple Software' section: CDJR, HAM , MClk *************************************************************************** Best regards, Rene Ros rgaros@bio.vu.nl -- Rene G.A. Ros rgaros@bio.vu.nl Amsterdam, The Netherlands - ------------------------------------------------------------------------------ English is deliberately designed to frustrate foreigners, you know... (Jeremy Roussak (UK) while trying to explain 'an/a' to me) --------------------------- >From danmcd@sundance.itd.nrl.navy.mil (Dan McDonald) Subject: Global storage in code resources Date: 14 Oct 1994 17:13:29 GMT Organization: Information Technology Division, Naval Research Laboratory With the advent of PowerPC, I'm again confused on something I thought I knew. I assumed that: * Global variables between procedures in a separate code resource were okay, as long as A4 was set up properly If that assumption was wrong, fine. If it's right, then * How the HELL do you set up A4 in PowerPC code resources? I may end up designing my external code modules such that the module asks the main program for storage, and the main program delivers, and subsequently sends pointers to it whenever the code in the module is called. Any comments, hints, death threats, etc. are vastly appreciated. -- Daniel L. McDonald | Mail: danmcd@itd.nrl.navy.mil -------------------------+ Computer Scientist | WWW: http://wintermute.itd.nrl.navy.mil/danmcd.html | Naval Research Lab | Phone: (202) 404-7122 #include | Washington, DC | "Rise from the ashes, A blaze of everyday glory" - Rush + +++++++++++++++++++++++++++ >From isis@netcom.com (Mike Cohen) Date: Sat, 15 Oct 1994 19:09:29 GMT Organization: ISIS International In article <37me7q$b40@ra.nrl.navy.mil>, danmcd@sundance.itd.nrl.navy.mil (Dan McDonald) wrote: > With the advent of PowerPC, I'm again confused on something I thought I > knew. > > I assumed that: > > * Global variables between procedures in a separate code resource > were okay, as long as A4 was set up properly > > If that assumption was wrong, fine. If it's right, then > > * How the HELL do you set up A4 in PowerPC code resources? > 68K code resources still need to have A4 set up, but you don't have to do anything in native code resources. In PPC code, every code fragment (including code resources) has its own global space accessible thru the RTOC, which a register is always pointing to when that code fragment is executing. -- Mike Cohen - isis@netcom.com NewtonMail, eWorld: MikeC / ALink: D6734 / AOL: MikeC20 Home Page: ftp://ftp.netcom.com/pub/isis/home.html --------------------------- >From zack@netcom.com (Zack T. Smith) Subject: How to execute MPW tools without MPW Date: Wed, 12 Oct 1994 13:58:39 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Hi, I'd like to find out how I can execute MPW commands without having MPW. I know that there is a program available for doing this (toolserver), but I don't want to use it. I notice that the MPW tool that I have (gcc) contains only code and version resources. I've tried to execute that as a standalone app by changing creator to FNDR and type to APPL, but the program immediately exits. Does anyone know why this might be happening, assuming that gcc is not buggy. I've tried to inquire with Apple via email, but they won't respond. My guess is that, if gcc had been executing properly, it simply didn't find any params to work on, so it exited. Would anyone know whether it's necessary to load MPW tools into memory in order to execute them and pass parameters? Thanks for any info, Zack Smith +++++++++++++++++++++++++++ >From shebs@cygnus.com (Stan Shebs) Date: Wed, 12 Oct 1994 18:52:22 GMT Organization: /cygint/s1/users/shebs/.organization In article zack@netcom.com (Zack T. Smith) writes: I notice that the MPW tool that I have (gcc) contains only code and version resources. I've tried to execute that as a standalone app by changing creator to FNDR and type to APPL, but the program immediately exits. Uh, MPW GCC requires considerable MPW infrastructure - for one thing, it is a collection of tools, for another, it expects to be able to use the MPW Assembler. And where do you plan to get include files and libraries? Changing the file type to get it to run is about like working the shift lever on an engineless car - it *might* start rolling if you happen to shift into neutral while on a downhill slope... MPW GCC needs a full MPW environment in order to be used. Jonathan Kimmitt has hacked up a standalone version, but it has a number of limitations (the last time I looked, it couldn't build itself, for instance). Does anyone know why this might be happening, assuming that gcc is not buggy. I've tried to inquire with Apple via email, but they won't respond. My guess is that, if gcc had been executing properly, it simply didn't find any params to work on, so it exited. It's not that "Apple won't respond", it's that there's nobody there *to* respond. MPW GCC is not an Apple product, it was a project I did while in Apple's ATG (and as you might guess from the address below, I'm no longer there). If you use it with MPW, it works just fine. (For those more knowledgeable who might be wondering, yes Cygnus would be willing to do an updated Mac GCC, *if* appropriate funding were to be provided - I have no spare time these days :-( ) Stan Shebs Cygnus Support shebs@cygnus.com +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Wed, 12 Oct 1994 09:52:59 -0700 Organization: Internet for the Olympic Peninsula In article , zack@netcom.com (Zack T. Smith) wrote: > Hi, > > I'd like to find out how I can execute MPW commands without > having MPW. I know that there is a program available for > doing this (toolserver), but I don't want to use it. > > I notice that the MPW tool that I have (gcc) contains only code > and version resources. I've tried to execute that as a > standalone app by changing creator to FNDR and type to APPL, > but the program immediately exits. MPW (and ToolServer) provides a considerable amount of environment in which MPW tools operate. (Including in MPW's case a "foreign file system" so that the tool access the current content of a window being edited, when it thinks it is opening a file by that name.) What you want to do is not impossible (witness Think/Symantec's SARez and SADerez, which are apps which provide the needed environment), but more trouble than it's worth. --John -- John Baxter Port Ludlow, WA, USA [West shore, Puget Sound] Sorry...clever signatures require cleverness, not found here. jwbaxter@pt.olympus.net +++++++++++++++++++++++++++ >From zack@netcom.com (Zack T. Smith) Date: Fri, 14 Oct 1994 23:48:09 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) In article shebs@cygnus.com (Stan Shebs) writes: > >In article zack@netcom.com (Zack T. Smith) writes: > > I notice that the MPW tool that I have (gcc) contains only code > and version resources. I've tried to execute that as a > standalone app by changing creator to FNDR and type to APPL, > but the program immediately exits. > >Uh, MPW GCC requires considerable MPW infrastructure - for one thing, >it is a collection of tools, for another, it expects to be able to use >the MPW Assembler. And where do you plan to get include files and >libraries? Changing the file type to get it to run is about like >working the shift lever on an engineless car - it *might* start >rolling if you happen to shift into neutral while on a downhill slope... Libs and header files are available from ftp.apple.com. MPW asm can be replaced with GNU asm (gas). Much of the "infrastructure" would be provided through my C Shell, assuming you mean environment variables, scripting, access to other tools. >MPW GCC needs a full MPW environment in order to be used. Jonathan >Kimmitt has hacked up a standalone version, but it has a number of >limitations (the last time I looked, it couldn't build itself, for >instance). Has anyone got Kimmit's email address? > Does anyone know why this might be happening, assuming that gcc > is not buggy. I've tried to inquire with Apple via email, but > they won't respond. My guess is that, if gcc had been > executing properly, it simply didn't find any params to work on, > so it exited. > >It's not that "Apple won't respond", it's that there's nobody there >*to* respond. MPW GCC is not an Apple product, it was a project I >did while in Apple's ATG (and as you might guess from the address below, >I'm no longer there). If you use it with MPW, it works just fine. > >(For those more knowledgeable who might be wondering, yes Cygnus >would be willing to do an updated Mac GCC, *if* appropriate funding >were to be provided - I have no spare time these days :-( ) > > Stan Shebs > Cygnus Support > shebs@cygnus.com Zack Smith +++++++++++++++++++++++++++ >From khatt@shell.portal.com (Judy Ann Kettenhofen) Date: 23 Oct 1994 09:04:32 GMT Organization: Portal Communications Company -- 408/973-9111 (voice) 408/973-8091 (data) Zack T. Smith (zack@netcom.com) wrote: : In article shebs@cygnus.com (Stan Shebs) writes: : > : >In article zack@netcom.com (Zack T. Smith) writes: : > : > I notice that the MPW tool that I have (gcc) contains only code : > and version resources. I've tried to execute that as a : > standalone app by changing creator to FNDR and type to APPL, : > but the program immediately exits. : > : >Uh, MPW GCC requires considerable MPW infrastructure - for one thing, : >it is a collection of tools, for another, it expects to be able to use : >the MPW Assembler. And where do you plan to get include files and : >libraries? Changing the file type to get it to run is about like : >working the shift lever on an engineless car - it *might* start : >rolling if you happen to shift into neutral while on a downhill slope... : Libs and header files are available from ftp.apple.com. : MPW asm can be replaced with GNU asm (gas). : Much of the "infrastructure" would be provided through my C Shell, : assuming you mean environment variables, scripting, access to other : tools. You just aren't going to be able to run an MPW tool as an app, at least very easily. I suspect it is more trouble than it is worth. An MPW tool has some curious code that is executed in the runtime.o library. This code basically hooks up the tools' input/output to the Shell's. You can think of it as almost like a dynamically-linked library. To give you some idea of which routines, do a dumpobj of stubs.o, a library generally included when making tools; you'll notice that most of these routines are simply empty routines. They are there to make the linker happy; they aren't used other than for that. Stubs.o, plus other mechanisms, are used by tools running under the Shell to provide the ability, as someone has pointed out, to deal with the contents of open (and unsaved) windows. IF you could talk Apple out of telling you *exactly* how this works, you might be able to build something around the tool to provide those services; but the tool, in and of itself does not contain those services. (Altho', if I recall correctly, someone within Apple once made one of the MPW tools so that it was able to determine whether it was running as a tool or as an app and do the appropriate thing.). ==Judy --former MPW/ToolServer/Asm Hack. --------------------------- >From Jon Lipsky Subject: MacTCP Completion Routines & Async Nofification Date: 18 Oct 1994 20:45:22 GMT Organization: Case Western Reserve University I am having trouble getting async connections working with my TCP library I am working on. I had no problems getting syncronous connection to work. I was wondering if there were bugs in the TCP header files with the Completion Rountine, and Async Notification Routine prototypes. If anyone could help me out, I would appreciate it. Thanks in advance, Jon... +++++++++++++++++++++++++++ >From Aaron Wohl Date: Wed, 19 Oct 1994 08:01:07 -0400 Organization: Systems Group 97, Carnegie Mellon, Pittsburgh, PA Excerpts from netnews.comp.sys.mac.programmer: 18-Oct-94 MacTCP Completion Routines .. Jon Lipsky@po.cwru.edu (363) > I was wondering if there were bugs in the TCP header files > with the Completion Rountine, and Async Notification Routine > prototypes. If anyone could help me out, I would appreciate > it. No none that I know of. However, the compleation routine is called from interrupt level. If you haven't done this sort of thing before it is almost impossible to get it right. The key items are: - be carefull of the registers, like A5 isn't setup so you can't access any globals - some compilers generate functionc calls off of A5 so you may not be able to call anything before A5 is setup. - You can't call hardly any of the mac OS system calls. For debugging such code take a look on host akutaktak.andrew.cmu.edu [128.2.35.1] in /aw0g/softkiss*.*. There is a debugging printf that can be called from hardware interrupt level. It writes directly to the screen memory so you can even call it from a VBL, inside a trap patch etc. A sample async notification routine: /* * handle incomming data or connection drop */ static pascal void myTCPNotifyProc(StreamPtr tcpStream, unsigned short eventCode, Ptr userDataPtr, unsigned short terminReason, struct ICMPReport *icmpMsg) { register tcp_conv_pt acnv=(tcp_conv_pt)userDataPtr; acnv->last_event=eventCode; acnv->service_me=TRUE; switch (eventCode) { case TCPTerminate: acnv->terminating++; break; case TCPClosing: acnv->closing++; break; case TCPULPTimeout: break; case TCPDataArrival: acnv->data_arrived++; break; case TCPUrgent: break; case TCPICMPReceived: break; default: break; } } Async compleation routines should similarly be kept very simple. Aaron Wohl / ham callsign N3LIW / 412-731-3691 / 412-268-5032 --------------------------- >From jbeeghly@u.washington.edu (Jeff Beeghly) Subject: Memory Management within the Real World Date: 17 Oct 1994 06:11:53 GMT Organization: University of Washington Well, the app which I am writing is up to the fully functioning stage, so now I have to tackle those neat real world scenarios .... like gracefully handling error conditions, running under low memory scenarios, etc... and I have several questions on issues which have come up recently. 1) Under a low memory condition (~6,000 to 7,000 bytes free) calling the StandardGetFile toolbox call crashes my app. When I ran my app under the debugger (THINK C ver 6.0) and called my function, my machine locked up (my app didn't even break to the THINK C debugger). I've tried to narrow down the conditions (for example, in my app I was originally using a custom file open dialog box), but right now I am just using StandardGetFile(0L, -1, 0L, &reply), and when I call this function (e.g. when I select the menu item that calls this function), I'm not calling anything else, so I'm VERY CONFIDENT that it is the system call that is crashing, not something that I have done (I've been working as a professional software tester for several years now.. believe me, I know how to isolate a bug ;-) ). Is this a known fact? Does StandardGetFile crash under low memory conditions? Do I have to do something like the following, just to ensure that my app doesn't crash? if(FreeMem() >7000L) { StandardGetFile(0L, -1, 0L, &reply); } else { //flash an alert and warn the user } 2) In one of my dialogs, I am loading four separate pictures (only one picture is displayed at a time) and displaying them to create an 'animation' effect within the dialog (OK. yes. it is my about dialog box). I'm doing something like the following: while( !dlgDone ) { ModalDialog(AboutDlgProc, &dlgItem); dlgDone = (dlgItem == OK_ITEM || dlgItem == CANCEL_ITEM); } - ----------------------- pascal Boolean AboutDlgProc(DialogPtr theDialog, EventRecord *e, short *iPtr) { static short step = 0; switch( e->what ) { case keyDown: case autoKey: . . bla, bla, bla.... the usual } DoAnimation(theDialog, step); step++; if(step >= 4) step = 0; } void DoAnimation(DialogPtr theDialog, short step) { PicHandle pic; Rect r; switch( step ) { case 0: pic = GetPicture(128); break; case 1: pic = GetPicture(129); break; case 2: pic = GetPicture(130); break; case 3: pic = GetPicture(131); break; } if(pic != nil) { HLock( (Handle )pic ); SetRect(&r, 20, 40, 20 + 124, 40 + 60); DrawPicture(pic, &r); HUnlock( (Handle )pic); } } Looks good so far, no? Well, the problem is that under a low memory condition (say ~7,000 - 8,000 bytes free), the first picture is loaded and displays fine, but when the second image is loaded, my app crashes (BTW: each picture is 124 x 60 pixels x 256 colors and ResEdit said each were ~ 4500 bytes large). I then went in and added a ReleaseResource( (Handle )pic); call after the HUnlock call. This time, each of the four pictures were loaded (and my app didn't crash), but when the counter turned back to 0, the first pic wasn't displayed. I dismissed the dialog box and brought it back up again. This time, none of the pictures were displayed! Well, this leads me to believe that when I call ReleaseResource(), it not only frees up the memory of the handle holding the picture, but it clears it from the current resource as well. I then tried to use the DisposeHandle() call in place of the ReleaseResource() call, and the same thing occurred (all four pictures were displayed once and only once). At this point, I added following: if(pic != nil) { . . . } else { MoveTo(20, 20); DrawString("\pCan't open image"); } I was thinking, OK, the problem is there is not enough memory to open the image... that is why my app is crashing... I'll just check to see if the PicHandle is nil. If it is not nil, I will draw the picture. If it is nil, I will not draw the pic and continue on. When I ran my program and brought up the dialog, the error message never came up! So what gives? I can't load and display the image, yet the pic isn't nil either!?!?! (btw: I did this for the case of when I try to release memory (via ReleaseResource or DisposeHandle) and when I don't release the Handle). Do I need to do a lot of watch dogging and not let any operations be performed if the app goes beneath 0k of memory is free? 3) In Macintosh C Programming Primmer Vol 2, it states that when a program starts, it contains a block of master pointers. It is within this location that the location of the Handles are kept (64 of them). If the program requires more than 64, the MoreMasters() call needs to be made (which will create 64 more locations for handles). What happens if I have filled up all 64 locations with handles, then create another handle (for arguments' sake, let's say that there is enough memory to create the size of the handle, and we create a new handle without calling MoreMasters())? Will I run the risk of loosing the handle when memory is juggled around? 4) In my program, I manage multiple files at the same time (hence, my app manages several windows at the same time). In each file/window, there are LOTS of different handles (my app displays dozens of icon suites, and each icon suite is a handle). In fact, if I have a window that is maxed out (each window will hold a maximum amount of 50 icon suites), It would seem that I would almost have to call MoreMasters() each time I create/open a new window (when I create/open a new window, I perform a NewHandle( sizeof(data_in_my_window) ) type of call in my program). Is there a call that REMOVES 64 master pointers? In other words, I was wondering if there is a way to call MoreMasters() before I create/open a window, and call RemoveMastersFunction() after I close a window? Yes, I could just add another MoreMasters() call at the begining of my program, but I intend to allow the user to have as many windows/files opened as they want. 5) Is there a call that forces the system to compact the fragmented memory of an app? I remember reading that the system automatically compacts the memory at certain intervals, and I know that there are functions that will compact the memory, so there is a certain amount of memory free (e.g. CompactMem( x ), where x is the number of bytes needed), but is there a call that will force the system to compact as much as possible? +++++++++++++++++++++++++++ >From philip@cs.wits.ac.za (Philip Machanick) Date: 17 Oct 1994 12:10:17 GMT Organization: Computer Science Dept, U of Witwatersrand In article <37t4j9$bq4@nntp1.u.washington.edu>, jbeeghly@u.washington.edu (Jeff Beeghly) wrote: > DoAnimation(theDialog, step); > step++; > if(step >= 4) > step = 0; > } Just a minor thing - I'll leave the memory management thing for others - but if your PICTs are sequentially numbered, why not use the resource ID directly, and savve yourself the switch statement? If they aren't guaranteed to be sequential, you could still store them in an array which would be easier to update than adding another case in the switch. > void DoAnimation(DialogPtr theDialog, short step) > { > PicHandle pic; > Rect r; > > > switch( step ) > { > case 0: > pic = GetPicture(128); > break; > > case 1: > pic = GetPicture(129); > break; etc. -- Philip Machanick philip@cs.wits.ac.za Department of Computer Science, University of the Witwatersrand 2050 Wits, South Africa (at University of Cape Town 4 July-7 Nov) phone 27(11)716-3309 fax 27(11)339-7965 +++++++++++++++++++++++++++ >From mhl@icf.hrb.com (MARK H. LINTON) Date: 17 Oct 94 13:44:22 EST Organization: HRB Systems, Inc. In article <37t4j9$bq4@nntp1.u.washington.edu>, jbeeghly@u.washington.edu (Jeff Beeghly) writes: > > 1) ... Does StandardGetFile crash under low memory conditions? > Sorry, don't know for sure, but I wouldn't be too surprised. > > 2) I am loading four separate pictures... > void DoAnimation(short step) { PicHandle pic = GetPicture(128+step); if (pic != nil) DrawPicture(pic, &(**pic).portRect); } > > Looks good so far, no? Well, no. I would guess this flashes like mad (but if you haven't gotten it to work yet, you wouldn't know that ;^). I would probably load the resources once, image them into offscreen graphics worlds and then just CopyBits in DoAnimation. Lots of sample code available to do this BTW. > Well, the problem is that under a low memory condition (say ~7,000 - > 8,000 bytes free), the first picture is loaded and displays fine, but > when the second image is loaded, my app crashes... How do you know how much memory you have free? > > I then went in and added a > ReleaseResource( (Handle )pic); > This time, each of the four pictures were loaded (and my app didn't crash) This should be a clue... (what has changed? why did that make a difference?... are your PICT resources marked purgeable?) > ...but when the counter turned back to 0, the first pic wasn't displayed. > > I dismissed the dialog box and brought it back up again. This time, none > of the pictures were displayed! Well, this leads me to believe that when > I call ReleaseResource(), it not only frees up the memory of the handle > holding the picture, but it clears it from the current resource as well. > I then tried to use the DisposeHandle() call in place of the > ReleaseResource() call, and the same thing occurred (all four pictures > were displayed once and only once). > > At this point, I added following: > if (pic != nil) { ... } else { > MoveTo(20, 20); > DrawString("\pCan't open image"); > } > > the error message never came up! > > So what gives? I can't load and display the image, yet the pic isn't nil > either!?!?! > There were three statements in that last line. 1) I can't load the image 2) I can't display the image 3) The handle to the image is not nil These can not all be true. GetPicture returns nil if it was unable to load the image. Since you say "the error message never came up" I will assume that 3 is true. This means that 1 must be false. This leaves only 2 as a problem for your application. This is what you must investigate. BTW, have you investigated how QuickDraw reports errors. Given that it appears that this "feature" is occurring in the DrawPicture call, how would you know that it failed? Apart from not being able to see the picture. > Do I need to do a lot of watch dogging and not let any operations be > performed if the app goes beneath 0k of memory is free? > You have less than 0k of memory free and expect the program to do something? BTW, just to be a total smart-***, the generally accepted way to handle this type of situation is to: 1) Figure out how much memory you application needs. 2) Make sure that it gets at least that much. ;^) <--- note the smiley! > > 3) In Macintosh C Programming Primmer Vol 2, it states that when a > program starts, it contains a block of master pointers. It is within > this location that the location of the Handles are kept (64 of them). If > the program requires more than 64, the MoreMasters() call needs to be > made (which will create 64 more locations for handles). What happens if > I have filled up all 64 locations with handles, then create another > handle (for arguments' sake, let's say that there is enough memory to > create the size of the handle, and we create a new handle without > calling MoreMasters())? Will I run the risk of loosing the handle when > memory is juggled around? > If you call NewHandle, and you have no more master pointers available, NewHandle will call MoreMasters for you. The point behind doing it youself is that master pointer blocks are non-relocatable and tend to lead to heap fragmentation. If you let NewHandle make the call, the master pointer block will be placed as low in the heap as possible. Depending on what you have been doing, you may have relocatable or purgeable structures in heap below that block. If you want to reuse that memory, especially with something that may be larger than the things that previously occupied that space (as seems like you may) you are unable to because you have a master pointer block sitting where you need to put your new structure. Go ahead and call MoreMasters two, three... maybe ten times early in your program. Master pointer blocks are pretty small compared to the space you could loose letting NewHandle do it for you. > 4) In my program, I manage multiple files at the same time (hence, my app > manages several windows at the same time). In each file/window, there > are LOTS of different handles (my app displays dozens of icon suites, and > each icon suite is a handle). In fact, if I have a window that is maxed > out (each window will hold a maximum amount of 50 icon suites), It would > seem that I would almost have to call MoreMasters() each time I > create/open a new window (when I create/open a new window, I perform a > NewHandle( sizeof(data_in_my_window) ) type of call in my program). > that would be a BadThing(r), see above. > > Is > there a call that REMOVES 64 master pointers? In other words, I was > wondering if there is a way to call MoreMasters() before I create/open a > window, and call RemoveMastersFunction() after I close a window? Yes, I > could just add another MoreMasters() call at the begining of my program, > but I intend to allow the user to have as many windows/files opened as > they want. > no, again, see above > 5) Is there a call that forces the system to compact the fragmented > memory of an app? I > remember reading that the system automatically compacts the memory at > certain intervals, and I know that there are functions that will compact > the memory, so there is a certain amount of memory free (e.g. > CompactMem( x ), where x is the number of bytes needed), but is there a > call that will force the system to compact as much as possible? > The memory manager has a number of calls in addition to CompactMem (FreeMem and PurgeMem come to mind) but these only help with relocatable and purgeable objects. If your memory is fragmented, it will stay fragmented, these calls only help you use the memory that you have left. From your literary reference above (an excellent starting point, I might add) I assume that you are (fairly) new to Macintosh programming, although from the apparent complexity of your application not to programming in general. Rather than answer you questions with answers, I will answer them with questions and refer you to further reading, so that you can learn the material yourself and not have to ask again next time. (new) Inside Macintosh: Memory - for references to questions about: MoreMasters, NewHandle, CompactMem, PurgeMem, FreeMem, etc. (new) Inside Macintosh: Imaging with QuickDraw - for references to questions about: DrawPicture, GetPicture, etc. -- Hope this helps. Mark H. Linton ____________________________________________________________________ mark \'märk\ 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 jbeeghly@u.washington.edu (Jeff Beeghly) Date: 18 Oct 1994 17:00:33 GMT Organization: University of Washington mhl@icf.hrb.com (MARK H. LINTON) writes: >In article <37t4j9$bq4@nntp1.u.washington.edu>, jbeeghly@u.washington.edu (Jeff Beeghly) writes: >> 1) ... Does StandardGetFile crash under low memory conditions? > Sorry, don't know for sure, but I wouldn't be too > surprised. I've received one reply that stated all standard system calls will most likely crash when memory gets too low. Therefore, in my app, if the memory gets below 10k or 12k, I am going to inform the user that there is not enough, and that they should close a file. >> >> 2) I am loading four separate pictures... >> >void DoAnimation(short step) { > PicHandle pic = GetPicture(128+step); > if (pic != nil) DrawPicture(pic, &(**pic).portRect); >} >> >> Looks good so far, no? > Well, no. I would guess this flashes like mad (but if you > haven't gotten it to work yet, you wouldn't know that ;^). > I would probably load the resources once, image them into > offscreen graphics worlds and then just CopyBits in > DoAnimation. Lots of sample code available to do this BTW. Well, I guess you missed my point. Yes, the function works fine (if there is enough memory available). For right now, I'm not calling my animation at a set interval, so YES, obviously on faster CPUs it will be 'FLASHED'. Yes, I'm am going to put in a timer, so the interval is standard from one machine to another. I do know how to use CopyBits and off screen GWorlds. For this portion of the code, it is redundant. Why? I don't want to permanently 'hold' the pictures... all I need is one picture drawn to the screen at a time (therefore, I don't feel I need to hold all four). Holding the bits in an offscreen gworld would mean I am using twice the memory for the images: one for the resource and one for the offscreen memory >> Well, the problem is that under a low memory condition (say ~7,000 - >> 8,000 bytes free), the first picture is loaded and displays fine, but >> when the second image is loaded, my app crashes... > How do you know how much memory you have free? There is a call called FreeMem() which I am using to output the free memory. I am also using a utility called SWATCH (System Watch) which graphically & numerically displays the amount of locked used memory, moveable used memory, and free memory each app is using. >> >> I then went in and added a >> ReleaseResource( (Handle )pic); >> This time, each of the four pictures were loaded (and my app didn't crash) > This should be a clue... (what has changed? why did that > make a difference?... are your PICT resources marked > purgeable?) Yes, it was a clue. It was telling me that not only the handle was being released, but the location of the resource was being released as well. That is why I was only able to display each image once (and only once). No, I was not marking the pictures within the resource as being purgeable, but I am now doing HPurge( (Handle pic ) after the DrawPicture call... it works..... better, but it still crashes (better in the sence that if I set my app to run with ~ 12k free and call my dialog it works, but if memory gets below 6k, it crashes... looks like I will definately have to work on this a bit. The point I was trying to make was this: If I perform a DisposeHandle on a pic handle, how come I am not able to load and display the picture a second time? DisposeHandle should just remove the handle, not the resouce, shouldn't it? The other point I was trying to make was this: If I can get the image (and pic != nil), how come I am not able to display it? If GetPicture failed, it's supposed to return a 0, yet it doesn't, so what gives? >> >> At this point, I added following: >> > if (pic != nil) { > ... > } else { >> MoveTo(20, 20); >> DrawString("\pCan't open image"); >> } >> >> the error message never came up! >> >> So what gives? I can't load and display the image, yet the pic isn't nil >> either!?!?! >> > There were three statements in that last line. > 1) I can't load the image > 2) I can't display the image > 3) The handle to the image is not nil > These can not all be true. GetPicture returns nil if it > was unable to load the image. Since you say "the error > message never came up" I will assume that 3 is true. This > means that 1 must be false. This leaves only 2 as a > problem for your application. This is what you must > investigate. > BTW, have you investigated how QuickDraw reports errors. > Given that it appears that this "feature" is occurring in > the DrawPicture call, how would you know that it failed? > Apart from not being able to see the picture. Yes, I was a bit unclear. The second time I get the picture, GetPicture does not return a nil, yet I am unable to display the image. I have THINK Reference and it states that DrawPicture is a void, and it does not indicate any error codes from DrawPicture. I just looked up in my IM QD book the QDError function. I will use it for my app. Thanks for the tip. >> Do I need to do a lot of watch dogging and not let any operations be >> performed if the app goes beneath 0k of memory is free? > You have less than 0k of memory free and expect the > program to do something? That was a typo. It should have been 10k free. > BTW, just to be a total smart-***, the generally accepted > way to handle this type of situation is to: > 1) Figure out how much memory you application needs. > 2) Make sure that it gets at least that much. > ;^) <--- note the smiley! Yep. Verry standard. But the problem is this: My app will handle an unlimited number of files/windows (memory permitting). I do not wish to limit the user by only allowing them a max number of files open at a time (like 5 or 10). Each window/file at it's maximum will use ~ 55 handles (I'm displaing a max of 50 icons, each is contained within an IconSuite, which is a handle). If I plan on having 5 files open, I should probably call MoreMasters 4 times. If I plan on having 10 files open, I should probably call MoreMasters 9 times. Get my point? It's varriable depending on the user. Ideally it would be nice to Call a MoreMasters() call before I open a file, then do a DeleteMoreMasters call (if such a call had existed) after I calosed a file. These are all design issues I will have to iron out I guess. >> > If you call NewHandle, and you have no more master > pointers available, NewHandle will call MoreMasters for > you. The point behind doing it youself is that master > pointer blocks are non-relocatable and tend to lead to > heap fragmentation. yep. > If you let NewHandle make the call, the master pointer > block will be placed as low in the heap as possible. > Depending on what you have been doing, you may have > relocatable or purgeable structures in heap below that > block. If you want to reuse that memory, especially with > something that may be larger than the things that > previously occupied that space (as seems like you may) you > are unable to because you have a master pointer block > sitting where you need to put your new structure. yep > Go ahead and call MoreMasters two, three... maybe ten > times early in your program. Master pointer blocks are > pretty small compared to the space you could loose letting > NewHandle do it for you. see above. > The memory manager has a number of calls in addition to > CompactMem (FreeMem and PurgeMem come to mind) but these > only help with relocatable and purgeable objects. If your > memory is fragmented, it will stay fragmented, these calls > only help you use the memory that you have left. Yes, but for each of these call you need to specify an amount of space to try to free up. What I was wondering was if there was a call that causes the system to compact ALL of the free memory. From what I can tell, it doesn't look like it. > From your literary reference above (an excellent starting > point, I might add) I assume that you are (fairly) new to > Macintosh programming, although from the apparent > complexity of your application not to programming in > general. Rather than answer you questions with answers, I > will answer them with questions and refer you to further > reading, so that you can learn the material yourself and > not have to ask again next time. Pretty close. I've been programming for several years and have programmed several different operating systems (Unix, Atari ST/GEM, Windows, now Mac). I've been programming the Mac for ~ 6 months in my spare time. The biggest problems I have encountered w/the Mac are: 1 Unconventional. I'm not taliking about event-driven programming conceps, but things like string types. Who the hell even USES Str63 or Str255?!?!??? After years of honning my pointer & string skills, I have to deal with this junk. If I write my own function, I use pointers, if I use a toolbox call, well... I use StrXXX. And linked lists... try doing a linked list on the Mac... I DARE YOU. 2 There are several good Mac programming books out there, but all only cover the basics. What I'd like to see is something that covers a full scale real world type app. One that covers such topics as Multiple files/windows opened at a time, localization, printing, error-proofing apps, etc... I've seen some books that start to deal with some of these topics, but don't go into very much depth on them. 3 Example code base is meeger. There are several areas of Mac programming which need some indepth examples. The app which I'm writing shouldn't have taken this long, but I got locked up on a couple topics. > (new) Inside Macintosh: Memory - for references to > questions about: MoreMasters, NewHandle, CompactMem, > PurgeMem, FreeMem, etc. Don't have it, but I have THINK Reference. > (new) Inside Macintosh: Imaging with QuickDraw - for > references to questions about: DrawPicture, GetPicture, > etc. Have it. >-- >Hope this helps. a little Jeff +++++++++++++++++++++++++++ >From gbolsinga@aol.com (GBolsinga) Date: 18 Oct 1994 17:41:08 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <380uvh$lqm@nntp1.u.washington.edu>, jbeeghly@u.washington.edu (Jeff Beeghly) writes: >If I perform a DisposeHandle on a pic handle, how come I am not able to >load and display the picture a second time? DisposeHandle should just >remove the handle, not the resouce, shouldn't it? This is bad. Use KillPicture for all PICTs that aren't resources. Use ReleaseResource for all other PICTs. Greg MPI Multimedia +++++++++++++++++++++++++++ >From bj@lamar.colostate.edu (B.J. Buchalter) Date: Tue, 18 Oct 1994 17:10:45 -0700 Organization: CSU Physics Department In article <380uvh$lqm@nntp1.u.washington.edu>, jbeeghly@u.washington.edu (Jeff Beeghly) wrote: > > I've received one reply that stated all standard system calls will most > likely crash when memory gets too low. Therefore, in my app, if the > memory gets below 10k or 12k, I am going to inform the user that there is > not enough, and that they should close a file. > > Yes, this is important. Basically, your strategy needs to be that if the amount of free memory gets to be too small (e.g. sufficently small that operations WILL fail), you need to disable all of the commands that will cause memory to be allocated. That is, if you don;t have enough memory for the about box, disable the about box command. Similarly, if you are really low on memory, don't allow the user to open another file, and perhaps ask them to close one, or ask them to do something else that will free up memory. > If I perform a DisposeHandle on a pic handle, how come I am not able to > load and display the picture a second time? DisposeHandle should just > remove the handle, not the resouce, shouldn't it? You definitely do not want to use DisposeHandle on a resource. The Resource Manager keeps a table of which resources are loaded and where they are in memory. The Memory Manager keeps a table(s) of which handles are allocated and where they are in memory. If you tell the resource manager to release the resource it cleans up its table and marks the resource purgable. If you tell the memory manager to Dispose the handle, it frees the handle, but the resource manager still thinks that the handle exists... bad news. If you make the resource purgable (HPurge), then GetPicture will return the resource handle, even if the handle has been purged. This means that you will get an empty PicHandle (if the available memory is small enough). An empty PicHandle is a non-null handle that points to a NULL value. This will cause quickdraw problems. > > The other point I was trying to make was this: If I can get the image > (and pic != nil), how come I am not able to display it? If GetPicture > failed, it's supposed to return a 0, yet it doesn't, so what gives? See above about empty PicHandles. Also, even if you do get the picture, there may not be enough memory available for the DrawPicture command to complete. If the picture is simply a bitmap there is not too much overhead in DrawPicture, but if there are any regions polygons, etc, DrawPicture can require a reasonable amount of memory. What program did you use to create the picture? SuperPaint, for example, stuffs a lot of crap into its pictures, including PostScript dictionaries. If you really want to be safe for low mem conditions, convert your picture into a bitmap or a pixmap, and use copybits to image it. Even with copybits, the fact that it is not interrupt safe probably means that you cannot rely on it not to use memory. Basically, the toolbox is not terribly stable under really low memory conditions. It was generally written to assume that memory allocation will not fail. It is your responsibility to ensure that the Toolbox has enough memory to satisfy any allocations that it wants to make. In your case, you have found that about 10-12K is required. You must ensure that the amount of memory avaiable to the system never drops below this amount. Disable commands if you must and explain to the user why these commands are disabled. It is better to not be able to do something than to have the entire machine crash, especially if the function in question is simply seeing the about box of the program. If you want to get a little more sophisticated, read about growzone functions in IM:Memory. This will allow you to set aside some 'emergency' memory for those system calls that just cannot fail. > > Yes, I was a bit unclear. The second time I get the picture, GetPicture > does not return a nil, yet I am unable to display the image. I have THINK > Reference and it states that DrawPicture is a void, and it does not > indicate any error codes from DrawPicture. I just looked up in my IM QD > book the QDError function. I will use it for my app. Thanks for the tip. > > See above statments about empty handles and DrawPicture. > >> Do I need to do a lot of watch dogging and not let any operations be > >> performed if the app goes beneath 10k of memory is free? > > You have less than 10k of memory free and expect the > > program to do something? > Yes. But you should allow operations that increase the amount of free memory. > Yep. Verry standard. But the problem is this: My app will handle an > unlimited number of files/windows (memory permitting). I do not wish to > limit the user by only allowing them a max number of files open at a time > (like 5 or 10). Each window/file at it's maximum will use ~ 55 handles > (I'm displaing a max of 50 icons, each is contained within an IconSuite, > which is a handle). If I plan on having 5 files open, I should probably > call MoreMasters 4 times. If I plan on having 10 files open, I should > probably call MoreMasters 9 times. > > Get my point? > > It's varriable depending on the user. Ideally it would be nice to Call a > MoreMasters() call before I open a file, then do a DeleteMoreMasters call > (if such a call had existed) after I calosed a file. These are all > design issues I will have to iron out I guess. > > There are a few things realed to this question. A master pointer block has 100 master pointers. The space for the pointers plus overhead is about 512 bytes (I think... don't remember exactly). You can get approx. 2 files per master pointer block. If you initialize, say, 20 master pointer blocks, that is only about 10k and it will allow approx. 40 windows before you automagically get a new block. Probably OK (not many people can deal with 40 windows at once). Remeber, you need the master pointer blocks for other types of handles also... not too much of a problem to have too many. Also, will all of the icons in every window be different? 40 x 50 = 2000. I would be really surprized if your app would actually have to show 2000 different icon suites (I could be wrong). You might look at sharing handles for the common suites (This could be a big win). If all of the above does not appeal, you can also look at generating new heaps for each window (probably not a great solution). But finally, fragmentation happens. You do everything you can to avoid it, but there are parts of the toolbox that make it kind of difficult (if you want to have no limits on your code). It is not the end of the world, just something to be avoided. Especially if, as in your case, each window will require approximately the same amount of space. If you have a memory map like X P X <- X X X P P P P where X = stuff for the window and P = non-relocatable (e.g. Master pointer block) if one window is closed (the one with the '<-', say) and another is opened, then with what you have described, the new window ought to fit into the memory occupied by the old window. In this case the fragmentation does not affect you. [stuff about memory management and MP blocks] see above > 1 Unconventional. I'm not taliking about event-driven programming > conceps, but things like string types. Who the hell even USES Str63 or > Str255?!?!??? After years of honning my pointer & string skills, I have > to deal with this junk. If I write my own function, I use pointers, if I > use a toolbox call, well... I use StrXXX. And linked lists... try doing > a linked list on the Mac... I DARE YOU. The Str63/Str255 is a legacy from pascal, and certain limits imposed from the early design of the operating system (e.g. filename length limits). They are generally not a problem (but I guess that I am used to them). As far as linked lists goes.... use them all of the time. What is the problem? > 3 Example code base is meeger. There are several areas of Mac programming > which need some indepth examples. The app which I'm writing shouldn't > have taken this long, but I got locked up on a couple topics. > Well, I guess that it is hard to make these claims if you don;t have access to New Inside Macintosh. There are pretty good examples and explanations of many of the issues you mention. Also, there is alot of good source out on the net that essentially functions as sample code of the type that you are looking for. > > > (new) Inside Macintosh: Memory - for references to > > questions about: MoreMasters, NewHandle, CompactMem, > > PurgeMem, FreeMem, etc. > > Don't have it, but I have THINK Reference. > Think reference is not really a substitute. Good luck, and don't let it get you down. It gets easier. Really. B.J. +++++++++++++++++++++++++++ >From Glenn L. Austin Date: Wed, 19 Oct 1994 04:02:29 GMT Organization: Eugene FreeNet In article <380uvh$lqm@nntp1.u.washington.edu> Jeff Beeghly, jbeeghly@u.washington.edu writes: >Pretty close. I've been programming for several years and have >programmed several different operating systems (Unix, Atari ST/GEM, >Windows, now Mac). I've been programming the Mac for ~ 6 months in my >spare time. 6 months is really not long enough to know the toolbox very well, but certainly long enough to get a feel of what programming the Mac is like. It's taken me 10 years to REALLY understand the guts of how the Macintosh work -- and I was programming for 10 years prior to the Mac introduction (mainframes, minis, micros). In relation to your problem with the pictures, if the handle is NULL, the resource didn't exist. If the first dereference of the handle is NULL, there either wasn't enough memory to load the resource, or the resource was purged. If the first dereference is NULL, call LoadResource to see if you can load it. Code that I use for loading any handle looks like this: Handle h = GetResource('XXXX', id); if (h) // resource exists? { if (!*h) LoadResource(h); if (*h) { // use the resource } ReleaseResource(h); // or HPurge(h) is even better! } >The biggest problems I have encountered w/the Mac are: > >1 Unconventional. I'm not taliking about event-driven programming >conceps, but things like string types. Who the hell even USES Str63 or >Str255?!?!??? After years of honning my pointer & string skills, I have >to deal with this junk. If I write my own function, I use pointers, if I >use a toolbox call, well... I use StrXXX. And linked lists... try doing >a linked list on the Mac... I DARE YOU. No problem. I use linked lists all the time. Pointer AND Handles. >2 There are several good Mac programming books out there, but all only >cover the basics. What I'd like to see is something that covers a full >scale real world type app. One that covers such topics as Multiple >files/windows opened at a time, localization, printing, error-proofing >apps, etc... I've seen some books that start to deal with some of these >topics, but don't go into very much depth on them. I agree. I've been thinking about that one for a while. Especially printing. Printing is *EASY* on the Mac. Try writing a simple printable app for Windows -- what a NIGHTMARE! For example, under Windows, you have to do your own scaling (Move and Line are device-resolution-specific, but Ellipse and such are based upon the current scaling factor set). I also found a major bug in printing landscape (on an HP PCL printer) -- the same code which worked correctly when printing portrait broke badly when printing landscape. Items were moved, portions of graphic items were drawn in different places on the page (for example, half of an ellipse was drawn in one spot, the other half was drawn in another spot, and there was white space between the two halves!). I ended up writing my own landscape code, and letting the print drivers (plural -- each printer does its own print code) tell me whether I should do my landscaping code. That bug alone took two months to find, diagnose and fix, because, although you can rotate text, many of the parts of Windows GDI break down when dealing with vertical rather than horizontal text. >3 Example code base is meeger. There are several areas of Mac programming >which need some indepth examples. The app which I'm writing shouldn't >have taken this long, but I got locked up on a couple topics. I definately agree on this one, especially some of the newer managers! However, many of the newer managers (that are extensive, like AOCE or QDGX) have many example programs to search through to find the answers to many questions. However, it has been my experience that Windows programming examples are even scarcer -- I had to find PD applications which addressed some of the same issues I had to deal with! Microsoft basically doesn't provide anything easily accessable, and although Borland did provide some sample code with their compiler, most of it had to do with the "bells & whistles" of Windows, like OLE, MCI, and so forth, but very little on standard "how to display a window contents and deal with scroll bars." I basically had to experiment with that until I got it right -- another two months down the drain. The same basic program that I wrote under Windows which took 12 months to write and debug took 1 weekend (that's less than 40 hrs, folks!) to write using Symantec C++ and TCL. Much of the stuff I got for free on the Macintosh. Much of the stuff I had to write under Windows... // // Glenn L. Austin // Computer Wizard and Racing Car Driver // Internet: glenn_a@efn.org // +++++++++++++++++++++++++++ >From Jaeger@fquest.com (Brian Stern) Date: 19 Oct 1994 17:25:21 GMT Organization: The University of Texas at Austin, Austin, Texas In article <380uvh$lqm@nntp1.u.washington.edu>, jbeeghly@u.washington.edu (Jeff Beeghly) wrote: < < < >> Do I need to do a lot of watch dogging and not let any operations be < >> performed if the app goes beneath 0k of memory is free? < > You have less than 0k of memory free and expect the < > program to do something? < < That was a typo. It should have been 10k free. < < > BTW, just to be a total smart-***, the generally accepted < > way to handle this type of situation is to: < < > 1) Figure out how much memory you application needs. < > 2) Make sure that it gets at least that much. < < > ;^) <--- note the smiley! < < Yep. Verry standard. But the problem is this: My app will handle an < unlimited number of files/windows (memory permitting). I do not wish to < limit the user by only allowing them a max number of files open at a time < (like 5 or 10). Each window/file at it's maximum will use ~ 55 handles < (I'm displaing a max of 50 icons, each is contained within an IconSuite, < which is a handle). If I plan on having 5 files open, I should probably < call MoreMasters 4 times. If I plan on having 10 files open, I should < probably call MoreMasters 9 times. < < Get my point? < < It's varriable depending on the user. Ideally it would be nice to Call a < MoreMasters() call before I open a file, then do a DeleteMoreMasters call < (if such a call had existed) after I calosed a file. These are all < design issues I will have to iron out I guess. < < Most of the sample code I've seen uses a size of about 40K as the time to post a low memory warning. Since we're talking about 'Real World' apps you should know that ALL real world apps have a growZone procedure and use some mechanism for keeping a buffer of memory available. Usually this done by a mechanism known as the rainy-day fund. Briefly, at app startup you allocate a handle of, say, 40K. That's your rainy day fund. Each time through your main event loop ( or perhaps only on null events) you check the available memory. If it's too low you post a warning alert. Under some circumstances you release the rainy day handle. Either from your growZone Proc or possibly in response to an explicit call from somewhere in your app. Regarding the MoreMasters calls. Exercise your app thoroughly with a number of windows/documents open that is on the high side of what you would consider avaerage. See how many Master Pointer blocks were needed. Maybe add 2 or 3 to this number and call MoreMasters this many times. Eight or ten should be more than sufficient. Realize that any user that sees the 'not enough memory' warning is going to up the partition size for the app. Although this doesn't automatically increase the number of Master Pointer blocks it does give the app more breathing room so that if any are automatically allocated any problems caused by heap fragmentation are minimized. The important thing is to warn when memory gets low. < The biggest problems I have encountered w/the Mac are: < < 1 Unconventional. I'm not taliking about event-driven programming < conceps, but things like string types. Who the hell even USES Str63 or < Str255?!?!??? After years of honning my pointer & string skills, I have < to deal with this junk. If I write my own function, I use pointers, if I < use a toolbox call, well... I use StrXXX. And linked lists... try doing < a linked list on the Mac... I DARE YOU. Gee Jeff, we were just beginning to like you, and then you turn on us like this:) Are you aware that your windowlist is a linked list? There are numerous operating system queues that are linked lists. Doing linked lists with memory allocated by NewPtr or by malloc is no different than on any other architecture. You can do linked lists with handles. The only difference is an extra * here or there when referring to the memory blocks. If you're not aware, the reason for the Str255 and friends string types are due to the Mac's Pascal heritage. Don't complain about it, just accept it. Every development environment has utility routines to translate between C and P strings. Sorry you had to learn something new. < < 2 There are several good Mac programming books out there, but all only < cover the basics. What I'd like to see is something that covers a full < scale real world type app. One that covers such topics as Multiple < files/windows opened at a time, localization, printing, error-proofing < apps, etc... I've seen some books that start to deal with some of these < topics, but don't go into very much depth on them. < < 3 Example code base is meeger. There are several areas of Mac programming < which need some indepth examples. The app which I'm writing shouldn't < have taken this long, but I got locked up on a couple topics. Are you aware of the sample code at ftp.apple.com and at the alt.sources.mac archive at ftp://ftpbio.bgsu.edu/? < < < < Have it. < < >-- < < >Hope this helps. < < < a little < < < Jeff Good luck, -- Brian Stern :-{)} Toolbox commando and Menu bard Jaeger@fquest.com +++++++++++++++++++++++++++ >From ari@world.std.com (Ari I Halberstadt) Date: Thu, 20 Oct 1994 04:00:28 GMT Organization: The World Public Access UNIX, Brookline, MA In article , Brian Stern wrote: >In article <380uvh$lqm@nntp1.u.washington.edu>, jbeeghly@u.washington.edu >(Jeff Beeghly) wrote: > >< >< >< >> Do I need to do a lot of watch dogging and not let any operations be >< >> performed if the app goes beneath 0k of memory is free? >... >< Get my point? Get ZoneRanger and a color monitor. This is the *coolest* free program for figuring out what the heck your app is doing in its memory partition. It should be on any archive site and plenty of CDs. Also, get ProcessWatcher, another free and useful tool. >Most of the sample code I've seen uses a size of about 40K as the time to >post a low memory warning. Since we're talking about 'Real World' apps >you should know that ALL real world apps have a growZone procedure and use >some mechanism for keeping a buffer of memory available. Usually this >done by a mechanism known as the rainy-day fund. Briefly, at app startup >you allocate a handle of, say, 40K. That's your rainy day fund. Each >time through your main event loop ( or perhaps only on null events) you >check the available memory. If it's too low you post a warning alert. >Under some circumstances you release the rainy day handle. Either from >your growZone Proc or possibly in response to an explicit call from >somewhere in your app. I've abstracted and elaborated this. Each level in an app gets a reserve memory. Then there's a memory cushion in addition. The app sets the allocation level. The Toolbox level is the lowest, since the TB can crash if it doesn't get memory. When I need to allocate memory, I bump up the level, then restore it afterwards. For critical things, like quitting and saving a file, I bump up the memory to a "critical" level. Each level allows access to different memory reserves. The size of the memory reserves for each level is set in a configuration resource. The grow zone function runs a loop in which it frees up reserves (depending on the current level) until enough bytes have been freed. Memory warnings are issued depending on how much of the reserves are depleted and how little memory is left. At each warning level, the application can take different actions, e.g., at first just an alert, then disabling functions like undo, then automatically asking the user to close files, then automatically closing unmodified files and saving modified files to temporary locations, and, finally, terminating the application if all of the reserves are depleted and there is very little memory left (e.g., less than 10K). I also have code to automatically unload inactive segments, but it's not very portable (works only with THINK C, not with Metrowerks). >... >< 1 Unconventional. I'm not taliking about event-driven programming >< conceps, but things like string types. Who the hell even USES Str63 or >< Str255?!?!??? After years of honning my pointer & string skills, I have >< to deal with this junk. If I write my own function, I use pointers, if I >< use a toolbox call, well... I use StrXXX. And linked lists... try doing >< a linked list on the Mac... I DARE YOU. >... >If you're not aware, the reason for the Str255 and friends string types >are due to the Mac's Pascal heritage. Don't complain about it, just >accept it. Every development environment has utility routines to >translate between C and P strings. Sorry you had to learn something new. I got tired of worrying about string types. At first, I just made a rule that everything was a C string, and wrote wrappers around offending toolbox routines. Then I decided it just didn't make sense to worry about how long a string is, especially for variable length things. So I wrote a string library that allocates everything dynamically, and even replaces sprintf. This would have been easier with C++, but hey, it works even with C. For string-intensive portions of my code where many strings are used and where performance is important, say parsing, I use direct pointers and allocate things from a large chunk of memory or use a fixed string length. the string library has functions for converting to and from regular C or Pascal strings. >< 3 Example code base is meeger. There are several areas of Mac programming >< which need some indepth examples. The app which I'm writing shouldn't >< have taken this long, but I got locked up on a couple topics. > >Are you aware of the sample code at ftp.apple.com and at the >alt.sources.mac archive at ftp://ftpbio.bgsu.edu/? Yup, I'd have to agree that there's tons of sample code. And there's all the sample code that comes with your compiler (e.g., TC, Metrowerks), and with Develop, etc. -- "Ramsgate (n.) All institutional buildings must, by law, contain at least twenty ramsgates. These are doors that open the opposite way to the one you expect." -- D. Adams & J. Lloyd "The Meaning of Liff", p75. +++++++++++++++++++++++++++ >From ari@world.std.com (Ari I Halberstadt) Date: Thu, 20 Oct 1994 04:25:35 GMT Organization: The World Public Access UNIX, Brookline, MA In article , Ari I Halberstadt wrote: >I've abstracted and elaborated this. Each level in an app gets a >reserve memory. Then there's a memory cushion in addition. The app >sets the allocation level. The Toolbox level is the lowest, since the >TB can crash if it doesn't get memory. When I need to allocate memory, >I bump up the level, then restore it afterwards. For critical things, >like quitting and saving a file, I bump up the memory to a "critical" >level. Each level allows access to different memory reserves. The size >... This paragraph is inconsistent. Basically, the Toolbox level has the highest priority. The normal priority is the Toolbox level, since there are so many TB calls that can allocate memory it's just easier to keep it as the default. At the TB level, both my reserves and the TB reserves can be accessed. When I allocate memory, I lower the priority so as not to deplete the TB reserves, but I can still deplete my reserves. This scheme can be extended to any number of levels (which, in my case, is a bit necessary, since I have the TB, low-level libraries, then the real application, each of which should have their own reserves, even though my libraries aren't supposed to crash if they run out of memory). -- "Ramsgate (n.) All institutional buildings must, by law, contain at least twenty ramsgates. These are doors that open the opposite way to the one you expect." -- D. Adams & J. Lloyd "The Meaning of Liff", p75. +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Thu, 20 Oct 1994 19:44:46 +0100 Organization: Royal Institute of Something or other In article , Jaeger@fquest.com (Brian Stern) wrote: >< conceps, but things like string types. Who the hell even USES Str63 or >< Str255?!?!??? After years of honning my pointer & string skills, I have >< to deal with this junk. If I write my own function, I use pointers, if I >< use a toolbox call, well... I use StrXXX. And linked lists... try doing >< a linked list on the Mac... I DARE YOU. I use Str31, Str63 and Str255 where appropriate; mostly as structure members and stack-based variables. Anyone who knows enough C or C++ to program any computer for a living (in those languages...) knows that when you have a typedef: typedef unsigned char Str31 [ 32 ] ; what really gets passed to functions is a pointer to unsigned char, so all functions should be declared as: void MyFunc ( const unsigned char * source , unsigned char * dest ) Similarly; you can pass an unsigned char pointer everywhere the headers say "StrXXX" Similarly for linked lists; use malloc() if you like it better, or use NewPtr(). Or do a linked list with Handles; it's really easy: typedef struct elem { struct elem * * next ; long data ; } elem , * elemPtr , * * elemHandle ; elemHandle theList ; void insertelematend ( long data ) { elemHandle theE = ( elemHandle ) NewHandle ( sizeof ( elem ) ) ; elemHandle * theP = & theList ; ( * theE ) -> next = NULL ; ( * theE ) -> data = data ; while ( * theP ) { theP = & ( * theP ) -> next ; } * theP = theE ; } Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden This is the kind of totally-gross-out-sick stuff you can do with C++ that makes the language kind of neat. -- Keith Rollin +++++++++++++++++++++++++++ >From lsr@taligent.com (Larry Rosenstein) Date: Wed, 19 Oct 1994 01:22:44 GMT Organization: Taligent, Inc. In article , bj@lamar.colostate.edu (B.J. Buchalter) wrote: > Yes, this is important. Basically, your strategy needs to be that if the > amount of free memory gets to be too small (e.g. sufficently small that > operations WILL fail), you need to disable all of the commands that will You also have to make sure that the amount of free memory doesn't get so small that the user can't save documents, quit, etc. -- Larry Rosenstein Taligent, Inc. lsr@taligent.com +++++++++++++++++++++++++++ >From Peter_Gontier@novell.com (Pete Gontier) Date: Mon, 24 Oct 1994 19:52:54 -0800 Organization: Novell, Inc., Walnut Creek Macintosh Site In article <380uvh$lqm@nntp1.u.washington.edu>, jbeeghly@u.washington.edu (Jeff Beeghly) wrote: > I've received one reply that stated all standard system calls will most > likely crash when memory gets too low. Therefore, in my app, if the > memory gets below 10k or 12k, I am going to inform the user that there is > not enough, and that they should close a file. Try 33K. Why? Because 32K is the largest several of the more complicated data structures in the Toolbox can be. Add 1K for super-emergencies and you should be better off than using only 12K. > The other point I was trying to make was this: If I can get the image > (and pic != nil), how come I am not able to display it? If GetPicture > failed, it's supposed to return a 0, yet it doesn't, so what gives? Because the data in a 'PICT' is compressed. It gets expanded somewhat during DrawPicture. Also, consider skipping calls like GetPicture and simply using GetResource directly. It provides an opportunity to do better error checking at the price of the following difference in typing: PicHandle ph = GetPicture (128); PicHandle ph = (PicHandle) GetResource ('PICT',128); Now you can call 'ResError' and find out all the other things which might have gone wrong other than 'resNotFound'. >The biggest problems I have encountered w/the Mac are: > > 1 Unconventional. I'm not taliking about event-driven programming > conceps, but things like string types. Who the hell even USES Str63 or > Str255?!?!??? After years of honning my pointer & string skills, I have > to deal with this junk. If I write my own function, I use pointers, if I > use a toolbox call, well... I use StrXXX. I actually prefer Pascal strings for most operations because I always have the length available without worrying about caching the result of 'strlen'. The fact that there are a zillion 'Str...' shouldn't faze you; they're just Pascal strings with different maximum sizes. I use 'Str15', for example, all the time for quick calls to 'NumToString'. > And linked lists... try doing > a linked list on the Mac... I DARE YOU. I have. Other posters have pointed out that handles on the Macintosh are not the same as handles on Windows. There's no more difficulty in writing linked list code on the Mac than there is in typing an extra '*'. (It's when people start trying to optimize the double-dereferencing that they get into trouble.) > 3 Example code base is meeger. There are several areas of Mac programming > which need some indepth examples. The app which I'm writing shouldn't > have taken this long, but I got locked up on a couple topics. This is an odd observation, given that you appear to have "real" internet access. Perhaps you are unaware of the many 'ftp' archive sites. There is also copious example code on the various CD ROMs produced by Apple. > > (new) Inside Macintosh: Memory - for references to > > questions about: MoreMasters, NewHandle, CompactMem, > > PurgeMem, FreeMem, etc. > > Don't have it, but I have THINK Reference. You absitively posolutely need to buy the relevant Inside Macintosh volumes. They cost a lot of money. You need to buy them anyway. -- Views expressed here do not necessarily reflect the views of Novell. --------------------------- >From pwhull@crl.com (Peter Hull) Subject: NewGWorld returns null pointer Date: 20 Oct 1994 09:24:21 GMT Organization: CRL Dialup Internet Access (415) 705-6060 [Login: guest] Hello, I have a problem related to using GWorlds-- NewGWorld returns null in the GWorld pointer. I am using TCL 1.1.3. When the problem occurs, I already have one document object open, identical to the one I am trying to create. If I close the first document and then open a second one, everything is cool. But if I try to open a second document while the first is still open, when my CGWorld object calls NewGWorld to create the offscreen world, it gets this null pointer. I am running the program in 4 megs of memory, and the images are only 256x256 pixels. (I'm using the Pico sample images from 'develop' #10, from 'develop' CD #19.) Does anybody have any idea why NewGWorld would return a null GWorld? There's nothing in Inside Macintosh that would suggest that NewGWorld might return a null pointer except for the example code in NIM: "Imaging with QuickDraw", chapter 6, which tests for a null pointer. That is where I got the idea that that might be the problem. (Originally I thought the problem might be with DrawPicture, because that's where the program froze.) Any help would be appreciated... Thanks in advance! -- -- Peter Hull +++++++++++++++++++++++++++ >From pwhull@crl.com (Peter Hull) Date: 20 Oct 1994 21:18:34 GMT Organization: CRL Dialup Internet Access (415) 705-6060 [Login: guest] Peter Hull (pwhull@crl.com) wrote: : Hello, : I have a problem related to using GWorlds-- NewGWorld returns null in the : GWorld pointer. I am using TCL 1.1.3. When the problem occurs, I already : have one document object open, identical to the one I am trying to create. : If I close the first document and then open a second one, everything is : cool. But if I try to open a second document while the first is still open, : when my CGWorld object calls NewGWorld to create the offscreen world, it : gets this null pointer. I am running the program in 4 megs of memory, : and the images are only 256x256 pixels. (I'm using the Pico sample images : from 'develop' #10, from 'develop' CD #19.) : Does anybody have any idea why NewGWorld would return a null GWorld? There's : nothing in Inside Macintosh that would suggest that NewGWorld might return : a null pointer except for the example code in NIM: "Imaging with QuickDraw", : chapter 6, which tests for a null pointer. That is where I got the idea that : that might be the problem. (Originally I thought the problem might be with : DrawPicture, because that's where the program froze.) I now have discovered that the problem occurs also on the first document object sometimes. Why this is I still have no idea. Here is the call, straight from my source code: FailOSErr(anErr = NewGWorld(&itsWorld, depth, &boundsRect, NULL, NULL, 0)); 'boundsRect' is { 0, 0, 256, 256 }, 'depth' is 16. After the call, sometimes 'itsWorld' is NULL. However, I have never had an error show up in 'anErr'. Any ideas? -- -- Peter Hull +++++++++++++++++++++++++++ >From Jaeger@fquest.com (Brian Stern) Date: 23 Oct 1994 18:07:12 GMT Organization: The University of Texas at Austin, Austin, Texas In article <386mra$kqk@nntp.crl.com>, pwhull@crl.com (Peter Hull) wrote: < Peter Hull (pwhull@crl.com) wrote: < : Hello, < < : I have a problem related to using GWorlds-- NewGWorld returns null in the < : GWorld pointer. I am using TCL 1.1.3. When the problem occurs, I already < < FailOSErr(anErr = NewGWorld(&itsWorld, depth, < &boundsRect, NULL, NULL, 0)); < < 'boundsRect' is { 0, 0, 256, 256 }, 'depth' is 16. < < After the call, sometimes 'itsWorld' is NULL. < < However, I have never had an error show up in 'anErr'. < Any ideas? < < -- < -- < Peter Hull Actually this very question was posted a month or so back. Are you locking the object before making this call? NewGWorld moves memory. TCL 1.1.3 objects are handles. If itsWorld is an instance varible and the object is unlocked then NewGWorld will succeed but &itsWorld won't point to the object anymore. Either lock the object, or use a local varible for the first parameter to NewGWorld and then set itsWorld from the local variable. Good luck, -- Brian Stern :-{)} Toolbox commando and Menu bard Jaeger@fquest.com +++++++++++++++++++++++++++ >From pwhull@crl.com (Peter Hull) Date: 24 Oct 1994 10:16:33 GMT Organization: CRL Dialup Internet Access (415) 705-6060 [login: guest] Regarding the GWorld problem with NewGWorld returning a null pointer, Brian Stern's solution was correct. He suggested that the problem was being caused by NewGWorld moving memory while the object that called it was unlocked in the heap. This caused the (handle-based) object to not receive the pointer correctly. Here is my implementation of the fix: HLock ((Handle) this); HUnlock ((Handle) this); Depressingly simple, isn't it? Many thanks to Brian and also to Francois Pottier who e-mailed me with the same solution. Cheers, Peter -- Peter Hull --------------------------- >From mclow@san_marcos.csusm.edu (Marshall Clow) Subject: Pathnames? I don't think so... Date: Fri, 14 Oct 1994 17:36:29 -0700 Organization: Aladdin Systems In article <272202942.8010432@chatter.chatter.com>, Daaron_Dwyer@chatter.com wrote: > Not to answer the question, but to advance it to a different level, when you > do a call to FindFolder (let's say to find the preferences folder on the > startup volume) and you get a Folder ID, what is the most efficient way to > convert it or utilize the information to be a path? > > Just another newbie, OK. Here we go: On the mac, in general, you don't want to use pathnames. Users have this distressing habit of moving files and renaming folders. To open/rename/delete/etc a file: All the appropriate routines take a triplet: volume, directory ID, and file name. In your example, you already have a volume refnum, and directory ID, (from your call to FindFolder), and presumably you have the name. err = HOpen ( vrefNum, dirID, fName, fsRdWrPerm, &refNum ); To save the location of a file so you can find it later: Use the alias manager. NewAlias (...); later: ResolveAlias ( ... ); -- Marshall Clow Aladdin Systems mclow@san_marcos.csusm.edu --------------------------- >From bb@lightside.com (Bob Bradley) Subject: Q: Creating Variable sized structures? Date: Sun, 16 Oct 1994 09:26:42 -0800 Organization: SS Software Inc. How do you create variable sized structures, similar to how DITL resources are used by the Dialog Manager? Do they just create a handle and tack on things as they go? If so, it would seem like they'd need some sort of index or they'd have to parse the list each time to access individual items. I'm writing a View-like library for creating Windows/Dialogs and I'm looking for a good way to create variable sized structures that define the details of the View but, having a tough time with this part of it. Any comments appreciated. +++++++++++++++++++++++++++ >From Eric Kidd Date: 18 Oct 1994 03:00:39 GMT Organization: Dartmouth College Q: Creating Variable sized structures? One easy way to do this is--if the variable part of the record is of constant size--is to define a struct like: typedef struct { // header info short index; element_type element[1]; } myType; Reference data of this type with a handle and use the memory manager (ResizeHandle? SizeHandle? I forget at the moment.) to resize it as you need. You could write a routine: ResizeMyType( myType** theData, short numSlots ) and call it as needed. Hope this helps. Any feedback appreciated. +++++++++++++++++++++++++++ >From Jaeger@fquest.com (Brian Stern) Date: 18 Oct 1994 06:52:05 GMT Organization: The University of Texas at Austin, Austin, Texas In article , bb@lightside.com (Bob Bradley) wrote: < How do you create variable sized structures, similar to how DITL resources < are used by the Dialog Manager? < < Do they just create a handle and tack on things as they go? If so, it < would seem like they'd need some sort of index or they'd have to parse the < list each time to access individual items. < < I'm writing a View-like library for creating Windows/Dialogs and I'm < looking for a good way to create variable sized structures that define the < details of the View but, having a tough time with this part of it. < < Any comments appreciated. Yes, variable-sized resources are built by allocating a handle and then tacking things onto the end of it. The routines like GetDItem, SetDItem, and GetIndString walk down the resource each time to find the particular item's data. In general these data structures are small so that finding the third or tenth item doesn't take very long. Finding the hundreth or thousandth item this way would be very slow. Each of the items in these variable length data structures has a length byte or short that is at a fixed offset from the beginning of each item (often the offset is zero) to facilitate walking down the structure. Also the resource has an entry count in it, usually at the beginning. Adding a new item at the end is just a matter of using PtrAndHand and then updating the item counter. Modifying existing items or inserting items in the middle is a matter of adjusting the size of the handle and blockmove to make space in the middle, followed by blockmove to insert the new data. My personal favorite is the Speech Manager 'dict' resource. In this perverse resource there is a header, followed by a variable length array of variable length records. Each of these last records consists of two (or more) variable length records. Sort of like an array of STR# resources. -- Brian Stern :-{)} Toolbox commando and Menu bard Jaeger@fquest.com +++++++++++++++++++++++++++ >From larson@base.cs.ucla.edu (Christopher Larson) Date: 18 Oct 1994 16:51:27 GMT Organization: UCLA, Computer Science Department In article <37vdon$gvt@dartvax.dartmouth.edu> Eric Kidd writes: >Q: Creating Variable sized structures? > >One easy way to do this is--if the variable part of the record is of >constant >size--is to define a struct like: > >typedef struct >{ > // header info > > short index; > element_type element[1]; >} myType; In THINK C (don't know about CW) it is legal to declare an array of unspecified size (e.g. "element_type element[];") which will not contribute to the size of the struct. Then allocation of the handle becomes: Handle theHandle; Size elementCount = kDefaultElementCount; // The number of array elements theHandle = NewHandle(sizeof(myType) + sizeof(element_type) * elementCount); IMHO this is easier than having to remember that you get one element for free in sizeof(myType). >Reference data of this type with a handle and use the memory manager >(ResizeHandle? SizeHandle? I forget at the moment.) to resize it as you >need. You could write a routine: That would be SetHandleSize(); All of the routines dealing with handles are documented in Inside Macintosh: Memory. --Chris _______________________________________________________________________________ Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious Death to the Trojans! Go Bruins! (Insert disclaimer here) Internet: larson@kingston.cs.ucla.edu --------------------------- >From b.kobben@frw.ruu.nl (Barend Kobben) Subject: QuickTime + MIDI? Date: Tue, 11 Oct 1994 15:45:13 GMT Organization: Cartography dept., Utrecht University Hi, REMARK: I recently was shown that if you have Quicktime 2.0 + "QuickTime Musical Instruments" extension, you have the ability to handle MIDI-files. When openening these Midi files with a QuickTime player (like MoviePlayer, PetersPlayer, etc.) you can convert the MIDI file to a Quicktime movie (Sound only, of course). Even better is the ability (under the Options... button) to fiddle around with the instruments. This means that the MIDI instruments (made by Roland, if you believe the About... button) are there, a samples, inside these extensions! QUESTION: Is there a description of this: How is it formatted, how can I handle this from inside my programs? -- Barend Kobben (b.kobben@frw.ruu.nl) Cartography Dept., Utrecht University PO Box 80115, 3508 TC Utrecht, The Netherlands tel +31-(0)30-532086; fax +31-(0)30-540604 +++++++++++++++++++++++++++ >From sandvik@apple.com (Kent Sandvik) Date: Sun, 16 Oct 1994 13:18:45 -0800 Organization: Apple Computer, Inc. Developer Technical Support In article , b.kobben@frw.ruu.nl (Barend Kobben) wrote: > Hi, > > REMARK: I recently was shown that if you have Quicktime 2.0 + "QuickTime > Musical Instruments" extension, you have the ability to handle MIDI-files. > When openening these Midi files with a QuickTime player (like MoviePlayer, > PetersPlayer, etc.) you can convert the MIDI file to a Quicktime movie > (Sound only, of course). > Even better is the ability (under the Options... button) to fiddle around > with the instruments. > This means that the MIDI instruments (made by Roland, if you believe the > About... button) are there, a samples, inside these extensions! Yes, but you need the MoviePlayer version shipped with the 2.0b9 SDK CD. > QUESTION: Is there a description of this: How is it formatted, how can I > handle this from inside my programs? This documentation will be released in the forthcoming SDK CD (2.0 final), as for final dates, sorry I don't have the data. Cheers, KEnt -- Kent Sandvik sandvik@apple.com New Media Analyst/Programmer Private activities on the net not sponsored by the company I work for. +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 17 Oct 94 16:06:59 +1300 Organization: University of Waikato, Hamilton, New Zealand (sorry for the previous failures, our News system ran out of room...) In article , sandvik@apple.com (Kent San dvik) writes: > In article , > b.kobben@frw.ruu.nl (Barend Kobben) wrote: > >> REMARK: I recently was shown that if you have Quicktime 2.0 + "QuickTime >> Musical Instruments" extension, you have the ability to handle MIDI-files. >> When openening these Midi files with a QuickTime player (like MoviePlayer, >> PetersPlayer, etc.) you can convert the MIDI file to a Quicktime movie >> (Sound only, of course). >> Even better is the ability (under the Options... button) to fiddle around >> with the instruments. >> This means that the MIDI instruments (made by Roland, if you believe the >> About... button) are there, a samples, inside these extensions! > > Yes, but you need the MoviePlayer version shipped with the 2.0b9 SDK CD. No you don't! I was trying this out over the weekend, with MoviePlayer 1.0. The MIDI files were off the CD-ROM that came with the July issue of "Future Music" magazine. I copied them to my hard disk, set their type to "Midi", and then did an "Open..." from within MoviePlayer. Sure enough, they showed up, and I was able to convert them. Just one problem: I had to click the "Options..." button before each file would convert properly. If I didn't, I got a garbage movie. Just bringing up the options dialog and clicking "Cancel" to go back to the save dialog was enough. By the way, the options dialog is fun: you get to see all the instruments that are installed, and there's a little keyboard so you can try them out! Lawrence D'Oliveiro fone: +64-7-856-2889 Computer Services Dept 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+13:00 +++++++++++++++++++++++++++ >From jim _reekes@quickmail.apple.com (Jim Reekes) Date: Mon, 17 Oct 1994 22:30:03 GMT Organization: Apple Computer, Inc. In article <1994Oct17.160700.34288@waikato.ac.nz>, ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) wrote: > (sorry for the previous failures, our News system ran out of room...) > > In article , sandvik@apple.com (Kent San > dvik) writes: > > In article , > > b.kobben@frw.ruu.nl (Barend Kobben) wrote: > > > >> REMARK: I recently was shown that if you have Quicktime 2.0 + "QuickTime > >> Musical Instruments" extension, you have the ability to handle MIDI-files. > >> When openening these Midi files with a QuickTime player (like MoviePlayer, > >> PetersPlayer, etc.) you can convert the MIDI file to a Quicktime movie > >> (Sound only, of course). > >> Even better is the ability (under the Options... button) to fiddle around > >> with the instruments. > >> This means that the MIDI instruments (made by Roland, if you believe the > >> About... button) are there, a samples, inside these extensions! > > > > Yes, but you need the MoviePlayer version shipped with the 2.0b9 SDK CD. > > No you don't! I was trying this out over the weekend, with MoviePlayer 1.0. > The MIDI files were off the CD-ROM that came with the July issue of "Future > Music" magazine. I copied them to my hard disk, set their type to "Midi", and > then did an "Open..." from within MoviePlayer. Sure enough, they showed up, > and I was able to convert them. > > Just one problem: I had to click the "Options..." button before each file would > convert properly. If I didn't, I got a garbage movie. Just bringing up the > options dialog and clicking "Cancel" to go back to the save dialog was enough. > > By the way, the options dialog is fun: you get to see all the instruments that > are installed, and there's a little keyboard so you can try them out! The file type needs to be set to 'Midi' and then you import them. But there's a bug and they may get imported as type TEXT. So you get a movie with a TEXT track and not a Midi track. The workaround, as Lawrence has found, is to first click the Options button. Then the Import will work. You only need the new and un-tested version of MoviePlayer to change the instruments *after* importing the Midi file to a movie. - --------------------------------------------------------------------- Jim Reekes, Polterzeitgeist | Macintosh Toolbox Engineering | Sound Manager Expert Apple Computer, Inc. | "All opinions expressed are mine, and do 2 Infinite Loop MS 302-3KS | not necessarily represent those of my Cupertino, CA 95014 | employer, Apple Computer Inc." +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 18 Oct 94 12:15:06 MST Organization: (none) In article , jim _reekes@quickmail.apple.com (Jim Reekes) writes: > In article <1994Oct17.160700.34288@waikato.ac.nz>, ldo@waikato.ac.nz > (Lawrence D'Oliveiro, Waikato University) wrote: > >> (sorry for the previous failures, our News system ran out of room...) >> >> In article , sandvik@apple.com > (Kent San >> dvik) writes: >> > In article , >> > b.kobben@frw.ruu.nl (Barend Kobben) wrote: >> > >> >> REMARK: I recently was shown that if you have Quicktime 2.0 + "QuickTime >> >> Musical Instruments" extension, you have the ability to handle MIDI-files. >> >> When openening these Midi files with a QuickTime player (like MoviePlayer, [mucho snipto] >> >> Just one problem: I had to click the "Options..." button before each > file would >> convert properly. If I didn't, I got a garbage movie. Just bringing up the >> options dialog and clicking "Cancel" to go back to the save dialog was enough. >> >> By the way, the options dialog is fun: you get to see all the instruments that >> are installed, and there's a little keyboard so you can try them out! > > The file type needs to be set to 'Midi' and then you import them. But > there's a bug and they may get imported as type TEXT. So you get a movie > with a TEXT track and not a Midi track. The workaround, as Lawrence has > found, is to first click the Options button. Then the Import will work. > > You only need the new and un-tested version of MoviePlayer to change the > instruments *after* importing the Midi file to a movie. > ON a related question: I know that QT 2.0 has MPEG capabilities also. WHile I'm aware that there's no software-based decompressor, I noticed that when I tried to open a .mpg file off of the SIGGRAPH CD, the latest Movie Player gave me the "CONVERT" button, just like when one converts a sound-track off of an audio CD. Unfortunately, it wouldn't actually do anything, saying "this is not a movie." Is this a feature that wasn't completely implemented, or am I not completing the process correctly? Thanks in advance. Lawson +++++++++++++++++++++++++++ >From paulcho@io.org (Paul C. H. Ho) Date: Wed, 19 Oct 1994 14:42:33 -0500 Organization: Pink Elephant Technologies In article , jim _reekes@quickmail.apple.com (Jim Reekes) wrote: > In article <1994Oct17.160700.34288@waikato.ac.nz>, ldo@waikato.ac.nz > (Lawrence D'Oliveiro, Waikato University) wrote: > > > (sorry for the previous failures, our News system ran out of room...) > > > > In article , sandvik@apple.com > (Kent San > > dvik) writes: > > > > > > Yes, but you need the MoviePlayer version shipped with the 2.0b9 SDK CD. > > > > No you don't! I was trying this out over the weekend, with MoviePlayer 1.0. > > The MIDI files were off the CD-ROM that came with the July issue of "Future > > Music" magazine. I copied them to my hard disk, set their type to "Midi", and > > then did an "Open..." from within MoviePlayer. Sure enough, they showed up, > > and I was able to convert them. > > > > Just one problem: I had to click the "Options..." button before each > file would > > convert properly. If I didn't, I got a garbage movie. Just bringing up the > > options dialog and clicking "Cancel" to go back to the save dialog was enough. > > > > By the way, the options dialog is fun: you get to see all the instruments that > > are installed, and there's a little keyboard so you can try them out! > > The file type needs to be set to 'Midi' and then you import them. But > there's a bug and they may get imported as type TEXT. So you get a movie > with a TEXT track and not a Midi track. The workaround, as Lawrence has > found, is to first click the Options button. Then the Import will work. I wrote a freeware program All Midi to do this in batch. Just drag and drop (based on DropShell 2.0), no need to change file type or click the Options button. All Midi will automatically skip all non-midi file, so you can just drop in a folder. I side step the bug by using Movie Data Exchange directly. > You only need the new and un-tested version of MoviePlayer to change the > instruments *after* importing the Midi file to a movie. For the rest of us, download my shareware QuickMovie to change the instruments after importing the Midi. It's in beta... I wrote four QT midi programs with no document at all (except the header files that come with CW4). Any comment or suggestion on my midi stuff are welcome. ftp://sumex-aim.stanford.edu/info-mac/grf/util/desktop-tv-120.hqx ftp://sumex-aim.stanford.edu/info-mac/grf/util/screen-movie-110.hqx ftp://sumex-aim.stanford.edu/info-mac/grf/util/quick-movie-10b2.hqx ftp://sumex-aim.stanford.edu/info-mac/snd/util/all-midi-10.hqx DesktopTV and ScreenMovie can record MIDI sequence and connect your MIDI keyboard to QT2.0 music instruments via MIDI manager. BTW, where can I find QuickTimeLib for QT 2.0. I can't link quick-movie with the PPC compiler. > ----------------------------------------------------------------------- > Jim Reekes, Polterzeitgeist | Macintosh Toolbox Engineering > | Sound Manager Expert > Apple Computer, Inc. | "All opinions expressed are mine, and do > 2 Infinite Loop MS 302-3KS | not necessarily represent those of my > Cupertino, CA 95014 | employer, Apple Computer Inc." Paul C.H. Ho Pink Elephant Technologies paulcho@io.org Paul_C.H._Ho@magic.ca 74020.772@compuserve.com +++++++++++++++++++++++++++ >From paulcho@io.org (Paul C. H. Ho) Date: Thu, 20 Oct 1994 09:03:13 -0500 Organization: Pink Elephant Technologies In article <1994Oct18.121506@west.cscwc.pima.edu>, 103t_english@west.cscwc.pima.edu wrote: > In article , jim _reekes@quickmail.apple.com (Jim Reekes) writes: > > In article <1994Oct17.160700.34288@waikato.ac.nz>, ldo@waikato.ac.nz > > (Lawrence D'Oliveiro, Waikato University) wrote: > > > >> (sorry for the previous failures, our News system ran out of room...) > >> > >> In article , sandvik@apple.com > > (Kent San > >> dvik) writes: > >> > In article , > >> > b.kobben@frw.ruu.nl (Barend Kobben) wrote: > >> > > >> >> REMARK: I recently was shown that if you have Quicktime 2.0 + "QuickTime > >> >> Musical Instruments" extension, you have the ability to handle MIDI-files. > >> >> When openening these Midi files with a QuickTime player (like MoviePlayer, > > [mucho snipto] > > >> > >> Just one problem: I had to click the "Options..." button before each > > file would > >> convert properly. If I didn't, I got a garbage movie. Just bringing up the > >> options dialog and clicking "Cancel" to go back to the save dialog was enough. > >> > >> By the way, the options dialog is fun: you get to see all the instruments that > >> are installed, and there's a little keyboard so you can try them out! > > > > The file type needs to be set to 'Midi' and then you import them. But > > there's a bug and they may get imported as type TEXT. So you get a movie > > with a TEXT track and not a Midi track. The workaround, as Lawrence has > > found, is to first click the Options button. Then the Import will work. > > > > You only need the new and un-tested version of MoviePlayer to change the > > instruments *after* importing the Midi file to a movie. > > > > > ON a related question: I know that QT 2.0 has MPEG capabilities also. WHile > I'm aware that there's no software-based decompressor, I noticed that when I > tried to open a .mpg file off of the SIGGRAPH CD, the latest Movie Player gave > me the "CONVERT" button, just like when one converts a sound-track off of an > audio CD. > > Unfortunately, it wouldn't actually do anything, saying "this is not a movie." > > Is this a feature that wasn't completely implemented, or am I not completing > the process correctly? It seem QT 2.0 come with 2 MPEG import components and a MPEG media handler but don't have any MPEG codec. That's why it try to import with the 'eat ' component and then run into problem later... > Thanks in advance. > > > Lawson Paul C. H. Ho Pink Elephant Technologies paulcho@io.org Paul_C.H._Ho@magic.ca 74020.772@compuserve.com +++++++++++++++++++++++++++ >From sandvik@apple.com (Kent Sandvik) Date: Sat, 22 Oct 1994 16:07:14 -0800 Organization: Apple Computer, Inc. Developer Technical Support In article <1994Oct17.160700.34288@waikato.ac.nz>, ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) wrote: > No you don't! I was trying this out over the weekend, with MoviePlayer 1.0. > The MIDI files were off the CD-ROM that came with the July issue of "Future > Music" magazine. I copied them to my hard disk, set their type to "Midi", and > then did an "Open..." from within MoviePlayer. Sure enough, they showed up, > and I was able to convert them. Oh, the wonders of the Component Manager. I stand corrected. --Kent -- Kent Sandvik sandvik@apple.com New Media Analyst/Programmer Private activities on the net not sponsored by the company I work for. --------------------------- >From emb121@hearst.cac.psu.edu (Eric Bennett) Subject: Software volume locking: HELP! Date: 18 Oct 1994 15:32:10 GMT Organization: Penn State University I have successfully used PBSetVInfo to software-lock a volume as described in Inside Mac: Files on page 2-147, which deals with PBSetVInfo (call PBGetVInfo, set bit 15 of the ioVAtrb field, and call PBSetVInfo). The only problem is that I cannot UNLOCK these volumes using the same method (this time clearing bit 15)--I get the error "volume locked" (error -43, I think). Yes, the volume is locked, but shouldn't the command which can set the lock be able to unlock it? What toolbox call CAN I use to unlock a software-locked volume? Thanks, Ericb@psu.edu +++++++++++++++++++++++++++ >From psadri@sdcc13.ucsd.edu (Pasha Sadri) Date: Tue, 18 Oct 1994 16:50:22 -0800 Organization: ucsd In article <380ppq$nep@hearst.cac.psu.edu>, emb121@hearst.cac.psu.edu (Eric Bennett) wrote: Yes, the volume is locked, but > shouldn't the command which can set the lock be able to unlock it? > What toolbox call CAN I use to unlock a software-locked volume? hi, Apparantly not. I think you need to clear the bit manually using something like Norton Disk Editor. I don't know how exactly but there was a post sometime ago about how to do this. I know this isn't much help, but at least you won't try that again and know what to look for. : ) Pasha Sadri psadri@ucsd.edu +++++++++++++++++++++++++++ >From emb121@hearst.cac.psu.edu (Eric Bennett) Date: 19 Oct 1994 00:59:54 GMT Organization: Penn State University In article psadri@sdcc13.ucsd.edu (Pasha Sadri) writes: > In article <380ppq$nep@hearst.cac.psu.edu>, emb121@hearst.cac.psu.edu > (Eric Bennett) wrote: > > Yes, the volume is locked, but > > shouldn't the command which can set the lock be able to unlock it? > > What toolbox call CAN I use to unlock a software-locked volume? > > hi, > > Apparantly not. I think you need to clear the bit manually using something > like Norton Disk Editor. I don't know how exactly but there was a post > sometime ago about how to do this. > > I know this isn't much help, but at least you won't try that again and > know what to look for. : ) > I know how to clear the bit with Norton Disk Editor--don't worry, I haven't done any damage to myself. But clearing the bit with NDE seems like a very non-Mac way of doing things. I'm sure that there has to be a toolbox call that will do this--I just have no idea what it is (alternatively, writing directly to the disk from within my program as NDE does ought to work, but I don't want to do that--I want to use a standard and SAFE toolbox call. -Ericb@psu.edu +++++++++++++++++++++++++++ >From lebra@cs.concordia.ca (LEBRA olivier) Date: 19 Oct 1994 16:05:00 GMT Organization: Dept. of Computer Science, Concordia University In article <380ppq$nep@hearst.cac.psu.edu>, emb121@hearst.cac.psu.edu (Eric Bennett) writes: |> I have successfully used PBSetVInfo to software-lock a volume as |> described in Inside Mac: Files on page 2-147, which deals with |> PBSetVInfo (call PBGetVInfo, set bit 15 of the ioVAtrb field, and call |> PBSetVInfo). The only problem is that I cannot UNLOCK these volumes |> using the same method (this time clearing bit 15)--I get the error |> "volume locked" (error -43, I think). Yes, the volume is locked, but |> shouldn't the command which can set the lock be able to unlock it? |> What toolbox call CAN I use to unlock a software-locked volume? |> |> Thanks, |> Ericb@psu.edu I will help you ! I have made a soft called DiskLocker that made what you want. Before unlocking the disk with PBSetVInfo, you must update a global variable used by the Finder. I do not remember its name and its structure but I will check at home and I will reply to you again soon. olivier lebra olebra@aedi.insa-lyon.fr or lebra@cs.concordia.ca +++++++++++++++++++++++++++ >From sbryan@maroon.tc.umn.edu (Steve Bryan) Date: Fri, 21 Oct 1994 06:24:29 GMT Organization: Sexton Software > In article <380ppq$nep@hearst.cac.psu.edu>, emb121@hearst.cac.psu.edu > (Eric Bennett) wrote: > > Yes, the volume is locked, but > > shouldn't the command which can set the lock be able to unlock it? > > What toolbox call CAN I use to unlock a software-locked volume? > I don't know if you already have the response but the trick is to update the vcb queue elem before making the unlock toolbox call. You can get the vcb queue elem either by "walking the vcb queue" and setting the appropriate bit in place (I think it is one of the bits in the attribute field) or make a couple of calls to PBGetVInfo and PBSetVInfo. This strategy worked for a little control panel I wrote many years ago (ie the source code is not handy). Good luck. -- Steve Bryan InterNet: sbryan@maroon.tc.umn.edu Sexton Software CompuServe: 76545,527 Minneapolis, MN Fax: (612) 929-1799 +++++++++++++++++++++++++++ >From lebra@cs.concordia.ca (LEBRA olivier) Date: 21 Oct 1994 19:08:39 GMT Organization: Dept. of Computer Science, Concordia University In article , sbryan@maroon.tc.umn.edu (Steve Bryan) writes: |> > In article <380ppq$nep@hearst.cac.psu.edu>, emb121@hearst.cac.psu.edu |> > (Eric Bennett) wrote: |> > |> > Yes, the volume is locked, but |> > > shouldn't the command which can set the lock be able to unlock it? |> > > What toolbox call CAN I use to unlock a software-locked volume? |> > |> |> I don't know if you already have the response but the trick is to update |> the vcb queue elem before making the unlock toolbox call. You can get the |> vcb queue elem either by "walking the vcb queue" and setting the |> appropriate bit in place (I think it is one of the bits in the attribute |> field) or make a couple of calls to PBGetVInfo and PBSetVInfo. This |> strategy worked for a little control panel I wrote many years ago (ie the |> source code is not handy). Good luck. |> |> -- |> Steve Bryan InterNet: sbryan@maroon.tc.umn.edu |> Sexton Software CompuServe: 76545,527 |> Minneapolis, MN Fax: (612) 929-1799 I think the simplest way to update the vcb queue is : DefVCBPtr->vcbAtrb &= 0x7FFF; -- ********************************************************************* * olivier * Until July 1996 : olebra@aedi.insa-lyon.fr * * lebra * Until May 1995 : lebra@cs.concordia.ca * ********************************************************************* * 1950, Lincoln App #1707 - H3H 2N8 Montreal, Quebec - CANADA * * Phone : (+1) 514-846 9781 * ********************************************************************* * "La simplicite est l'ultime forme de la sophistication." * ********************************************************************* +++++++++++++++++++++++++++ >From emb121@hearst.cac.psu.edu (Eric Bennett) Date: 24 Oct 1994 16:18:11 GMT Organization: Penn State University In article <88387349253@jonathan.srcc.msu.su> kluev@jonathan.srcc.msu.su (Kluev) writes: > Try clear locked flag of vcbAtrb field of VCB describing volume. > You can find VCB using GetVCBQHdr call and stepping via dLink > field until you find the volume. This method, however, should > be treated as modifying internal File Manager structures and > should be avoided if possible. I know--Inside Mac says DON'T PLAY WITH THE VCB--it is supposed to be read only, not written to. My question was, if I'm not supposed to modify the VCB, how do I unlock the volume? (Incidentally, when I tried modifying the VCB, my machine locked up; however, since that's the only suggestion I've gotten, I guess I'll try doing it again :). -Ericb@psu.edu --------------------------- >From rang@winternet.com (Anton Rang) Subject: Some string routines for the PowerPC Date: 15 Oct 1994 21:29:50 GMT Organization: Trillium Research, Inc. Archive-name: ppc-string-utils.txt Submitted-by: rang@winternet.com This file implements some basic string routines for both C and Pascal strings. It's written in PowerPC assembly. I did this mainly as a learning experience; I was bored one day, and wanted to play with the string instructions. Routines implemented here are: strcpy and strcat -- both of these are about 30% faster than those provided by Apple or Metrowerks. pstrcpy and pstrcat -- very fast versions of the above for use with Pascal-style strings; much faster than those provided by Apple (PLstrcpy/PLstrcat). pstreq -- a fast equality test for Pascal-style strings. If there's interest, I may develop and post more of these later. I've appended a binhexed object library for those without an assembler. An open question: Is there interest in developing a complete, or at least subset, copyright-free, optimized, ANSI library for the PowerPC? I see people complaining about Metrowerks' implementation, and neither Metrowerks nor Apple has so far released a highly optimized library. I'd rather see them concentrating on compiler technology, anyway. If there's enough interest, surely those of us on the net could compile a reasonably complete library. This would surely benefit all of the Mac community. -- Anton - -------- mylib.s ; ; Anton's library of handy string routines and such. ; ; ; char *strcpy(char *, const char *) ; ; Copy a null-terminated string from one location to another; return the first location. ; This goes really fast if you use the POWER 'lscbx' instruction. *sigh* ; export my_strcpy[DS] export .my_strcpy[PR] toc tc my_strcpy[TC], my_strcpy[DS] csect my_strcpy[DS] dc.l .my_strcpy[PR] dc.l TOC[tc0] dc.l 0 csect .my_strcpy[PR] ; First, move R3 into R5, so we have a copy we can change. Bias it down by one byte. ; Bias R4 down too. subi r5, r3, 1 subi r4, r4, 1 ; Read a byte, store it, and compare it against zero. Loop until we find the zero. ; By issuing the compare before the store, we save one cycle in branch resolution. @0: lbzu r0, 1(r4) cmpwi r0, 0 stbu r0, 1(r5) bne @0 ; All done. Note that R3 has the return value already. blr ; ; void pstrcpy(unsigned char *, const unsigned char *) ; ; Copy a byte-counted string from one location to another. ; export pstrcpy[DS] export .pstrcpy[PR] toc tc pstrcpy[TC], pstrcpy[DS] csect pstrcpy[DS] dc.l .pstrcpy[PR] dc.l TOC[tc0] dc.l 0 csect .pstrcpy[PR] ; Get the byte count, and add one to it to include the length byte. lbz r5, 0(r4) addi r5, r5, 1 ; If the length is <= 32, we can complete the move in one pass. We assume that this ; is the most common case, and hence set the branch-predict bit here. ; (Why 32 bytes? We have 8 non-volatile scratch registers, R5..R12, to use.) @0: cmpwi r5, 32 ble+ @1 ; OK...more than 32 bytes to move. We'll move 28 bytes and then see if we can finish. ; (Why 28 bytes? We're holding the length in R5, so we only have 7 scratch registers.) subi r5, r5, 28 lswi r6, r4, 28 addi r4, r4, 28 stswi r6, r3, 28 addi r3, r3, 28 b @0 ; We complete the move here, mov b @0 ; We complete the move here, moving between 1 and 32 bytes. @1: mtxer r5 lswx r5, r0, r4 stswx r5, r0, r3 blr ; ; char *strcat(char *, const char *) ; ; Concatenate a null-terminated string onto another; return the address of the first string. ; export my_strcat[DS] export .my_strcat[PR] toc tc my_strcat[TC], my_strcat[DS] csect my_strcat[DS] dc.l .my_strcat[PR] dc.l TOC[tc0] dc.l 0 csect .my_strcat[PR] ; First, move R3 into R5, so we have a copy we can change. Bias it down by one byte. ; Bias R4 down too. subi r5, r3, 1 subi r4, r4, 1 ; Walk down the first string to its end. @0: lbzu r0, 1(r5) cmpwi r0, 0 bne @0 ; R5 is now one byte past the end of the string. Go backwards to bytes, so that ; it points just before the end of the string. subi r5, r5, 2 ; Read a byte, store it, and compare it against zero. Loop until we find the zero. ; By issuing the compare before the store, we save one cycle in branch resolution. @1: lbzu r0, 1(r4) cmpwi r0, 0 stbu r0, 1(r5) bne @1 ; All done. Note that R3 has the return value already. blr ; ; void pstrcat(unsigned char *, const unsigned char *) ; ; Concatenate a byte-counted string onto another. This doesn't do any error checking. ; export pstrcat[DS] export .pstrcat[PR] toc tc pstrcat[TC], pstrcat[DS] csect pstrcat[DS] dc.l .pstrcat[PR] dc.l TOC[tc0] dc.l 0 csect .pstrcat[PR] ; Get the byte count of both strings. lbz r6, 0(r3) lbz r5, 0(r4) ; Note that lswx/stswx are defined to do nothing if the length (in XER) is zero. ; If they weren't, we would want the following two lines, to check that the ; concatenation is actually doing something. ; cmpwi r5, 0 ; beqlr ; Add them together to get the new length; store it. add r7, r6, r5 stb r7, 0(r3) ; Move destination address past old data (length + 1 bytes). ; Move source address past its length too (1 byte). addi r3, r3, 1 addi r4, r4, 1 add r3, r3, r6 ; If the length is <= 32, we can complete the move in one pass. We assume that this ; is the most common case, and hence set the branch-predict bit here. ; (Why 32 bytes? We have 8 non-volatile scratch registers, R5..R12, to use.) @0: cmpwi r5, 32 ble+ @1 ; OK...more than 32 bytes to move. We'll move 28 bytes and then see if we can finish. ; (Why 28 bytes? We're holding the length in R5, so we only have 7 scratch registers.) subi r5, r5, 28 lswi r6, r4, 28 addi r4, r4, 28 stswi r6, r3, 28 addi r3, r3, 28 b @0 ; We complete the move here, moving between 1 and 32 bytes. @1: mtxer r5 lswx r5, r0, r4 stswx r5, r0, r3 blr ; ; void pstrcatchr(unsigned char *dest, unsigned char src) ; ; Concatenate a single character onto a byte-counted string. ; export pstrcatchr[DS] export .pstrcatchr[PR] toc tc pstrcatchr[TC], pstrcatchr[DS] csect pstrcatchr[DS] dc.l .pstrcatchr[PR] dc.l TOC[tc0] dc.l 0 csect .pstrcatchr[PR] ; Get the byte count of the string; add one to it and store it back. lbz r5, 0(r3) addi r5, r5, 1 stb r5, 0(r3) ; Store the character we want to concatenate at the end of the string, and return. stbx r4, r3, r5 blr ; ; Boolean pstreq(unsigned char *s1, unsigned char *s2) ; ; Compare two byte-counted strings for equality; return true (1) if they're equal. ; export pstreq[DS] export .pstreq[PR] toc tc pstreq[TC], pstreq[DS] csect pstreq[DS] dc.l .pstreq[PR] dc.l TOC[tc0] dc.l 0 csect .pstreq[PR] ; First, get the byte count of both strings. lbz r5, 0(r3) lbz r6, 0(r4) ; If the byte counts aren't equal, fail immediately. cmpw r5, r6 bne @fail ; OK, we have two strings of matching length. Increment the addresses to point to ; the actual text of the strings. addi r3, r3, 1 addi r4, r4, 1 ; If the length is <= 16, we can complete the comparison in one pass. We assume ; that this is the most common case, and hence set the branch-predict bit here. ; (Why 16 bytes? We have 8 non-volatile scratch registers, R5..R12, to use.) @0: cmpwi r5, 16 ble+ @1 ; OK...more than 16 bytes to compare. We'll compare 12 bytes and then see if we can ; finish. (Why 12 bytes? The length is in R5, so we only have 7 scratch registers, ; and we can only use whole registers for the string-load instructions.) lswi r6, r3, 12 lswi r9, r4, 12 addi r3, r3, 12 addi r4, r4, 12 subi r5, r5, 12 ; Compare each of the register pairs R6/R9, R7/R10, R8/R11. If any differs, exit. cmp 0, 0, r6, r9 cmp 1, 0, r7, r10 cmp 2, 0, r8, r11 bne 0, @fail bne 1, @fail bne 2, @fail b @0 ; We complete the comparison here, comparing between 1 and 16 bytes. ; If R5 is zero, we succeed immediately. @1: cmpwi r5, 0 beq @succ ; Load the strings into R5..R8 and R9..R12. Save R5 first. mr r0, r5 mtxer r5 lswx r5, r0, r3 lswx r9, r0, r4 ; Compare R5 against R9; if they differ, fail. ; If they're the same, and R0 is <= 4, succeed. cmp 0, 0, r5, r9 cmpi 1, 0, r0, 4 bne 0, @fail ble 1, @succ ; Compare R6 against R10; fail if different. Succeed if R0 <= 8. cmp 0, 0, r6, r10 cmpi 1, 0, r0, 8 bne 0, @fail ble 1, @succ ; Compare R7 against R11; fail if different. Succeed if R0 <= 12. cmp 0, 0, r7, r11 cmpi 1, 0, r0, 12 bne 0, @fail ble 1, @succ ; compare R8 against R12; fail if different, succeed if same. cmpw r7, r11 bne @fail ; Success! @succ: li r3, 1 blr ; Failure @fail: li r3, 0 blr - ----- mylib.s.o.hqx (This file must be converted with BinHex 4.0) :#@ejE'PL,R-ZE`"B3dp'69"6)!#3"!CJ!*!%-AJ"h`!#UX9iiJ!!!`J!N!-T!*! %,R4PH(3!N!d"N!!!N!0N!*!2)#jNBA4K!*!&!C!!!!!"N!!!N!0J!!!"p!!!!P3 !N!85!*!&3$LMrrmiK2rrM!3!!5`!N!1F"3!"3),rp%k!!##)T!!!1+8!!5`&!#" !S3!F1+Arj(c%j+SiK!!FI-2PUMKM!"a,rrrNI+%$TRbJ*#TmS"dU6S!!)$LMrrm iK2rrM!8!!5`!N!0!J[ri1+ArrS`%!!%X!*!$R!8!!8##rr41J!!JL--!!)LN!!" mjLS8Q1-!!$KM!!%iK!!"I'-b&#`&!#"!S3!F1+Arj(c%j+SiK!!FI-2PUMKM!"a ,rrrNI+%$TRbJ*#TmS"dU6S!!))LM!!!iT3!"Q+-!!(b$+Dj1J!!JL+-!!)M%!!" m"6!!3))!R$KM!!%iK!!",!8!%%#K!$4m`f5UI54NUMKM!!`iK!!-1+Arp(`'5!" mKe!!I3KB!%##!'K!KJ"N3)S!B%[rrm`X"3!!3B)!6(bJ+hKmS31QI+!F+RdJ*#T m"8J!,)!!"%##!$K!K3!XI!C3!#b!!!K!JJ!S3)8!((`(@!!XJ!!-3))!'%#&!!a m"eJ!3))!$$KJ!!&1J!!J1'!!!%k!!#!!N!B"f!#3"a`!!!(B!*!(9!!!!GJ!N!H !!!!"f!#3"m`!!!(B!*!(i!!!!GJ!N!B"N!!!!!'F!!!"U!!!!E3!!!(!!!!"c!! !!C!!!*!$#4m!N!-"P!#3!`-I!*!$!C`!N!-2(`#3!`'J!*!$!am!N!-"U!#3!a8 I!*!$!D`!N!-$(`#3!`'d!*!$'am!N!-"Z!#3!`-I!*!$!F!!N!-K(`#3!`(%!*! $!am!N!-"c!#3!bFI!*!$!G!!N!-$(`#3!`(B!*!$"am!N!-"h!#3!`dI!*!$!H! !N!-6(`#3!`(N!*!$'4m!N!-"k!#3!amI!*!$!H`!N!-P(`"YH@aTBLjc!*!&rri -!@F!N!i"!!"V!3#3#K%!N!G86d-!N!F"f!!#!!"V!3#3#K%2!*!0"!!!!GJ!!J! !D`%!N!-%!*!'%3-!N!d1!!!"N!!!!J!!!J%!N!--!*!'%3S!N!dB!*!&!3!!!J% !N!-F!*!'%3#3"h"cG(*MF(N!N!-"h!!#!!"V!3#3!`3!N!B4!`#3"R"cG(*MF(N !N!-"R!!#!!!#!3#3!``!N!B4#J#3$5-!N!-F!!%!!!)"!*!$1!#3"K%!N!iX!!! "i!!#!!"V!3#3!`3!N!B4!`#3$6B!!!'S!!)!!!)"!*!$$!#3"K%+!*!03!#3!e3 !!3!!!J%!N!-X!*!'%3#3"h"cG(*MBA3!N!-"j!!#!!"V!3#3!`3!N!B4!`#3"R" cG(*MBA3!N!-"Y!!#!!!#!3#3!``!N!B4#J#3$8X!N!1!!!%!!!)"!*!$6!#3"K% !N!j8!!!"k!!#!!"V!3#3!`3!N!B4!`#3$9m!!!(!!!)!!!)"!*!$$!#3"K%+!*! 0DJ#3!m`!!3!!!J%!N!-8!*!'%3#3"h"cG(*PF3#3"!(X!!)!!'X"!*!$"!#3"K% $!*!'F(0dFQ9a!*!%!F`!!J!!!J%!N!--!*!'%3S!N!BZF(0dFQ9a!*!%i!!"!!! #!3#3!l!!N!B4!*!+GQejAh0dFQ0`H3"YH9pcG(*MF(N!,QejAh0dFQ0`H3!ZF(0 dFQ0`H3"YH9pcG(*MBA3!EAPIFh4bBf&d!#jYH9pcG(*MBA3!,R"cG(*MBA3!F(0 dFQ0KG'0SFJ"`Fh4bBf&dBfKb!#j`Fh4bBf&dBfKb!1RK!!!: -- Anton Rang (rang@winternet.com) --------------------------- >From blob@apple.com (Brian Bechtel) Subject: Tech Notes on the World Wide Web, and History Is Made Date: 19 Oct 1994 16:49:23 -0700 Organization: Apple Computer, Inc., Cupertino, California New excitement on the digital traffic jam. Apple has now put all the tech notes (including the four new technotes from the November developer CD which is _just_ going into the mail to our developers right now as I type) on the Web. Use Mosaic. Use MacWeb. Use NetScape. Explore. http://www.info.apple.com/dev/technotes/Main.html The new tech notes include Jim Luther's "FL 37 Permission to do What?!!?" (file permissions), Nitin Ganatra's "PS 02 Background-Only Applications" (a revision of how to write faceless background applications), Brian Bechtel's "OS 06 Control Strip Modules" (docs for writing Control Strip modules, revised and corrected), and... Errata for Inside Macintosh:Networking Yeah. That's right. Rich Kubota and Scott Kuechle put together an actual list of known errors in Inside Macintosh:Networking. We have more errata sheets under review, too. When they get reviewed, we'll put them up there as well. For some help on getting started programming the Mac (and a desperate plea for some feedback on said help), look at http://www.info.apple.com/dev/default.html If you find this stuff useful, please let us know. Thanks to Michelle Wyner, ex-intern, and Mark Cookson for doing all the real work. --Brian Bechtel blob@apple.com "My opinion, not Apple's" If you don't know all these buzzwords, go read a different newsgroup until you do. Don't ask me; hell, I made up half of them myself. --------------------------- End of C.S.M.P. Digest **********************