Path: utzoo!mnetor!uunet!husc6!endor!olson
From: olson@endor.harvard.edu (Eric K. Olson)
Newsgroups: comp.sys.mac
Subject: Re: Question about WDEF routines.
Message-ID: <3709@husc6.harvard.edu>
Date: 5 Jan 88 04:56:59 GMT
References: <7595@sunybcs.UUCP> <7126@apple.UUCP>
Sender: news@husc6.harvard.edu
Reply-To: olson@endor.UUCP (Eric K. Olson)
Distribution: na
Organization: Lexington Software Design
Lines: 46

In a recent article Larry Rosenstein writes:
>In article <7595@sunybcs.UUCP> domino@sunybcs.UUCP (Michael Domino) writes:
>>    ...usual init stuff...
>>        
>>        /* The window is created invisible. */          
>>        w = GetNewWindow(windowID, NULL, (WindowPtr)(-1L));
>>        (WindowPeek)w->windowDefProc = NewHandle(0L);
>>        *((WindowPeek)w->windowDefProc) = (Ptr)WindowDef;
>>        ShowWindow(w);  
>
>One problem is that this code trashes the heap.  It is creating a handle and
>replacing the master pointer.  The block that was created contains a back
>pointer to the master pointer, which the Memory Manager uses when the heap
>needs to be compacted.
>
>[About how MacTutor has published this technique more than once]
>
>The correct thing to do is allocate a 6-byte handle and install a 68000 JMP
>instruction in the handle, which goes to the defproc.  The first 2 bytes of
>such an instruction are $4EF9; the last 4 bytes should be the address of the
>defproc procedure.  Then you simply install the handle in the window record.

While writing a WDEF I got sick of repeatedly compiling it into a resource
and came up with another method for testing code fragments that need to
be referenced as handles.  I believe it will not trash the heap, and is
correct (if somewhat unorthadox):

If you have a compiler that can specify code segments (LSC, for example),
move the WDEF code into a segment of its own and do a GetResource('CODE',id)
and a DetachResource of the returned handle.  This gives you a private
copy of the code, referenced as a handle.  Detaching it ensures that it will
not be mucked with by the segment loader or resource manager.  You may also
need to HNoPurge the handle, depending on how it is flagged in the resource
file.

This works well for me, and I can't see a reason why it would screw anything
up.  On the other hand, I would never do such a thing after the WDEF is
done being developed, since the WDEF resource/ProcId Window Field combo
works so very well.

-Eric


                      (defun maybe (x) (maybe (not x)))
Eric K. Olson     olson@endor.harvard.edu     harvard!endor!olson     D0760
   (Name)                (ArpaNet)                 (UseNet)        (AppleLink)