Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!labrea!Shasta!mrh
From: mrh@Shasta.STANFORD.EDU (Marc Hannah)
Newsgroups: comp.sys.mac
Subject: Re: MPW C 2.0 interfaces into ColorQuickDraw
Message-ID: <2009@Shasta.STANFORD.EDU>
Date: Thu, 10-Sep-87 13:50:41 EDT
Article-I.D.: Shasta.2009
Posted: Thu Sep 10 13:50:41 1987
Date-Received: Sat, 12-Sep-87 09:24:43 EDT
References: <2001@Shasta.STANFORD.EDU> <2816@husc6.UUCP>
Organization: Stanford University
Lines: 22
Keywords: GetNewCWindow, CopyPix

In article <2816@husc6.UUCP>, stew@endor.harvard.edu (Stew Rubenstein) writes:
> In article <2001@Shasta.STANFORD.EDU> daveg%slacvm.bitnet@forsythe.stanford.edu (David Gelphman) writes:
> 
> They have indeed been eliminated.  CopyBits will now handle a PixMap
> as well as a BitMap, and GetNewWindow creates a color window if there
> is a 'wctb' resource with the same ID as the WIND resource.
> 
> Stew Rubenstein
     
    Will the REAL Inside Mac Volume V please stand up. Golly it is tough
sometimes. The CopyBits <-> CopyPix change I could believe and figured it
out. The use of GetNewWindow makes sense so you can color a window without
making changes to the source code. What really threw me off however is:
1. The LSC, LSP, and the MPW Assembler interfaces all have a GetNewCWindow
   call or trap.
2. Compiling the code with GetNewWindow and Fediting the GetNewWindow
   opcode to GetNewCWindow worked fine.

From this I gather that the already existing Rom code will not be supported
on direct call. 
Thanks to those who replied on this.
David Gelphman      daveg%slacvm.bitnet@forsythe.stanford.edu