From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-010 Date: Thu, 7 Apr 94 12:50:06 MET DST C.S.M.P. Digest Thu, 07 Apr 94 Volume 3 : Issue 10 Today's Topics: *Simple* CopyMask question C-C++ public domain compiler Code Fragment Loader and VM Code to rebuild desktop? CodeWarrior features? Graphic Elements release announcement How to get Finder icon? Porting Think C to CodeWarrior Quickdraw GX Beta 3 fun Spoofing a serial port Using Think Pascal Library in SC++ rowBytes for the screen too big? 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 as comp.sys.mac.programmer.src. ------------------------------------------------------- >From gk1@acpub.duke.edu (Gavin Kistner) Subject: *Simple* CopyMask question Date: 21 Mar 1994 21:07:59 GMT Organization: Duke University; Durham, NC; USA I'm new to programming the mac (making my first) and want to use CopyMask to put a picture over a background with a non-square clip. The picture is stored as a 'PICT' resource, but CopyMask needs a BitMap (or pixMap for source or dest) record. The placement is a one-shot deal...I've been trying to understand some serious SPRITE toolkits, but they're way too overkill and (I think) complex. Can someone give me the simplest, even ineffecient, way to use CopyMask with 'PICT' resources. I'm programming in C, if you want to show in source code :D Oh, and there are actually many pieces and masks to use...I can either keep them in one conglomerate picture or put each in its own resource...you tell me. One other question - I've used Photoshop to create beautifully dithered 8-bit versions from the 24-bit originals, but when I tell PS to save the colormap it created, it makes some file that's all data fork...I want a 'clut' to set the palette up correctly, right? Anyone know of an easy way to do this? Or even a hard one? Many thanks, and may God bless the Mac and especially its programmers! - Gavin PS My apologies if this appeared before...I tried to post it last night, but never was able to find my article. Perhaps my newsreader is messed - perhaps it would be best if you could mail replies to me directly. gk1@acpub.duke.edu -- This message brought to you by Gavin Kistner, aka The Rabid Yak, aka RabYak gk1@acpub.duke.edu My experimental ftp server: alspaugh-2181.dorm.duke.edu +++++++++++++++++++++++++++ >From Arsenault_C@msm.cdx.mot.com (Chris Arsenault) Date: Thu, 24 Mar 1994 12:26:29 -0500 Organization: Motorola Codex In article <2ml2bf$76l@news.duke.edu>, gk1@acpub.duke.edu (Gavin Kistner) wrote: > Can someone give me the simplest, even ineffecient, way to use CopyMask > with 'PICT' resources? I'm assuming here that your 'PICT's are primarily pixel or paint images vs drawn (pict opcode) images. Grab a copy of Tony Myle's excellent SpriteWorld sprite library on sumex-aim or some of the other ftp archives. There are a number of image functions provided in the utilities file that allow you to load pictures into GWorlds etc. This is a good starting point for what I describe below. Draw your pict image in a paint program. Duplicate the file and convert it to a 1 bit (B&W) image. This is your mask bitmap. Copy this into your resource file. Load the mask bitmap into a grafport (there is a function in the SpriteWorld utils that does this), then use this for your CopyMask operation, or alternately convert the bitmap mask into a region (BitmapToRegion) and use CopyBits with the maskRgn. There are a number of other ways to mask off images, but this should get you started. > One other question - I've used Photoshop to create beautifully dithered > 8-bit versions from the 24-bit originals, but when I tell PS to save the > colormap it created, it makes some file that's all data fork...I want a > 'clut' to set the palette up correctly, right? Anyone know of an easy way > to do this? Or even a hard one? There is a problem with how color information is exchanged when working with various paint programs. (Images that are copied into a ResEdit PICT do not retain the correct palette that the paint program uses, but use the system palette instead) I'll assume that you are using PS to save the image as a PICT resource so you should be okay. Do a GetPicture to obtain the PicHandle, then use the Picture Utilities call GetPictInfo(). This will return all the information you could need about the picture, including a CTabHandle (the color table for the picture). The GetPictInfo also returns a palette. If you assign this palette to the window you're going to display your picture in, you'll get the correct picture colors in the window instead of the approximations the Palette Manager provides. Have fun! Chris -- #include --------------------------- >From giac@ada.dei.unipd.it (Giovanni Iachello 366675/IF) Subject: C-C++ public domain compiler Date: Mon, 14 Mar 1994 11:55:05 GMT Organization: B.B.B - Universita' di Padova, Italia does anybody know where to find a public domain C/C++ compiler for the MAc? Maybe the GNU compiler? Thank you! giac@maya.dei.unipd.it +++++++++++++++++++++++++++ >From arentz@batcave.knoware.nl (Stefan Arentz) Date: Sun, 20 Mar 1994 13:04:42 GMT Organization: Knoware In article , giac@ada.dei.unipd.it (Giovanni Iachello 366675/IF) wrote: > does anybody know where to find a public domain C/C++ compiler for the > MAc? Maybe the GNU compiler? > > Thank you! > giac@maya.dei.unipd.it On the MacHack '93 CD, there is a GNU 2.3.3 C and C++ compiler. You need MPW to use it though... -- Stefan - ----------------------------------------------------------------------- Stefan Arentz -- Software Constructor -- arentz@knoware.nl +++++++++++++++++++++++++++ >From holiday@bnr.ca (Matthew Holiday) Date: 21 Mar 1994 15:20:47 GMT Organization: Bell-Northern Research, Richardson, TX In article , arentz@batcave.knoware.nl (Stefan Arentz) writes: -> In article , giac@ada.dei.unipd.it (Giovanni -> Iachello 366675/IF) wrote: -> -> > does anybody know where to find a public domain C/C++ compiler for the -> > MAc? Maybe the GNU compiler? -> > -> > Thank you! -> > giac@maya.dei.unipd.it -> -> On the MacHack '93 CD, there is a GNU 2.3.3 C and C++ compiler. You need -> MPW to use it though... Where can one obtain this CD? And how much does it cost? -- Matt Holiday #include holiday@bnr.ca BNR Richardson, TX "Proud owner of an unregistered computer" +++++++++++++++++++++++++++ >From shebs@cygnus.com (Stan Shebs) Date: Mon, 21 Mar 1994 18:26:24 GMT Organization: /cygint/s1/users/shebs/.organization In article <2mke0f$cqr@crchh327.bnr.ca> holiday@bnr.ca (Matthew Holiday) writes: -> On the MacHack '93 CD, there is a GNU 2.3.3 C and C++ compiler. You need -> MPW to use it though... Where can one obtain this CD? And how much does it cost? There is also a slightly more up-to-date version of 2.3.3 on ftp.atg.apple.com. Neither version is totally usable however, since they have some bugs in code generation for Pascal-declared functions. With care, you might be able to use it, but don't cry too loudly if the object code crashes and takes your machine with it. At this point, I've abandoned the 2.3.3 port and am starting over with a different strategy for 2.5.x, involving very few MPW-Assembler-specific hacks and a *real* cross-compilation setup (i.e. sit on a Sun and produce a Mac executable, resources, fat binary, etc as desired). Stan Shebs Cygnus Support shebs@cygnus.com +++++++++++++++++++++++++++ >From holiday@bnr.ca (Matthew Holiday) Date: 22 Mar 1994 14:47:05 GMT Organization: Bell-Northern Research, Richardson, TX In article , shebs@cygnus.com (Stan Shebs) writes: -> -> In article <2mke0f$cqr@crchh327.bnr.ca> holiday@bnr.ca (Matthew Holiday) writes: -> -> -> On the MacHack '93 CD, there is a GNU 2.3.3 C and C++ compiler. You need -> -> MPW to use it though... -> -> Where can one obtain this CD? And how much does it cost? -> -> There is also a slightly more up-to-date version of 2.3.3 on -> ftp.atg.apple.com. Neither version is totally usable however, -> since they have some bugs in code generation for Pascal-declared -> functions. With care, you might be able to use it, but don't cry -> too loudly if the object code crashes and takes your machine with it. -> -> At this point, I've abandoned the 2.3.3 port and am starting over with -> a different strategy for 2.5.x, involving very few MPW-Assembler-specific -> hacks and a *real* cross-compilation setup (i.e. sit on a Sun and produce -> a Mac executable, resources, fat binary, etc as desired). That's neat, but all I want to do is compile MPW tools under MPW, using C++ instead of C. Thanks for 2.3.3 -- I'm going to try building that tonight. Does the C++ front end part of 2.3.3 work, or am I stuck with Apple's port of CFront 2.1? -- Matt Holiday #include holiday@bnr.ca BNR Richardson, TX "Proud owner of an unregistered computer" +++++++++++++++++++++++++++ >From shebs@cygnus.com (Stan Shebs) Date: Tue, 22 Mar 1994 21:57:02 GMT Organization: /cygint/s1/users/shebs/.organization In article <2mn0d9$8k3@crchh327.bnr.ca> holiday@bnr.ca (Matthew Holiday) writes: That's neat, but all I want to do is compile MPW tools under MPW, using C++ instead of C. Thanks for 2.3.3 -- I'm going to try building that tonight. Does the C++ front end part of 2.3.3 work, or am I stuck with Apple's port of CFront 2.1? Although I haven't tried it lately, "cc1plus" has been observed to build and run under MPW. However, it won't generate code that will link with any MPW C++ libraries (different name mangling). You would have to recompile any and all libraries from source code, then work out a way to run static constructors and destructors, and do many other weird and obscure bits of work. Might take a couple weeks of dinking around. Note also that the dialect of C++ is different than what you would get with CFront 2.1, or even the latest (2.5.8) version of GCC. Stan Shebs Cygnus Support shebs@cygnus.com +++++++++++++++++++++++++++ >From holiday@bnr.ca (Matthew Holiday) Date: 23 Mar 1994 20:48:57 GMT Organization: Bell-Northern Research, Richardson, TX In article , shebs@cygnus.com (Stan Shebs) writes: -> In article <2mn0d9$8k3@crchh327.bnr.ca> holiday@bnr.ca (Matthew Holiday) writes: -> -> That's neat, but all I want to do is compile MPW tools under MPW, using C++ -> instead of C. -> -> Thanks for 2.3.3 -- I'm going to try building that tonight. Does the C++ -> front end part of 2.3.3 work, or am I stuck with Apple's port of CFront 2.1? -> -> Although I haven't tried it lately, "cc1plus" has been observed to build -> and run under MPW. However, it won't generate code that will link with any -> MPW C++ libraries (different name mangling). You would have to recompile -> any and all libraries from source code, then work out a way to run static -> constructors and destructors, and do many other weird and obscure bits of -> work. Might take a couple weeks of dinking around. Note also that the -> dialect of C++ is different than what you would get with CFront 2.1, or -> even the latest (2.5.8) version of GCC. Good points. I really hadn't thought about name mangling conventions. It's probably more effort than I've got to put into it to make it work with MPW. I haven't heard anything from Apple/APDA about planned improvements to MPW C++ (i.e., supporting a later version of the C++ language), so I guess I'll just keep doing tools in C. Or switch to a Unix machine.... -- Matt Holiday #include holiday@bnr.ca BNR Richardson, TX "Proud owner of an unregistered computer" --------------------------- >From Willie Rauchwerger Subject: Code Fragment Loader and VM Date: 17 Mar 1994 19:53:35 GMT Organization: OU Health Sciences Center Here is a dumb question... Why does your application memory requirement decrease on native PPC apps when virtual memory is turned on? - ----------------------------------------------------------------- Willie Rauchwerger AppleLink: Willie Telemedicine Software Guy Internet: willie-rauchwerger@uokhsc.edu OU Health Sciences Center +++++++++++++++++++++++++++ >From rang@winternet.mpls.mn.us (Anton Rang) Date: 19 Mar 1994 02:01:14 GMT Organization: Minnesota Angsters In article <2macfv$7iv@romulus.ucs.uoknor.edu> Willie Rauchwerger writes: >Here is a dumb question... Actually, it's not a dumb question. :-) >Why does your application memory requirement decrease on native PPC >apps when virtual memory is turned on? When virtual memory is turned on, an application's code (as well as that of any shared libraries it uses) is mapped into high memory, rather than being loaded into the application heap. Because this high-memory area doesn't correspond to real RAM, the program doesn't need any memory to be allocated for its code. -- Anton Rang (rang@winternet.mpls.mn.us) +++++++++++++++++++++++++++ >From peirce@outpost.SF-Bay.org (Michael Peirce) Date: Wed, 23 Mar 94 21:09:25 PST Organization: Peirce Software, Inc. In article <2macfv$7iv@romulus.ucs.uoknor.edu> (comp.sys.mac.programmer), Willie Rauchwerger writes: > Here is a dumb question... > > Why does your application memory requirement decrease on native PPC > apps when virtual memory is turned on? No CODE resources get loaded into your heap. With VM turned on, your code (from the data fork) is paged into its own memory area as needed (and it never gets paged back to disk since it's read only, it can always be read back from the data fork). -- Michael Peirce -- peirce@outpost.sf-bay.org -- Peirce Software, Inc. -- 719 Hibiscus Place, Suite 301 -- -- San Jose, California USA 95117 -- Makers of: Smoothie & -- voice: +1.408.244.6554 fax: +1.408.244.6882 -- Peirce Print Tools -- AppleLink: peirce & America Online: AFC Peirce --------------------------- >From martinher@urvax.urich.edu Subject: Code to rebuild desktop? Date: Tue, 22 Mar 1994 18:46:44 GMT Organization: University of Richmond Does anyone have a pointer to source code (C/C++ preferred) to rebuild the desktop? Herb Martin martinher@urvax.urich.edu +++++++++++++++++++++++++++ >From leonardr@netcom.com (Leonard Rosenthol) Date: Thu, 24 Mar 1994 18:53:07 GMT Organization: Aladdin Systems, Inc. In article <1994Mar22.184329.22097@gossip.urich.edu>, martinher@urvax.urich.edu wrote: > Does anyone have a pointer to source code (C/C++ preferred) to rebuild > the desktop? > It is IMPOSSIBLE for an application to do the rebuild itself since most of the contents of the Desktop File are undocumented. What you can do is to ask the Finder to quit (via Apple events), delete the DTDB files yourself, and the relaunch the Finder. At that point the Finder will rebuild the DTDB for you. Leonard - ------------------------------------------------------------------------ Leonard Rosenthol Internet: leonardr@netcom.com Director of Advanced Technology AppleLink: MACgician Aladdin Systems, Inc. GEnie: MACgician --------------------------- >From mdiamond@gradient.cis.upenn.edu (Matthew T Diamond) Subject: CodeWarrior features? Date: 23 Mar 1994 19:56:35 GMT Organization: University of Pennsylvania I know; every coupla days someone wants to know if CodeWarrior supports feature X. But I AM very curious about it. Is there any online information available that summarizes the whole thing? I would like to learn more about the editing environment, as well as what tools it comes with, how good is the code, what debugging is like, etc. (Yes, I know it's still alpha or beta) Presumably some kind of promotional text was written up somewhere? It might answer my own and other folks' questions. Matt mdiamond@gradient.cis.upenn.edu ps. On a related note, I noticed that Symantec 7.0 press releases didn't mention improvements to the editor. Did I miss something?? +++++++++++++++++++++++++++ >From mwron@aol.com (MW Ron) Date: 23 Mar 1994 17:15:03 -0500 Organization: America Online, Inc. (1-800-827-6364) In article <2mq6tj$abe@netnews.upenn.edu>, mdiamond@gradient.cis.upenn.edu (Matthew T Diamond) writes: >Is there any online information available that summarizes the whole thing? a bit of background on Metrowerks: Metrowerks has been developing and selling academic computer language products since 1988 and has registered users in 26 countries. On January 5th, 1994, Metrowerks introduced Metrowerks CodeWarrior, a completely new, very powerful development environment for C/C++ and Pascal on either 68K Macintosh or the new PowerMacintosh. Metrowerks CodeWarrior contains very fast, state-of-the-art compiler technology that builds your products faster than any other development environment on Macintosh. CodeWarrior also is compatible with MPW C/C++ source code and both MacApp 3.1 and the TCL have been successfully compiled with CodeWarrior since introduction. It is currently in use in most of the major software companies worldwide to port their products to the new PowerMacintosh. Also included on the CodeWarrior CD is PowerPlant, our new application framework, written by Greg Dow, the orginal architect of the Think Class Library. Metrowerks business hours are (EST): Monday to Friday, 9 AM to 5 PM. Address: In the USA Metrowerks, Inc The Trimex Building Route 11, Mooers NY 12958 Canada and International Metrowerks, Inc 1500 Du College, Suite 300 St-Laurent, QC H4L 5G6 Other electronic addresses: support@metrowerks.ca sales@metrowerks.ca MWRON@AOL.COM Tel: (514) 747-5999 Fax: (514) 747-2822 +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Thu, 24 Mar 1994 15:10:58 -0800 Organization: Internet for the Olympic Peninsula In article <2mq6tj$abe@netnews.upenn.edu>, mdiamond@gradient.cis.upenn.edu (Matthew T Diamond) wrote: > > I know; every coupla days someone wants to know if > CodeWarrior supports feature X. > > But I AM very curious about it. Is there any online > information available that summarizes the whole thing? > I would like to learn more about the editing environment, > as well as what tools it comes with, how good is the code, > what debugging is like, etc. (Yes, I know it's still alpha or beta) MacTech magazine has had several articles recently about CodeWarrior. *Should* be available at your library, but with budgets the way they are these days, who knows. [MacTech is also a convenient place to buy CodeWarrior. That does not seem (to this outsider) to have affected the articles.] Frameworks magazine has, I think, had one or two, also. Harder to find. Both "MacTech" and "develop" are essential parts of one's Macintosh developer closet, IMHO. -- John Baxter Port Ludlow, WA, USA [West shore, Puget Sound] jwbaxter@pt.olympus.net --------------------------- >From al@crucible.powertools.com (Al Evans) Subject: Graphic Elements release announcement Date: 23 Mar 94 15:41:54 GMT Organization: PowerTools, Austin, Texas I am pleased to announce the net release of Graphic Elements. Graphic Elements is a new paradigm for implementing high-performance interactive computer graphics in a framework-independent (and, potentially, platform-independent) manner. The Graphic Elements system is modular and extensible, and individual Graphic Elements can be re-used in new applications by simple inclusion. This release is available from mac.archive.umich.edu and its mirrors in the file: /mac/misc/demo/graphicelementsdemo.sit.hqx I do not know why they put it in the demo area, since it is a completely functional version including linkable library and examples with source code (Think C 6.0). Note: I do ask a fee for the "registered shareware version", which includes an additional code module to speed up the graphics, a linkable MPW library, source for a TCL pane, and source for a MacApp view. Here are some excerpts from the Graphic Elements README file: [begin excerpts] Graphic Elements is a very general, high-performance, framework- independent graphics presentation system. It offers graphic performance comparable to that of a "sprite animation" system. At the same time, it affords a very flexible mechanism for defining what a graphic is and does. Anything that can be drawn on the screen can be a Graphic Element. ...the Graphic Elements system is completely "legal". Any normal Macintosh window can contain a Graphic Elements "world". >From the viewpoint of the application programmer, a Graphic Element is an independent software object which knows how to image itself on demand into an offscreen workspace. Each Graphic Element may optionally have ways of reacting to 1) the passage of time, 2) contact with another Graphic Element, and 3) the user's actions. These methods will be called automatically by the Graphic Elements system, as required. In addition, the application program can act on Graphic Elements explicitly at any time. After initialization, the application (or the view or pane object, if a class library is being used) needs only two calls to the Graphic Elements system to run a window full of animated graphics. ...the Graphic Elements system allows any graphic to be defined as a Graphic Element. ...scenes can easily be moved from one program to another by simply including them in the new program and calling their initialization routines. The same Graphic Elements "scene" source can [...] be compiled under MPW C or C++, Think C 6.0, and Symantec C++. The compiled code can be utilized from a normal application or from one based on the MacApp or TCL class libraries. [end excerpts] If you're still with me, thank you for your attention. --Al Evans-- -- Al Evans Tu causes, tu causes al@crucible.powertools.com C'est tout ce que tu sais faire cs.utexas.edu!crucible!al -- LaVerdure --------------------------- >From Steve Barrera Subject: How to get Finder icon? Date: 23 Mar 1994 16:37:33 GMT Organization: Computing Center I want to make a call to the standard get file dialog, then extract the Finder icon associated with the selected file and put it in a window. I can't find a hint anywhere in Inside Mac:Files as to how to do this. Anyone have a clue? Steve Barrera barrera@vt.edu +++++++++++++++++++++++++++ >From E.J. Draper Date: 23 Mar 1994 17:06:04 GMT Organization: U.T.M.D. Anderson Cancer Center In article <2mpr8d$9nr@solaris.cc.vt.edu> Steve Barrera, barrera@vt.edu writes: >I can't find a hint anywhere in Inside Mac:Files as to how to do this. >Anyone have a clue? Here!s a little snippet. The main call you!re looking for is PBDTGetIcon(). PBDTGetIcon() is only available on volumes that use the System 7 desktop manager scheme. clearbytes(&DTDBparamBlock,longsizeof(DTDBparamBlock)); DTDBparamBlock.ioVRefNum = volrefnum; DTDBparamBlock.ioNamePtr = nil; if (PBDTGetPath(&DTDBparamBlock) == noErr) { if (DTDBparamBlock.ioDTRefNum == 0) { return nil; } icondata = NewPtrClear(kLarge8BitIconSize); if (icondata == nil) { return nil; } DTDBparamBlock.ioDTReqCount = kLarge8BitIconSize; DTDBparamBlock.ioDTBuffer = icondata; DTDBparamBlock.ioIconType = kLarge8BitIcon; DTDBparamBlock.ioFileCreator = Creator; DTDBparamBlock.ioFileType = Type; Err = PBDTGetIcon(&DTDBparamBlock,false); if (Err == afpItemNotFound) { DisposePtr(icondata); icondata = nil; thePic = dogenericdocicon(); if (thePic != nil) { return thePic; } return nil; } |E|J- ED DRAPER rEpar|D|<- Radiologic/Pathologic Institute The University of Texas M.D. Anderson Cancer Center draper@utmdacc.mda.uth.tmc.edu --------------------------- >From tchan@irus.rri.uwo.ca (Thomas KC Chan) Subject: Porting Think C to CodeWarrior Date: 22 Mar 1994 21:57:21 GMT Organization: Imaging Labs, Robarts Research Institute, London I am porting my programs from Think C to CodeWarrior. Right now I am just testing the 68K port. The programs works...but... 1. when I time my program speed using clock(), the program gives me a big ellapse time. It turns out that the constant CLOCKS_PER_SEC is declared as (_CPS which is) 1. I check with Think C and find that it has CLOCKS_PER_SEC declared as 60. ??? 2. My program generates output for a line counter using ANSI printf. Everything I use "\r" to overwrite the previous value. It works in Think C. But in CodeWarrior, the output would go to SIOUX. And seemingly the "\r" character is treated as a new-line char. ??? Any one knows any fix to my problems? Are patches needed for my CodeWarrior (Gold) compiler? I find the on-line ref. manual does not provide enough details (like PowerPC's PEF [what is it anyways???]) Is there any doc available on s/w porting to PowerPC? Thomas Chan email: tchan@irus.rri.uwo.ca +++++++++++++++++++++++++++ >From mlevy@csr.uvic.ca (Michael Levy) Date: Wed, 23 Mar 94 13:38:46 GMT Organization: University of Victoria In Article <2mnpk1$8ol@falcon.ccs.uwo.ca>, tchan@irus.rri.uwo.ca (Thomas KC Chan) wrote: > >I am porting my programs from Think C to CodeWarrior. Right now I >am just testing the 68K port. The programs works...but... > > 1. when I time my program speed using clock(), the program gives > me a big ellapse time. It turns out that the constant CLOCKS_PER_SEC > is declared as (_CPS which is) 1. I check with Think C and find > that it has CLOCKS_PER_SEC declared as 60. ??? Yes, I found this too. Change #define _CPS 1 to #define _CPS 60 in . (See item 2 in the bug-report below). There were a couple of other bugs that I have reported to Metrowerks. There was no response from them, but I assume they will fix most of them in the next release. The most serious bug (not included in the report) was with malloc - its supposed to take an unsigned long as its argument. Instead, it is treating its argument as a signed int. If you try to allocated more than 32,767 bytes, malloc will return NULL. (Actually, its a bit worse than this. It is taking the least significant 16 bits of its argument, and treating that as a signed int. If you pass a long that is larger than 32,767, but which happens to have a zero in bit 16, malloc will succeed, giving you much less storage than you think you received). I did phone tech-support about this bug, and they said that it would be fixed in their next releasw (apparantly being cut into CD as we spoke - about 2 or 3 weeks ago). I do not know about your second problem, but here for your benefit, and for the benefit of anyone else trying a THINK C->Metroworks C port, is a copy of the message I sent them. Because of these problems (and, most notably, with the debuggers inability to evaluate expressions,) SYMANTEC still gets my vote as the ANSI C compiler of choice for the Mac. I haven't done any C++ programming on the Mac, so I am not entering the other debate. Here is the bug report: 1. In the file, you have #define _ILONG 1 Shouldn't this be conditional, depending on the value of __FOURBYTEINTS__? 2. In the same file, #define _CPS 1 is wrong - shouldn't it be 60 on the Mac? I think its ticks-per-second to divide into the value returned by the ANSI function clock(). 3. SystemSevenOrLater seems to be defined as 0 instead of 1 even though I am using system 7.1. I can't figure out how to change it, or find out where it is defined. 4. I got the version 1.a -> 1.b updater. It changed Macheaders but not Macheaders.c What gives? 5. The predefined names in the C manual (such as __mwerks__) are in lower-case. They should be in upper case. I also noticed some bugs in the debugger, most notably, in a case like this: int t1,t2; .... t1 = 1000; t2 = 2000; ... the debugger showed the same values for t1 and t2, and changed them simultaneously! While I am on the debugger, I would like to add an item to your wishlist. I like the overall structure of your debugger when compared with THINK C. However, for me it is crucial to be able to evaluate expressions in the debugger. For example, I have a horrible macro called TAG(X) defined like this: #define TAG(X) \ ((!(heap[X]&1))?(heap[X]&3):((!(heap[X]&2))?(heap[X]&15):(heap[X]&63))) THINK C's debugger lets me place the expression TAG(X) in the "data" window and see a value (like 1 or 63). I find this soooo useful. Please consider adding something similar. In fact, if I could coerce the result to an enum type and get the symbol instead of a number in the debugger, I would be ecstatic. Good luck with your product. +============================================+ | Michael Levy | | Department of Computer Science | | University of Victoria | | PO Box 3055 Victoria B.C. | | Canada V8W 3P6 | | email: mlevy@csr.uvic.ca | | phone: (604) 721-7303 | | fax: (604) 721-7292 | +============================================+ +++++++++++++++++++++++++++ >From johnmce@world.std.com (John McEnerney) Date: Thu, 24 Mar 1994 02:18:33 GMT Organization: The World Public Access UNIX, Brookline, MA >int t1,t2; >.... >t1 = 1000; >t2 = 2000; >... >the debugger showed the same values for t1 and t2, and >changed them simultaneously! This is probably -not- a bug in the debugger. If the compiler can determine that t1 and t2 will never be live simultaneously, it is free to place them in the same register or memory location. In fact, it is free to delete the assignments altogether if t1 and t2 are never used. (Unless they are declared 'volatile') >I have a horrible macro called TAG(X) defined like this: >#define TAG(X) \ >((!(heap[X]&1))?(heap[X]&3):((!(heap[X]&2))?(heap[X]&15):(heap[X]&63))) > >THINK C's debugger lets me place the expression TAG(X) in the "data" >window and see a value (like 1 or 63). I find this soooo useful. >Please consider adding something similar. This will not be possible with our current debugger/compiler architecture. THINK C is one of the only environments I've ever seen which does this; it is a side-effect of the way the debugger works, which is to call the compiler to evaluate the expression. We will probably support some form of expression evaluation in the debugger eventually (post-DR3) but it will probably not include macro expansion. -- John McEnerney, Metrowerks PowerPC Product Architect +++++++++++++++++++++++++++ >From tchan@irus.rri.uwo.ca (Thomas KC Chan) Date: 24 Mar 1994 16:46:07 GMT Organization: Imaging Labs, Robarts Research Institute, London Michael Levy, thanks you for sharing your list with us. In article johnmce@world.std.com (John McEnerney) writes: >>int t1,t2; >>.... >>t1 = 1000; >>t2 = 2000; >>... >>the debugger showed the same values for t1 and t2, and >>changed them simultaneously! > >This is probably -not- a bug in the debugger. If the compiler can >determine that t1 and t2 will never be live simultaneously, it is free to >place them in the same register or memory location. In fact, it is free >to delete the assignments altogether if t1 and t2 are never used. (Unless >they are declared 'volatile') As a high-level language programmer, I don't think I have to worry about which register is assigned to which variable. If this happens only when certain optimization option is on, then it is not a bug; otherwise it definitely is a bug! Can Michael verify this? >>I have a horrible macro called TAG(X) defined like this: >>#define TAG(X) \ >>((!(heap[X]&1))?(heap[X]&3):((!(heap[X]&2))?(heap[X]&15):(heap[X]&63))) >> >>THINK C's debugger lets me place the expression TAG(X) in the "data" >>window and see a value (like 1 or 63). I find this soooo useful. >>Please consider adding something similar. > >This will not be possible with our current debugger/compiler >architecture. THINK C is one of the only environments I've ever seen >which does this; it is a side-effect of the way the debugger works, which >is to call the compiler to evaluate the expression. How about unix's dbx & debuggers on VMS ... ? This feature is definitely needed. As a matter of facts, CW debugger is the only one I used so far that lack of this feature. I also want the capability of hidding some of the variables (local & global) that I am not interested in. Currently I have to scroll the window ups & downs just to see the variables I have doubts on... (Have I overlooked that such feature is already implemented in CW debugger?!!) As for my second question, I only want to overwrite the same line on the screen by using a "" character instead of a "" in the ANSI "printf" function. Any special character I could use to send to CW's SIOUX to simulate this behavior?! (Any way to re-position a SIOUX window besides manually draging it? Any DOC on SIOUX besides the on-line User Manuals that comes with the CD-ROM?) I always want to ask this: Is "support@metrowerks.ca" the e-mail address for "support" from Metrowerks. (It was printed on the little booklet that comes with the CW CD-ROM.) I have sent my queries there for a couple/several weeks but never got any replies ??!! --------------------------- >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Subject: Quickdraw GX Beta 3 fun Date: 23 Mar 94 12:00:23 +1300 Organization: University of Waikato, Hamilton, New Zealand Just for fun, I tried duplicating the example on page 207 of the PostScript Red Book, 2nd Ed. For those without the book, the design is a large letter A against a rectangular background. Both the letter and the rectangle are filled with a pattern of stars, alternately black and grey. The first snag I hit is that QuickDraw GX doesn't allow multicoloured fill patterns--not unless you use a bitmap for the pattern shape, I guess. So all my stars are one colour for now. The second problem I hit was that the fill for the letter would not draw properly: stars would appear well outside the character outline. This bug is still present in beta 3, but I can get around it by changing the shape type from text to a path. The same thing would happen for the rectangle before, but this works properly in beta 3. The next problem was that the fills for the rectangle and the letter would not match up--the positions of the stars were different. This is also fixed in beta 3. All in all, the betas are getting better and better. I hope release isn't too far off now... 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+12:00 +++++++++++++++++++++++++++ >From dowdy@apple.com (Tom Dowdy) Date: Wed, 23 Mar 1994 00:46:58 GMT Organization: Apple Computer, Inc. In article <1994Mar23.120024.26760@waikato.ac.nz>, ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) wrote: > Just for fun, I tried duplicating the example on page 207 of the PostScript > Red Book, 2nd Ed. > > For those without the book, the design is a large letter A against a rectangular > background. Both the letter and the rectangle are filled with a pattern of > stars, alternately black and grey. > > The first snag I hit is that QuickDraw GX doesn't allow multicoloured fill > patterns--not unless you use a bitmap for the pattern shape, I guess. So all > my stars are one colour for now. Ah! You can make *two* shapes, each filled with a different pattern/color. I haven't seen the picture in a while, but I assume that it's just one phase is gray and another black. Since only the pattern areas of the filled shape are blitted, you can place them on top of one another to get the alternating behavior you mention. -- Tom Dowdy Internet: dowdy@apple.COM Apple Computer MS:302-3KS UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy 1 Infinite Loop AppleLink: DOWDY1 Cupertino, CA 95014 "The 'Ooh-Ah' Bird is so called because it lays square eggs." --------------------------- >From jarezina@magnus.acs.ohio-state.edu (Jasna M. Arezina-Wilson) Subject: Spoofing a serial port Date: 22 Mar 1994 20:54:55 GMT Organization: Ohio State University I have a need to write an app/extension/cdev that will allow me to either intercept a port speed call and/or modify said call (the reason is that I have an older software package that drives the port at 19200, but my lab's scanner interface is limited to 9600, and the software doesn't let me change the port speed). Before I start on this nasty little project, does anyone have any tips/clues/warnings? - ------------------------------------------------------- #include /* "My words are my own, and nobody paid me to say them." */ void void(void); /* void where voided */ +++++++++++++++++++++++++++ >From Frank Price Date: 22 Mar 1994 22:40:47 GMT Organization: Pomona College In article Jasna M. Arezina-Wilson, jarezina@magnus.acs.ohio-state.edu writes: >I have a need to write an app/extension/cdev that will allow me to either >intercept a port speed call and/or modify said call (the reason is that I >have an older software package that drives the port at 19200, but my lab's >scanner interface is limited to 9600, and the software doesn't let me >change the port speed). Before I start on this nasty little project, does >anyone have any tips/clues/warnings? A MUCH better idea would be to modify the subject program's code directly. Making a patch on PBControl would be unreliable depending on how they decided to set the baud rate. There are two ways to set the baud rate. One is a PBControl with csCode of 13 (this is from memory so don't quote me). The other is the standard SerReset call which the Apple glue should translate into a different PBControl call (see Serial Driver chapter of IM). Basically, use Macsbug (TMON would be a lot easier here) to trap on all PBControl calls in the app. Look at the csCode. When you find the place in the code that the appropriate call is occurring, use the ResEdit CODE disassembler or similar device to edit the hex instructions directly to modify the baud rate requested into what you really want. This solution will solve your problem permanently and reliably, and will not introduce a whole slew of potential problems caused by trap patches. -Frank _______________________________________________________________________ | Frank Price | wprice@jarthur.claremont.edu | |_______________|______________________________________________________| +++++++++++++++++++++++++++ >From jarezina@magnus.acs.ohio-state.edu (Jasna M. Arezina-Wilson) Date: 23 Mar 1994 15:44:41 GMT Organization: Ohio State University In article <2mns5f$jje@jaws.cs.hmc.edu>, Frank Price wrote: > [Idea on using MacsBug to hack serial speed] This is pretty much what I did. The problem I had in not doing this in the first place is that I had no way to get MacsBug to run (no int button on the SE here), so I had to track down the F-Key to get into MacsBug. Plus, adding to the fact that I have never used MacsBug before (other than finding where my program crashed), it was real fun. I still wasn't able to change the baud-rate directly - I had to patch the code and check the control call, but at least it works! (PS: I still think writing a program to spoof the baud rate would be interesting) - ------------------------------------------------------- #include /* "My words are my own, and nobody paid me to say them." */ void void(void); /* void where voided */ --------------------------- >From Dan Crevier Subject: Using Think Pascal Library in SC++ Date: 22 Mar 94 05:18:13 GMT Organization: Harvard University Hi, I'm trying to use the WASTE TextEdit engine with SC++. WASTE comes with WASTE.lib, a Think Pascal library. I used oConv from Think C 5.0 (I couldn't add it to my project to use the .o converter...). That gave me a .pi file I could add to the project, and when I tried to link, I got a message that WESetInfo, _LMUL, and _LDIV weren't defined. I assume that the are some long multiplication and division routines. Can I write short routines to implement these? I have MWC, and MPW, but not Think Pascal. As for WESetInfo, I used DumpObj from MPW (I'd never used it before, I'm not a MPW person), and it showed a list of routines at the top with EP= in front of them, and the routine name in all caps (including WESETINFO). What does this mean? Any help would be appreciated. Thanks. dan +++++++++++++++++++++++++++ >From ingemar@lysator.liu.se (Ingemar Ragnemalm) Date: Thu, 24 Mar 1994 10:49:25 GMT Organization: (none) Dan Crevier writes: > Hi, I'm trying to use the WASTE TextEdit engine with SC++. WASTE >comes with WASTE.lib, a Think Pascal library. I used oConv from Think C >5.0 (I couldn't add it to my project to use the .o converter...). That >gave me a .pi file I could add to the project, and when I tried to link, >I got a message that WESetInfo, _LMUL, and _LDIV weren't defined. I >assume that the are some long multiplication and division routines. Can >I write short routines to implement these? I have MWC, and MPW, but not >Think Pascal. This is exactly the problem I wrote about in my recent post (about how to make SAT work under Think C v6). 1) You must include uRuntime.lib. Convert it to a C library and include it. Using Think C 5, this was all you had to do. (You may have to fiddle with the .v file a bit too.) 2) Under Think C 6 (or C++), there's a bug in the linker (?) that makes it really confused with uRuntime.lib. You must open it with Think C 5 and REMOVE the segment named TOOLBOX. Ugly, isn't it? -- - - Ingemar Ragnemalm, PhD Image processing, Mac shareware games E-mail address: ingemar@isy.liu.se or ingemar@lysator.liu.se --------------------------- >From alex@metcalf.demon.co.uk (Alex Metcalf) Subject: rowBytes for the screen too big? Date: Sat, 19 Mar 1994 00:52:44 GMT Organization: Demon Internet Hey there! After hacking around with my custom CopyBits routine (which works nicely, BTW), I checked what the rowBytes was for the screen's PixMap. My screen's only 640 pixels wide (in 8-bit, so one pixel per byte), but the rowBytes is 1024. What gives? Is this something to do with making the transfer faster in/out of video RAM? Hmm... Alex alex@metcalf.demon.co.uk +++++++++++++++++++++++++++ >From mssmith@afterlife.ncsc.mil (M. Scott Smith) Date: Sat, 19 Mar 1994 04:35:11 GMT Organization: The Great Beyond In article alex@metcalf.demon.co.uk (Alex Metcalf) writes: > > Hey there! > > After hacking around with my custom CopyBits routine (which works >nicely, BTW), I checked what the rowBytes was for the screen's PixMap. My >screen's only 640 pixels wide (in 8-bit, so one pixel per byte), but the >rowBytes is 1024. What gives? Is this something to do with making the >transfer faster in/out of video RAM? > > Hmm... > Alex Alex, If your rowBytes is sincerely 1024, then take your Mac to an Apple service center immediately. It must be quarantined before you begin to cause others' Macs to have obscure video symptoms. But seriously.. You've discovered a truth about how video works on Macs, and some pretty quantitative evidence why it's not safe to assume that jumping ahead 640 bytes puts you on the next line (particularly if you're fooling around with direct-screen addressing, as I do). Part of the reasoning behind this (and this is true of all video cards, Mac and non-Mac) is that you can't buy a, say, 3.7 byte RAM chip. RAM chips only come in certain sizes, so it's not really possible to have _exactly_ the right amount of RAM for the screen dimensions and depth. Since it probably wouldn't be a good idea to have _less_, most video cards have _more_ -- and "jump up" to the most convenient (cheap, etc.) amount. Keep in mind that most video cards can drive monitors of varying resolutions, and depths. If you switch your monitor to black and white mode, you don't even need 640 bytes per scanline. (More like 80.) Jump it up to 24-bit mode, and you need quite a bit more. There's _always_ going to be wasted space, even if you're at the best monitor configuration your video hardware can support. (Step beyond that, and your video hardware won't support it -- which is a good reason why you can often get 24-bit color on 13" monitors with some cards, but not on 21" monitors.) Now, you're talking about the screen's PixMap. In my own PixMap's I "align" the data to fit nice boundaries, and there's handy formulas for doing this. In that case it does benefit things like CopyBits. The strategy is that you have a width and height of "usable" space in a PixMap (what you intend to actually be there), and rowBytes (and colBytes) might not necessarily jive with width and height. So you subtract rowBytes from width to know how to get to the next line in a PixMap. But there's other reasons, as I listed, for the screen's PixMap to be super- aligned. Now, just think! You've found a lot of extra RAM that you can use if you need! Let's see, 1024-640 = 384 * 480 = 180k of free RAM! (Pardon any math errors, it's late.) And imagine what's in store with video cards that are perfectly happy driving 21" monitors in 24-bit color but are only hooked up to 12" black and white monitors.. Of course I'm sort of kidding. But that extra RAM has been put to good use in the past; as I recall, someone wrote a program called MaxAppleSomethingOrOther that "enlarged" the dimensions of the 13" monitor when used with the 8/8-24 video card. (It essentially got rid of the black borders around the 13" screen.) It didn't work with my 8-24GC, darn it, so I never got to try it, but I saw it and it was neat. In any case, it can be baffling to see inflated rowBytes but that's how it is; just be sure to make no relations between width of screen and number of bytes dedicated to each line by the video card.. Hope that made sense! Have fun, Scott - - M. Scott Smith (mssmith@afterlife.ncsc.mil || umsmith@mcs.drexel.edu) Mac developer. Student. Ski bum. Not responsible for the national debt. +++++++++++++++++++++++++++ >From phixus@netcom.com (Chris DeSalvo) Date: Mon, 21 Mar 1994 04:48:51 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) Alex Metcalf (alex@metcalf.demon.co.uk) wrote: : Hey there! : After hacking around with my custom CopyBits routine (which works : nicely, BTW), I checked what the rowBytes was for the screen's PixMap. My : screen's only 640 pixels wide (in 8-bit, so one pixel per byte), but the : rowBytes is 1024. What gives? Is this something to do with making the : transfer faster in/out of video RAM? Always do a & 0x07FF on a rowBytes field before using it. L8R Chris -- +-----------------------------------------------------------------+ | phixus@netcom.com | Macintosh: Changing the world, | | Chris De Salvo | one person at a time! | | Professional Mac Geek | ----------------------------- | | MacPlay, Irvine, CA | (I wish they'd hurry up!) | +-----------------------------------------------------------------+ Any opinions expressed, or implied, are my own! They should not be considered representative of the opinions or policies of my employer, MacPlay, a division of Interplay Productions, Inc. +++++++++++++++++++++++++++ >From phixus@netcom.com (Chris DeSalvo) Date: Tue, 22 Mar 1994 07:45:08 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) Chris DeSalvo (phixus@netcom.com) wrote: : Alex Metcalf (alex@metcalf.demon.co.uk) wrote: : : Hey there! : : After hacking around with my custom CopyBits routine (which works : : nicely, BTW), I checked what the rowBytes was for the screen's PixMap. My : : screen's only 640 pixels wide (in 8-bit, so one pixel per byte), but the : : rowBytes is 1024. What gives? Is this something to do with making the : : transfer faster in/out of video RAM? : Always do a & 0x07FF on a rowBytes field before using it. Mistake already realised. Please, no flames. I was thinking GWorlds, not monitors. Yes, a monitor's rowBytes might very well be 1024 because 1K block transfers probably go a heck of a lot faster than 640K transfers. Chris -- +-----------------------------------------------------------------+ | phixus@netcom.com | Macintosh: Changing the world, | | Chris De Salvo | one person at a time! | | Professional Mac Geek | ----------------------------- | | MacPlay, Irvine, CA | (I wish they'd hurry up!) | +-----------------------------------------------------------------+ Any opinions expressed, or implied, are my own! They should not be considered representative of the opinions or policies of my employer, MacPlay, a division of Interplay Productions, Inc. +++++++++++++++++++++++++++ >From paul@taniwha.com (Paul Campbell) Date: 24 Mar 1994 06:37:09 GMT Organization: Taniwha Systems Design In article phixus@netcom.com (Chris DeSalvo) writes: > Alex Metcalf (alex@metcalf.demon.co.uk) wrote: > : After hacking around with my custom CopyBits routine (which works > : nicely, BTW), I checked what the rowBytes was for the screen's PixMap. My > : screen's only 640 pixels wide (in 8-bit, so one pixel per byte), but the > : rowBytes is 1024. What gives? Is this something to do with making the > : transfer faster in/out of video RAM? nah ... it's just easier for the hardware guys - esp. if the same hardware has to do 1024x768 - chances are you weren't going to use that extra memory anyway > Always do a & 0x07FF on a rowBytes field before using it. NO!! ... always do a & 0x7FFF before using it [and DON'T do as older IMs suggest do an & 0x3FFF - there are now cards out there with genuine rowbytes equal to 0x4000 (or greater) - if you bypass quickdraw and write directly to the screen BEWARE!) Paul ______________________________________________________________________ Paul Campbell paul@taniwha.com "Xenon? It's a rare gas ...." --------------------------- End of C.S.M.P. Digest **********************