From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-065 Date: Fri, 14 Oct 1994 14:54:01 +0100 (MET) C.S.M.P. Digest Fri, 14 Oct 94 Volume 3 : Issue 65 Today's Topics: Books-Reference: opinions needed!! Changing to new toolbox routine names with MacPerl Cleanest way to turn AppleTalk on-off Dialog Edit text> 256 characters Fast zeroing on PPC Inside Mac on CD-ROM Q: Using PPC apps without Shared Libraries? Reading STR# resource - Pascal code 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 stone@phoenix.cs.uga.edu (Robert) Subject: Books-Reference: opinions needed!! Date: 24 Sep 1994 22:09:29 GMT Organization: kind of sloppy actually.... I need YOUR opinion! Here are some books that I've heard of, and I want to know how they rate. Also, let me know if you have any good suggestions on where to get them (mail order or otherwise.) Note that I'm interested in books for people who know little or nothing about mac programming in general (but who know something about programming on other platforms.) Inside Macintosh: Overview - worth it or not? necessary? What Inside mac books are absolutely essential for any mac programmer? Power Macintosh Programming Starter Kit (book + CD) Anyone used it? Is it useful for people who have, say, CW gold but no PowerPC? What is the "special" version of MW CodeWarrior included on the CD like? (i.e. how stripped down?) Other books: (How suitable for complete neophytes? How "good" in general?) Think THINK C by Dan Parks Sydow Macintosh Programming for Dummies by Dan Parks Sydow The C Programming Primer from Dave Mark Learn C on the Macintosh by Dave Mark Learn C++ on the Macintosh by Dave Mark Symantec C++ Programming for the Macintosh by ??? How to Write Macintosh Software, Third Edition "Macintosh Programming Secrets" 2nd edition by ??? Debugging Macintosh Software With MacsBug the Waite Group's C Primer Plus the Waite Group's C++ Primer (or something like that) C++ Primer (Addison Wesley) C++ Programming Language (Addison Wesley) K&R's The C Programming Language, 2nd Edition. Any books I'm missing that might be useful for complete novices? Thanks for your reply. This info will be very useful to me and many others. (I may start a "getting started with mac programming FAQ.") @@@@@ Robert Stone (stone@phoenix.cs.uga.edu) @@@@@ Some Sort of Computer-Related Person, UGA - Extension Dairy Sci. @@@@@ Windows - n. a software package designed to cure the DOS virus, but which proved to be ineffective. While removing the 640K limit symptom, the system performance becomes degraded even further. Also increases chance of system crash and consumes additional disk space. +++++++++++++++++++++++++++ >From nick+@pitt.edu ( nick.c ) Date: Sun, 25 Sep 94 01:28:48 GMT Organization: The Pitt, Chemistry In Article <36282p$n72@hobbes.cc.uga.edu>, stone@phoenix.cs.uga.edu (Robert) wrote: >Inside Macintosh: Overview - worth it or not? necessary? What Inside mac >books are absolutely essential for any mac programmer? A good introduction to the general structure of the essentials of a mac program. Read it - once. Not necessary, but helpfull. The essential NIM? Depends on what you're doing. In general I'd say Toolbox, More Toolbox, Imaging with Quickdraw, and Files. I found "Text" very usefull, not sure I'd call it essential. Some folks say "Memory" is essential, not sure I'd agree. >Power Macintosh Programming Starter Kit (book + CD) Anyone used it? Is it >useful for people who have, say, CW gold but no PowerPC? What is the "special" >version of MW CodeWarrior included on the CD like? (i.e. how stripped down?) A neat book, it discusses some issues unique to the Power Mac that I know of no other source for. It also presents some unique mac programming techniques (eg Rez) that are not usually brought up in introductory books. The version of CW included will only allow you to open existing projects, not create new ones. There are example projects on the CD, so you have a fully functional environment for learning/evaluating CW - but you won't be able to use it to generate your own projects. I'd recommend this book to someone who wants to familiarize themselves with the CW environment, or is considering buying CW, or who has an interest in programming for the powermac. I would not recommend this for someone entirely new to mac programming. >Other books: (How suitable for complete neophytes? How "good" in general?) > >Think THINK C by Dan Parks Sydow It's been highly recommended on the net, and Dan is a good author, but I haven't read it. >Macintosh Programming for Dummies by Dan Parks Sydow >The C Programming Primer from Dave Mark A little out of date, but it's what I learned with, and I'd still recommend it for someone who knows C but is unfamiliar with programming on the mac. Written in plain old english, it presents the concepts and implementation of basic macintosh programming techniques such as how to use menus and how to manage windows. It's still very relevant, and extremely well written. >Learn C on the Macintosh by Dave Mark The mac toolbox is a collection of rom "tools" that you use to generate many of the common elements of the macintosh interface: both it's visible interface and it's "method" for dealing with user interactions. A program is a recipe for getting a job done that the computer will read and follow. You can tell the computer to use the "tools" in the rom toolbox as well as other actions but you have to tell the computer in a language it'll understand. The most common language for creating these recipes on the mac is C. You have to learn to a language before you can do anything else, if you choose to learn C, Dave Mark's book is a clear, effective, and well structured introduction to that language. Recommended as the first book you buy to learn macintosh programming. >Learn C++ on the Macintosh by Dave Mark C++ is a superset of C, and should not be the first language you learn. This was one of two books I read when I learned C++, and I recommend it, however I'd consider this book the un-official "volume 2" to Dave Mark's _Learn C on the Macintosh_. Learn C first, then learn the toolbox. Program for a while, and when you're confident with that this book is a good intro to the joys and frustrations of a new *style* of programming called OOP. C++, an enhanced version of C, is a good choice to implement that style. >Symantec C++ Programming for the Macintosh by ??? Eh. A good introduction to the Symantec environment, and a handy reference - but not a must have. It general learning the compiler is the easy part, learning what you can do with it - that's the art. Does re-introduce a lot of C++ concepts, but not the place to learn 'em. >How to Write Macintosh Software, Third Edition >"Macintosh Programming Secrets" 2nd edition by ??? A good, *fun* book that includes so many "in-jokes" it's hard to read with a straight face. I don't think this is intended as a "first" book on the toolbox, but it's good supplemental reading - and a lot of fun to read. >Debugging Macintosh Software With MacsBug >the Waite Group's C Primer Plus >the Waite Group's C++ Primer (or something like that) >C++ Primer (Addison Wesley) >C++ Programming Language (Addison Wesley) As close to the definitive reference on C++ as exists. As I said above, don't start to C++, but when you want to learn C++ this is a must have. Reads like stereo instructions, but an essential *reference*. >K&R's The C Programming Language, 2nd Edition. The classic. If you program in C, you have this book. I wouldn't learn C from it, but I wouldn't learn C without it. >Any books I'm missing that might be useful for complete novices? > >Thanks for your reply. This info will be very useful to me and many others. >(I may start a "getting started with mac programming FAQ.") Overdue, please do. -- nick _/ _/ _/ _/_/_/ _/ _/ Interet: nick@pitt.edu _/_/ _/ _/ _/ _/ _/_/_/ eWorld: nick _/ _/_/ _/ _/ _/ _/ CIS: 71232,766 _/ _/ _/ _/_/_/ _/ _/ +++++++++++++++++++++++++++ >From thundero@news.delphi.com (THUNDERONE@DELPHI.COM) Date: 25 Sep 1994 03:43:25 -0000 Organization: Delphi Internet Services Corporation nick+@pitt.edu ( nick.c ) writes: >In Article <36282p$n72@hobbes.cc.uga.edu>, stone@phoenix.cs.uga.edu (Robert) >wrote: [snip] >>Learn C on the Macintosh by Dave Mark [explaination of mac programming paradigm deleted] > on the mac is C. You have to learn to a language before you > can do anything else, if you choose to learn C, Dave Mark's book > is a clear, effective, and well structured introduction to that > language. Recommended as the first book you buy to learn macintosh > programming. >>Learn C++ on the Macintosh by Dave Mark > C++ is a superset of C, and should not be the first language you > learn. This was one of two books I read when I learned C++, > and I recommend it, however I'd consider this book the un-official > "volume 2" to Dave Mark's _Learn C on the Macintosh_. Learn > C first, then learn the toolbox. Program for a while, and when > you're confident with that this book is a good intro to the joys > and frustrations of a new *style* of programming called OOP. > C++, an enhanced version of C, is a good choice to implement > that style. [rest deleted] I disagree. There are much better books that assume no platform-specifics which are better introductions to C and C++ as languges. Dave Mark's Learn C/++ on the Mac books are an incredible waste of trees. 1. They only teach you the very basics of the languges. Platform-null books go into much greater detail. 2. He doesn't know how to program effective C++ (or didn't at the time he wrote the book). 3. Both of these books are specific to programming DOS/Unix boxes using Think C. I repeat: there are much better books for this purpose. Such as: C++ Inside Out The Waite Group's stuff Teach Yourself C++ by Al Stevens I think almost any C/C++ book that is platform-null will do the job well. ........................................................................ Chris Thomas, thunderone@delphi.com, Project KillThinkRef @ Echo Software +++++++++++++++++++++++++++ >From afcsusan@aol.com (AFC Susan) Date: 25 Sep 1994 04:17:02 -0400 Organization: America Online, Inc. (1-800-827-6364) Re article , nick+@pitt.edu ( nick.c ): Thank you for your thorough response. Sorry I must disagree on these two books. > > Learn C on the Macintosh by Dave Mark ...You have to learn to a > language before you can do anything else, if you choose to learn > C, Dave Mark's book is a clear, effective, and well structured > introduction to that language. Recommended as the first book you > buy to learn macintosh programming.... This book has the surface appearance of a new wonder drug, touted as containing the C language, a compiler, reference material, a glossary, and programming examples. Too bad people fall for slick packaging. It is really sad to see a discipline accepting of such nonsense, when a rock solid foundation is needed instead. > > Learn C++ on the Macintosh by Dave Mark... C++ is a superset of > C, and should not be the first language you learn. This was one > of two books I read when I learned C++, and I recommend it, > however I'd consider this book the un-official "volume 2" to Dave > Mark's _Learn C on the Macintosh_. Learn C first, then learn the > toolbox.... Pardon the paraphrase. As a much brighter brain than mine said regarding plummeting educational standards in the USA, in Doonesbury, "Maybe we could call ourselves Programming High School and get away with it." Something tells me that continued recommendation of Mr. Mark's books, which is apparently based on his Primer fame, in professional circles like c.s.m.p is an emergency that just won't go away. Susan Lesch (AFC Susan) Forum Consultant, Macintosh Utilities Forum America Online, Inc. Speaking only for myself and my colleagues. "You be me for a while. And I'll be you." --Paul Westerberg, and The Replacements, circa 1989. +++++++++++++++++++++++++++ >From Gilles Dignard Date: 25 Sep 1994 13:40:34 GMT Organization: HookUp Communication Corporation, Oakville, Ontario, CANADA In article <36282p$n72@hobbes.cc.uga.edu> Robert, stone@phoenix.cs.uga.edu writes: >Any books I'm missing that might be useful for complete novices? Actually, your list is missing the two I consider were the most helpful to me learning C++. Neither is Macintosh specific, though. The first is essentially a textbook. It is "Classic Data Structures in C++" by Timothy A. Budd, published by Addison Wesley, ISBN 0-201-50889-3. What I found particularly useful were the numerous code snippets and source to a large number of important classes that are included (Linked lists, string classes, vectors, queues, matrices, etc.). Most importantly, it isn't just a cookbook of classes, however. The classes are discussed in detail, and while it may or may not be something new, what the classes represent in a more general computational sense is also discussed. Once you get your feet wet, and want to know how to best use your new-found C++ abilities, the book to get is "Effective C++ / 50 Specific Ways to Improve Your Programs and Designs" by Scott Meyers, published by Addison-Wesley, ISBN 0-201-56364-9. One of the best "programming" books I've ever run across. A must-have for all C++ programmers. - -------------------- #### /\ #### Gilles Dignard - gdignard@hookup.net #### ]\/\ /\/[ #### #### \ \ / / #### The human mind treats a new idea the way the #### /--------\ #### body treats a strange protein; it rejects it. #### ][ #### - P.B. Medawar - -------------------- +++++++++++++++++++++++++++ >From howard@netcom.com (Howard Berkey) Date: Sun, 25 Sep 1994 20:53:18 GMT Organization: Psychonaut Foundation In article , nick+@pitt.edu ( nick.c ) wrote: > >Debugging Macintosh Software With MacsBug > >the Waite Group's C Primer Plus > >the Waite Group's C++ Primer (or something like that) > >C++ Primer (Addison Wesley) > >C++ Programming Language (Addison Wesley) > > As close to the definitive reference on C++ as exists. As I said > above, don't start to C++, but when you want to learn C++ this is > a must have. Reads like stereo instructions, but an essential > *reference*. > ARM. ARM. ARM. Must have. (until I can get the ANSI standard, that is :-) Really, the Annotated Reference Manual is as close to definitive as it gets for C++, at least as a target for current compilers, which is what is really important unless you can head-compile your code and speak in assembler :-) > > >Thanks for your reply. This info will be very useful to me and many others. > >(I may start a "getting started with mac programming FAQ.") > > Overdue, please do. > Jon's is a good start at least... you might check it out, he posts it here regularly. -H- -- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Howard Berkey howard@netcom.com Segmentation Fault (core dumped) +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Mon, 26 Sep 1994 19:29:02 +0100 Organization: Royal Institute of Something or other In article <363uki$rap@relay.tor.hookup.net>, Gilles Dignard wrote: >Once you get your feet wet, and want to know how to best use your >new-found C++ abilities, the book to get is "Effective C++ / 50 Specific >Ways to Improve Your Programs and Designs" by Scott Meyers, published by May I pop in with a recommendation for "Writing Solid Code" by Steve Maguire? Once you've gotten through your first C or C++ or even Pascal book, this book will teach you lots of good habits which will help you a LOT. It also goes through known problem areas, especially when writing C code, and tells you what you can do about it. Or maybe I should keep quiet about it and treat it as a secret corporate advantage? :-) Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden "Psychotherapist" - "Psycho-The-Rapist" Pure coincidence? You decide! +++++++++++++++++++++++++++ >From garyg@oak.circa.ufl.edu (gary greenberg) Date: 26 Sep 1994 01:39:36 GMT Organization: Center for Instructional and Research Computing Activities In article <36282p$n72@hobbes.cc.uga.edu>, stone@phoenix.cs.uga.edu (Robert) writes: >I need YOUR opinion! [massive snip] >Any books I'm missing that might be useful for complete novices? > >Thanks for your reply. This info will be very useful to me and many others. >(I may start a "getting started with mac programming FAQ.") > >@@@@@ Robert Stone (stone@phoenix.cs.uga.edu) Here's advice from a _true neophyte_ fwiw, In the last few months, I've spent a good deal of time in the books. I've started at the ANSI C level 'cause I need it for work, and I'm teaching myself for fun. I've read several Smalltalk books, some UNIX C, and am working my way thru several Mac Programming books. Rather than offer specific comments about any single book compared to another, I'll post the following note cause I think *everyone* reading this list will want the information included. There is an online source to these books; several actually. Addison Wesley has an online Gopher, and probably a WWW. O'Reilly and Associates does also. I don't have the A/W handy, but O'Reilly is at nuts@ora.com for general questions (they do the *great* Nutshell books -- I just finished their VI book and its A++). To get their catalog, send mail to catalog@ora.com, and to get info about their gopher send to gopher@ora.com. Now, ... for more Mac Specific books & everything else ... ____ begin included ______________ From: MX%"books@softproeast.com" 22-SEP-1994 17:51:03.62 To: me Subj: Softpro Internet Resources [snip header; increase other's reading pleasure ;-) ] =============================================================== ... Below you will find additional information for accessing our on-line resources such as our Gopher and Mosaic Catalog services. If you have any additional questions, feel free to e-mail, write, fax, or give us a call. David Vins Softpro ================================================================== Softpro offers both on-line Gopher and World Wide Web/Mosaic services complete with browse, search, and on-line order capabilities. Our booklist is also availble via FTP. To access these services, follow the information provided below. FTP: -> Anonymous ftp to "ftp.std.com" -> Our booklist can be obtained as the following... "customers/books/Softpro/booklist" Gopher: -> "gopher storefront.xor.com" -> Select the "Softpro Books" menu item. WWW/Mosaic: -> "xmosaic http://storefront.xor.com" -> Select the "Softpro Books" menu item. -> Mosaic for Windows/Mac users please note, our URL (Universal Resource Locator) for Softpro is "http://storefront.xor.com/" ================================================================ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - Softpro Books & Software -=- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= = - 112 Burlington Mall Rd. Hours: Mon-Fri 9am to 8pm - = Burlington, MA 01803-5300 Saturday 10am to 6pm = - Sunday 12pm to 5pm - = Sales: +1.617.273.2919 = - Fax: +1.617.273.2499 - =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= = - E-Mail -> books@softproeast.com -=- = WWW/Mosaic -> http://storefront.xor.com = - Gopher -> gopher storefront.xor.com - =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= __________________ End Included ____________________ The folks at SoftPro have it all; books on C, C++, LISP, Smalltalk, UNIX, Windoze, whatever & the description of many books is also on line -- lots of the FAQ is there for the _including_. For ANSI C stuff, there are also online training courses avaliable, go to rtfm at mit, look in the Usenet FAQs for comp.lang.c and comp.lang.c++ -- they also include and rate books that are basically platform independent. Of course, to really code on the Mac you'll still need the Toolbox books at a minimum. Well, I've already told you more than I know, but hey ... at this price it's a good deal ;-) Cheers, Gary +++++++++++++++++++++++++++ >From tblanch@lookout (Todd Blanchard) Date: Mon, 26 Sep 1994 15:56:48 GMT Organization: US WEST Information Technologies Robert (stone@phoenix.cs.uga.edu) wrote: : I need YOUR opinion! Here are some books that I've heard of, and I want to : know how they rate. Also, let me know if you have any good suggestions on : where to get them (mail order or otherwise.) Note that I'm interested in : books for people who know little or nothing about mac programming in general : (but who know something about programming on other platforms.) I rely on the following pretty heavily: The Annotated C++ Reference Manual (ARM) Ellis & Stroustrup Effective C++, Scott Meyers - (Awesome book!) C++ IOStreams Handbook, Teale The C Programming Language, K&R Think Ref, Mac online refernce from Symantec. Apart from the last one, these are more general C++ references rather than Mac-specific. I'll leave the Mac stuff to those who actually do Macs for a living (I play for fun). Todd Blanchard --------------------------- >From hecht@vnet.net (Michael Hecht) Subject: Changing to new toolbox routine names with MacPerl Date: 25 Sep 1994 06:41:58 GMT Organization: Vnet Internet Access, Charlotte, NC - info@char.vnet.net The new Universal Headers rename many (~135) of the existing toolbox routines as part of the switch from a trap-based system to a code fragment system. For example, DisposHandle is now DisposeHandle. Apple suggests that you change your code to use the new names. Currently, they provide #defines to map the old name to the new one, but they claimed at the WWDC that the #defines will go away eventually. Those of you with MPW can use its canon tool to change the toolbox routines in all your source code easily. Those of you (like me) without MPW or canon can do the job using the MacPerl scripts I wrote. The first script searches the Universal Headers for #defines that look like old-->new name mappings. I included it for your edification--you don't need to actually run it. The second script applies the changes (read from the end of the script) to a group of .c files. Someone could probably turn this one into a MacPerl droplet if they were so inclined. Anyway, here they are. --Michael ============= begin "mkcanon.pl" # This is the directory where the Universal Headers live on my Mac $syshdir = 'Wynonna:Development:Symantec C++ for Macintosh:Mac #includes:Universal Headers:'; # Get a list of all Universal Header files opendir( SYSHDIR, $syshdir ) || die; @sysh = grep( /\.h$/, readdir( SYSHDIR )); closedir( SYSHDIR ); # For each header file foreach $sysh ( @sysh ) { # Read the header file open( SYSH, "<$syshdir$sysh" ) || die; while( ) { # Look for #defines with parameters next unless /^#define \w+\(/; # Read in multiline #defines $_ = $` . while /\\\n$/; # Look for #defines that simply rename a function call next unless /^#define (\w+)(\([^)]*\)) (\w+)\2/; # Get old & new names ( $old, $new ) = ( $1, $3 ); # The "IU" routines are confused in Apple? ( $new, $old ) = ( $old, $new ) if $new =~ /^IU/i; print "$old --> $new\n"; } close( SYSH ); } ============= end "mkcanon.pl" ============= begin "canon.pl" # This is the directory of source code to be changed $projdir = 'Wynonna:MyProject:'; # This is the directory that the changed files will be written to $outdir = 'Wynonna:MyProject Out:'; # Unbuffer STDOUT $| = 1; # Initialize substitution command string $s = ""; $npairs = 0; print "\nReading mapping pairs... "; # Read mapping pairs while( ) { # Split up this mapping pair chop; ( $old, $new ) = split( / --> / ); # Append substitution command to string $s .= "\$n = s/\\b$old\\b/$new/g; \$canon{ '$_' } += \$n if \$n;\n"; # Count pairs $npairs++; } print "$npairs\n"; # Uncomment next line to see what kind of code we're generating #print $s; # Get a list of all the source files in the project directory opendir( PROJDIR, $projdir ) || die; @proj = grep( /\.cp{0,2}$/, readdir( PROJDIR )); closedir( PROJDIR ); # Read entire file at once rather than line-by-line undef $/; $* = 1; # Go through the list of files foreach $proj ( @proj ) { # Read this file open( PROJ, "<$projdir$proj" ) || die; ( $fcreator, $ftype ) = &MacPerl'GetFileInfo( "$projdir$proj" ); $_ = ; close( PROJ ); # Reset our count of substitutions made, and perform all substitutions undef %canon; eval $s; # Continue if no changes were made next unless %canon; # Log the changes print "\n$proj:\n"; foreach $change ( sort keys %canon ) { print "$change: $canon{$change}\n"; } # Uncomment next line to skip writing the changed file # next; # Write the file open( PROJ, ">$outdir$proj" ) || die; &MacPerl'SetFileInfo( $fcreator, $ftype, "$outdir$proj" ); print PROJ; close( PROJ ); } __END__ SetCTitle --> SetControlTitle GetCTitle --> GetControlTitle UpdtControl --> UpdateControls SetCtlValue --> SetControlValue GetCtlValue --> GetControlValue SetCtlMin --> SetControlMinimum GetCtlMin --> GetControlMinimum SetCtlMax --> SetControlMaximum GetCtlMax --> GetControlMaximum SetCRefCon --> SetControlReference GetCRefCon --> GetControlReference SetCtlAction --> SetControlAction GetCtlAction --> GetControlAction SetCtlColor --> SetControlColor GetAuxCtl --> GetAuxiliaryControlRecord GetCVariant --> GetControlVariant getctitle --> getcontroltitle setctitle --> setcontroltitle DisposDialog --> DisposeDialog UpdtDialog --> UpdateDialog GetDItem --> GetDialogItem SetDItem --> SetDialogItem HideDItem --> HideDialogItem ShowDItem --> ShowDialogItem SelIText --> SelectDialogItemText GetIText --> GetDialogItemText SetIText --> SetDialogItemText FindDItem --> FindDialogItem GetAlrtStage --> GetAlertStage ResetAlrtStage --> ResetAlertStage DlgCut --> DialogCut DlgPaste --> DialogPaste DlgCopy --> DialogCopy DlgDelete --> DialogDelete SetDAFont --> SetDialogFont getitext --> getdialogitemtext setitext --> setdialogitemtext findditem --> finddialogitem KeyTrans --> KeyTranslate LDoDraw --> LSetDrawingMode LFind --> LGetCellDataLocation lfind --> lgetcelldatalocation ApplicZone --> ApplicationZone MFTempNewHandle --> TempNewHandle MFMaxMem --> TempMaxMem MFFreeMem --> TempFreeMem MFTempHLock --> TempHLock MFTempHUnlock --> TempHUnlock MFTempDisposHandle --> TempDisposeHandle MFTopMem --> TempTopMem ResrvMem --> ReserveMem DisposPtr --> DisposePtr DisposHandle --> DisposeHandle ReallocHandle --> ReallocateHandle AddResMenu --> AppendResMenu InsMenuItem --> InsertMenuItem DelMenuItem --> DeleteMenuItem SetItem --> SetMenuItemText GetItem --> GetMenuItemText GetMHandle --> GetMenuHandle DelMCEntries --> DeleteMCEntries DispMCInfo --> DisposeMCInfo addresmenu --> appendresmenu getitem --> getmenuitemtext setitem --> setmenuitemtext insmenuitem --> insertmenuitem OSAComponentFunctionInline --> ComponentCallNow LongDate2Secs --> LongDateToSeconds LongSecs2Date --> LongSecondsToDate IUMetric --> IsMetric Date2Secs --> DateToSeconds Secs2Date --> SecondsToDate DisposPictInfo --> DisposePictInfo DisposPixMap --> DisposePixMap DisposPixPat --> DisposePixPat DisposCTable --> DisposeCTable DisposCCursor --> DisposeCCursor DisposCIcon --> DisposeCIcon DisposGDevice --> DisposeGDevice NDrawJust --> DrawJustified NMeasureJust --> MeasureJustified NPortionText --> PortionLine SizeResource --> GetResourceSizeOnDisk MaxSizeRsrc --> GetMaxResourceSize RmveResource --> RemoveResource SetSysJust --> SetSysDirection GetSysJust --> GetSysDirection Font2Script --> FontToScript GetEnvirons --> GetScriptManagerVariable SetEnvirons --> SetScriptManagerVariable IUGetIntl --> GetIntlResource IUSetIntl --> SetIntlResource IUClearCache --> ClearIntlResourceCache IUGetItlTable --> GetIntlResourceTable TESetJust --> TESetAlignment TextBox --> TETextBox TEStylNew --> TEStyleNew SetStylHandle --> TESetStyleHandle GetStylHandle --> TEGetStyleHandle GetStyleHandle --> TEGetStyleHandle TEStylPaste --> TEStylePaste GetStylScrap --> TEGetStyleScrapHandle GetStyleScrap --> TEGetStyleScrapHandle SetStylScrap --> TEUseStyleScrap SetStyleScrap --> TEUseStyleScrap TEStylInsert --> TEStyleInsert TESetScrapLen --> TESetScrapLength TEGetScrapLen --> TEGetScrapLength SetClikLoop --> TESetClickLoop SetWordBreak --> TESetWordBreak IULDateString --> LongDateString iuldatestring --> longdatestring IULDateString --> LongTimeString iultimestring --> longtimestring String2Date --> StringToDate String2Time --> StringToTime UprString --> UpperString uprstring --> upperstring IUCompPString --> CompareString iucomppstring --> comparestring IUMagPString --> CompareText IUMagIDPString --> IdenticalText IUEqualPString --> IdenticalString iuequalpstring --> identicalstring IULangOrder --> LanguageOrder IUTextOrder --> TextOrder IUStringOrder --> StringOrder Str2Format --> StringToFormatRec Format2Str --> FormatRecToString FormatX2Str --> ExtendedToString FormatStr2X --> StringToExtended IUDatePString --> DateString iudatepstring --> datestring IUTimePString --> TimeString iutimepstring --> timestring ============= end "canon.pl" +++++++++++++++++++++++++++ >From neeri@iis.ee.ethz.ch (Matthias Neeracher) Date: 25 Sep 1994 12:26:08 GMT Organization: Swiss Federal Institute of Technology (ETHZ) hecht@vnet.net (Michael Hecht) writes: >Those of you with MPW can use its canon tool to change the toolbox >routines in all your source code easily. Those of you (like me) without >MPW or canon can do the job using the MacPerl scripts I wrote. K001. Hope you don't mind me borrowing these for my MacPerl hall of fame? >============= begin "mkcanon.pl" ># This is the directory where the Universal Headers live on my Mac >$syshdir = 'Wynonna:Development:Symantec C++ for Macintosh:Mac >#includes:Universal Headers:'; For those taking the script out of this article & try to run it: The above two lines are in fact one long word wrapped line. Matthias - --- Matthias Neeracher http://err.ethz.ch/members/neeri.html "And that's why I am going to turn this world upside down, and make of it a fire so *bright* that someone real will notice" -- Vernor Vinge, _Tatja Grimm's World_ --------------------------- >From mars@netcom.com (Darren Giles) Subject: Cleanest way to turn AppleTalk on-off Date: Thu, 15 Sep 1994 08:04:28 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) What is the cleanest way to turn AppleTalk on & off? I've used MPPOpen and MPPClose with some success in the past, but it's no longer in the universal headers. There's a mention of using OpenDriver in IM, but I'm a little leery of using it without more info than given. Basically, what I'm trying to do is simulate clicking on the "AppleTalk on/off" buttons in the Chooser. Has anyone done this? - Darren I know this is not something that should "normally" be done. I'm working on an embedded application, where the user will never even see the screen... so "normal" doesn't seem to apply. +++++++++++++++++++++++++++ >From mars@netcom.com (Darren Giles) Date: Mon, 26 Sep 1994 02:27:06 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) In article , I asked: > >What is the cleanest way to turn AppleTalk on & off? > >Basically, what I'm trying to do is simulate clicking on the "AppleTalk on/off" >buttons in the Chooser. Has anyone done this? I got answers from several people, request for the info from several others. Here's the code I'm now using, which works great: //////////////////////////////////////////////////////////////////////////////// // Must reboot after an off -> on transition for change to take effect //////////////////////////////////////////////////////////////////////////////// void cdev_atalk_on (void) { LMSetSPConfig (useATalk); } //////////////////////////////////////////////////////////////////////////////// void cdev_atalk_off (void) { LMSetSPConfig (useAsync); } --------------------------- >From startz@u.washington.edu (Dick Startz) Subject: Dialog Edit text> 256 characters Date: Thu, 22 Sep 1994 08:45:43 +0800 Organization: University of Washington I have a desparate need to display very long edit text items in dialogs. Can anyone suggest a kludge to let me do this? BTW, sometimes I have more than one per dialog. Thanks to all. -Dick Startz +++++++++++++++++++++++++++ >From rmah@panix.com (Robert Mah) Date: Thu, 22 Sep 1994 15:47:54 -0500 Organization: One Step Beyond startz@u.washington.edu (Dick Startz) wrote: ) I have a desparate need to display very long edit text items in dialogs. ) Can anyone suggest a kludge to let me do this? BTW, sometimes I have ) more than one per dialog. I just answered this in another post yesterday (complete with untested sample code). I'm afraid I can't remember the subject line, but it was similar to yours. Cheers, Rob _____________________________________________________________________ Robert S. Mah Software Development +1.212.947.6507 One Step Beyond and Network Consulting rmah@panix.com +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Fri, 23 Sep 1994 10:39:58 +0800 Organization: NCRPDA, Curtin University In article , startz@u.washington.edu (Dick Startz) wrote: >I have a desparate need to display very long edit text items in dialogs. >Can anyone suggest a kludge to let me do this? BTW, sometimes I have more >than one per dialog. Just write a dialog user item proc, and use TextBox (or better yet, use NeoTextBox as described in develop a few issues back (16?)). Peter. -- Peter N Lewis - Macintosh TCP fingerpainter FTP my programs from redback.cs.uwa.edu.au:Others/PeterLewis/ or amug.org:pub/peterlewis/ or nic.switch.ch:software/mac/peterlewis/ +++++++++++++++++++++++++++ >From fyock@mathworks.com (Lee Fyock) Date: Fri, 23 Sep 1994 10:23:59 -0400 Organization: The MathWorks, Inc. In article , peter.lewis@info.curtin.edu.au (Peter N Lewis) wrote: > In article , startz@u.washington.edu > (Dick Startz) wrote: > > >I have a desparate need to display very long edit text items in dialogs. > >Can anyone suggest a kludge to let me do this? BTW, sometimes I have more > >than one per dialog. > > Just write a dialog user item proc, and use TextBox (or better yet, use > NeoTextBox as described in develop a few issues back (16?)). This is too tough. Just get the TEHandle associated with the dialog item, and set the hText to whatever you'd like. The Dialog Manager does fine at displaying the item and editing it. To set it up, do like so: dlogPtr = GetNewDialog(DISPLAY_DLOG, nil, (WindowPtr) -1); SetPort(dlogPtr); GetDItem(dlogPtr,TEXT_ITEM,&iType,&iHandle,&iRect); teH = ((DialogPeek) dlogPtr)->textH; // textH contains the >255 character text to put into the dialog SetHandleSize((**teH).hText, 0); HLock(textH); err = HandAndHand(textH, (**teH).hText); HUnlock(textH); TECalText(teH); The "GetDItem" is necessary to get the Dialog Manager to actually load the dialog and set it up... You may need to add some stuff for more than one text item in the dialog, since the dialog has only one TextEdit record that is switched between the text items. Getting the data back out is similar and is left as an exercise to the reader. Have fun! Lee - ------------------------------------------------------------------ Lee Fyock "I think I would remain fyock@mathworks.com perfectly still." +++++++++++++++++++++++++++ >From gurgle@dnai.com (Pete Gontier) Date: Sat, 24 Sep 1994 10:19:35 -0800 Organization: Integer Poet Software In article , startz@u.washington.edu (Dick Startz) wrote: > I have a desparate need to display very long edit text items in dialogs. > Can anyone suggest a kludge to let me do this? BTW, sometimes I have more > than one per dialog. My understanding is that although the system calls which access the editText items take Pascal strings and thus are limited to 255 characters, it's possible to have larger pieces of text in an editText item. You just can't get that text out using the standard routines. You might want to reverse-engineer just exactly what kind of handle is returned to you by GetDItem. It may be a text handle and it may be a TE handle. Let us know what you discover. -- Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com "Anything the Windows gang hates this much can't be all bad." -- Andrew Gore , on OpenDoc, MacWEEK 9/19/94 +++++++++++++++++++++++++++ >From gurgle@dnai.com (Pete Gontier) Date: Mon, 26 Sep 1994 09:02:59 -0800 Organization: Integer Poet Software In article <364jlo$rg6@uropax.contrib.de>, stk@uropax.contrib.de (Stefan Kurth) wrote: > In article , > gurgle@dnai.com (Pete Gontier) wrote: > > > You might want to reverse-engineer just exactly what kind of handle is > > returned to you by GetDItem. It may be a text handle and it may be a TE > > handle. Let us know what you discover. > > Think Reference says it's the hText field of a TE handle, and that > sounds reasonable to me, because there is only one TE handle in a > dialog, even if there are several text fields. However, if you call 'GetDItem' for an editText which is not active (does not have the insertion point), the handle cannot be directly from the 'hText' field. Perhaps it's the-handle-which-might-be-in-the-'htext'-field. :-) Anyway, it would be interesting if this sort of thing is an Apple-documented behavior. I can't remember ever seeing documentation to this effect; your THINK Reference, er, reference is news to me. I'm not saying it's a bad idea to rely on this, but it would be nice to see an Apple sanction, just to make it official. -- Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com "One of (Misty's) recent paintings, 'Interring the Terrier', 1993, which appears to show a small headless dog being stuffed inside a red armchair by two frogs and a sardine, sold at auction for $21,000 -- a record price..." -- Busch and Silver, 'Why Cats Paint', p55 --------------------------- >From craig@raru.adelaide.edu.au (Craig Kloeden) Subject: Fast zeroing on PPC Date: Sun, 18 Sep 1994 00:56:26 +0930 Organization: University of Adelaide I have the following piece of code: - - Byte plane[maxX][maxY]; for (i=0;iFrom 103t_english@west.cscwc.pima.edu Date: 17 Sep 94 11:06:28 MST Organization: (none) In article , craig@raru.adelaide.edu.au (Craig Kloeden) writes: > I have the following piece of code: > > --- > > Byte plane[maxX][maxY]; > > for (i=0;i for (j=0;j plane[i][j] = 0; > > --- > > Believe it or not, this is a bottleneck in my program. > I need to make this as fast as possible on the PPC. > > Any advice would be appreciated. > Please note that I've cross-posted this to c.s.powerpc, (which is where it belongs, IMHO). Several things that you can do here: First, understand that you are dealing with a cached memory, where x values can fit in cache lines, and you want to deal with things one cache line at a time. Make the x loop your inner loop. Second, recognize that you are dealing with 1 byte numbers when you could easily be dealing with 4-byte numbers (or 8 if you are doing this directly to video where the video bus latency makes up for the slow speed of doing floating point load stores). Redo your loop as manipulating longs, and it will go much faster. Third, remember that the MPC601 chip "pipelines" loads and stores, so if you "unroll/unwrap" your inner loop so that you are performing [at least] 4 loads/stores each time through, you will see a tremendous speedup. Finally, if you have access to the PPCAsm, you can directly zero out this memory (if it all fits in the L1 cache) by simply using the assembly language instruction that zeros the cache rather than loading it from memory and THEN zeroing it. This would give you a HUGE speedup from what I understand. I don't have my MPC601 user's manual handy, and this isn't something that I really know how to do, so if some kind soul that DOES know how to do this would go into greater detail for him (and me)? If you don't have the PPCAsm, maybe we could compose this routine on-line for you, and I or somebody else could assemble it and either post it here in .hqx format or just e-mail it to you... That way, you could just link it to your program as a library routine... Lawson +++++++++++++++++++++++++++ >From jrb@mitre.org (Bob Boonstra) Date: Sat, 17 Sep 1994 18:22:30 -0400 Organization: MITRE Corp. In article , craig@raru.adelaide.edu.au (Craig Kloeden) wrote: > I have the following piece of code: > Byte plane[maxX][maxY]; > for (i=0;i for (j=0;j plane[i][j] = 0; > > Believe it or not, this is a bottleneck in my program. > I need to make this as fast as possible on the PPC. > Any advice would be appreciated. Others can probably do better, but you can get a significant improvement by writing in units larger than bytes and by loop unrolling. For example, the following code is more than 4 times faster than the original: register long double *p,*q; register long double zero=0; p = (long double *)plane; q = p + maxX*maxY/sizeof(long double); /* This assumes maxY is a multiple of long double in size */ /* If not, add a cleanup loop at the end. */ while (pFrom pchang@Xenon.Stanford.EDU (The Weasel) Date: 18 Sep 1994 18:54:03 GMT Organization: Computer Science Department, Stanford University. >In article , >craig@raru.adelaide.edu.au (Craig Kloeden) wrote: > >> I have the following piece of code: >> Byte plane[maxX][maxY]; >> for (i=0;i> for (j=0;j> plane[i][j] = 0; >> >> Believe it or not, this is a bottleneck in my program. >> I need to make this as fast as possible on the PPC. >> Any advice would be appreciated. [ Good suggestions deleted ] Another things you might try is to allocate your memory in a single continous block and running through it linearly. The array references that you have above is sort of equivilant to: plane[i * kMaxY + j] = ... Additionally, this may not be true based on your snippet, but if you are allocating the memory dynamically then allocating a single block is definitely cheaper and easier on the cache. Peter +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Sun, 18 Sep 1994 14:38:12 +1200 (NZST) Organization: (none) craig@raru.adelaide.edu.au (Craig Kloeden) writes: > I have the following piece of code: > > --- > > Byte plane[maxX][maxY]; > > for (i=0;i for (j=0;j plane[i][j] = 0; > > --- > > Believe it or not, this is a bottleneck in my program. > I need to make this as fast as possible on the PPC. > > Any advice would be appreciated. The quality of code generation doesn't matter much here -- it's all in how efficiently you bash the memory subsystem. The problem with the straight C code is that the processor has to read the old data from RAM, then you zero it, then you write it back. It's twice as fast if you only have to write the data out. This is exactly what the PPC "dcbz" instruction (Data Cache Block Zero) does -- it zeros 32 bytes of memory without first reading it from external RAM. i.e. it totally ignores the previous contents. This is useful no matter what you want to write into the memory, but it you happen to *want* zeros, then you don't need to do anything else. Here's a little PPC assembly routine that makes this instruction available to you in C, and an XCOFF object file that you can use from botht eh MPW and CodeWarrior compilers: - ------------------------------- ; void Zero32Bytes(void *p) ; function that zeros a 32 byte range of memory using dcbz export Zero32Bytes[DS] export .Zero32Bytes[PR] toc tc Zero32Bytes[TC], Zero32Bytes[DS] csect Zero32Bytes[DS] dc.l .Zero32Bytes[PR] dc.l TOC[tc0] dc.l 0 csect .Zero32Bytes[PR] dcbz r0,r3 ;implicit r0=0 blr - ------------------------------- (This file must be converted with BinHex 4.0) :$eTPFQmc-N*jG'9c,R-ZE`"B3dp'69"6)!%!!!!"L3!!!!#qA!(I!!+USJ#p!!! !QJ!!!!X!!!!!,R4PH(3!!!!!!!!!!!!!!!!!!!J!!!"N!!!!!!!!!!!!!!!!!!! !)#jNBA4K!!!!!!!!#!!!!!J!!!!3!!!!E!!!!(`!!!!!!!-!!!!!!%"m!"rX6S! !)!!!!!!!!!!8!!!!!!!!!!J!!!!)!!!!#4m!!!!!$!!!!!-I!!!!!"3!!!!((`" NBf*k,R-!!!!!!!$rrJ`"C`!!!!!!!!!!!!!!!!!!!3!!D`%!!!!!!!!!!!!!%3! !!!!!!!"86d-!!!!!!!!!!"3!!J!!D`%!!!!!!!!!!!!!%3m!!!!!!!!!!!!!!!! !"!!!!"3!!J!!D`%!!!!%!!!!!!!!%3-!!!!!!!!!!!!!!!!!%!!!!!J!!J!!!J% !!!!-!!!!!!!!%3S!!!!!!!!!!!!!!!!!(!!!!!!!!3!!!J%!!!!)!!!!!!!!%3! !!!!!!!!!!!!T@Q9bEc-b3RPdCA-!@Q9bEc-b3RPdCA-!,PTPFQmc-N*jG'9c!$e c!!!: - ------------------------------- Be careful! This is somewhat of a shotgun! It zeros not the 32 bytes starting at the pointer, but the 32 bytes *around* the pointer -- from p&~31 to p|31. Make sure you don't want anything that's already there next to your array! *IF* your array is aligned to a 32-byte boundary AND each row is a multiple of 32 bytes long, then all you need to use this is (in C -- in C++ you'll need 'extern "C"'): - ------------------------------- extern void Zero32Bytes(void *p); Byte plane[maxX][maxY]; for (i=0;iFrom al@crucible.powertools.com (Al Evans) Date: 19 Sep 94 13:43:14 GMT Organization: PowerTools, Austin, Texas In article craig@raru.adelaide.edu.au (Craig Kloeden) writes: >I have the following piece of code: >--- > >Byte plane[maxX][maxY]; > >for (i=0;i for (j=0;j plane[i][j] = 0; > >--- >Believe it or not, this is a bottleneck in my program. >I need to make this as fast as possible on the PPC. Here's an answer I haven't seen yet. If you've got the memory to spare, you can initialize one copy of your plane array, then use BlockMoveData(inittedMaster, plane, maxX * maxY); To rapidly initialize the "real" plane. If plane is particularly large, it will be hard to beat this technique for speed. And since BlockMove() is a ROM routine, you can be certain it's optimized for each Mac model. --Al Evans-- -- Al Evans | Graphic Elements: A new standard for ________________________|__ high-performance interactive Macintosh graphics. al@crucible.powertools.com | Available from mac.archive.umich.edu - -------------------------| /mac/development/libraries/graphicelements2.sit.hqx +++++++++++++++++++++++++++ >From Darrin Cardani Date: Mon, 19 Sep 1994 14:42:50 GMT Organization: AT&T Global Information Solutions, Atlanta >In article <35i2cb$2ug@Times.Stanford.EDU> The Weasel writes: >>In article , >>craig@raru.adelaide.edu.au (Craig Kloeden) wrote: >> >>> I have the following piece of code: >>> Byte plane[maxX][maxY]; >>> for (i=0;i>> for (j=0;j>> plane[i][j] = 0; >>> >>> Believe it or not, this is a bottleneck in my program. >>> I need to make this as fast as possible on the PPC. >>> Any advice would be appreciated. > >[ Good suggestions deleted ] > >Another things you might try is to allocate your memory in a single >continous block and running through it linearly. The array references >that you have above is sort of equivilant to: > > plane[i * kMaxY + j] = ... What about Ptr plane; plane = NewPtrClear (maxX*maxY); Or is NewPtrClear not very efficient? Darrin +++++++++++++++++++++++++++ >From weare@galaxy.ucr.edu (christopher weare) Date: 19 Sep 1994 10:47:33 -0700 Organization: University of California, Riverside You might want to try unrolling your loops abit: long numFloats, i; float *pointer,*temp; pointer = (float *)NewPointer(sizeof(float)*numFloats); temp = pointer; for(i=0;iFrom dsemchi@glenayre.com (Dale Semchishen [4597]) Date: Mon, 19 Sep 1994 19:24:55 GMT Organization: Glenayre Electronics Ltd. In article 2ug@Times.Stanford.EDU, pchang@Xenon.Stanford.EDU (The Weasel) writes: >>In article , >>craig@raru.adelaide.edu.au (Craig Kloeden) wrote: >> >>> I have the following piece of code: >>> Byte plane[maxX][maxY]; >>> for (i=0;i>> for (j=0;j>> plane[i][j] = 0; >>> >>> Believe it or not, this is a bottleneck in my program. >>> I need to make this as fast as possible on the PPC. >>> Any advice would be appreciated. You write a function that zeros a generic buffer as follows: - two parameters (buffer_pointer and number_of_bytes) - calculate how many longs are in buffer by shifting number_of_bytes right twice - clear the calculated number of longs and then the remaining bytes If you are compiling your source code for PPC and the Plain Jane 68000, then your function must make sure it does not write a long to an odd address. - - Dale Semchishen | dsemchi@glenayre.com Glenayre Electronics Ltd | (604) 293-1611 Vancouver, BC, CANADA | +++++++++++++++++++++++++++ >From zstern@adobe.com (Zalman Stern) Date: Tue, 20 Sep 1994 02:30:52 GMT Organization: Adobe Systems Incorporated Al Evans writes > If you've got the memory to spare, you can initialize one copy of > your plane array, then use > BlockMoveData(inittedMaster, plane, maxX * maxY); > To rapidly initialize the "real" plane. If plane is particularly large, > it will be hard to beat this technique for speed. And since BlockMove() > is a ROM routine, you can be certain it's optimized for each Mac model. This is a bad answer as it takes approximately twice the memory bandwidth. (And introduces another read latency into a conceptually write only operation.) To put it mildly, there is a reason you haven't this mentioned yet. In theory, the right solution is "memset(plane, 0, sizeof(plane));" but Apple blew it big time in implementing memset. A really good PowerPC implementation of this operation might try to use the data cache block zero instruction, though it cannot be used on uncached memory and you p[retty much have to know the cache block size to implement the code. (In other words, doing it portably requires dynamic code generation.) For this application, an unrolled loop that writes longs will probably work fine. Writing floating-point values on the MPC601 is dubious as you can only get in one floating-point store per 3 cycles. If you're going to uncached memory that is probably the right thing. Otherwise not. -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 Please do not change color while I am talking to you -- MC 900 Ft Jesus. +++++++++++++++++++++++++++ >From ari@world.std.com (Ari I Halberstadt) Date: Tue, 20 Sep 1994 02:30:40 GMT Organization: The World Public Access UNIX, Brookline, MA In article <2862743892@hoult.actrix.gen.nz>, Bruce Hoult wrote: >craig@raru.adelaide.edu.au (Craig Kloeden) writes: >> I have the following piece of code: >> >> --- >> >> Byte plane[maxX][maxY]; >> >> for (i=0;i> for (j=0;j> plane[i][j] = 0; >> >> --- >> >> Believe it or not, this is a bottleneck in my program. >> I need to make this as fast as possible on the PPC. >> >> Any advice would be appreciated. > >The quality of code generation doesn't matter much here -- it's all >in how efficiently you bash the memory subsystem. Actually, the quality of code generation is quite important. Compilers can do all sorts of tricks to speed up loops like the above. Things that are often done manually, such as loop unrolling, pointer arithmetic, common subexpression elimination, etc. can all be handled by the compiler. And the compiler may be better suited to make decisions on pipelining instructions for a RISC processor. What the original poster needs is to zero a block of memory of maxY by maxX bytes. The simple call memset(p,0,n) is almost always sufficient and it's portable. Assuming the compiler's optimizer or implementation of memset is pathetic, he can hand-code all sorts of optimizations, most of which have already been suggested. One other way to unroll a loop is to use a fancy (or obscure, take your pick) switch statement; most C texts have it as an exercise in "what does this do", but I don't know if it really is any faster than a more obvious loop unrolling. The use of a dedicated processor instruction (as suggested by Bruce) along with the other optimizations should result in a memory-zeroing routine that is as fast as can be made. Further optimizations would have to examine the need for the zeroed memory. Does the memory have to be zeroed, or is it just being filled up with data later on that don't need to be zeroed initially? Is the array being used to represent a data structure that would be better represented in some other form? Is the algorithm written in such a way that the memory zeroing code is being called more than may be necessary? Could the memory be zeroed in small chunks over time, rather than all at once? You could spawn a thread to do the zeroing, and run it in the background while the user is figuring out which buttons to click. By the time the user is ready to do something, the memory is zeroed, and the user will notice no delay. If the user is real speedy, you can always wait for the thread to complete before proceeding. (This is an approximation of parallelization, where a second processor and instruction set are simulated via a thread.) -- Ari Halberstadt ari@world.std.com One generation passes away, and another generation comes: but the earth abides for ever. -- Ecclesiastes, 1:4. +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Tue, 20 Sep 1994 16:10:12 +1200 (NZST) Organization: (none) 103t_english@west.cscwc.pima.edu writes: > > Byte plane[maxX][maxY]; > > > > for (i=0;i > for (j=0;j > plane[i][j] = 0; > > Finally, if you have access to the PPCAsm, you can directly zero out this > memory (if it all fits in the L1 cache) by simply using the assembly language > instruction that zeros the cache rather than loading it from memory and THEN > zeroing it. This would give you a HUGE speedup from what I understand. I don't > have my MPC601 user's manual handy, and this isn't something that I really know > how to do, so if some kind soul that DOES know how to do this would go into > greater detail for him (and me)? > > If you don't have the PPCAsm, maybe we could compose this routine on-line for > you, and I or somebody else could assemble it and either post it here in .hqx > format or just e-mail it to you... That way, you could just link it to your > program as a library routine... Already done :-) +++++++++++++++++++++++++++ >From craig@raru.adelaide.edu.au (Craig Kloeden) Date: Tue, 20 Sep 1994 22:55:44 +0930 Organization: University of Adelaide In article <2862743892@hoult.actrix.gen.nz>, Bruce@hoult.actrix.gen.nz (Bruce Hoult) wrote: - > Byte plane[maxX][maxY]; - > - > for (i=0;i for (j=0;j plane[i][j] = 0; - > Believe it or not, this is a bottleneck in my program. - > I need to make this as fast as possible on the PPC. - > - > Any advice would be appreciated. - - The quality of code generation doesn't matter much here -- it's all - in how efficiently you bash the memory subsystem. - - The problem with the straight C code is that the processor has to read - the old data from RAM, then you zero it, then you write it back. It's - - This is exactly what the PPC "dcbz" instruction (Data Cache Block Zero) - does -- it zeros 32 bytes of memory without first reading it from external - RAM. i.e. it totally ignores the previous contents. - - This is useful no matter what you want to write into the memory, but it - you happen to *want* zeros, then you don't need to do anything else. - - Here's a little PPC assembly routine that makes this instruction - available to you in C, and an XCOFF object file that you can use from - botht eh MPW and CodeWarrior compilers: Many many thanks. This is exactly what i needed. Check out ftp://raru.adelaide.edu.au/rotater/ if you want to see the final program. thanks again Craig -- Craig Kloeden E-mail: craig@raru.adelaide.edu.au Road Accident Research Unit Phone : +61 8 303 5885 The University of Adelaide Fax : +61 8 232 4995 Australia Disclaimer: Not this little black duck! +++++++++++++++++++++++++++ >From mcgrath@egret.SLAC.Stanford.EDU (Gary G. McGrath) Date: Tue, 20 Sep 1994 20:25:54 GMT Organization: University of California, Department of Physics |> If you've got the memory to spare, you can initialize one copy of |> your plane array, then use |> |> BlockMoveData(inittedMaster, plane, maxX * maxY); |> |> To rapidly initialize the "real" plane. If plane is particularly large, |> it will be hard to beat this technique for speed. And since BlockMove() |> is a ROM routine, you can be certain it's optimized for each Mac model. -- Maybe some apple folks can better tell us the validity of this last sentence. Can we be sure that BlockMoveData will be optimized for whatever platform it is on? I seem to remember a MacTech article on 040 assembly optimization of BlockMoveData where he got something like a factor 2+ on small to medium size routines because of less overhead. I would say that is consistent with my experience. Sincerely, Gary McGrath +---------------------+-------------------------------------------- | _ O _ O O | Gary McGrath \ | \|/ _/|\_ ||| | Stanford Linear Accelerator Center, MS-95 \ | | | | | PO Box 4349 \ | _/ \_ _/ \_ _/ \_ | Stanford, CA 94307 | 27887::gary \ |---------------------| | gmcgrath@uci.edu \ | Shiny, Happy People | (415) 926-3593 | mcgrath@slac.stanford.edu \ +---------------------+--------------------+------------------------------ * My opinions do not represent those of Stanford University, the University of California, or the D.O.E. +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 21 Sep 94 08:39:09 MST Organization: (none) In article <2862743892@hoult.actrix.gen.nz>, Bruce@hoult.actrix.gen.nz (Bruce Hoult) writes: > craig@raru.adelaide.edu.au (Craig Kloeden) writes: >> I have the following piece of code: >> >> --- >> >> Byte plane[maxX][maxY]; >> >> for (i=0;i> for (j=0;j> plane[i][j] = 0; >> >> --- >> >> Believe it or not, this is a bottleneck in my program. >> I need to make this as fast as possible on the PPC. >> >> Any advice would be appreciated. > > The quality of code generation doesn't matter much here -- it's all > in how efficiently you bash the memory subsystem. > > The problem with the straight C code is that the processor has to read > the old data from RAM, then you zero it, then you write it back. It's > twice as fast if you only have to write the data out. > > This is exactly what the PPC "dcbz" instruction (Data Cache Block Zero) > does -- it zeros 32 bytes of memory without first reading it from external > RAM. i.e. it totally ignores the previous contents. > > This is useful no matter what you want to write into the memory, but it > you happen to *want* zeros, then you don't need to do anything else. > > Here's a little PPC assembly routine that makes this instruction > available to you in C, and an XCOFF object file that you can use from > botht eh MPW and CodeWarrior compilers: > > --------------------------------- > ; void Zero32Bytes(void *p) > ; function that zeros a 32 byte range of memory using dcbz > > export Zero32Bytes[DS] > export .Zero32Bytes[PR] > > toc > tc Zero32Bytes[TC], Zero32Bytes[DS] > > csect Zero32Bytes[DS] > dc.l .Zero32Bytes[PR] > dc.l TOC[tc0] > dc.l 0 > > csect .Zero32Bytes[PR] > dcbz r0,r3 ;implicit r0=0 > blr > --------------------------------- > (This file must be converted with BinHex 4.0) > :$eTPFQmc-N*jG'9c,R-ZE`"B3dp'69"6)!%!!!!"L3!!!!#qA!(I!!+USJ#p!!! > !QJ!!!!X!!!!!,R4PH(3!!!!!!!!!!!!!!!!!!!J!!!"N!!!!!!!!!!!!!!!!!!! > !)#jNBA4K!!!!!!!!#!!!!!J!!!!3!!!!E!!!!(`!!!!!!!-!!!!!!%"m!"rX6S! > !)!!!!!!!!!!8!!!!!!!!!!J!!!!)!!!!#4m!!!!!$!!!!!-I!!!!!"3!!!!((`" > NBf*k,R-!!!!!!!$rrJ`"C`!!!!!!!!!!!!!!!!!!!3!!D`%!!!!!!!!!!!!!%3! > !!!!!!!"86d-!!!!!!!!!!"3!!J!!D`%!!!!!!!!!!!!!%3m!!!!!!!!!!!!!!!! > !"!!!!"3!!J!!D`%!!!!%!!!!!!!!%3-!!!!!!!!!!!!!!!!!%!!!!!J!!J!!!J% > !!!!-!!!!!!!!%3S!!!!!!!!!!!!!!!!!(!!!!!!!!3!!!J%!!!!)!!!!!!!!%3! > !!!!!!!!!!!!T@Q9bEc-b3RPdCA-!@Q9bEc-b3RPdCA-!,PTPFQmc-N*jG'9c!$e > c!!!: > --------------------------------- > > > Be careful! This is somewhat of a shotgun! It zeros not the 32 > bytes starting at the pointer, but the 32 bytes *around* the > pointer -- from p&~31 to p|31. Make sure you don't want anything > that's already there next to your array! > > *IF* your array is aligned to a 32-byte boundary AND each row is > a multiple of 32 bytes long, then all you need to use this is > (in C -- in C++ you'll need 'extern "C"'): > > --------------------------------- > extern void Zero32Bytes(void *p); > > Byte plane[maxX][maxY]; > > for (i=0;i for (j=0;j Zero32Bytes(&plane[i][j]); > --------------------------------- > > Hope this helps. > > Oh, yeah, if you try to use this on non-cachable memory (such as the > video memory) you'll get an alignment exception trap. > > -- Bruce I notice that you don't bother with the prologue/epilogue stuff. That's because it don't use no local memory, and doesn't call any subroutines, right? I tried to get Tim Olson's more robust zerobyte procedure to work with PPCAsm, but I didn't understand his syntax. It looked like it was designed for an assembler similar to, but not identical with, PPCAsm (the first time I tried to assemble it, it had hundreds of errors). BTW, I think that we should start compiling a list of useful assembly-language routines to suppliment the less-than-perfect compilers that the PowerMac has available. This could be tacked onto the end of Jon's Mac Programming FAQ, or could (eventually) be kept separate. The source code, the tool used to assemble it, and binhexed object code could all be supplied. Comments? Lawson +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 21 Sep 94 08:40:32 MST Organization: (none) In article , Darrin Cardani writes: >>In article <35i2cb$2ug@Times.Stanford.EDU> The Weasel writes: >>>In article , >>>craig@raru.adelaide.edu.au (Craig Kloeden) wrote: >>> >>>> I have the following piece of code: >>>> Byte plane[maxX][maxY]; >>>> for (i=0;i>>> for (j=0;j>>> plane[i][j] = 0; >>>> >>>> Believe it or not, this is a bottleneck in my program. >>>> I need to make this as fast as possible on the PPC. >>>> Any advice would be appreciated. >> >>[ Good suggestions deleted ] >> >>Another things you might try is to allocate your memory in a single >>continous block and running through it linearly. The array references >>that you have above is sort of equivilant to: >> >> plane[i * kMaxY + j] = ... > > What about > > Ptr plane; > > plane = NewPtrClear (maxX*maxY); > > Or is NewPtrClear not very efficient? > > Darrin > Only works the first time... Lawson +++++++++++++++++++++++++++ >From ari@world.std.com (Ari I Halberstadt) Date: Thu, 22 Sep 1994 02:43:54 GMT Organization: The World Public Access UNIX, Brookline, MA In article <1994Sep21.083909@west.cscwc.pima.edu>, <103t_english@west.cscwc.pima.edu> wrote: >BTW, I think that we should start compiling a list of useful assembly-language >routines to suppliment the less-than-perfect compilers that the PowerMac has >available. This could be tacked onto the end of Jon's Mac Programming FAQ, or >could (eventually) be kept separate. > >The source code, the tool used to assemble it, and binhexed object code could >all be supplied. This is what the newsgroup alt.sources.mac is for. It's still premature to consider splitting it into alt.sources.mac.ppc, since most of the traffic seems to be from people unclear on the purpose of alt.sources.mac. The archive sites should probably add a "dev/src/ppc" directory; you might suggest this to the info-mac folks and other major sites. The FAQ could contain a specific pointer to the various places to find these PPC goodies. -- Ari Halberstadt ari@world.std.com One generation passes away, and another generation comes: but the earth abides for ever. -- Ecclesiastes, 1:4. +++++++++++++++++++++++++++ >From craig@raru.adelaide.edu.au (Craig Kloeden) Date: Fri, 23 Sep 1994 09:21:46 +0930 Organization: University of Adelaide In article , ari@world.std.com (Ari I Halberstadt) wrote: > >> Byte plane[maxX][maxY]; > >> > >> for (i=0;i >> for (j=0;j >> plane[i][j] = 0; > >The quality of code generation doesn't matter much here -- it's all > >in how efficiently you bash the memory subsystem. > > Actually, the quality of code generation is quite important. Compilers > can do all sorts of tricks to speed up loops like the above. Things > that are often done manually, such as loop unrolling, pointer > arithmetic, common subexpression elimination, etc. can all be handled > by the compiler. And the compiler may be better suited to make decisions > on pipelining instructions for a RISC processor. > > What the original poster needs is to zero a block of memory of maxY by > maxX bytes. The simple call memset(p,0,n) is almost always sufficient > and it's portable. Assuming the compiler's optimizer or implementation > of memset is pathetic, he can hand-code all sorts of optimizations, > most of which have already been suggested. One other way to unroll a > loop is to use a fancy (or obscure, take your pick) switch statement; > most C texts have it as an exercise in "what does this do", but I > don't know if it really is any faster than a more obvious loop > unrolling. The use of a dedicated processor instruction (as suggested > by Bruce) along with the other optimizations should result in a > memory-zeroing routine that is as fast as can be made. > > Further optimizations would have to examine the need for the zeroed > memory. > > Does the memory have to be zeroed, or is it just being filled up with > data later on that don't need to be zeroed initially? It has to be filled to zero. > Is the array being used to represent a data structure that would be > better represented in some other form? Represents the screen. Well actually it is for keeping a record of the 'depth' of the last plotted pixel to that location. (for hidden point removal in displaying 3d images. > Is the algorithm written in such a way that the memory zeroing code is > being called more than may be necessary? Only once per frame :-) > Could the memory be zeroed in small chunks over time, rather than all > at once? You could spawn a thread to do the zeroing, and run it in the > background while the user is figuring out which buttons to click. nope. i need it straight away Here are some rough benchmarks that I ran. (using CW4) Time Method - -- ------ 1033 Clearing Individual Bytes 270 Clearing 1 long at a time 249 memset() 226 Clearing 2 longs at a time (unrolled loop) 213 Clearing 3 longs at a time (unrolled loop) 204 Clearing 4 longs at a time (unrolled loop) 55 bzero* * bzero is an XCOFF written by tim@apple.com (Tim Olson) posted recently to comp.sys.powerpc assumes cacheable memory (i.e. uses DCBZ) assumes 32-byte cache block/sector (works on 601, 603, 604) The rest of my code uses 386 units of time (best case) so all but the last significantly cuts into my frame rate. Guess which one i am using :-) regards and thanks Craig ps. the program i am working on with source is at: ftp://raru.adelaide.edu.au/rotater/ -- Craig Kloeden E-mail: craig@raru.adelaide.edu.au Road Accident Research Unit Phone : +61 8 303 5885 The University of Adelaide Fax : +61 8 232 4995 Australia Disclaimer: Not this little black duck! +++++++++++++++++++++++++++ >From al@crucible.powertools.com (Al Evans) Date: 23 Sep 94 14:41:45 GMT Organization: PowerTools, Austin, Texas In article <1994Sep20.023052.26490@adobe.com> zstern@adobe.com (Zalman Stern) writes: >> use >> BlockMoveData(inittedMaster, plane, maxX * maxY); >> To rapidly initialize the "real" plane. >This is a bad answer as it takes approximately twice the memory bandwidth. >(And introduces another read latency into a conceptually write only >operation.) To put it mildly, there is a reason you haven't this mentioned >yet. Oops. Obviously, you're right. I can only plead brain-fade, and the fact that I was thinking of a case where the memory in question had to be initialized to something more complex than all zeros. --Al Evans-- -- Al Evans | Graphic Elements: A new standard for ________________________|__ high-performance interactive Macintosh graphics. al@crucible.powertools.com | Available from mac.archive.umich.edu - -------------------------| /mac/development/libraries/graphicelements2.sit.hqx +++++++++++++++++++++++++++ >From usenet@lowry.eche.ualberta.ca (Brian Lowry) Date: Fri, 23 Sep 1994 10:38:08 -0800 Organization: Dept. of Chemical Eng., University of Alberta In article , craig@raru.adelaide.edu.au (Craig Kloeden) wrote: > Here are some rough benchmarks that I ran. (using CW4) > Time Method > ---- ------ > 1033 Clearing Individual Bytes > 270 Clearing 1 long at a time > 249 memset() > 226 Clearing 2 longs at a time (unrolled loop) > 213 Clearing 3 longs at a time (unrolled loop) > 204 Clearing 4 longs at a time (unrolled loop) > 55 bzero* > * bzero is an XCOFF written by tim@apple.com (Tim Olson) > posted recently to comp.sys.powerpc > assumes cacheable memory (i.e. uses DCBZ) > assumes 32-byte cache block/sector (works on 601, 603, 604) Did you try something like: //plane is a 2D array of bytes //N = (xMax * yMax) / 8; register double dblZero = +0.0; register double *doubleP; for (i=N, doubleP = &plane[maxX][maxY]; i>0; i--) { *(--doubleP) = dblZero;} I believe a double precision zero is a 64bit zero, and that this takes fewer clock cycles than writing longs (but I could be wrong). Just curious how it might compare... -- Brian Lowry +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 23 Sep 94 18:42:15 MST Organization: (none) In article , usenet@lowry.eche.ualberta.ca (Brian Lowry) writes: > In article , > craig@raru.adelaide.edu.au (Craig Kloeden) wrote: > >> Here are some rough benchmarks that I ran. (using CW4) [deleted] > Did you try something like: > //plane is a 2D array of bytes > //N = (xMax * yMax) / 8; > > register double dblZero = +0.0; > register double *doubleP; > > for (i=N, doubleP = &plane[maxX][maxY]; i>0; i--) > { *(--doubleP) = dblZero;} > > I believe a double precision zero is a 64bit zero, and that this takes > fewer clock cycles than writing longs (but I could be wrong). Just > curious how it might compare... > Come on Brian, even *I* know that 8-byte floating-point writes take 3 cycles while the 4-byte store takes 1 cycle (allowing for pipelining, etc -best case). The only time that the double store is better is on non-cached memory like VRAM, where the bus interface is your biggest problem. Your scheme is good for zeroing video. (Gorsh! I almost sound like a know what I'm talking about... I hope I didn't mangle what everyone else has told me too badly) Lawson +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Sun, 25 Sep 1994 12:57:26 +1200 (NZST) Organization: (none) ari@world.std.com (Ari I Halberstadt) writes: > >> Byte plane[maxX][maxY]; > >> > >> for (i=0;i >> for (j=0;j >> plane[i][j] = 0; > >> > >> --- > >> > >> Believe it or not, this is a bottleneck in my program. > >> I need to make this as fast as possible on the PPC. > >> > >> Any advice would be appreciated. > > > >The quality of code generation doesn't matter much here -- it's all > >in how efficiently you bash the memory subsystem. > > Actually, the quality of code generation is quite important. Compilers > can do all sorts of tricks to speed up loops like the above. Things > that are often done manually, such as loop unrolling, pointer > arithmetic, common subexpression elimination, etc. can all be handled > by the compiler. And the compiler may be better suited to make decisions > on pipelining instructions for a RISC processor. I stand by my original statement -- the quality of code generation in this loop matters not at all. A 60 MHz PPC 601 is capable of writing into its cache RAM at 240 MB/sec. A PowerMac 6100/60 has a memory subsystem capable of copying about 20 MB/sec (using BlockMoveData, for instance). This huge discrepency (a factor of more than 10:1) means that it virtually doesn't matter if your program uses ten instructions where one would have been enough -- assuming that you are wanting to zero a block of memory that is larger than your cache. Loop unrolling, pointer arithmetic, common subexpression elimination -- none of these matter in this case. I'm perfectly capable of using these when they help -- and you'll often see me advocate such things here. This is not one of those times. What *does* help, and help more than anything you suggested, is to tell the processor that it doesn't have to read the memory before it writes new contents to it. This results in an instant doubling of speed. You've got to understand what's going on, not just blindly apply the same trick in every case. -- Bruce --------------------------- >From mhlee@hsc.usc.edu (Marianne Lee) Subject: Inside Mac on CD-ROM Date: 16 Sep 1994 04:58:51 -0700 Organization: University of Southern California, Los Angeles, CA I want to start programming on the Mac soon and so I ordered the new Inside Macintosh on CD-ROM. It seems like a great deal because it has all the info of the current Inside Macs at a fraction of the price. One of my friends told me that with 7.5 out now, the old Inside Macs might get out of date soon. Is it worth it to get this CD-ROM then? +++++++++++++++++++++++++++ >From plsuh@econ.sas.upenn.edu (Paul L. Suh) Date: Fri, 16 Sep 1994 11:00:38 -0400 Organization: UPenn Grad Econ In article <35c19r$7vt@hsc.usc.edu>, mhlee@hsc.usc.edu (Marianne Lee) wrote: > I want to start programming on the Mac soon and so I ordered the new > Inside Macintosh on CD-ROM. It seems like a great deal because it has > all the info of the current Inside Macs at a fraction of the price. > One of my friends told me that with 7.5 out now, the old Inside Macs > might get out of date soon. Is it worth it to get this CD-ROM then? Actually, the thing to do is subscribe to the APDA monthly developer mailing. It includes quarterly issues of Develop magazine, plus monthly CD-ROMs. The CD-ROMs are of 3 types: System Software, Toolkit, and Reference Library. They are sent out one per month on a rotating basis. In particular, the Ref Lib CD has the entire new IM plus all of the current Tech Notes. Since this is updated every three months, you'll never have to worry about being out of date! --Paul +++++++++++++++++++++++++++ >From aaron_bratcher@fpm.uchicago.edu (Aaron Bratcher) Date: Fri, 16 Sep 1994 18:20:03 GMT Organization: University of Chicago In article , plsuh@econ.sas.upenn.edu (Paul L. Suh) wrote: > Actually, the thing to do is subscribe to the APDA monthly developer > mailing. It includes quarterly issues of Develop magazine, plus monthly > CD-ROMs. The CD-ROMs are of 3 types: System Software, Toolkit, and > Reference Library. They are sent out one per month on a rotating basis. > In particular, the Ref Lib CD has the entire new IM plus all of the > current Tech Notes. Since this is updated every three months, you'll > never have to worry about being out of date! > > > --Paul I thought it was stated on this channel that the monthly mailings were not going to include the new IM any more. -- Aaron L. Bratcher University of Chicago aaron_bratcher@fpm.uchicago.edu +++++++++++++++++++++++++++ >From alyx@apple.com (alyx) Date: Fri, 16 Sep 1994 21:03:06 GMT Organization: Apple Computer, Inc. In article , aaron_bratcher@fpm.uchicago.edu (Aaron Bratcher) wrote: > In article , > plsuh@econ.sas.upenn.edu (Paul L. Suh) wrote: > > > Actually, the thing to do is subscribe to the APDA monthly developer > > mailing. [...] > > I thought it was stated on this channel that the monthly mailings were not > going to include the new IM any more. > The _Developer CD Series_ will continue to include the complete IM. The _develop magazine Bookmark CD_ will contain a core set (Files, Memory, TB, More TB, Imaging w/QD) and rotate through the rest a couple at a time. +++++++++++++++++++++++++++ >From temple@itd.nrl.navy.mil (Dr. Jon Gerard Temple) Date: 17 Sep 1994 03:49:01 GMT Organization: Naval Research Laboratory In article alyx@apple.com (alyx) writes: > In article , > aaron_bratcher@fpm.uchicago.edu (Aaron Bratcher) wrote: > > > In article , > > plsuh@econ.sas.upenn.edu (Paul L. Suh) wrote: > > > > > Actually, the thing to do is subscribe to the APDA monthly developer > > > mailing. [...] > > > > I thought it was stated on this channel that the monthly mailings were not > > going to include the new IM any more. > > > > The _Developer CD Series_ will continue to include the complete IM. The > _develop magazine Bookmark CD_ will contain a core set (Files, Memory, TB, > More TB, Imaging w/QD) and rotate through the rest a couple at a time. Folks: You can always just backorder the Develop Bookmark CD issue #17 for $13, direct from d e v e l o p. (They even have a 1-800 toll free number :) It has the complete New Inside Mac collection on it. I did this and thus was not affected by Develop's decision to leave them off of newer BookMark CDs (my subscription began with issue #18, the first one that was affected). The last I checked, $13 was quite a bit less than the $99 that will be charged for the new CD. It's a great deal! +++++++++++++++++++++++++++ >From mhlee@hsc.usc.edu (Marianne Lee) Date: 16 Sep 1994 22:16:11 -0700 Organization: University of Southern California, Los Angeles, CA temple@itd.nrl.navy.mil (Dr. Jon Gerard Temple) writes: >Folks: You can always just backorder the Develop Bookmark CD issue #17 >for $13, direct from d e v e l o p. (They even have a 1-800 toll free >number :) It has the complete New Inside Mac collection on it. I did >this and thus was not affected by Develop's decision to leave them off >of newer BookMark CDs (my subscription began with issue #18, the first >one that was affected). The last I checked, $13 was quite a bit less >than the $99 that will be charged for the new CD. It's a great deal! So is there any new stuff or anything useful in the new CD? Why would Apple release such a thing if it were already available at $13? Is it purely marketing? BTW, when is the next develop issue coming out? I ordered a subscription last month and was wondering when the I'm going to get the first one. +++++++++++++++++++++++++++ >From neil_ticktin@xplain.com (Neil Ticktin) Date: Sun, 18 Sep 1994 18:54:02 GMT Organization: MacTech Magazine/Xplain Corporation In article <35c19r$7vt@hsc.usc.edu>, mhlee@hsc.usc.edu (Marianne Lee) wrote: >> I want to start programming on the Mac soon and so I ordered the new >> Inside Macintosh on CD-ROM. It seems like a great deal because it has >> all the info of the current Inside Macs at a fraction of the price. >> One of my friends told me that with 7.5 out now, the old Inside Macs >> might get out of date soon. Is it worth it to get this CD-ROM then? Marianne, You've gotten many positive comments on the develop Bookmark CD. Let me give you some other bits of information. You can order develop and related things through APDA. Here are some addresses and phone numbers you may find useful: To recieve an APDA catalog (development tools and documentation): APDA P.O. Box 319 Buffalo, NY 14207-0319 Phone: 1 800 282-2732 (U.S.A.) 1 800 637-0029 (Canada) 716 871-6555 (international) 716 871-6511 (FAX) AppleLink: APDA E-Mail: apda@applelink.apple.com CompuServe: 76666,2405 In addition, there's a CD from Addison-Wesley that is shortly going to ship (if it isn't already). This will contain all of the New IM volumes (as I understand it). I believe it is priced in the $80-130 price range. This is a DocViewer type CD and doesn't really have searching or hypertext capabilities. Finally, there's THINK Reference by Symantec. TR is the _old_ Inside Macintosh Volumes 1-6. If you are going to do "standard" Macintosh programming and not take advantage of anything beyond the basic System 7 technologies, this will cover what you need. The best part about TR is it extensive hyperlinks and searching -- far better than any other solution today. If you want more info on the Bookmark CD, call APDA. If you want more info on the AW CD, you can get that from APDA or our mail order dept. If you want TR, you can get it at your local dealer, or you can buy our MacTech CD which has TR bundled with it. Our customer service dept can help you with anything from our Mail Order Dept. Hope it helps, Neil Ticktin MacTech Magazine - --------------------------------------------------------------------- Neil Ticktin, MacTech Magazine (formerly MacTutor) PO Box 250055, Los Angeles, CA 90025 * 310-575-4343 * Fax: 310-575-0925 For more info, anonymous ftp to ftp.netcom.com and cd to /pub/xplain custservice@xplain.com * editorial@xplain.com * adsales@xplain.com marketing@xplain.com * accounting@xplain.com * pressreleases@xplain.com progchallenge@xplain.com * publisher@xplain.com * info@xplain.com +++++++++++++++++++++++++++ >From mhlee@hsc.usc.edu (Marianne Lee) Date: 18 Sep 1994 11:30:50 -0700 Organization: University of Southern California, Los Angeles, CA neil_ticktin@xplain.com (Neil Ticktin) writes: >In addition, there's a CD from Addison-Wesley that is shortly going to >ship (if it isn't already). This will contain all of the New IM volumes >(as I understand it). I believe it is priced in the $80-130 price range. >This is a DocViewer type CD and doesn't really have searching or hypertext >capabilities. No searching or hypertext on the NIM CD? How about the IMs on the develop CDs, do they have any type of indexing or easy way to look up things? Just a question, how many of you would prefer the NIM CD over having the develop version? Buying develops 17 through 19 and getting a subscription (which I will be doing anyway) is still cheaper than one NIM CD. +++++++++++++++++++++++++++ >From nick+@pitt.edu ( nick.c ) Date: Mon, 19 Sep 94 11:53:45 GMT Organization: The Pitt, Chemistry In Article <35i10q$s6n@hsc.usc.edu>, mhlee@hsc.usc.edu (Marianne Lee) wrote: >neil_ticktin@xplain.com (Neil Ticktin) writes: >>In addition, there's a CD from Addison-Wesley that is shortly going to >>ship (if it isn't already). This will contain all of the New IM volumes >>(as I understand it). I believe it is priced in the $80-130 price range. >>This is a DocViewer type CD and doesn't really have searching or hypertext >>capabilities. > >No searching or hypertext on the NIM CD? How about the IMs on the develop >CDs, do they have any type of indexing or easy way to look up things? > >Just a question, how many of you would prefer the NIM CD over having the >develop version? Buying develops 17 through 19 and getting a subscription >(which I will be doing anyway) is still cheaper than one NIM CD. The CD Neil mentions is starting at $99, available from SoftPro at 1-617-273-2919 (it was pre-orderable from macworld for $80, and will eventually sell for $150). It will have indexes and searching, but nothing as exntensive and the Think Reference hyperlinks. It's identical to those on the develop CD's. I think we'd all prefer to have as many of the NIM on one CD as possible. The question is: is it worth the extra $99. Personally, I'm going to pass on the Addison Wesley CD, I already have the _develop_ CD's, but I'm sure some folks will find $99 worth it to have all the info on one, rather than 5 CD's. Note another option is a subscription to the Developer mailing. For $250, you'll get 12 disks a year including ones with all the NIM on one disk, and System 7.5. That alone makes it tempting, the additional system enhancements, reference literature, and development tools make it a pretty good deal. -- nick _/ _/ _/ _/_/_/ _/ _/ Interet: nick@pitt.edu _/_/ _/ _/ _/ _/ _/_/_/ eWorld: nick _/ _/_/ _/ _/ _/ _/ CIS: 71232,766 _/ _/ _/ _/_/_/ _/ _/ +++++++++++++++++++++++++++ >From neil_ticktin@xplain.com (Neil Ticktin) Date: Tue, 20 Sep 1994 03:55:10 GMT Organization: MacTech Magazine/Xplain Corporation In article <35i10q$s6n@hsc.usc.edu>, mhlee@hsc.usc.edu (Marianne Lee) wrote: >> No searching or hypertext on the NIM CD? How about the IMs on the develop >> CDs, do they have any type of indexing or easy way to look up things? Marianne, I'm not 100% sure on this. If I understood some previous comments, there's searching within an individual document, but that's it. There's no real indexing or searching mechanism across documents. Hopefully, someone will correct me if I'm wrong -- but that's how I understand it. Good luck, Neil - --------------------------------------------------------------------- Neil Ticktin, MacTech Magazine (formerly MacTutor) PO Box 250055, Los Angeles, CA 90025 * 310-575-4343 * Fax: 310-575-0925 For more info, anonymous ftp to ftp.netcom.com and cd to /pub/xplain custservice@xplain.com * editorial@xplain.com * adsales@xplain.com marketing@xplain.com * accounting@xplain.com * pressreleases@xplain.com progchallenge@xplain.com * publisher@xplain.com * info@xplain.com +++++++++++++++++++++++++++ >From dkj@apple.com (Dave Johnson) Date: Tue, 20 Sep 1994 22:07:33 GMT Organization: Apple Computer In article , neil_ticktin@xplain.com (Neil Ticktin) wrote: > I'm not 100% sure on this. If I understood some previous comments, > there's searching within an individual document, but that's it. There's > no real indexing or searching mechanism across documents. Hopefully, > someone will correct me if I'm wrong -- but that's how I understand it. Since the books are all in DoicViewer format, there is good searching within and across all the books. Using the collections feature in Docviewer in combination with the query command can be very powerful. Any DocViewer users out there who don't know about collections and/or Query should check it (them) out. Of course, this is true for ANY set of DocViewer documents, not just the NIM CD. Dave Johnson +++++++++++++++++++++++++++ >From hrody@ingr.com (H. M. Rody) Date: Wed, 21 Sep 1994 07:51:08 -0500 Organization: Intergraph Corporation In article , neil_ticktin@xplain.com (Neil Ticktin) wrote: > In article <35i10q$s6n@hsc.usc.edu>, mhlee@hsc.usc.edu (Marianne Lee) wrote: > > >> No searching or hypertext on the NIM CD? How about the IMs on the develop > >> CDs, do they have any type of indexing or easy way to look up things? > > Marianne, > > I'm not 100% sure on this. If I understood some previous comments, > there's searching within an individual document, but that's it. There's > no real indexing or searching mechanism across documents. Hopefully, > someone will correct me if I'm wrong -- but that's how I understand it. I too believe that this is true. I am currently programming on NT and Mac and I have found that the the layout of the Microsoft CDs as far as search is far better that on the Developer CDs. The search engines on the Microsoft CDs can search the whole CD or parts. This is an area that Apple can definately improve on. What about integrating Apple Search into their own CD? Apple Search looks like an excellent product. -- - ---------------------------------------------------------------------- Marshall Rody | Intergraph Corporation UUCP: ...uunet!ingr!infonode!hrody | One Madison Industrial Park INTERNET: hrody@ingr.com | Mail Stop GD3002 AT&T: (205) 730-3748 | Huntsville, AL 35807-4201 +++++++++++++++++++++++++++ >From alyx@apple.com (alyx) Date: Wed, 21 Sep 1994 17:15:51 GMT Organization: Apple Computer, Inc. In article , the usually better-informed neil_ticktin@xplain.com (Neil Ticktin) wrote: > This is a DocViewer type CD and doesn't really have searching [...] > capabilities. oh, please. it's called "Query". RTFM!! +++++++++++++++++++++++++++ >From doumakes@netcom.com (Don Doumakes) Date: Mon, 26 Sep 1994 16:41:00 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Sorry for the repetition, folks. Problem with my offline reader. -- ______________________________________________________________________ Don Doumakes doumakes@netcom.com --------------------------- >From bb@lightside.com (Bob Bradley) Subject: Q: Using PPC apps without Shared Libraries? Date: Mon, 26 Sep 1994 15:00:39 -0800 Organization: SS Software Inc. I noticed that every application that uses a shared library (including my own) will not launch if that shared library cannot be found. Is there any way around this? I'm using the Thread Manager on a PowerPC in my application and have the appropriate checks in my application to tell whether or not the Thread Manager is available and if not, it uses non-Thread Manager code to still function (it is limited if not using the Thread Manager). The problem is my code never gets a chance to run since the system says it couldn't find the ThreadsLib (when the extension isn't loaded). The System doesn't appear to be very thorough in it's search for the library either since another application that requires QuickTime wouldn't run even when QuickTime was installed. I tried copying the QuickTimeLib and it still didn't work until I re-installed QuickTime. +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Wed, 28 Sep 1994 07:49:01 -0700 Organization: Internet for the Olympic Peninsula In article , bb@lightside.com (Bob Bradley) wrote: > I noticed that every application that uses a shared library (including my > own) will not launch if that shared library cannot be found. Is there any > way around this? > > I'm using the Thread Manager on a PowerPC in my application and have the > appropriate checks in my application to tell whether or not the Thread > Manager is available and if not, it uses non-Thread Manager code to still > function (it is limited if not using the Thread Manager). The problem is > my code never gets a chance to run since the system says it couldn't find > the ThreadsLib (when the extension isn't loaded). > > The System doesn't appear to be very thorough in it's search for the > library either since another application that requires QuickTime wouldn't > run even when QuickTime was installed. I tried copying the QuickTimeLib > and it still didn't work until I re-installed QuickTime. There are two ways to link code which uses routines from a PPC shared library. One is as you describe (a "hard" link), and the Code Fragment Manager refuses to proceed if a library so linked is not present at the time the fragment is prepared. The other is the "soft" link...in this case the absence of a needed library causes references into that library to be resolved by CFM into a magic value which will cause an error when the reference is later used. It is then up to the using code to protect itself before using such a reference. See Inside Mac: Power PC System Software. There is a case you need to protect against, which means that with most shared libraries, merely checking Gestalt is not safe enough. Suppose the needed library is present at startup time. The Gestalt selector gets set up on that basis. The user drags the Shared Library out of the Extensions folder and then starts your app. CFM sees the absence of the library, and does its magic value thing. In many cases though, your app's check of Gestalt suggests that the library is present because the feature it implements is available. HOW you do a soft link depends on which development environment you use. MPW and CodeWarrior can do it. --John -- John Baxter Port Ludlow, WA, USA [West shore, Puget Sound] "Occasionally...astronomers add a second to either June 31 or December 31..." IM: OS Utilities, p 4-12 jwbaxter@pt.olympus.net +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Wed, 28 Sep 1994 15:40:30 +0100 Organization: Royal Institute of Something or other In article , bb@lightside.com (Bob Bradley) wrote: >I noticed that every application that uses a shared library (including my >own) will not launch if that shared library cannot be found. Is there any >way around this? Yes: 1) Indlude the shared library with your application or 2) Import the library "weakly" - in CodeWarrior, it's a flag in the project window popup menu for the file. The search path for a shared library is: * In the Applications' folder * In the Extensions folder That's it. -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden "Don't use the Layer Manager" +++++++++++++++++++++++++++ >From willie-abrams@uokhsc.edu (Willie Abrams) Date: Wed, 28 Sep 1994 14:58:27 -0500 Organization: OUHSC Center for Telemedicine In article , bb@lightside.com (Bob Bradley) wrote: > I noticed that every application that uses a shared library (including my > own) will not launch if that shared library cannot be found. Is there any > way around this? > > I'm using the Thread Manager on a PowerPC in my application and have the > appropriate checks in my application to tell whether or not the Thread > Manager is available and if not, it uses non-Thread Manager code to still > function (it is limited if not using the Thread Manager). The problem is > my code never gets a chance to run since the system says it couldn't find > the ThreadsLib (when the extension isn't loaded). > > The System doesn't appear to be very thorough in it's search for the > library either since another application that requires QuickTime wouldn't > run even when QuickTime was installed. I tried copying the QuickTimeLib > and it still didn't work until I re-installed QuickTime. Import "weak" (if you are using CodeWarrior, that option is in the little triangle thingy next to the library) the shared libraries that you are using, and then check for their presence before calling the routines. -- Willie Abrams willie-abrams@uokhsc.edu Less is more. God is in the details. - Mies van der Rohe +++++++++++++++++++++++++++ >From isis@netcom.com (Mike Cohen) Date: Thu, 29 Sep 1994 18:01:12 GMT Organization: ISIS International bb@lightside.com (Bob Bradley) writes: >I noticed that every application that uses a shared library (including my >own) will not launch if that shared library cannot be found. Is there any >way around this? >I'm using the Thread Manager on a PowerPC in my application and have the >appropriate checks in my application to tell whether or not the Thread >Manager is available and if not, it uses non-Thread Manager code to still >function (it is limited if not using the Thread Manager). The problem is >my code never gets a chance to run since the system says it couldn't find >the ThreadsLib (when the extension isn't loaded). If you're using MetroWerks, click on the popup next to the library and select "soft import". If you do this, make sure you check that the functions in it actually exist before calling them (you could probably test only one function at startup). To do it, write something like: if (someFunction != NULL) someFunction(); -- Mike Cohen - isis@netcom.com NewtonMail, eWorld: MikeC / ALink: D6734 / AOL: MikeC20 Home Page: file://ftp.netcom.com/pub/isis/home.html +++++++++++++++++++++++++++ >From Jens Alfke Date: Fri, 30 Sep 1994 18:25:32 GMT Organization: Apple Computer Jon W{tte, h+@nada.kth.se writes: > The search path for a shared library is: > > * In the Applications' folder > * In the Extensions folder You forgot: * In any folder inside the Extensions folder (including aliases to folders.) --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 30 Sep 94 13:08:43 MST Organization: (none) In article <1994Sep30.182532.29882@gallant.apple.com>, Jens Alfke writes: > Jon W{tte, h+@nada.kth.se writes: >> The search path for a shared library is: >> >> * In the Applications' folder >> * In the Extensions folder > > You forgot: > * In any folder inside the Extensions folder (including aliases to folders.) > > --Jens Alfke jens_alfke@powertalk.apple.com > "A man, a plan, a yam, a can of Spam ... Bananama!" OW! There goes the trick of putting inactive extesions in the "Inactive Extensions Folder"... Lawson +++++++++++++++++++++++++++ >From greg@math.harvard.edu (Gregory D. Landweber) Date: 30 Sep 94 20:21:23 EDT Organization: Dept. of Math, Harvard Univ. In article bb@lightside.com (Bob Bradley) writes: >I noticed that every application that uses a shared library (including my >own) will not launch if that shared library cannot be found. Is there any >way around this? You need to mark the library as "weak", in which case the system will not require that it be linked in when the application is launched. You can designate the library as "weak" in the CodeWarrior project window (using the tiny pop up to the right of the library name). Of course, if you do so, you'll have to check to make sure that the routines are present before you call them. Checking the appropriate Gestalt selectors should be good enough, but you can double check that a pointer to the routine isn't null -- Greg greg@math.harvard.edu +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Fri, 30 Sep 1994 21:04:59 -0700 Organization: Internet for the Olympic Peninsula In article <1994Sep30.130843@west.cscwc.pima.edu>, 103t_english@west.cscwc.pima.edu wrote: > In article <1994Sep30.182532.29882@gallant.apple.com>, Jens Alfke writes: > > Jon W{tte, h+@nada.kth.se writes: > >> The search path for a shared library is: > >> > >> * In the Applications' folder > >> * In the Extensions folder > > > > You forgot: > > * In any folder inside the Extensions folder (including aliases to folders.) > > > > --Jens Alfke jens_alfke@powertalk.apple.com > > "A man, a plan, a yam, a can of Spam ... Bananama!" > > OW! There goes the trick of putting inactive extesions in the "Inactive > Extensions Folder"... No...just put that folder "beside" the Extensions folder, not inside it. [Or use Extension Manager, which does that using " disabled" as a suffix.] I usually drag things between the real and the corresponding (disabled) folders, rather than bothering with Extension Manager. For things I toggle a lot, I write a (Frontier, but AppleScript will do) script. --John -- John Baxter Port Ludlow, WA, USA [West shore, Puget Sound] Sorry...clever signatures require cleverness, not found here. jwbaxter@pt.olympus.net --------------------------- >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Subject: Reading STR# resource - Pascal code Date: Thu, 29 Sep 1994 12:25:30 +0800 Organization: NCRPDA, Curtin University >epenneba@ux1.cso.uiuc.edu (Erik Pennebaker ) wrote: > > ) This is probably a relatively lightweight quesiton, but I couldn't get > ) a straight answer (or couldn't find a straight answer) from Inside Mac. > ) I'm writing a program that needs to read strings from STR# resource, > ) and needs to know how many strings are in this. I've seen this done, > ) but for some reason mine seemed to read a null string. If anyoone > ) could write an quick example of this it would be great....:) Here is some Pascal code to create, modify, read, and write STR# resources and handles. Peter. unit MyStrH; interface {$IFC undefined THINK_Pascal} uses Types; {$ENDC} type lineIndex = integer; function NewStrH: handle; procedure ReinitStrH (h: handle); function CountStrs (id: integer): lineIndex; function CountStrsH (h: handle): lineIndex; function GetIndStr (id: integer; index: lineIndex): str255; function GetIndStrH (h: handle; index: lineIndex): str255; procedure SetIndStr (id, index: lineIndex; s: str255); procedure SetIndStrH (h: handle; index: lineIndex; s: str255); procedure DelIndStr (id: integer; index: lineIndex); procedure DelIndStrH (h: handle; index: lineIndex); procedure InsIndString (id: integer; index: lineIndex; s: str255); procedure InsIndStrH (h: handle; index: integer; s: str255); implementation {$IFC undefined THINK_Pascal} uses Memory, Resources, ToolUtils; {$ENDC} type indexPtr = ^lineIndex; indexHandle = ^indexPtr; function NewStrH: handle; begin NewStrH := NewHandleClear(SizeOf(lineIndex)); end; procedure ReinitStrH (h: handle); begin SetHandleSize(h, SizeOf(lineIndex)); indexHandle(h)^^ := 0; end; function CountStrsH (h: handle): integer; begin CountStrsH := indexHandle(h)^^; end; function CountStrs (id: integer): lineIndex; var h: handle; begin h := GetResource('STR#', id); CountStrs := indexHandle(h)^^; end; function GetIndStr (id: integer; index: lineIndex): str255; var s: str255; begin GetIndString(s, id, index); GetIndStr := s; end; function GetIndStrH (h: handle; index: lineIndex): str255; var count, i: lineIndex; s: str255; ps: longInt; begin count := indexHandle(h)^^; if (1 <= index) and (index <= count) then begin ps := SizeOf(lineIndex); for i := 1 to index - 1 do ps := ps + BAND(ptr(ord(h^) + ps)^, $FF) + 1; BlockMove(ptr(ord(h^) + ps), @s, BAND(ptr(ord(h^) + ps)^, $FF) + 1); end else s := ''; GetIndStrH := s; end; procedure SetIndStrH (h: handle; index: lineIndex; s: str255); var count, i: lineIndex; sz: longInt; p: longInt; err: longInt; ps: longInt; begin count := indexHandle(h)^^; sz := GetHandleSize(h); if count < index then begin SetHandleSize(h, sz + index - count); for p := ord(h^) + sz to ord(h^) + sz + index - count - 1 do ptr(p)^ := 0; indexHandle(h)^^ := index; count := index; end; ps := SizeOf(lineIndex); for i := 1 to index - 1 do ps := ps + BAND(ptr(ord(h^) + ps)^, $FF) + 1; err := Munger(h, ps, nil, BAND(ptr(ord(h^) + ps)^, $FF) + 1, @s, length(s) + 1); end; procedure SetIndStr (id, index: lineIndex; s: str255); var h: handle; begin h := GetResource('STR#', id); HNoPurge(h); SetIndStrH(h, index, s); HPurge(h); ChangedResource(h); WriteResource(h); end; procedure DelIndStrH (h: handle; index: integer); var count, i: lineIndex; sz: longInt; err: longInt; ps: longInt; begin count := indexHandle(h)^^; sz := GetHandleSize(h); if count >= index then begin ps := SizeOf(lineIndex); for i := 1 to index - 1 do ps := ps + BAND(ptr(ord(h^) + ps)^, $FF) + 1; err := Munger(h, ps, nil, BAND(ptr(ord(h^) + ps)^, $FF) + 1, @err, 0); { @err is a safe, non nil addr } indexHandle(h)^^ := count - 1; end; end; procedure DelIndStr (id: integer; index: lineIndex); var h: handle; begin h := GetResource('STR#', id); HNoPurge(h); DelIndStrH(h, index); HPurge(h); ChangedResource(h); WriteResource(h); end; procedure InsIndStrH (h: handle; index: integer; s: str255); var count, i: lineIndex; err: longInt; ps: longInt; t: string[2]; begin count := indexHandle(h)^^; if count >= index then begin ps := SizeOf(lineIndex); for i := 1 to index - 1 do ps := ps + BAND(ptr(ord(h^) + ps)^, $FF) + 1; t := ''; err := Munger(h, ps, nil, 0, @t, length(t) + 1); indexHandle(h)^^ := count + 1; end; SetIndStrH(h, index, s) end; procedure InsIndString (id: integer; index: lineIndex; s: str255); var h: handle; begin h := GetResource('STR#', id); HNoPurge(h); InsIndStrH(h, index, s); HPurge(h); ChangedResource(h); WriteResource(h); end; end. -- Peter N Lewis - Macintosh TCP fingerpainter FTP my programs from redback.cs.uwa.edu.au:Others/PeterLewis/ or amug.org:pub/peterlewis/ or nic.switch.ch:software/mac/peterlewis/ --------------------------- End of C.S.M.P. Digest **********************