From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-048 Date: Thu, 28 Jul 1994 15:48:03 +0200 (MET DST) C.S.M.P. Digest Thu, 28 Jul 94 Volume 3 : Issue 48 Today's Topics: Color in System 7 popups? Controlling Apple MultiSync Monitors Drag Mgr problem w- flavorTypePromiseHFS GWorlds and other questions - Help PBControl() "hangs" the Macintosh Patching the GetResource() toolbox routine 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 summeral@benji.Colorado.EDU (Summerall Thomas G) Subject: Color in System 7 popups? Date: Tue, 5 Jul 1994 23:13:04 GMT Organization: University of Colorado, Boulder This is probably a common question, so I apologize in advance. Can the standard system 7 popup cdef use colored menu items? If so, how? It doesn't seem to recognize mctb resources associated with the menu I'm adding. What am I missing here? If it isn't a feature of system 7, is there a public domain library that can accomplish this? Thanks, Tom Summerall +++++++++++++++++++++++++++ >From ari@world.std.com (Ari I Halberstadt) Date: Wed, 13 Jul 1994 01:59:45 GMT Organization: The World Public Access UNIX, Brookline, MA In article , Summerall Thomas G wrote: >This is probably a common question, so I apologize in advance. > >Can the standard system 7 popup cdef use colored menu items? If so, how? It >doesn't seem to recognize mctb resources associated with the menu I'm >adding. What am I missing here? If it isn't a feature of system 7, is >there a public domain library that can accomplish this? Soon there will be a free CDEF that supports color. My popup CDEF already does most of what you might wan, but its current version (1.0b3) doesn't work in color grafports. I'm adding color support right now, and it should be ready within a week or two. There are still some bugs (visual appearance things, not crashing) that may require another release or two before I finally discover the magical solution. The system 7 CDEF seemed to crash when I added a mctb resource and tried to display the menu's title. I'm also thinking of adding coloration using an auxillary control color resource, with part codes for the text, outline, down arrow, etc. of the control. While on this topic, the width of my CDEF is perfect when run on a macplus. That is, when the menu is displayed, its width is enlarged to cover the down arrow and the margins around the menu. But on a Quadra, the width isn't enlarged, it just is set to the actual width of the menu. Just before calling PopupMenuSelect I set the menuWidth field of the menu handle to the desired width, but on the color machine the width I specify is just being ignored. Does anyone know of some magical workaround to this problem? -- Ari Halberstadt ari@world.std.com One generation passes away, and another generation comes: but the earth abides for ever. -- Ecclesiastes, 1:4. +++++++++++++++++++++++++++ >From leonardr@netcom.com (Leonard Rosenthol) Date: Wed, 13 Jul 1994 21:47:09 GMT Organization: Aladdin Systems, Inc. In article , ari@world.std.com (Ari I Halberstadt) wrote: > While on this topic, the width of my CDEF is perfect when run on a > macplus. That is, when the menu is displayed, its width is enlarged to > cover the down arrow and the margins around the menu. But on a Quadra, > the width isn't enlarged, it just is set to the actual width of the > menu. Just before calling PopupMenuSelect I set the menuWidth field of > the menu handle to the desired width, but on the color machine the > width I specify is just being ignored. Does anyone know of some > magical workaround to this problem? > The problem/situation is that PopupMenuSelect() will call CalcMenuWidth on the menu before the menu gets drawn and so the MDEF will recalc the size w/o the arrow :(. The standard solution to this is to create a "stub" MDEF which knows to resize the width on a calc message. If you need a code sample, let me know. Leonard - ------------------------------------------------------------------------ Leonard Rosenthol Internet: leonardr@netcom.com Director of Advanced Technology AppleLink: MACgician Aladdin Systems, Inc. GEnie: MACgician --------------------------- >From tgaul@halcyon.com (Troy Gaul) Subject: Controlling Apple MultiSync Monitors Date: Fri, 08 Jul 1994 22:57:23 -0700 Organization: Infinity Systems Is there an API that can be used to determine when the resolution of a MultiSync monitor changes? Obviously, one could walk the GDevices when returning from being switched into the foreground, or checked during idle time, but is there any other way to find out immediately? On a related note, is there any way to force a change of resolution via a call (or a driver Control call)? I'm considering an extension that would facilitate changing monitor resolutions, but I haven't been able to find the developer notes for MultiSync monitors. Thanks, _troy //////// //////___Troy Gaul____________________tgaul@halcyon.com___// // // Infinity Systems // // // // Redmond, Washington // // //////____________________________________________________// +++++++++++++++++++++++++++ >From Dave Falkenburg Date: Wed, 13 Jul 1994 18:40:06 GMT Organization: Apple Computer, Inc. In article Troy Gaul, tgaul@halcyon.com writes: >Is there an API that can be used to determine when the resolution of a >MultiSync monitor changes? Obviously, one could walk the GDevices when >returning from being switched into the foreground, or checked during idle >time, but is there any other way to find out immediately? Yes, but somehow nobody wrote any tech notes yet. The API is defined in , but is cryptic at best. The Display Manager allows an application to install an AppleEvent handler to detect when a display has been changed (e.g., a new display has come online because you've docked a Duo, or you change the resolution of a multisynch monitor via the monitors control panel). BTW: Extensions can supply a callback function instead of relying on an AppleEvent. In order to receive this AppleEvent, you must set the displayManagerAware bit in your size resource, and install an AppleEvent Handler for kCoreEventClass,kSystemConfigNotice (or something like that). NOTE: If you choose to become "display manager aware", you must also be prepared to deal with the change in displays and keep your windows onscreen. This is just screaming for a tech note, some sample code, and a develop or MacTech magazine article. -Dave Falkenburg -Apple Computer, Inc. +++++++++++++++++++++++++++ >From Dave Falkenburg Date: Wed, 13 Jul 1994 18:43:25 GMT Organization: Apple Computer, Inc. In article Troy Gaul, tgaul@halcyon.com writes: >On a related note, is there any way to force a change of resolution via a >call (or a driver Control call)? I'm considering an extension that would >facilitate changing monitor resolutions, but I haven't been able to find >the developer notes for MultiSync monitors. Oops. Forgot to mention that all you really need to do this is a special video adapter cable. I have an NEC 6FG & their "PowerMac" video cable adpater which converts the Mac's video cable into that industry standard SVGA type connector. Under System 7.1.2 on a PowerMac, or System 7.5 on most other recent machines with built in video, all you need to do is go to the Monitors control panel to swich resolutions. -Dave Falkenburg -Apple Computer, Inc. --------------------------- >From ron@mcs.com (Ron Schneider) Subject: Drag Mgr problem w- flavorTypePromiseHFS Date: Tue, 12 Jul 1994 22:36:36 -0600 Organization: Just a guy... I'm playing with the drag manager, and have incorporated it into my app. Everything works fine, all my handlers are called, I'm dragging text between apps, sounds, creating clipping flies, etc. Most cool. But I can't get flavorTypePromiseHFS to work. As I'm dragging around, the Finder correctly hilites applications that accept the file type I specified in the PromiseHFSFlavor struct, and my DragSendDataProc is called back at the correct time to return the FSSpec of the created file. But nothing ever happens! The TrackDrag routine returns noErr. I have AppleEvents turned on, DragPeek returns the expected results, System 7.1 w/ the DragManager, Clipping Extension, etc all installed and working. I am reduced to random changes hoping to stumble onto the solution. Here are some questions I have come up with. 1. Are there any examples in the universe that show the 'phfs' flavor in use? Or anywhere in the finder that uses it so I could use DragPeek to look at what is happening? 2. The doc says (I love online docs!) 'This structure (PromiseHFSFlavor) allows you to create the file in your DragSendDataProc, and provide the FSSpec for the new file at that time.' What does this really mean? In the DragSendDataProc do I specify a completed HFSFlavor, or a completed FSSpec, or maybe an alias like all the AppleEvent stuff? I have tried all, same non-results. 3. I have noticed the Finder trims its FSSpecs in the 'hfs ' flavors to the minimum length, whereas it is easier for me to pass sizeof( HFSFlavor ) or sizeof( FSSpec ), since the filename length is in the structure anyway. Does it matter? (I have tried both). Thanks for any help, suggestions, sympathy, or pointers that you can offer! -- ron schneider ron@mcs.com, ron@odesta.com .sig under construction +++++++++++++++++++++++++++ >From leonardr@netcom.com (Leonard Rosenthol) Date: Wed, 13 Jul 1994 21:53:32 GMT Organization: Aladdin Systems, Inc. In article , ron@mcs.com (Ron Schneider) wrote: > 1. Are there any examples in the universe that show the 'phfs' flavor in > use? Or anywhere in the finder that uses it so I could use DragPeek to > look at what is happening? > I believe that the HFS sample app in the Mac Drag & Drop folder on the Mozart beta CD (and therefore the WWDC CD) shows what you need to know about using promise HFS flavors. Here is some "sample" code that should show what how to deal with promiseHFS flavors in your sendProc. This code will definitely not compile as is (it's missing var & function declarations but shows the important stuff! Leonard - ---------- pascal OSErr SampleSendDataProc(FlavorType theType, void *refCon, ItemReference theItem, DragReference theDrag) { OSErr result = noErr; AEDesc dropLoc, specDesc; FSSpec myFSSpec; long dataSize; short tempVRef; long tempDirID; if (theType == flavorTypePromiseSample) { if (!GetDropLocation(theDrag, &dropLoc)) { if(!GetDropLocationDirectory(&dropLoc, &defdir, &defvol)) { dataSize = sizeof(sampleFlavorRec); if (result = GetFlavorData(theDrag, theItem, flavorTypeSample, &mySFRec, &dataSize, 0L)) goto out; result = FindFolder(defvol, kTrashFolderType, kDontCreateFolder, &tempVRef, &tempDirID); // Check if the destination is the trash - if so delete if ((tempVRef == defvol) && (tempDirID == defdir)) { if(firstPromise) DeleteIt(); } else { // youšve been grabbed - do something with the it!!! if(!abort) { myFSSpec.vRefNum = defvol; myFSSpec.parID = defdir; NameCopy(string,myFSSpec.name); result = SetDragItemFlavorData(theDrag,theItem,flavorTypePromiseSample, &myFSSpec,sizeof(FSSpec),0); } } firstPromise = FALSE; } } } else { return(cantGetFlavorErr); } out: return(result ? cantGetFlavorErr : noErr); } - ------------------------------------------------------------------------ Leonard Rosenthol Internet: leonardr@netcom.com Director of Advanced Technology AppleLink: MACgician Aladdin Systems, Inc. GEnie: MACgician --------------------------- >From cconstan@epdiv1.env.gov.bc.ca (Carl B. Constantine) Subject: GWorlds and other questions - Help Date: Wed, 13 Jul 1994 07:59:52 -0700 Organization: Ministry of Environment, Lands & Parks It seems, no matter how much material I read on GWorlds & CopyBits, et. al, it doesn't answer some of my main questions. So I humbly turn to the experts on the net for your guided support and help. 1) IM IV says to set RGBForeColor to White and RGBBackColor to Black before using CopyBits to avoid colorization. That's great, but I've seen many examples where people don't do this. My question is, do you have to do it for Color GWorlds? 2) I've seen alot about rowBytes and BaseAddr values for PixMaps/BitMaps. How you have to set it to long word aligned for fastest copying. If you use NewGWorld to create your offscreen port (as opposed to OpenCPort), do you still need to set these values or does NewGWorld do it for you? 3) Develop 17 (ftp'd from ftp.apple.com) mentions in Brigham Stevens' article "Ten Tips for Game Developers" to use CopyBits with a mask region instead of CopyMask or CopyDeepMask because it's faster. OK, but how do I convert my mask (sitting in a GWorld called maskWorld) to a region. I haven't seen any good examples of the use of BitMapToRgn anywhere (I did look, but got more confused. IM didn't explain how to use this at all and neither did THINK Reference) 4) Can GetGWorld and SetGWorld be used instead of GetPort and SetPort when using offscreen GWorlds? 5) I can't seem to find the TechNote anymore called, Out of This GWorld. Can someone tell me where to get it (prefereablly in DocViewer Format). Thanks for all your help. Signed, Dazed and Confused. -- ======================================================================== Carl B. Constantine B.C. Environment, Lands & Parks End-User Support Analyst CCONSTAN@epdiv1.env.gov.bc.ca +++++++++++++++++++++++++++ >From giles@med.cornell.edu (Aaron Giles) Date: 13 Jul 1994 17:11:37 GMT Organization: Cornell University Medical College In article , cconstan@epdiv1.env.gov.bc.ca (Carl B. Constantine) wrote: > 1) IM IV says to set RGBForeColor to White and RGBBackColor to Black > before using CopyBits to avoid colorization. That's great, but I've seen > many examples where people don't do this. My question is, do you have to > do it for Color GWorlds? Yes, you do need it. (BTW, it's RGBForeColor to *black* and RGBBackColor to *white*). If the foreground and background colors are something else, CopyBits will do color masking, which is a cool effect, but slows things down a lot. > 2) I've seen alot about rowBytes and BaseAddr values for PixMaps/BitMaps. > How you have to set it to long word aligned for fastest copying. If you > use NewGWorld to create your offscreen port (as opposed to OpenCPort), do > you still need to set these values or does NewGWorld do it for you? NewGWorld always allocates longword-aligned chunks of memory for its screen buffer. As long as you are copying from a longword-aligned offset from the baseAdr, you don't need to worry. > 3) Develop 17 (ftp'd from ftp.apple.com) mentions in Brigham Stevens' > article "Ten Tips for Game Developers" to use CopyBits with a mask region > instead of CopyMask or CopyDeepMask because it's faster. OK, but how do I > convert my mask (sitting in a GWorld called maskWorld) to a region. I > haven't seen any good examples of the use of BitMapToRgn anywhere (I did > look, but got more confused. IM didn't explain how to use this at all and > neither did THINK Reference) I assume you're using cicn's to store your graphics? If you are, then look at the structure of a CIconHandle in THINK Reference; in there is a pointer to a BitMap containing the mask. Allocate a new RgnHandle with NewRgn(), then call BitMapToRegion() to convert the mask BitMap into a region. It's pretty straightforward. Something like this: CIconHandle myIcon = GetCIcon(kMyIconID); if (myIcon) { RgnHandle myMaskRgn = NewRgn(); if (myMaskRgn) { char hState = HGetState((Handle)myIcon); OSErr theErr; HLock((Handle)myIcon); theErr = BitMapToRegion(myMaskRgn, &(*myIcon)->iconMask); HSetState((Handle)myIcon, hState); if (theErr == noErr) // everything worked! } } However, you need to be careful, because the mask BitMap was originally in the source coordinates of the image, so you could just pass the same mask to CopyMask() to copy to any destination. When you start using a mask region for CopyBits(), however, the region is relative to the *destination* port, so you will need to call OffsetRgn() on the mask region to transform it from source to destination coordinates before you copy. That is, if you were doing CopyMask() to two different locations, you would just do this: CopyMask((BitMap *)*mySrcPixMap, &myMaskBitMap, (BitMap *)*myDestPixMap, &srcRect, &srcRect, &destRect1); CopyMask((BitMap *)*mySrcPixMap, &myMaskBitMap, (BitMap *)*myDestPixMap, &srcRect, &srcRect, &destRect2); However, if you were doing the same thing with CopyBits(), you would need to do a little more work: RgnHandle myDestRgn = NewRgn(); if (myDestRgn) { CopyRgn(myMaskRgn, myDestRgn); OffsetRgn(myDestRgn, destRect1.left, destRect1.top); CopyBits((BitMap *)*mySrcPixMap, (BitMap *)*myDestPixMap, &srcRect, &destRect1, mode, myDestRgn); CopyRgn(myMaskRgn, myDestRgn); OffsetRgn(myDestRgn, destRect2.left, destRect2.top); CopyBits((BitMap *)*mySrcPixMap, (BitMap *)*myDestPixMap, &srcRect, &destRect2, mode, myDestRgn); } > 4) Can GetGWorld and SetGWorld be used instead of GetPort and SetPort when > using offscreen GWorlds? Yes; in fact, they *must* be used. I never use SetPort() anymore; SetGWorld() always does the job and you never have to worry about pointing to the wrong or nonexistant GDevice. Hope this helps! Aaron -- Aaron Giles (giles@med.cornell.edu) Power Macintosh Developer, Cornell University Medical College JPEGView home page: http://www.med.cornell.edu/jpegview.html JPEGView FTP site: ftp://ftp.med.cornell.edu/pub/aarong/jpegview/ +++++++++++++++++++++++++++ >From gurgle@dnai.com (Pete Gontier) Date: Wed, 13 Jul 1994 12:22:25 -0800 Organization: Integer Poet Software In article , giles@med.cornell.edu (Aaron Giles) wrote: > In article , > cconstan@epdiv1.env.gov.bc.ca (Carl B. Constantine) wrote: > > > 1) IM IV says to set RGBForeColor to White and RGBBackColor to Black > > before using CopyBits to avoid colorization. That's great, but I've seen > > many examples where people don't do this. My question is, do you have to > > do it for Color GWorlds? > > Yes, you do need it. (BTW, it's RGBForeColor to *black* and RGBBackColor > to *white*). If the foreground and background colors are something else, > CopyBits will do color masking, which is a cool effect, but slows things > down a lot. You don't need to do it every time if you think it is slowing your code down. What you do need to do is assure yourself that the foreground and background colors are set the way you think they should be set. Most of the time that's fore/black and back/white. It so happens that these are the default foreground and background colors, so that accounts for why you see code which doesn't bother to set them. -- Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com "I am Wang of Symantec. You will be assimilated. Resistance is futile." --------------------------- >From tzagara@tigris.cti.gr Subject: PBControl() "hangs" the Macintosh Date: 12 JUL 94 18:21:00 GMT Organization: Computer Technology Institute (CTI), Patras, Greece Hi there, I am new in Macintosh programming and I want to write two simple programs implementing a client and a server. I am using MacTCP and I am trying to open a UDP connection between the client and the server. I am using Think C 5.0 on a MacQuadra 700 and MacTCP 1.1. I wrote the following code trying to open the MacTCP driver and a UDP stream, but when I try to "run" it, the Macintosh "hangs". - ------------------------------------------------------------------- /* Open a UDP stream */ #include #include #include #include main() { short DrefNum=0; UDPiob myUDPblock; CntrlParam myUDPCblock; UDPCreatePB myUDPCreate; Ptr RcvBuffer; OsErr MyErr; char DriverName[9]="\p.ipp"; myUDPblock.ioCompletion = NULL; myUDPblock.ioNamePtr = DriverName; myUDPblock.ioCRefNum = 0; MyErr = PBOpen((ParmBlkPtr)&myUDPblock,false); DrefNum=myUDPblock.ioCRefNum; if (MyErr != noErr) printf("Error %d\n",MyErr); else printf("No Error\n"); myUDPCblock.csCode=20; myUDPCblock.ioCRefNum=DrefNum; myUDPCblock.oCompletion=NULL; RcvBuffer=(char *)malloc(2048*sizeof(char)); myUDPCreate.rcvBuff=RcvBuffer; myUDPCreate.localPort=0; myUDPCreate.endingPort=1500; **>> MyErr=PBControl((ParmBlkPtr)&myUDPCblock,false); /* At this point the Mac "hangs" */ if (MyErr != noErr) printf("PBControl returned error %d\n",MyErr); else printf("No error returned\n"); } - ---------------------------------------------------------------------------- The point where the Macintosh "hangs" is market with **>>. When I use the debugger, at the specified point a message appears saying "Bus Error". Can anybody tell me, what I am doing wrong ? Thank you in advance. **************************************************************** Emmanuel Tzangarakis, tzagara@cti.gr, tzagara@grpatvx1.bitnet Computer Technology Institute (CTI) Patras, Greece. +++++++++++++++++++++++++++ >From oster@netcom.com (David Phillip Oster) Date: Tue, 12 Jul 1994 18:34:26 GMT Organization: Netcom Online Communications Services (408-241-9760 login: guest) In article <12JUL94.18210014@tigris.cti.gr> tzagara@tigris.cti.gr writes: >I wrote the following code trying to open the MacTCP driver and a UDP stream, >but when I try to "run" it, the Macintosh "hangs". > > myUDPCblock.csCode=20; > myUDPCblock.ioCRefNum=DrefNum; > myUDPCblock.oCompletion=NULL; > > RcvBuffer=(char *)malloc(2048*sizeof(char)); > myUDPCreate.rcvBuff=RcvBuffer; > myUDPCreate.localPort=0; > myUDPCreate.endingPort=1500; > >**>> MyErr=PBControl((ParmBlkPtr)&myUDPCblock,false); /* At this point the Mac > "hangs" */ You don't initialize your parameter block, so your code installs garbage as an ASR. When the mac calls that garbage ASR, it bus errors. The following does almost what you want: /* This is a complete, correct, example of creatign a TCP stream. Written and tested by David Phillip Oster, 7/12/94 */ #include "AddressXlation.h" #include "UDPPB.h" #include "TCPPB.h" #include static short tcpRefNum = 0; /* UDPMTU - return UDPMaxMTUSize */ static OSErr UDPMTU(ip_addr hostAddr, unsigned short *dgramSize){ UDPiopb pb; OSErr err; if(0 == tcpRefNum){ return openFailed; } memset(&pb, 0, sizeof pb); pb.ioCRefNum = tcpRefNum; pb.csCode = UDPMaxMTUSize; pb.csParam.mtu.remoteHost = hostAddr; pb.csParam.mtu.userDataPtr = nil; if(noErr == (err = PBControl((ParmBlkPtr) &pb, FALSE))){ *dgramSize = pb.csParam.mtu.mtuSize; } return err; } /* TcpCreate - opens a TCP stream. */ static OSErr TcpCreate( Ptr rcvBuff, unsigned long rcvBuffLen, StreamPtr *streamp){ TCPiopb pb; OSErr err; if(0 == tcpRefNum){ return openFailed; } memset(&pb, 0, sizeof pb); pb.ioCRefNum = tcpRefNum; pb.csCode = TCPCreate; pb.csParam.create.rcvBuff = rcvBuff; pb.csParam.create.rcvBuffLen = rcvBuffLen; if(noErr == (err = PBControl((ParmBlkPtr) &pb, FALSE))){ *streamp = pb.tcpStream; } return err; } /* TcpRelease - closes a Tcp stream */ static OSErr TcpRelease(StreamPtr stream, Ptr *rcvBuff, long *rcvBuffLen){ TCPiopb pb; OSErr err; if(0 == tcpRefNum){ return openFailed; } memset(&pb, 0, sizeof pb); pb.ioCRefNum = tcpRefNum; pb.csCode = TCPRelease; pb.tcpStream = stream; if(noErr == (err = PBControl((ParmBlkPtr) &pb, FALSE))){ *rcvBuff = pb.csParam.create.rcvBuff; *rcvBuffLen = pb.csParam.create.rcvBuffLen; } return err; } /* main - although it appears that err is unused here, actually, I dump it out in the debugger. weaver is just some host this machine can reach, so I can ask how big a buffer to allocate, to hand to the stream. */ main(){ OSErr err; ip_addr weaver_addr; struct hostInfo weaverInfo; unsigned short dgramSize; Ptr buf, buf2; long bufLen, bufLen2; StreamPtr stream; weaver_addr = 0; err = OpenDriver("\p.ipp", &tcpRefNum); /* opens the MacTCP implementation */ err = OpenResolver(nil); err = StrToAddr("weaver.", &weaverInfo, nil, nil); if(noErr == err){ weaver_addr = weaverInfo.addr[0]; } err = CloseResolver(); err = UDPMTU(weaver_addr, &dgramSize); /* the minimum memory allocation for TCP is 4L*dgramSize + 1024L */ bufLen = 2048L + 4L*dgramSize; buf = NewPtr(bufLen); err = MemError(); err = TcpCreate(buf, bufLen, &stream); err = TcpRelease(stream, &buf2, &bufLen2); return 0; } +++++++++++++++++++++++++++ >From Mark Hanrek Date: Thu, 14 Jul 1994 07:22:48 GMT Organization: The Information Workshop In article <12JUL94.18210014@tigris.cti.gr> , tzagara@tigris.cti.gr writes: > Hi there, > > I am new in Macintosh programming and I want to write two simple programs > implementing a client and a server. I am using MacTCP and I am trying to > open a UDP connection between the client and the server. > > I am using Think C 5.0 on a MacQuadra 700 and MacTCP 1.1. > > I wrote the following code trying to open the MacTCP driver and a UDP stream, > but when I try to "run" it, the Macintosh "hangs". > < source code not included> > > > The point where the Macintosh "hangs" is market with **>>. When I use the > debugger, at the specified point a message appears saying "Bus Error". > > Can anybody tell me, what I am doing wrong ? > > Thank you in advance. > > **************************************************************** > Emmanuel Tzangarakis, tzagara@cti.gr, tzagara@grpatvx1.bitnet > Computer Technology Institute (CTI) > Patras, > Greece. Emmanuel, Your *real* problem is that you did not first draw from working example source code. Fortunately, David Oster supplied you with an excellent, and "known to be working" example. When you look at it, and compare it to yours, you will see that there are significant differences. The only way to be successful in programming these days is to "stand on the shoulders of work already done" -- because there is still quite a bit to do after that. :) If you tackle each programming task all over from scratch, it could take you weeks, or even months to duplicate the effort that went into David's code alone. It is okay for you to stand on the shoulders of that work and utilize it directly. If it was not okay, David would have politely let you know. - --- I would wager that the mistake you made is a common one, which is using "parameter block" type calls without first initializing them to zero. Your parameter block structures are allocated on the stack, but they are not initialized, so there is random stuff in all of the parameter block's fields. You are setting the values of some of them, but what about the rest? ooops. :) The toolbox call you are making may be looking at some of the other parameter block field and perhaps if on of them is not nil, then it figures it must be good a valid address, and so it uses the address in that field, not knowing that is is actually a random value -- bus error! In David's code, the "memset" call is used to initialize a parameter block before it is used. Now you will remember this from now on, I am sure! I made the same mistake, too, and will always remember it. :) Keep working at it! Mark Hanrek --------------------------- >From Dmitry Boldyrev Subject: Patching the GetResource() toolbox routine Date: 8 Jul 1994 01:51:15 GMT Organization: University of Utah Hi folx! I am the author of LZSS Res resource compression utility. The way LZSS Res works now is, it has a library function called GetCResource(rType, rID) which has a call inside it to GetResource, then, the resource is decompressed in real time and returned. However, it is a not very convinient way of doing that, that is someone who's using my package would have to change GetPicture to (PicHandle)GetCResource() and so on.. you see, it is not a good way. Yesterday, I spoke to the current president of TopSoft, inc. Tony Jacobs who suggested me another idea, to patch the trap GetResource() so that whenever someone makes a call GetResource() actually my function will be called and the resource will be grabbed decompressed and passed. Now, is there a way to do it? Greatly appreciate any info. +++++++++++++++++++++++++++ >From radixinc@aol.com (RadixInc) Date: 8 Jul 1994 02:39:01 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <2vibej$fve@u.cc.utah.edu>, Dmitry Boldyrev writes: "...suggested me another idea, to patch the trap GetResource() so that whenever someone makes a call GetResource() actually my function will be called and the resource will be grabbed decompressed and passed. Now, is there a way to do it?" First off, you'll have to patch more than just GetResource. There are quite a few calls that load resources: GetResource, GetNamedResource, Get1Resource, Get1NamedResource, LoadResource, and some others. I suspect they all come down to a call into LoadResource, but the ROM won't get there through a trap, so you'll probably have to patch them all. Second, you'll have to do your thing AFTER the toolbox gets the resource, so your patch will do the actual GetResource (or whatever), then decompress the result and return it. The problem is that by this time the Resource Manager has already allocated a handle for the resource and made an entry in the resource map. If you then decompress the resource into another (larger) block and return a handle to that block to the caller, you have a bit of a mess to clean up. First you'll have to get rid of the resource manager's copy, with ReleaseResource. Then you'll have to patch the ReleaseResource, DetachResource, and perhaps some other calls that will be expecting resource handles, just in case the calling program decides to do a resource call with the handle you gave it. The main problem here is that resource handles are NOT the same as other blocks; the Resource Manager keeps a private list or map of resources in the heap. Obviously you'll have to install your patch(es) in the System Heap at boot time (with an INIT) so they will be global to all applications. You'll probably then find out how many other INITs patch the Resource Manager, with possibly frustrating results. Your code isn't the only thing that compresses and decompresses resources, so it had better be able to identify those it has compressed and ignore anything else. In short, this could get messy. Gregory Jorgensen XCommander Radix Consulting Inc. +++++++++++++++++++++++++++ >From benmartz@grex.cyberspace.org (Ben Martz) Date: 12 Jul 1994 02:08:23 GMT Organization: PawPrint Enterprises In article <2vibej$fve@u.cc.utah.edu>, dmtiry@atlas.chem.utah.edu (Dmitry Boldyrev) wrote: > I am the author of LZSS Res resource compression utility. The way LZSS Res > ... > ... However, it is a not very convinient way of doing that... > ..suggested me another idea, to patch the trap GetResource() so that > whenever someone makes a call GetResource() actually my function will be > called and the resource will be grabbed decompressed and passed. > Now, is there a way to do it? > > Greatly appreciate any info. Ok, Dmitry, first of all, a disclaimer, if you don't have a way to determine if the resource is compressed, ADD ONE! Source code - from the way you wrote your article, it looks like you are using C so here's some C code for an INIT to patch a trap and call the original one: /* GR_Patch.c, GetResource patch -- MAY NEED SOME WORK TO WORK! */ #include #define CODE_SETUP() asm {\ movem.l a0-a5/D0-D7, -(SP)\ move.l a0, a4\ } #define CODE_CLEANUP() asm {\ movem.l (SP)+, a0-a5/D0-D7\ } #define GrafSize 206 #define ADD_GRAFSIZE (GrafSize - 130) typedef struct { char filler[ADD_GRAFSIZE]; long randSeed; BitMap screenBits; Cursor arrow; Pattern dkGray; Pattern ltGray; Pattern gray; Pattern black; Pattern white; GrafPtr thePort; } QD_GLOBALS; #ifndef NULL #define NULL ( (void *)0 ) #endif static QD_GLOBALS our_qd; #define GetResource_Address 0xA9A0 /* yes this is the right address! */ /* define our routine*/ pascal Handle our_GetResource(ResType rType, short rID); static void *old_GetResource; void main(void) { Handle self_handle; Ptr selfPtr; CODE_SETUP(); asm { move.l a0, selfPtr } self_handle = RecoverHandle(selfPtr); HLock(self_handle); DetachResource(self_handle); /* get the old routine's address for future use! */ old_GetResource = (void *)NGetTrapAddress(GetResource_Address, ToolTrap); /* substitute our routine! */ NSetTrapAddress((UniversalProcPtr)StripAddress(our_GetResource), GetResource_Address, ToolTrap); CODE_CLEANUP(); } pascal Handle our_GetResource(ResType rType, short rID) { Handle returnValue; CODE_SETUP(); SetUpA4(); /* call the old GetResource to get the resource */ returnValue = CallPascalL(old_GetResource, rType, rID); /* first, check to see if the resource is compressed, if so, */ /* decompress resource here! */ RestoreA4(); CODE_CLEANUP(); return(returnValue); } /* end of file */ BTW: I don't think that this code is powerpc compatible unless you compile it as 68K code Hope that this helps! - Ben -CUT HERE------------------------------------------------------------------ +---------------+ -------------------------------------- / +-----------+ / -- Ben Martz -- / / () () / / -- benmartz@grex.cyberspace.org -- / / ^ / / -- currently residing in Ann Arbor, -- / / ______ / / -- Michigan -- / / \-----/ / / -------------------------------------- / +-----------+ / -- The views and opinions expressed -- / _____ / -- here are mine and no one elses! -- / *.... / -------------------------------------- +---------------+ -- "Football can touch a young man -- / / / / / / / / -- where nobody else can...legally" -- +-------------+ --------------------------------------= +++++++++++++++++++++++++++ >From devans@apple.com (Dave Evans) Date: Wed, 13 Jul 1994 09:10:21 GMT Organization: N/A In article <2vibej$fve@u.cc.utah.edu>, Dmitry Boldyrev wrote: > The way LZSS Res works now is, it has a > library function called GetCResource(rType, rID) which has a call inside > it to GetResource, then, the resource is decompressed in real time > and returned. However, it is a not very convinient way of doing that, that is > someone who's using my package would have to change GetPicture to > (PicHandle)GetCResource() and so on.. you see, it is not a good way. Please Dmtiry, DON'T PATCH. Even if more technically challenging, patching only makes your software less stable, less compatible, and much more difficult to maintain across system software versions. Also, your patches may very well break other applications; you would need to test many applications to verify that your software was successful. If you stick with a linked library, you will avoid all of this. Now, to solve your problem, I recommend you provide a library with many routines instead of just one routine. Name them, for example: DBGetResource() DBGet1Resource() DBGetPicture() etc. The DB is for your name's initials, just to designate your routines as separate from the Mac Toolbox routines. Then write very small routines for each which call your GetCResource() routine as appropriate or Macro's which redefine them to casted GetCResource() calls. You can then also provide a header file which optionally defines all the developer's routines to be yours instead. E.G.: #if hasDmtiryLibrary #define GetResource(...) DBGetResource() #endif So they don't need to change their code and can easily use your software... AND no patching!!! Dave --------------------------- End of C.S.M.P. Digest **********************