From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-050 Date: Wed, 10 Aug 1994 13:16:49 +0200 (MET DST) C.S.M.P. Digest Wed, 10 Aug 94 Volume 3 : Issue 50 Today's Topics: Detecting Apple Events on launch? Dialogs and fonts... Filtering Edit Text items MoreFiles 1.2 available on ftp.apple.com Styled Text in Dialogs The shock of the new (mac vs unix) What does "reentrant" mean? 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 chriss@microware.com (Chris Severtson) Subject: Detecting Apple Events on launch? Date: Wed, 20 Jul 1994 13:44:09 GMT Organization: Microware Systems Corp., Des Moines, Iowa I have just added support for the core apple events to a hobby application of mine and they work great! I am concerned, however, about detecting apple events upon application launch. When my application is launched, it creates an untitled document window, and if the application was launched because someone double-clicked one of its documents in the finder, then I do not want the application to create this untitled document. I tried using EventAvail(highLEvelEventMask, evtPtr) before entering my main event loop to detect this, but it always tells me there are no pending high-level events. Is there a better way to detect if you were launched because a user double-clicked one of your documents in the Finder? (I want to detect this before I enter my main event loop). All help is greatly appreciated, Chris chriss@microware.com +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Wed, 20 Jul 1994 09:35:10 -0700 Organization: Internet for the Olympic Peninsula In article <1994Jul20.134409.27760@microware.com>, chriss@microware.com (Chris Severtson) wrote: > I have just added support for the core apple events to a hobby > application of mine and they work great! I am concerned, however, > about detecting apple events upon application launch. When my > application is launched, it creates an untitled document window, and > if the application was launched because someone double-clicked one of > its documents in the finder, then I do not want the application to > create this untitled document. > > I tried using EventAvail(highLEvelEventMask, evtPtr) before entering > my main event loop to detect this, but it always tells me there are no > pending high-level events. > > Is there a better way to detect if you were launched because a user > double-clicked one of your documents in the Finder? (I want to detect > this before I enter my main event loop). This is pretty well spelled out in Inside Mac: Interapplication Communication. Briefly: if Apple events are not implemented (ie, you still support archiac pre-7 Systems), do the old thing with the application parameters. If Apple events ARE implemented, when your program is launched just do your no-matter-what initialization. Shortly, you will receive one of: 'aevt'/'oapp' meaning: your app was double-clicked on (or you should act that way) 'aevt'/'odoc' meaning: the user wants you to open these documents 'aevt'/'pdoc' meaning: the user wants you to print these documents, bugging him/her as little as possible You'll only get one of these as the aftermath of being launched. That's how you decide whether to open an untitled document. [You can receive 'odoc' and 'pdoc' later, too.] If Finder wants you to quit after printing as the result of a 'pdoc', it will send an 'aevt'/'quit' event. It does that if your app was not running when the user asked Finder to print the document. --John -- John Baxter Port Ludlow, WA, USA [West shore, Puget Sound] No hablo Intel. jwbaxter@pt.olympus.net +++++++++++++++++++++++++++ >From jcav@kimbark.uchicago.edu (JohnC) Date: Thu, 21 Jul 1994 05:17:15 GMT Organization: The Royal Society for Putting Things on Top of Other Things In article <1994Jul20.134409.27760@microware.com> chriss@microware.com (Chris Severtson) writes: >I have just added support for the core apple events to a hobby >application of mine and they work great! Cool. Did you do it by installing event handlers via the Apple Event Manager? >I am concerned, however, about detecting apple events upon application >launch. > >Is there a better way to detect if you were launched because a user >double-clicked one of your documents in the Finder? (I want to detect >this before I enter my main event loop). WHY do you want to do it before the main event loop? Why not do it as Apple intended: -Initialize (installing your Apple Event handlers) -Start your even loop -pass each high-level event to AEProcessAppleEvent If the Finder launches you, you are guaranteed to get EITHER an OpenDocuments event OR an OpenApplication event, NOT both. Your OpenApplication handler puts up an untitled window, whereas your OpenDocuments handler opens the specified document or documents but does not put up an untitled window. Your QuitApplication handler sets a flag that will cause your event loop to terminate. Your PrintDocuments handler will print the specified document or documents. It really is just about that simple. There is some clear sample code in either IM-6 or IM-Interapplication Communication. -- ______ John Cavallino - B0 f++ w c+ g++ k+ s++ e h- pv \ / queer person \ / EMail: jcav@midway.uchicago.edu \/ It should absurdly obvious that I speak ONLY for myself. +++++++++++++++++++++++++++ >From mathews@ns9000.furman.edu (Owen Mathews) Date: 21 Jul 1994 15:02:56 GMT Organization: furman university computing center Chris Severtson (chriss@microware.com) wrote: : I have just added support for the core apple events to a hobby : application of mine and they work great! I am concerned, however, : about detecting apple events upon application launch. When my : application is launched, it creates an untitled document window, and : if the application was launched because someone double-clicked one of : its documents in the finder, then I do not want the application to : create this untitled document. : I tried using EventAvail(highLEvelEventMask, evtPtr) before entering : my main event loop to detect this, but it always tells me there are no : pending high-level events. : Is there a better way to detect if you were launched because a user : double-clicked one of your documents in the Finder? (I want to detect : this before I enter my main event loop). : All help is greatly appreciated, : Chris : chriss@microware.com Actually, I think it's even simpler than that... The system should *automatically* put an apple event in the event queue when your application is opened (see previous post); all you should need to do is go straight to your event loop. The first event you get with WaitNextEvent() should be the AppleEvent you need to determine whether or not the user has double-clicked on a file belonging to you application. EventAvail() before your loop should also work. IOW, what you posted above *should* work (as far as I know :) ). The only reason I can think of why your code does not work is the flags in the SIZE resource. Unless you make sure to set the IsHighLevelEventAware flag, the system won't send you any AppleEvents when it launches your app. Set the flag either by making your own SIZE resource with ResEdit, or by selecting the appropriate option when building your application. Hope this sheds a little light... :) -- Owen Mathews mathews@furman.edu <><><><><><><><><><><><><><><><><><><><> Furman University, Computer Science Dept +++++++++++++++++++++++++++ >From isis@netcom.com (Mike Cohen) Date: Thu, 21 Jul 1994 18:40:04 GMT Organization: ISIS International chriss@microware.com (Chris Severtson) writes: When you start up, *don't* create an untitled document; just do the rest of your initialization and enter your main event loop.Next, you'll receive either an 'odoc' event if a document was double-clicked or an 'oapp' if only the application was double-clicked. You should create a new document when you receive the 'oapp' event. Currently, there will only be one 'oapp' when the application is started with no documents, but in the future you may receive them when an already running application is double-clicked in the Finder. >I have just added support for the core apple events to a hobby >application of mine and they work great! I am concerned, however, >about detecting apple events upon application launch. When my >application is launched, it creates an untitled document window, and >if the application was launched because someone double-clicked one of >its documents in the finder, then I do not want the application to >create this untitled document. >I tried using EventAvail(highLEvelEventMask, evtPtr) before entering >my main event loop to detect this, but it always tells me there are no >pending high-level events. >Is there a better way to detect if you were launched because a user >double-clicked one of your documents in the Finder? (I want to detect >this before I enter my main event loop). >All help is greatly appreciated, >Chris >chriss@microware.com -- Mike Cohen - isis@netcom.com NewtonMail, eWorld: MikeC / ALink: D6734 / AOL: MikeC20 Home Page: file://ftp.netcom.com/pub/isis/home.html +++++++++++++++++++++++++++ >From gurgle@dnai.com (Pete Gontier) Date: 26 Jul 1994 17:30:02 GMT Organization: Integer Poet Software In article <1994Jul21.051715.18936@midway.uchicago.edu> jcav@kimbark.uchicago.edu (JohnC) writes: > >Is there a better way to detect if you were launched because a user > >double-clicked one of your documents in the Finder? (I want to detect > >this before I enter my main event loop). > > WHY do you want to do it before the main event loop? Why not do it as Apple > intended: -Initialize (installing your Apple Event handlers) > -Start your even loop > -pass each high-level event to AEProcessAppleEvent Because this AE handling model assumes a traditional document-oriented app. If your app is not such a thing, there may be a decent reason for you to wait and see whether you are going to get an open-application or open-documents or print-documents event. I just did it in a Eudora add-on app I'm writing. I wrote another event loop which calls WaitNextEvent with a mask which exlcudes everything but AppleEvents. -- Pete Gontier // Integer Poet Software // gurgle@dnai.com "Clear-cutting removes all trees... to create new habitats for wildlife. P&G uses this economically and environmentally sound method because it most closely mimics nature's own processes. Clear-cutting also opens the floor to sunshine, thus stimulating growth and providing food for animals." -- Procter & Gamble's "Decision Earth" free school curriculum --------------------------- >From Tony Andreoli Subject: Dialogs and fonts... Date: Sat, 23 Jul 1994 14:00:17 GMT Organization: Naval Air Warfare Center - Weapons Division I have a dialog that contains a series of editText and staticText fields, the problem is, I want them to be in Geneva 9! I understand that SetDAFont will allow me to adjust the font, but how to I set the point size (as TextFont and TextSize don't work)? Think Reference say's there's no "direct" method, but what about an indirect one? Thanks... Tony Andreoli +++++++++++++++++++++++++++ >From jarezina@magnus.acs.ohio-state.edu (Jasna M. Arezina-Wilson) Date: Tue, 26 Jul 1994 17:49:55 -0400 Organization: Ohio State University In article , Tony Andreoli wrote: > I have a dialog that contains a series of editText and staticText fields, > the problem is, I want them to be in Geneva 9! I understand that > SetDAFont will allow me to adjust the font, but how to I set the point > size (as TextFont and TextSize don't work)? Think Reference say's > there's no "direct" method, but what about an indirect one? Try this for a function (in C): void SetDialogFontAndSize(DialogPtr theDialog, short fontNum, short fontSize) { FontInfo f; SetPort(theDialog); // set up the port info TextFont(fontNum); TextSize(fontSize); // now deal with the static & edit text issues GetFontInfo(&f); (*((DialogPeek)theDialog)->textH)->txFont = applFont; (*((DialogPeek)theDialog)->textH)->txSize = 9; (*((DialogPeek)theDialog)->textH)->lineHeight = f.ascent + f.descent + f.leading; (*((DialogPeek)theDialog)->textH)->fontAscent = f.ascent; } However, this will not do it for for buttons, but it will do it for Static and Edit text fields. Anyone know how to do it for buttons without changing the system font (since this has the side effect of wrecking the menu font). - ---------------------------------------- "...when friends rejoice both far and near How can I keep from singing?" - Enya +++++++++++++++++++++++++++ >From larson@oahu.cs.ucla.edu (Christopher Larson) Date: Wed, 27 Jul 94 14:50:58 GMT Organization: UCLA, Computer Science Department In article jarezina@magnus.acs.ohio-state.edu (Jasna M. Arezina-Wilson) writes: >In article , Tony Andreoli > wrote: > >> I have a dialog that contains a series of editText and staticText fields, >> the problem is, I want them to be in Geneva 9! I understand that >> SetDAFont will allow me to adjust the font, but how to I set the point >> size (as TextFont and TextSize don't work)? Think Reference say's >> there's no "direct" method, but what about an indirect one? [Code Deleted...] >However, this will not do it for for buttons, but it will do it for Static >and Edit text fields. Anyone know how to do it for buttons without changing >the system font (since this has the side effect of wrecking the menu font). To force controls to use their window's font, simply add the constant useWFont (or something like that; refer to IM: Mac TB Essentials, "Control Manager" chapter) to the variation code of the control. No need to change the system font. --Chris _______________________________________________________________________________ Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious Death to the Trojans! Go Bruins! (Insert disclaimer here) Internet: larson@kingston.cs.ucla.edu +++++++++++++++++++++++++++ >From jarezina@magnus.acs.ohio-state.edu (Jasna M. Arezina-Wilson) Date: Wed, 27 Jul 1994 13:12:26 -0400 Organization: Ohio State University In article <1994Jul27.145058.17888@cs.ucla.edu>, larson@oahu.cs.ucla.edu (Christopher Larson) wrote: > To force controls to use their window's font, simply add the constant useWFont > (or something like that; refer to IM: Mac TB Essentials, "Control Manager" > chapter) to the variation code of the control. No need to change the system > font. Okay, how does one do that without building the DITL on the fly? I read that you can patch the GetNewControl (or NewControl, depending on what your computer is doing) and modify that as it goes by, but I haven't been able to come up with a working patching function (one that just falls-through, that is). (BTW, IM:MTBE isn't avail to me) - ---------------------------------------- "...when friends rejoice both far and near How can I keep from singing?" - Enya +++++++++++++++++++++++++++ >From Jens Alfke Date: Wed, 27 Jul 1994 20:16:05 GMT Organization: Apple Computer Jasna M. Arezina-Wilson, jarezina@magnus.acs.ohio-state.edu writes: > Okay, how does one do that without building the DITL on the fly? You can use control items -- with associated CNTL resources -- instead of buttons. Keeping the resources in sync is a bit of a pain, but the CNTL does let you specify the variation code. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From jamesw7955@aol.com (JamesW7955) Date: 27 Jul 1994 19:49:01 -0400 Organization: America Online, Inc. (1-800-827-6364) In article , Tony Andreoli writes: >> I have a dialog that contains a series of editText and staticText >>fields, >>the problem is, I want them to be in Geneva 9! I understand that >>SetDAFont will allow me to adjust the font, but how to I set the >>point >>size (as TextFont and TextSize don't work)? Think Reference say's >>there's no "direct" method, but what about an indirect one? Have you looked at the 'ictb' resource? It allows you to specifiy fonts for items in a DITL (as well as colors and other goodies). It is documented in IM: Mac toolbox essentials. Beware: it is a tough resource to build and its structure may leave you scratching your head. - James Wilson JamesW7955@aol.com --------------------------- >From spohn@mayo.edu (Al Spohn) Subject: Filtering Edit Text items Date: 26 Jul 1994 04:01:57 GMT Organization: Mayo Clinic I've working on a dialog box that takes a time, e.g., 23:12:14.35 as user input. The input is organized into four edit text boxes - hours, minutes, seconds, and hundredths. Before I pose my question, I should let you know that I ordered the "Text" volume of Inside Macintosh - it just hasn't arrived yet. So, if the answer to my question is in-depth and covered in that book, feel free to blow this off. However, on the off chance that there's a relatively quick, easy answer, I'll go ahead and pose the question: What's the best way to restrict the input of each of the text edit boxes to two digits? I've played with a few different ideas, but I continue to be plagued by the funky scrolling that ensues when the user enters more than two digits. I don't want to be too much of a nazi in the way I restrict the input, i.e., I'd prefer to be within sight of Apple's user interface guidelines. If I could count on the user tabing to each field and just replacing highlighted text, things would be easy. It's dealing with the insertion point and what happens to the text as a result that has me stumped. Any suggestions would be appreciated! ********************************************************************** * Al Spohn spohn@mayo.edu 507-284-1666 Mayo Clinic Hilton 517A * ********************************************************************** +++++++++++++++++++++++++++ >From dougw@astro.as.arizona.edu (Doug Williams) Date: 26 Jul 1994 14:05:45 GMT Organization: University of Arizona, Tucson, AZ In article <3121rl$ihg@fermat.mayo.edu> spohn@mayo.edu (Al Spohn) writes: >What's the best way to restrict the input of each of the text edit >boxes to two digits? I've played with a few different ideas, but I >Any suggestions would be appreciated! Get DialogBits from ftp.apple.com. It has working source code to handle exactly what you are asking for (limiting the number of characters in an edit box), and also show how to limit the input to only digits. There are a few mistakes in it (< instead of <=), but they are pretty obvious. -=-doug-=- +++++++++++++++++++++++++++ >From mark_tillinghast@lamg.com (mark tillinghast) Date: 26 Jul 1994 07:53:49 -0000 Organization: Los Angeles Macintosh Group BBS Al Spohn,spohn@mayo.edu,Internet writes: >I've working on a dialog box that takes a time, e.g., 23:12:14.35 as >user input. The input is organized into four edit text boxes - hours, >minutes, seconds, and hundredths. >What's the best way to restrict the input of each of the text edit >boxes to two digits? I've played with a few different ideas, but I >continue to be plagued by the funky scrolling that ensues when the user >enters more than two digits. I don't want to be too much of a nazi in >the way I restrict the input, i.e., I'd prefer to be within sight of >Apple's user interface guidelines. If I could count on the user tabing >to each field and just replacing highlighted text, things would be >easy. It's dealing with the insertion point and what happens to the >text as a result that has me stumped. One way is to create a filter-proc for your dialog. That way you can conviently restrict it to two digits, error trap bad times, (ie 25.61.61.00). The filterproc essentially gives you first dibs on the Next event. You need somthing more than Inside Macintosh if you are going to use the C programming language. Inside Macintosh describes things in terms of the pascal programming language, and the translation to the C programming language is, in the case of the filterproc, inobvious. It is precisely because Inside Macintosh is in pascal that I recommend "Macintosh Programming Secrets" by Scott Knaster and Keith Rollins 2nd Edition Addison Wesley 1992. Chapter 4 of this book deals with dialogs modal and modeless. I have done this filter proc thing before, but if you want to know what I think is a slick way to do it, take a look at the alarm clock DA. If you make your program behave like the alarm clock DA, I think it will be easy to use. Have fun! --------------------------- >From jumplong@aol.com (Jump Long) Subject: MoreFiles 1.2 available on ftp.apple.com Date: 27 Jul 1994 11:52:08 -0400 Organization: America Online, Inc. (1-800-827-6364) Yesterday I finished MoreFiles 1.2. I've added lots of new code, and enhanced several of the existing routines. The change history for version 1.2 is pasted below. MoreFile 1.2 is available now at: ftp.apple.com (IP address 130.43.2.3) /ftp/dts/mac/sc/more-files-1-2.hqx Thanks to all of you who have reported bugs, or suggested enhancements and additions. - Jim Luther, Apple Developer Technical Support - -------------------------------------- v1.2 07/20/94 New Routines: - Added GetDInfo, FSpGetDInfo, SetDInfo, FSpSetDInfo, CheckVolLock, CheckObjectLock, and FSpCheckObjectLock to MoreFilesExtras. - Added MoreDesktopMgr. In the process, I moved GetComment, SetComment, and CopyComment over from MoreFilesExtras and changed their names (added a DT). My apologies to anyone this API change screws up. I think the new and improved code makes up for the hassles. - Added Search. Ever want to search a volume with PBCatSearch and it isn't available? Then you'll like this code. Enhancements to existing routines: - Made changes for powerc. - THINK C project is for version 7.0.3. - Reformatted code to meet new DTS standards for sample code. - Added code to FileCopy to open and copy only file forks that contain data. By doing this, we won't create a data or resource fork for the copied file unless it's really needed (some foreign file systems such as the ProDOS File System and Macintosh PC Exchange have to create additional disk structures to support resource forks). - Added code to FileCopy to copy the file attributes to the destination only if the destination is an AppleShare drop box. That way, if the file has the bundle bit set and if FileCopy is modified (by you - read the comments in the source before modification) to give up time to other processes during a copy, any Finder with access to the file won't try to read bundle information from a partially copied resource fork. - DirectoryCopy no longer calls your CopyErrProc with a copyDirCommentOp failed operation code. There's really nothing wrong with comments not getting copied and DirectoryCopy does give it its best effort. - Modified OpenAware and OpenRFAware functions to check for locked volume if write access is requested. - Rewrote GetObjectLocation so that it calls PBGetCatInfo fewer times (worst case is two calls). That makes the code a little harder to read, but on slow volumes (for example, AppleShare volumes over AppleTalk Remote Access), fewer calls *is* better. - Replaced the static pcpy functions with calls to BlockMoveData (which is BlockMove if you don't have System Update 3.0, System 7.5, or later). - The routines in MoreDesktopMgr (used to be in MoreFilesExtras) can get APPL mappings, icons, and comments from the "Desktop" file if the Desktop Manager isn't supported by a volume. - NameFileSearch and CreatorTypeFileSearch in MoreFilesExtras now call PBCatSearchSyncCompat in Search so that they can search on all volumes. - Tweaked all headers so that they can be read by a future "documentation viewer" project. Bugs fixed: - Changed DTCopyComment to use Str255 instead of unsigned char commentBuffer[199]. PhotoCD's wrongly return up to 255 characters instead of 200 characters and that was trashing memory. - Changed FSMakeFSSpecCompat to fix Macintosh PC Exchange 1.0.x bug. - Fixed a couple of bugs in GetFilenameFromPathname. - Fixed ChangeFDFlags and ChangeCreatorType to get the real vRefNum before calling BumpDate. BumpDate was "bumping" the wrong object in some cases. - Fixed GetParentID so that it gets the right parent ID in all cases (HFS has a weird bug that I work around). - Cleared ioFVersNum field for all PBHOpenDF, PBHOpenRF, PBHOpen, PBHCreate, PBHDelete, PBHGetFInfo, PBHSetFInfo, PBHSetFLock, PBHRstFLock, and PBHRename calls. Not needed for HFS volumes, but some of those old MFS volumes might still be around. - Changed the macro name hasLocalList to hasLocalWList to match bit name in Files.h. end. --------------------------- >From jcr@mbunix.mitre.org (Rogers) Subject: Styled Text in Dialogs Date: 25 Jul 1994 21:44:07 GMT Organization: The MITRE Corporation, Bedford, MA Can anyone tell me how to change the font, size, and style of the text for dialog items, including buttons? Thanks, Jeff Rogers The MITRE Corp. +++++++++++++++++++++++++++ >From Jens Alfke Date: Tue, 26 Jul 1994 20:27:41 GMT Organization: Apple Computer Rogers, jcr@mbunix.mitre.org writes: > Can anyone tell me how to change the font, size, and style of > the text for dialog items, including buttons? You can change the text style of static and edit-text items by changing the style of the grafPort (via TextFont, TextSize, TextFace). You also need to update the txFont, txSize, txFace fields of the dialog's TE record, then call TECalText. Don't forget to SetPort to the dialog first. It looks better if you turn off the isVisible flag in the DLOG resource, then manually call ShowWindow after making your changes. Changing the style of buttons is harder. If you create the button yourself using NewControl, you can OR the variation code with 8 (useWFont) which will make the title of the button appear in the grafPort's current font. Unfortunately control items in dialogs are created for you by the dlog mgr and there is no way to change their var code once created. The two ways I know of to get around this are: (A) make all your buttons be control items, not buttons, then set the variation code in the CNTL resource (B) Temporarily patch out GetNewControl during the call to GetNewDialog. In the patch, OR the varCode with useWFont and call through to the old trap. (This is what I do in Stickies and it works great.) --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From jarezina@magnus.acs.ohio-state.edu (Jasna M. Arezina-Wilson) Date: 27 Jul 1994 11:14:49 GMT Organization: Ohio State University In article <1994Jul26.202741.20971@gallant.apple.com>, Jens Alfke wrote: > (B) Temporarily patch out GetNewControl during the call to GetNewDialog. In > the patch, OR the varCode with useWFont and call through to the old trap. > (This is what I do in Stickies and it works great.) Are you this this is right? I tried it, and GetNewControl is not called - NewControl is. (at least on my SE & sys7.0) Could you post your code fragment here or to alt.sources.mac? - ---------------------------------------- "...when friends rejoice both far and near How can I keep from singing?" - Enya +++++++++++++++++++++++++++ >From Jens Alfke Date: Wed, 27 Jul 1994 20:08:54 GMT Organization: Apple Computer Jasna M. Arezina-Wilson, jarezina@magnus.acs.ohio-state.edu writes: > Are you this this is right? I tried it, and GetNewControl is not called - > NewControl is. (at least on my SE & sys7.0) Oops, you're right. It's NewControl you need to patch. > Could you post your code > fragment here or to alt.sources.mac? Unfortunately the code I have that does this is part of Stickies, and Apple wouldn't want me to redistribute the source. I should probably snip out just the essentials and give them to DTS as an official Snippet... --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world --------------------------- >From quasar@ctt.bellcore.com (Laurence R. Brothers) Subject: The shock of the new (mac vs unix) Date: Thu, 21 Jul 1994 17:27:17 GMT Organization: Bellcore I don't intend to start a flame war about relative merits of things with this article, but I must say that as a programmer familiar with a variety of unix gui toolkits, ranging (historically) from Sunview all the way through TCL/TK, that my introduction to the Mac environment was rather a shock. Keep in mind I'm used to an environment where you just don't have to worry about managing and dispatching your own events, and even updating windows will often be magically taken care of for you. Most unix GUI toolkit objects either have useable default behavior, or you simply register callbacks for them. You never have to mess with the event loop in a typical X application unless you're doing something really weird and/or low-level. In fact if you use TCL/TK (that's a different TCL than the Mac acronym, by the way), almost every little thing is taken care of with amazingly acceptable default behaviour in the toolkit library. A list of amazements as I started trying to develop some simple test applications to learn the Mac development environment: * What, I have to write my own event loop? Haven't they heard of callbacks? Interposition? Well, I guess it's not a pre-emptive OS, but still, does that make any difference? * I have to manage operating system events myself? What's the point of having an operating system if it can't manage its own events? * I have to write an event procedure in case someone inserts an unformatted disk? Give me a break. How about I request a notification only if I'm interested in a bad disk event, and otherwise you take care of it, Mr. Disk Manager? No deal? Too bad. * OK, first I see the event is in the menu bar, then I adjust the menus to show what is active, then I call the menu tracking procedure, then I divide a long int into two "words" (gee, 16 bit words, I wonder where that came from -- me, I call it a half-word.... :-), then I find out which menu and item it was, then I get to actually have my own code do something after checking the global state of the program. How baroque. * Wait a minute, this isn't a scrollbar, it's just a bit of graphics. It doesn't actually *do* anything. It takes a page of code just to get to the point that you find out which scrollbar thingie got clicked on, then you have to do it all yourself. Apple wouldn't have to have all this style guide stuff if they actually implemented any functionality anywhere. * Hmm... I guess the zoom box and the grow icon don't do anything either. Well, gee, at least I have system zoom and grow procedures, but my event procedure needs at least a page of checks surrounding each one before I can call it. Same thing for window movement. * Hey wait a second, you mean I actually have to activate and deactivate the windows myself? I have to deselect the controls, and all that? Oh come on.... * I guess geometry management is too much to ask for? Oh well. Should have known better than to ask. Of course there are no subwindows on the Mac anyhow, so I guess there's not much point. * Oh well, at least the update event is the same. What, you say I shouldn't use backing store? Why not? Why provide the feature and then say not to use it? ... Well, you can see what I mean, if you have any familiarity with your typical Unix/X toolkit (which I had previously thought of as the pessimal programming environment!) I have to qualify all this by saying I've only been messing around with Mac programming for a few weeks, so I am not used to it all yet, but still.... I would have thought the basic programming paradigm might have advanced slightly in the last 10 years, at least to the extent of a standard re-entrant toolkit event-loop with callbacks and event interposition instead of all this manual dispatching. Even in an antique like Sunview you could code a typical application in probably 1/5 to 1/2 the space of an equivalent Mac application. It must take at least 500 lines of C to produce a Mac application that is minimally conformant to the general rules of application behavior, probably more. IMHO, even a 3 line hello world program should automagically do all "the right things" because the windowing environment/finder/OS/whatever should take care of it all. I also must admit that I have only been using MPW C, not MacApp or any of the C++ stuff as yet. I imagine that every Mac programmer must use some standard application framework to build their programs after a while, be it MacApp, AppWannaBe, or whatever, but still, the whole thing seems a lot more awkward than it really needs to be. Of course all the above is IMHO only.... Of course there are many things available on the Mac platform that are either real expensive or very hard to implement in the typical unix environment. Still, I would really like someone to tell me: "You obviously haven't used the foo class libraries with the bar uims package and the baz event manager yet, so what do you expect". -- Laurence R. Brothers (quasar@bellcore.com) Bellcore -- Computing Technology Integration -- Knowledge-Based Applications "There is no memory with less satisfaction in it than the memory of some temptation we resisted." -- James Branch Cabell +++++++++++++++++++++++++++ >From Jens Alfke Date: Thu, 21 Jul 1994 20:57:20 GMT Organization: Apple Computer Laurence R. Brothers, quasar@ctt.bellcore.com writes: > Keep in mind I'm used to an environment where you just don't have to > worry about managing and dispatching your own events, and even > updating windows will often be magically taken care of for you. Most > unix GUI toolkit objects either have useable default behavior, or you > simply register callbacks for them. You never have to mess with the > event loop in a typical X application unless you're doing something > really weird and/or low-level. In fact if you use TCL/TK (that's a > different TCL than the Mac acronym, by the way), almost every little > thing is taken care of with amazingly acceptable default behaviour in > the toolkit library. You really need to start using one of the frameworks -- MacApp, TCL or PowerPlant. They implement most of the nice things you describe above. Keep in mind the historical legacy of the Mac: that it was built in the early-'80s on a slow CPU with 128k of RAM (and originally it was only supposed to have 64k.) There wasn't enough RAM or oomph to use object oriented languages, and C++ didn't exist anyway. Nor was there enough memory, or development time, to provide sophisticated libraries to do the work for you. The goal of the Toolbox was to provide the facilities you'd need to put together a Mac-style application, not to make it as easy as possible. Unfortunately, it's never been possible to move away from that, since it would have meant breaking every existing application. What _has_ been done is to layer more sophisticated environments on top of the Toolbox, such as the class libraries I mentioned above. I think you'll find those much more to your taste. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From todd@fred.dfrf.nasa.gov (Todd Vernon) Date: Thu, 21 Jul 1994 21:14:01 GMT Organization: NASA -- > I don't intend to start a flame war about relative merits of things > with this article, but I must say that as a programmer familiar with a > variety of unix gui toolkits, ranging (historically) from Sunview all > the way through TCL/TK, that my introduction to the Mac environment > was rather a shock. Hold on there sport. I come from the same direction as you but I have a little different perspective. First of all. You are comparing the Mac Toolbox to a high level lib like Motif or TCL/TK ? Try XLib. Xlib is only moderatly better in a side by side comparison then the MacToolbox. Think of the Mac Toolbox as Xlib with controls. And yes they really are controls, you didn't have to "draw" the button did you ? If you choose to use the toolbox alone that is your biz, but I would suggest something a little better, at least initially. I use TranSkel and think it is really quite nice, and yes it has the callbacks that are familiar to you. Pay a little respect to the Mac roots, it was the first wide spread use of GUI stuff. It carries a little baggage. As for MPW, well you made that choice, nothing can help you there. (try Code Warrior). - ---------------------------------------------------------- Todd Vernon |\/\/\/| PRC Inc. | | NASA Dryden Flight Research Facility | | Edwards, CA 93523 | (o)(o) @ _) | ,___| Phone: 805 258 2106 | / FAX : 805 258 2792 /____\ Email: todd@fred.dfrf.nasa.gov / \ - ---------------------------------------------------------- +++++++++++++++++++++++++++ >From rmah@panix.com (Robert Mah) Date: Thu, 21 Jul 1994 17:29:43 -0500 Organization: One Step Beyond quasar@ctt.bellcore.com (Laurence R. Brothers) wrote: ) I don't intend to start a flame war about relative merits of things ) with this article, but I must say that as a programmer familiar with a ) variety of unix gui toolkits, ranging (historically) from Sunview all ) the way through TCL/TK, that my introduction to the Mac environment ) was rather a shock. ) [...] ) It must take at least 500 lines of C to produce a Mac application that ) is minimally conformant to the general rules of application behavior, ) [...] ) I also must admit that I have only been using MPW C, not MacApp or any ) of the C++ stuff as yet. I imagine that every Mac programmer must use ) some standard application framework to build their programs after a ) while, be it MacApp, AppWannaBe, or whatever, but still, the whole ) thing seems a lot more awkward than it really needs to be. Gack. You're using the most primative (interface wise) programming environment and language on the Mac and programming to the metal (well the raw OS anyway) and compare that against sophisticated X toolkits for UNIX???? As you implied, if you should compare your X experience vs MacApp or TCL or PowerPlant or Galaxy or XVT or... If you weren't the kind of guy who did raw X programming, why do you want to do raw Mac programming? There are plenty of higher level tools to choose from. Go choose one. Or build one, as it seems you are in the process of doing :-). In addition, remember that the Mac is a _personal_ computer, not a work- station. As such, it generally runs with much slimmer resources than workstations. 32MB's of RAM is not common. Only around 65% of Mac users even have color. Hell, a good 20% or 30% still use System 6 on 2MB or less. P.S. I would put the minimal LOC in C at a few thousand for a useless, but fully conformant Mac application. That said, just for kicks, I'll try to explain some of the reasons the Mac is the way it is. ) * What, I have to write my own event loop? Haven't they heard of ) callbacks? Interposition? Well, I guess it's not a pre-emptive OS, The original Mac was designed in '82/83 and was a single tasking machine. When it came out, it had the most sophisticated and rich API of any machine of its class available at the time. In addition, in a cooperative environment, IMO, you need fine control over event handling to be nice-nice with other apps. ) * I have to manage operating system events myself? What's the point of ) having an operating system if it can't manage its own events? It does. It simply notifies you when things happen. Would you rather it didn't? ) * OK, first I see the event is in the menu bar, then I adjust the ) menus to show what is active, then I call the menu tracking procedure, ) [...] ) something after checking the global state of the program. How baroque. If you only want simple menu selections, yes. Some folks have to do more complex things like tear-off menus that turn into floating palettes. Same with scroll bars and other interface elements. ) * Oh well, at least the update event is the same. What, you say I ) shouldn't use backing store? Why not? Why provide the feature and then ) say not to use it? The PicHandle thing for windows IS NOT a backing store. You shouldn't use a backing store because the average Mac today has only 4MB to 8MB of real RAM. That's not enough for backing stores. The original had only 128K of RAM. ) but still.... I would have thought the basic programming paradigm ) might have advanced slightly in the last 10 years, at least to the ) [...] Nope. There's this little thing called backward compatability that's extremely important in the personal computer world. UNIX people are generally technical enough to roll with the punches, but secretaries, artists and office workers would balk. Apple is, of course, working on a pre-emptive kernal and memory protection and all that other stuff. But we gotta wait. When they do come, the days of free-form hacking and wild system patches will be gone. Maybe that's good, maybe that's bad...to each his own. Well, that's enough for now. Cheers, Rob _____________________________________________________________________ Robert S. Mah Software Development +1.212.947.6507 One Step Beyond and Network Consulting rmah@panix.com +++++++++++++++++++++++++++ >From afcjlloyd@aol.com (AFC JLloyd) Date: 21 Jul 1994 17:32:05 -0400 Organization: America Online, Inc. (1-800-827-6364) In article , quasar@ctt.bellcore.com (Laurence R. Brothers) writes: >I don't intend to start a flame war about relative merits of things >with this article, but I must say that as a programmer familiar with a >variety of unix gui toolkits, ranging (historically) from Sunview all >the way through TCL/TK, that my introduction to the Mac environment >was rather a shock. > > [ some interesting stuff omitted] > >I also must admit that I have only been using MPW C, not MacApp or any >of the C++ stuff as yet. I imagine that every Mac programmer must use >some standard application framework to build their programs after a >while, be it MacApp, AppWannaBe, or whatever, but still, the whole >thing seems a lot more awkward than it really needs to be. > >Of course all the above is IMHO only.... Of course there are many >things available on the Mac platform that are either real expensive or >very hard to implement in the typical unix environment. Still, I would >really like someone to tell me: "You obviously haven't used the foo >class libraries with the bar uims package and the baz event manager >yet, so what do you expect". Yes, you've got it right, even down to your suspicion that application framework libraries like MacApp are what you are missing. At one time Apple hinted that a framework like MacApp might make it into ROM, but that idea seems to have been abandoned, which in my opinion is just as well. I worked on Bedrock for two years, which was to be a next generation framework (and may still become one in its reincarnation as the OpenDoc Parts Framework). My experiences tell me that we still have more to learn about the right way to create application frameworks; putting one into ROM at this point seems like a bad idea. All of the established frameworks address many of the points you raise, but none are without flaws. So, you should survey the established frameworks, pick one, and then be prepared to enter a love/hate relationship with it. Jim Lloyd afcjlloyd@aol.com +++++++++++++++++++++++++++ >From Bill North Date: 21 Jul 1994 22:36:35 GMT Organization: NASA Goddard Space Flight Center -- InterNetNews site In article Laurence R. Brothers, quasar@ctt.bellcore.com writes: > >A list of amazements as I started trying to develop some simple test >applications to learn the Mac development environment: > Clearly, what you really want is to work on the Apple IIgs. :) Much more advanced than the Mac. ;-) Most of those things exist in the Apple IIgs toolbox. I never understood why Apple never added the equivalent of IIgs calls to the Mac, when the same company developed both toolboxes. Why can't Apple add TaskMaster to the Mac? (TaskMaster handles all "typical" system events: Window moving, scrolling, resizing, etc; Menu selecting, highlighting, blinking, etc; Desk accessory handling; Control activation, highlighting, etc.) How about "HandleDiskInsert" on the IIgs, which will handle all disk insert activities, including formatting. Could go on, but... Apple should apply the lessons learned from the IIgs and apply them to the Mac. /* Bill North -- north@spso.gsfc.nasa.gov */ +++++++++++++++++++++++++++ >From stuart@lorelei.ece.drexel.edu (Stuart R. Harper) Date: Thu, 21 Jul 1994 18:52:34 -0400 Organization: Drexel U. In article <1994Jul21.205720.2022@gallant.apple.com>, Jens Alfke wrote: > Laurence R. Brothers, quasar@ctt.bellcore.com writes: > > Keep in mind I'm used to an environment where you just don't have to > > worry about managing and dispatching your own events, and even > > updating windows will often be magically taken care of for you. Most > > unix GUI toolkit objects either have useable default behavior, or you > > simply register callbacks for them. You never have to mess with the > > event loop in a typical X application unless you're doing something > > really weird and/or low-level. In fact if you use TCL/TK (that's a > > different TCL than the Mac acronym, by the way), almost every little > > thing is taken care of with amazingly acceptable default behaviour in > > the toolkit library. > > You really need to start using one of the frameworks -- MacApp, TCL or > PowerPlant. They implement most of the nice things you describe above. > > Keep in mind the historical legacy of the Mac: that it was built in the > early-'80s on a slow CPU with 128k of RAM (and originally it was only > supposed to have 64k.) There wasn't enough RAM or oomph to use object > oriented languages, and C++ didn't exist anyway. Nor was there enough memory, > or development time, to provide sophisticated libraries to do the work for > you. The goal of the Toolbox was to provide the facilities you'd need to put > together a Mac-style application, not to make it as easy as possible. That was an EXTREME cop-out. Reading Mr. Brothers list of complaints reminded me of my own annoyance with programming the mac after moving over from the Amiga, a 256K RAM/ROM, 68K based system. At the time of my change ('90), I couldn't believe that Apple provided an impressive guideline on 'how' the Mac should look and function without providing default actions from system required user-interface features. Window management and user-input code that took 3 or 4 lines to control suddenly took pages. Requiring the development environment to push basic features invites all kinds of compatibilty problems between systems, increases development time with wasted compilation of 'standard' actions and increases the overall code 'bloat'. Add that to the normal OOPS bloat and you've created multi-megabyte monsters that require '040s and 601 just to grow the window. :) -- Stuart R. Harper - E4 Lab Technician - LeBow 132 - CCD - Drexel U. stuart@lorelei.ece.drexel.edu harper@e4mail.ece.drexel.edu +++++++++++++++++++++++++++ >From aclaasse@nyx.cs.du.edu (Arne Claassen) Date: 21 Jul 1994 20:16:47 -0600 Organization: /usr/lib/news/organi[sz]ation In article <1994Jul21.205720.2022@gallant.apple.com>, Jens Alfke wrote: >You really need to start using one of the frameworks -- MacApp, TCL or >PowerPlant. They implement most of the nice things you describe above. > Being a Newbie to CodeWarrior and Macintosh C programming i felt a lot like Lawrence. I looked at Powerplant and then decided to dig into the user manual which explained to me that if i didn't have a good working knowledge of the Toolbox and other such things, i should not bother with Powerplant yet. So i'm going through Macintosh C primer and anything i can find and find myself programming Event loops and stuff like that and never even getting to an actual program aside from handling the basic interface. I'm looking for something that let's me design the interface in a manner similar to Visual C or similar and be able to concentrate on writing the code that operates within the interface framework. Is this what Powerplant (or MacApp, or whatever) does and how do i get started with it? Thanks, Arne F. Claassen claassen@ebs330.eb.uah.edu aclaasse@nyx.cs.du.edu +++++++++++++++++++++++++++ >From thundero@news.delphi.com (THUNDERONE@DELPHI.COM) Date: 22 Jul 1994 03:32:51 -0000 Organization: Delphi Internet Services Corporation quasar@ctt.bellcore.com (Laurence R. Brothers) writes: >I don't intend to start a flame war about relative merits of things >with this article, but I must say that as a programmer familiar with a >variety of unix gui toolkits, ranging (historically) from Sunview all >the way through TCL/TK, that my introduction to the Mac environment >was rather a shock. >Keep in mind I'm used to an environment where you just don't have to >worry about managing and dispatching your own events, and even >updating windows will often be magically taken care of for you. Most >unix GUI toolkit objects either have useable default behavior, or you >simply register callbacks for them. You never have to mess with the >event loop in a typical X application unless you're doing something >really weird and/or low-level. In fact if you use TCL/TK (that's a >different TCL than the Mac acronym, by the way), almost every little >thing is taken care of with amazingly acceptable default behaviour in >the toolkit library. John Ousterhout's new group at Sun is apparently working on a Mac port of Tk. There's already an "unofficial" port of Tcl. >A list of amazements as I started trying to develop some simple test >applications to learn the Mac development environment: >* What, I have to write my own event loop? Haven't they heard of >callbacks? Interposition? Well, I guess it's not a pre-emptive OS, >but still, does that make any difference? You're trying not to start a flame war? "I ask merely for information." >* I have to manage operating system events myself? What's the point of >having an operating system if it can't manage its own events? Hey, go check out Windows before you complain about Macintosh's handling of events. >* I have to write an event procedure in case someone inserts an >unformatted disk? Give me a break. How about I request a notification >only if I'm interested in a bad disk event, and otherwise you take >care of it, Mr. Disk Manager? No deal? Too bad. >* OK, first I see the event is in the menu bar, then I adjust the >menus to show what is active, then I call the menu tracking procedure, >then I divide a long int into two "words" (gee, 16 bit words, I wonder >where that came from -- me, I call it a half-word.... :-), then I find >out which menu and item it was, then I get to actually have my own >code do something after checking the global state of the program. How >baroque. >* Wait a minute, this isn't a scrollbar, it's just a bit of graphics. >It doesn't actually *do* anything. It takes a page of code just to get >to the point that you find out which scrollbar thingie got clicked on, >then you have to do it all yourself. Apple wouldn't have to have all >this style guide stuff if they actually implemented any functionality >anywhere. >* Hmm... I guess the zoom box and the grow icon don't do anything >either. Well, gee, at least I have system zoom and grow procedures, >but my event procedure needs at least a page of checks surrounding >each one before I can call it. Same thing for window movement. >* Hey wait a second, you mean I actually have to activate and >deactivate the windows myself? I have to deselect the controls, and >all that? Oh come on.... >* I guess geometry management is too much to ask for? Oh well. Should >have known better than to ask. Of course there are no subwindows on >the Mac anyhow, so I guess there's not much point. You think subwindows are a good thing? I can see why they would be used in X and all those other GUIs, but the Mac has a Human Interface. They really wouldn't fit. >* Oh well, at least the update event is the same. What, you say I >shouldn't use backing store? Why not? Why provide the feature and then >say not to use it? > ... >Well, you can see what I mean, if you have any familiarity with your >typical Unix/X toolkit (which I had previously thought of as the >pessimal programming environment!) >I have to qualify all this by saying I've only been messing around >with Mac programming for a few weeks, so I am not used to it all yet, >but still.... I would have thought the basic programming paradigm >might have advanced slightly in the last 10 years, at least to the >extent of a standard re-entrant toolkit event-loop with callbacks and >event interposition instead of all this manual dispatching. Even in an >antique like Sunview you could code a typical application in probably >1/5 to 1/2 the space of an equivalent Mac application. Unlike Sunview, X, Motif, etc, Macintosh has a considerably large installed base. The people forming the installed base would be rather upset if all the applications they use suddenly broke overnight. [snip] >Of course all the above is IMHO only.... Of course there are many >things available on the Mac platform that are either real expensive or >very hard to implement in the typical unix environment. Still, I would >really like someone to tell me: "You obviously haven't used the foo >class libraries with the bar uims package and the baz event manager >yet, so what do you expect". You haven't tried the PowerPlant class library, which is included with CodeWarrior, so what do you expect? >-- > Laurence R. Brothers (quasar@bellcore.com) > Bellcore -- Computing Technology Integration -- Knowledge-Based Applications > "There is no memory with less satisfaction in it than the memory > of some temptation we resisted." -- James Branch Cabell ...................................................................... Chris Thomas, Programmer, Echo Software, thunderone@delphi.com +++++++++++++++++++++++++++ >From eascharf@u.washington.edu (Elizabeth Scharf) Date: 22 Jul 1994 04:36:32 GMT Organization: University of Washington, Seattle This reminds me of Jerry Pournelle's infamous quote in 1984 to the effect that the problem with the Macintosh was that "they wrote half of the operating system and left the other half as an exercise to the reader." Fortunately, things have progressed a little since then... rmgw This is not my account: Please address replies to hawkfish@aol.com Disclaimer: All views expressed are entirely my own and do not reflect the opinions of Elizabeth Scharf or the University of Washington. - --------------------------------------------------------------------------- Richard Wesley | "If I can't dance, you can keep your hawkfish@aol.com | revolution." 71062.1711@compuserve.com | - Emma Goldman - --------------------------------------------------------------------------- +++++++++++++++++++++++++++ >From tbrown@magnus.acs.ohio-state.edu (Ted C Brown) Date: 22 Jul 1994 05:33:23 GMT Organization: The Ohio State University In article <30mpgl$e40@search01.news.aol.com>, >Yes, you've got it right, even down to your suspicion that application >framework libraries like MacApp are what you are missing. At one time >Apple hinted that a framework like MacApp might make it into ROM, but that >idea seems to have been abandoned, which in my opinion is just as well. I >worked on Bedrock for two years, which was to be a next generation >framework (and may still become one in its reincarnation as the OpenDoc >Parts Framework). My experiences tell me that we still have more to learn >about the right way to create application frameworks; putting one into ROM >at this point seems like a bad idea. I don't really want the app frameworks in ROM, I want the base classes to exist in one place in memory, probably loaded by an extention, and for programs to dynamically link to them. The main problem with this is that we'd have to settle on one app framework. Well maybe not -- having the PowerPlant/MacApp/TCL load all at once would eat up alot of memory, but dramatically reduce the code/memory needs of every program that used them. Maybe Dylan will do this (you'd think it'd be able to handle the Dynamic Linking part). +++++++++++++++++++++++++++ >From mburch@ksu.ksu.edu (Matt Burch) Date: 21 Jul 1994 20:24:36 -0500 Organization: Kansas State University For most of the stuff you mentioned, I use the freeware TransSkel 3.0. It does all the event handling, menus, windows, etc. and calls my callback routines when something relavent happens. Easy as 3.1415927. -- - ------------------------------------------------------- Matt Burch | mburch@ksu.ksu.edu | Cogito, ergo cogito sum - ------------------------------------------------------- +++++++++++++++++++++++++++ >From xperts@infi.net (Russell LaVelle) Date: 22 Jul 1994 14:27:16 GMT Organization: InfiNet Ted C Brown (tbrown@magnus.acs.ohio-state.edu) wrote: : In article <30mpgl$e40@search01.news.aol.com>, : >Yes, you've got it right, even down to your suspicion that application : >framework libraries like MacApp are what you are missing. At one time : >Apple hinted that a framework like MacApp might make it into ROM, but that : >idea seems to have been abandoned, which in my opinion is just as well. I : >worked on Bedrock for two years, which was to be a next generation : >framework (and may still become one in its reincarnation as the OpenDoc : >Parts Framework). My experiences tell me that we still have more to learn : >about the right way to create application frameworks; putting one into ROM : >at this point seems like a bad idea. : I don't really want the app frameworks in ROM, I want the base classes to : exist in one place in memory, probably loaded by an extention, and for : programs to dynamically link to them. The main problem with this is : that we'd have to settle on one app framework. Well maybe not -- : having the PowerPlant/MacApp/TCL load all at once would eat up alot : of memory, but dramatically reduce the code/memory needs of every program : that used them. You want a Shared Library, which is possible in the PPC. : Maybe Dylan will do this (you'd think it'd be able to handle the Dynamic : Linking part). Thats axactly waht Dylan does. There is a Dylan Core that goes in the extensions folder. Also, the developer can choose to link the core in to the final app if they want stand alone. -- MacXperts, Inc. 804.353.7122 Certified Apple Developers fax 804.358.3847 3228-L West Cary St. applelink: xperts Richmond, VA 23221 net: xperts@infi.net +++++++++++++++++++++++++++ >From d88-jwa@dront.nada.kth.se (Jon Wätte) Date: 22 Jul 1994 17:44:32 GMT Organization: The Royal Institute of Technology In quasar@ctt.bellcore.com (Laurence R. Brothers) writes: >Keep in mind I'm used to an environment where you just don't have to >worry about managing and dispatching your own events, and even >updating windows will often be magically taken care of for you. Most Well, using a GUI toolkit for the Mac, like MacApp, TCL or the non-C++ TransSkel, will take care of that for you. No muss no fuss. >* What, I have to write my own event loop? Haven't they heard of >callbacks? Interposition? Well, I guess it's not a pre-emptive OS, >but still, does that make any difference? Do it once, then it's done. Or use one of the libraries available and pointed out in the FAQ. If you really want to, this means you can get more control if you really want to. >* I have to manage operating system events myself? What's the point of >having an operating system if it can't manage its own events? What do you mean operating-system events? The only one I can think of is the diskEvent, which, again, is handled by all available libraries, or you write it once from sample code and forget it - the pro is that you can intercept the event and do something interesting to the floppy if you want to. >I also must admit that I have only been using MPW C, not MacApp or any >of the C++ stuff as yet. I imagine that every Mac programmer must use See, there you go. It's like trying to write something in XLib. You CAN, but it's not a good idea. For plain C, try TransSkel. >while, be it MacApp, AppWannaBe, or whatever, but still, the whole >thing seems a lot more awkward than it really needs to be. Have you ever used XLib? -- -- Jon W{tte, h+@nada.kth.se, Mac Software Engineer Deluxe -- "Something horrible is wrong." - Steve Falkenberg +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Fri, 22 Jul 1994 17:46:26 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) afcjlloyd@aol.com (AFC JLloyd) writes: >Yes, you've got it right, even down to your suspicion that application >framework libraries like MacApp are what you are missing. At one time >Apple hinted that a framework like MacApp might make it into ROM, but that >idea seems to have been abandoned, which in my opinion is just as well. I >worked on Bedrock for two years, which was to be a next generation >framework (and may still become one in its reincarnation as the OpenDoc >Parts Framework). My experiences tell me that we still have more to learn >about the right way to create application frameworks; putting one into ROM >at this point seems like a bad idea. >All of the established frameworks address many of the points you raise, >but none are without flaws. So, you should survey the established >frameworks, pick one, and then be prepared to enter a love/hate >relationship with it. The basic problem is that all the Mac frameworks are lousy. Apple's MacApp is big, old, clunky, and weakly supported. Last year at this time, Apple was telling developers to go to Symantec's Bedrock, which got as far as a CD-ROM with the Bedrock headers and some sample apps before being dropped. Symantec has the "old TCL", written for their dialect of C with some C++ extensions; it's widely used, more or less stable, and on the way out. Symantec also has the "new TCL", which is true C++, very new, and very buggy. Symantec is generally considered to be concentrating on the Windows market now. Then there's the new vendor, MetroWerks, which is selling an almost-finished C++ compiler (no templates) and a somewhat thin class library that goes with it. Generally, users of MetroWerks are happier with their vendor than Symantec users. There's also the "Nerdworks" library, which is a free class library available on Apple's "ftp.apple.com", and there's a book that goes with it. This is a weak, but workable class library. At the high end, there are some tools from Neuron Data that allow cross-platform development, but pricing is in the $10K and up range. John Nagle +++++++++++++++++++++++++++ >From shebs@cygnus.com (Stan Shebs) Date: Fri, 22 Jul 1994 18:51:39 GMT Organization: /cygint/s1/users/shebs/.organization In article quasar@ctt.bellcore.com (Laurence R. Brothers) writes: * What, I have to write my own event loop? Haven't they heard of callbacks? Interposition? Well, I guess it's not a pre-emptive OS, but still, does that make any difference? When I first wrote Xconq for X10, when the Xt toolkit was too broken to use, guess what, I had to write my own event loop! Actually, the value of the explicit event loop is that you can bypass when necessary. A heavily-tuned Mac program can have a number of event loops, such as the one that handles the spiffy scrollbar response when you're dragging the thumb. This kind of thing really helps performance. In general, Mac applications (binaries, not sources) are smaller and use the CPU more efficiently than Unix/X applications. It's very educational to put a 68000-based Mac Plus side-by-side with a Sparc-based Sun machine, and watch the Plus run interactive programs smoother and faster than the Sun! * Wait a minute, this isn't a scrollbar, it's just a bit of graphics. It doesn't actually *do* anything. It takes a page of code just to get to the point that you find out which scrollbar thingie got clicked on, then you have to do it all yourself. Apple wouldn't have to have all this style guide stuff if they actually implemented any functionality anywhere. What makes you think that everybody wants to do scrollbars the same way? There are many application-specific optimizations and variations available. If you ever get to a point where you need to do one of these, you'll be very glad it's not in ROM! Incidentally, the guidelines are intended only as a starting point. Many of the interface developments of the past ten years started out by violating some guideline, but then went on become part of the guidelines themselves. Just compare a 1984 IM with the latest HIG... * I guess geometry management is too much to ask for? Oh well. Should have known better than to ask. Of course there are no subwindows on the Mac anyhow, so I guess there's not much point. After having wasted months and years of my life messing with X's yucko notions of "geometry management", I was very happy not to have that on Macs. I have to qualify all this by saying I've only been messing around with Mac programming for a few weeks, so I am not used to it all yet, but still.... I would have thought the basic programming paradigm might have advanced slightly in the last 10 years, at least to the extent of a standard re-entrant toolkit event-loop with callbacks and event interposition instead of all this manual dispatching. Even in an antique like Sunview you could code a typical application in probably 1/5 to 1/2 the space of an equivalent Mac application. Of course, the main application that everybody runs in a "modern" Unix environment is a terminal emulator set to mimic terminals from 10-20 years ago, still you type "ls" and "rm" just like Ken and Dennis did, and heaven help you if you try to write a program that doesn't have a console available for stdout to write to, even if it *is* an "toolkit event-loop with callbacks". I think you'll find that it takes more than a few weeks to realize that the Unix style of programming is not the only way, and that the Mac style, in addition to its weaknesses, has many strengths that the Unix world has yet to approach. It must take at least 500 lines of C to produce a Mac application that is minimally conformant to the general rules of application behavior, probably more. IMHO, even a 3 line hello world program should automagically do all "the right things" because the windowing environment/finder/OS/whatever should take care of it all. That's not exactly fair, because the "3-line hello world" of Unix doesn't do *any* interaction at all. If I just wanted to scribble on the screen and exit, I could write a pretty short Mac program for that, and do it with just the basic Mac traps. Also, once the basic framework is in place, you don't have to mess with it anymore. I now have versions of Xconq for both Macs and X11, and it's *much* easier to add a new menu item or button or image to the Mac version, so much so that my Mac version usually gets all the features first. Of course there are many things available on the Mac platform that are either real expensive or very hard to implement in the typical unix environment. Amen to that! Try having a reasonable response time when dragging something with the mouse. Can you say "stu-stutt-stu-st-stutter"? Still, I would really like someone to tell me: "You obviously haven't used the foo class libraries with the bar uims package and the baz event manager yet, so what do you expect". Others have gone into the details, so I'll just leave it at the "what do you expect". :-) Stan Shebs Cygnus Support shebs@cygnus.com +++++++++++++++++++++++++++ >From Jens Alfke Date: Fri, 22 Jul 1994 17:24:12 GMT Organization: Apple Computer Stuart R. Harper, stuart@lorelei.ece.drexel.edu writes: > That was an EXTREME cop-out. Reading Mr. Brothers list of complaints > reminded me of my own annoyance with programming the mac after moving over > from the Amiga, a 256K RAM/ROM, 68K based system. Well, I'm not saying that the design of the Mac OS was perfect; I think they really screwed up in some areas and we're still paying the price for that. Your point about the Amiga is valid; nevertheless, note that the Amiga came out a few years after the Mac and was able to learn from some of its mistakes (the same can be said for Windows). Also, both may seem tiny by today's standards but there is a _big_ difference between a system with 256k each of RAM and ROM, and one with 128k RAM and 64k ROM. The Amiga had twice the RAM (which means much more RAM available to apps) and four times the ROM, so that gave them more headroom to put in things like e.g. threading and an improved Toolbox interface. > Requiring the development environment to push basic features invites all > kinds of compatibilty problems between systems, increases development time > with wasted compilation of 'standard' actions and increases the overall > code 'bloat'. Good dynamic linking technology, as is finally starting to appear on the Mac with ASLM and SOM, will take care of a lot of that. (Note that the NeXT application framework is a shared library living on top of a very Mac-like lower level toolbox.) I really don't care whether the code that handles my basic app functionality is in ROM or in a shared library; it looks the same to me, and the library is easier to update and maintain. OpenDoc and its framework will take advantage of this in a big way. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From isis@netcom.com (Mike Cohen) Date: Fri, 22 Jul 1994 18:21:07 GMT Organization: ISIS International Look at one of the class libraries or application frameworks such as TCL, MacApp, or PowerPlant. All of them take care of the event dispatching & all of the other things that you're so grossed out about - you only have to add your own callbacks by overriding various behaviours, such as clicking in the content are of a pane. They even handle scrolling by providing a scroller object which does most of the work. -- Mike Cohen - isis@netcom.com NewtonMail, eWorld: MikeC / ALink: D6734 / AOL: MikeC20 Home Page: file://ftp.netcom.com/pub/isis/home.html +++++++++++++++++++++++++++ >From oster@netcom.com (David Phillip Oster) Date: Fri, 22 Jul 1994 18:32:14 GMT Organization: Netcom Online Communications Services (408-241-9760 login: guest) Just to add my fuel to the flame war: There is geometry management, if you want it, so it doesn't cost you anything if you don't use it. You get it by writing rez #define expressions. This lets you line dialog items up, or arrange them any way you like, but at compile time, rather than run time. Ever try to write copy and paste in motif? There are multiple, incompatible definitions of the clipboard, so doing what on a mac is ZeroScrap() PutScrap() takes pages of code to do correctly (read the emacs source for an example.) - - - - Callbacks are just syntactic sugar around X's event loop. If you know, because you are writing your program, what procedure you are going to call in response to an event, then it is much simpler to simply call the procedure: for(;;){ GetNextEvent(everyEvent, &event); switch(event->what){ case keyDown: GoKey(&event); break; ... } } as opposed to the mysterious: XtAddCallback(rootWidget, XmNkeyDownEventCallback, GoKey, NULL); In fact, Apple has lost the vision, and started importing to many unix heads: the interface to the Applescript inter-application communication system looks like it was designed by Unix wannabees. When you are trying to debug a program, it is much easier to put a single breakpoint in an explicit event loop, and trace it than it is to have the heart of the program embedded in some system undebuggable library, and have to set breakpoints in ALL your callbacks because you don't know which one will trigger. X gives you no help with printing: once you write your application to do its drawing to the screen, you need to write it a second time to directly generate postscript, so you can write a text file of postsript to send to the printer. On the mac, you open a printer GrafPort, and do the same drawing to it that you do to the screen. The translation to the printer driver happens automatically. Then of course, there is the speed of progress in the two environments. At least there is a standard inter-application communication system for the Mac. Unix still hasn't fixed the security bug in "login" I reported back in 1977 : 17 years ago. I've done numerous commercial products on Macintosh and on Unix/Motif. Macs are much easier to program at the toolbox level than Unix/Motif. +++++++++++++++++++++++++++ >From Rob Browning Date: 22 Jul 1994 19:30:30 GMT Organization: The University of Texas at Austin, Austin, Texas In article <30p0i0$fhi@news.kth.se> Jon W!tte, d88-jwa@dront.nada.kth.se writes: >>Keep in mind I'm used to an environment where you just don't have to >>worry about managing and dispatching your own events, and even >>updating windows will often be magically taken care of for you. Most Une thing that I would mention is that MCL (Yes that's Macintosh Common Lisp) has a very impressive class library that handles your interface with the Mac Toolbox. It has callbacks, it handles the event loop behind your back, and you don't ever have to call WaitNextevent (but you can if you like). It supports windows which contain views which contain subviews... And you just subclass one of these and override it's view-draw-contents method, and you are on your way. All this and much much more :> And not to start a religious war, but if you put in all the type declarations in your code (the ones that you have to put in a C/C++ program) you can get quite good performance. No, it won't beat C or C++ on a reguar basis, But as a development/prototyping environment, it is quite impressive. It's too bad it looks like it is going the way of the DoDo. MCL shows what Apple can do if they put their mind to it. And as good as Dylan sounds, it's not quite as powerful as Common Lisp. --Rob. +++++++++++++++++++++++++++ >From ingemar@lysator.liu.se (Ingemar Ragnemalm) Date: 22 Jul 1994 20:23:12 GMT Organization: (none) mburch@ksu.ksu.edu (Matt Burch) writes: >For most of the stuff you mentioned, I use the freeware >TransSkel 3.0. It does all the event handling, menus, windows, etc. >and calls my callback routines when something relavent happens. >Easy as 3.1415927. One of the *best* things with TransSkel is that while it does simplify the programming a lot (making trivial programs trivial to write) I still have full access to the Toolbox as much as I *want*. For example, when I wanted to handle suspend/resume events, using TransSkel 2.0 (which was made before suspend/resume was invented), I could add that without editing TransSkel at all! I still use TransSkel 2.0 (updated for some "new" stuff like WNE and hierarcical menus), and it works just great. I guess 3.0 is better, but it doesn't come with Pascal-useable TransEdit and TransDisplay. Programming the Mac from the ground up from the Toolbox, without a package like that, is really confusing. Getting into stuff like Apple Events, Appletalk and QuickTime is even worse. I find myself writing simplified interfaces to all of them as I start using them. You can go to that level later, but do yourself a favor and start on a level that is simpler. -- - - Ingemar Ragnemalm, PhD Image processing, Mac shareware games E-mail address: ingemar@isy.liu.se or ingemar@lysator.liu.se +++++++++++++++++++++++++++ >From aclaasse@nyx.cs.du.edu (Arne Claassen) Date: 22 Jul 1994 15:04:21 -0600 Organization: University of Denver, Dept. of Math & Comp. Sci. In article <30n74k$7nr@matt.ksu.ksu.edu>, Matt Burch wrote: >For most of the stuff you mentioned, I use the freeware >TransSkel 3.0. It does all the event handling, menus, windows, etc. >and calls my callback routines when something relavent happens. >Easy as 3.1415927. Where can i find TransSkel? I've tried archie and sumex-aim. but to no avail. is it under a different name than transskel? Arne F. claassen claassen@ebs330.eb.uah.edu +++++++++++++++++++++++++++ >From shimpei@leland.Stanford.EDU (Shimpei Yamashita) Date: 23 Jul 1994 10:22:40 GMT Organization: Stanford University, CA 94305, USA In article <30pc8l$1kk@nyx.cs.du.edu>, Arne Claassen wrote: :Where can i find TransSkel? I've tried archie and sumex-aim. but to no :avail. is it under a different name than transskel? : :Arne F. claassen :claassen@ebs330.eb.uah.edu : : ftp.primate.wisc.edu in /pub/mac/TransSkel Would someone like to upload it to sumex? I just got it, and I don't want to upload anything I haven't evaluated for a few days. -- Shimpei Yamashita, Stanford University shimpei@leland.stanford.edu +++++++++++++++++++++++++++ >From d88-jwa@dront.nada.kth.se (Jon Wätte) Date: 24 Jul 1994 10:52:09 GMT Organization: The Royal Institute of Technology In stuart@lorelei.ece.drexel.edu (Stuart R. Harper) writes: >Agreed! Quick adoption of ASLM will make up for alot of real or perceived >problem in Mac code development i.e. You don't like rolling all your own >UI code, find GUI library that you like that does the job for you. ASLM is doomed to die; except OpenTransport will use it so it has to survive :-( ASLM does dynamic linking of C++ classes compiled with MPW C++ (CFront) For other things, with other compilers/environments, it doesn't work. SOM is the future, and it will be on top of the CFM which is _here_ in production, release, use, ... since March 14. Cheers, / h+ -- -- Jon W{tte, h+@nada.kth.se, Mac Software Engineer Deluxe -- "Windows doesnÕt use AppleEvents." - Anon +++++++++++++++++++++++++++ >From Mark Hanrek Date: Sun, 24 Jul 1994 10:45:55 GMT Organization: The Information Workshop There have been many enlightened observations, and a few chuckles, too, regarding a lot of related things. I was rolling on the floor when I read the one about where... "The Mac was built only half-way, and the rest was left as an exercise for the reader." But with respect to identifying the real source of Mr. Brother's programming problems, you've all missed it. -------------------------------------------------------------- The problem is with HOW one is introduced to any new subject. -------------------------------------------------------------- If an excellent guide were sitting next to him for a week or two, he would still be having a pleasant experience, regardless of platform, and probably out-producing most of the rest of his colleagues. But, every last one of us is thrown into any new subject, sink or swim... - -- When it gets frustrating, we question the design. :) And rightly so! But when we're finally making progress, we forget, and go back to accepting things the way they are. And "acceptance" is what perpetuates "the trap", where we are all so busy trying to catch up that we never have any extra time to help make things better. - --- The Power of Simplicity Simple "guided introductions" into a new can mean 5,000 people working productively with , instead of 50. It means avoiding and preventing humongous amounts of floundering, repeating classic mistakes, repeated questions, and having to reverse incorrect models we've created in our heads. And so easily done. It doesn't take much. - --- Case In Point As We Speak Mark my words. You read it here (too). In three years we'll all be wondering why it has taken forever for OpenDoc to catch on. Everyone will have an opinion. Yes, there were the "guided introductions" into the fabulous world of OpenDoc made available through Apple's Developer University, but their effectiveness was negated by Apple needing to make a return on its investment in developing its tutorials, rather than its investment in the supply of OpenDoc-savvy programmers, and as a consequence only 50 programmers purchased them. Well... What did we expect when we take an existing set of programmers, and then ALL AT ONCE ask them to... * learn how to use a second development environment (MPW or ToolServer) along with their primary one, with many ALSO switching to a new primary environment. * learn C++. * learn the tricks of the trade for writing programs that run correctly on the PowerMacintosh. * get their object-oriented savvy developed so they too can speak comfortably of mixin classes, operator overloading, iostreams, templates, virtual destructors, unmangling, and the relative merits of various class libraries. * Get up ot speed on at least one of Apple's new technologies, which includes AppleScript/OSA, Drag Manager, AE/Object, AOCE, Threads, CommToolbox/TCP, Components/ASLM, new printing architecture, etc. * Produce sellable OpenDoc parts by mastering OpenDoc's new paradigms, new terms and concepts, normally large class library, IBM's SOM, and the new tools that work with them. That's "the shock of the new". How can we expect programmers to make progress when they are "thrown in" to handle all of this, unguided, sink or swim, and offered no way to get past dog-paddling? Every question in csmp that has been asked before is DOG-PADDLING. Every valuable question/answer that is not saved and made easily re-accessible in a central place perpetuates DOG-PADDLING. - --------------------------------------------------------------------- ... and all this just seems to go in one ear, and out the other, 'cuz things go right back to the way they were, just like the discussion in this thread will. Watch... :) Mark Hanrek The Information Workshop +++++++++++++++++++++++++++ >From stuart@lorelei.ece.drexel.edu (Stuart R. Harper) Date: Sat, 23 Jul 1994 11:44:58 -0400 Organization: Drexel U. In article <1994Jul22.172412.20391@gallant.apple.com>, Jens Alfke wrote: > Stuart R. Harper, stuart@lorelei.ece.drexel.edu writes: > > That was an EXTREME cop-out. Reading Mr. Brothers list of complaints > > reminded me of my own annoyance with programming the mac after moving over > > from the Amiga, a 256K RAM/ROM, 68K based system. > > Well, I'm not saying that the design of the Mac OS was perfect; I think they > really screwed up in some areas and we're still paying the price for that. > Your point about the Amiga is valid; nevertheless, note that the Amiga came > out a few years after the Mac and was able to learn from some of its mistakes > (the same can be said for Windows). Also, both may seem tiny by today's > standards but there is a _big_ difference between a system with 256k each of > RAM and ROM, and one with 128k RAM and 64k ROM. The Amiga had twice the RAM > (which means much more RAM available to apps) and four times the ROM, so that > gave them more headroom to put in things like e.g. threading and an improved > Toolbox interface. True enough, but when the Mac+ and MacII made their rollouts with their 128KROM and 256KROM, Apple still didn't see fit to add a "Default Action Manager" or update the Toolbox/Event Manager to take care of basic user-interface function. Yeah, I know, they had alot of other development going on (Color QuickDraw, 020 migration, Networking etc), but adding a basic event->action or even a shared library framework to the ROM would have made accessing new features a breeze. > > Requiring the development environment to push basic features invites all > > kinds of compatibilty problems between systems, increases development time > > with wasted compilation of 'standard' actions and increases the overall > > code 'bloat'. > > Good dynamic linking technology, as is finally starting to appear on the Mac > with ASLM and SOM, will take care of a lot of that. (Note that the NeXT > application framework is a shared library living on top of a very Mac-like > lower level toolbox.) I really don't care whether the code that handles my > basic app functionality is in ROM or in a shared library; it looks the same > to me, and the library is easier to update and maintain. OpenDoc and its > framework will take advantage of this in a big way. Agreed! Quick adoption of ASLM will make up for alot of real or perceived problem in Mac code development i.e. You don't like rolling all your own UI code, find GUI library that you like that does the job for you. -- Stuart R. Harper - E4 Lab Technician - LeBow 132 - CCD - Drexel U. stuart@lorelei.ece.drexel.edu harper@e4mail.ece.drexel.edu +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Sun, 24 Jul 1994 17:10:21 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Rob Browning writes: >In article <30p0i0$fhi@news.kth.se> Jon W!tte, d88-jwa@dront.nada.kth.se writes: >>>Keep in mind I'm used to an environment where you just don't have to >>>worry about managing and dispatching your own events, and even >>>updating windows will often be magically taken care of for you. Most >Une thing that I would mention is that MCL (Yes that's Macintosh Common >Lisp) has a very impressive class library that handles your interface >with the Mac Toolbox. It has callbacks, it handles the event loop behind >your back, and you don't ever have to call WaitNextevent (but you can if >you like). Is this still an active product? Is there a PPC version? We used to think Common LISP was big. Then came C++. John Nagle +++++++++++++++++++++++++++ >From d88-jwa@hemul.nada.kth.se (Jon Wätte) Date: 24 Jul 1994 17:45:49 GMT Organization: The Royal Institute of Technology In Mark Hanrek writes: >Simple "guided introductions" into a new can mean 5,000 people >working productively with , instead of 50. If the is the Mac toolbox, there are courses from the Developer University, both self-paced and on-site. They are expensive, but from what I hear, very good. >It means avoiding and preventing humongous amounts of floundering, The FAQ for this group is intended to at least give a hint of what you should do in that situation. >That's "the shock of the new". Well, with these new technologies, and OpenDoc specifically, it seems as if Apple is trying to bet it all on one card: We Want The Future To Be Like This. Unfortunately, they don't do it with all their hearts, orr rather, with all their wallet, just with all of their minds, which may explain why Apple seems so mindless of other things :-) I can envision a future where OpenDoc works the wonders it's supposed to do, but as you say: it's all about adoption. And adoption right now is not feasible; there's not even a sanctioned way of using a scroll bar... Cheers, / h+ -- -- Jon W{tte, h+@nada.kth.se, Mac Software Engineer Deluxe -- I offer a pot of gold for Gates' head on a pole. Naah - bashing Microsoft is "out." Love, Peace and Understanding! +++++++++++++++++++++++++++ >From aclaasse@nyx.cs.du.edu (Arne Claassen) Date: 24 Jul 1994 14:43:57 -0600 Organization: University of Denver, Dept. of Math & Comp. Sci. In article , John Nagle wrote: > Is this still an active product? Is there a PPC version? > > We used to think Common LISP was big. Then came C++. The last version is MCL 2.0 and available from APDA. Dunno the price, but i'd say about $500. MCL 2.0 is an updated version of Franz's Allegro Common LISP and does include CLOS (Common Lisp Object System) as to the specifications discussed by Guy Steele in Common Lisp: The Language, second edition. It does not, however include CLIM (Common LISP Interface Manager) which will allow transporatable application development for all Common LISP platforms. CLIM is available in beta (maybe later by now) form from a number of independent developers. Forget support from Apple, tho. You'd actually get more helpful info from Franz although they don't support it either. So, no PPC and not likely either. On the other hand, for large applications, it's a great development platform, does include excellent tools for dealing with interface elements and implements the Event Loop in the environment. Of course there's always the overhead. A simple application will take almost a Meg in LISP overhead for the compiled application, but if you build a five meg application, that's not too bad (HMM.. me thinks, MS Windows was developed in LISP with their overhead... :) Arne F. Claassen claassen@ebs330.eb.uah.edu +++++++++++++++++++++++++++ >From aclaasse@nyx.cs.du.edu (Arne Claassen) Date: 25 Jul 1994 07:30:39 -0600 Organization: University of Denver, Dept. of Math & Comp. Sci. In article <30voj2$j37@news.kth.se>, Jon Wätte wrote: >In <30u5jq$fvg@acmex.gatech.edu> gt7092d@prism.gatech.edu (Damir Smitlener) writes: >>Until there is something like Visual C++ (if there is and i havent >>seen it, please tell me! and i dont mean multi-thousand dollar >>packages.), ile leave 'Mac' programming to those who want it. > >Why not pay a few thousand dollars for a good package? You paid >a lot for you Mac, you're going to earn your living with it, so >you'd better have decent tools, right? Um, i the point is that on inferior (ok, if someone wants to flame me for calling Windows inferior, go right ahead) platforms there are excellent tools for developing software and one can worry less about meeting the overhead needed for a program that fits well into the platform. While on the mac, there really isn't anything like cheap tools, such as Visual C++, so why should i spent more money than a Windows developer? Because of the glory and warm'n'fuzzy-feeling of programming for the Macintosh? Um, i love my Mac and i'll never go back to PCs, but i don't see why there cannot be a development environment worth the OS we work with. > >>All these defenses of mac-programming here confuse me; do you >>folks WANT to work that hard on non-essentials? Doesnt anyone > >No; we DON'T work hard on essentials. Either we did it once >before, and copy/paste into a new project, or we use one of the >many good environments/frameworks available. But if you're the >typical lazy integrator consultant type, I'm not surprised you >don't want to do the research necessary before condemning a >platform you haven't used for any extended period of time. I'm doing research and i'm getting places, but it's still annoying. But defending the intrinic necessity for the overhead in even handling and interface management, strikes me in much of the same way as the arguments from unix-people i know that try to convince me of the intrinsic superiority command lines as opposed to GUIs (another posssible flame war, but i'd rather not get into that one) Arne F. Claassen - -- claassen@ebs330.eb.uah.edu +++++++++++++++++++++++++++ >From gt7092d@prism.gatech.edu (Damir Smitlener) Date: 24 Jul 1994 12:41:30 -0400 Organization: Georgia Institute of Technology >How can we expect programmers to make progress when they are "thrown in" >to handle all of this, unguided, sink or swim, and offered no way to get >past dog-paddling? Simple answer: you cant. As a relative newcomer to the mac, but not to programming in general, I write NO software that can be considered 'Mac-like.' I write using standard c/c++, which means i basically write unix-code. To take this code to windows has proven quite painless with tools like Visual C++. Going to X , not too bad. Making it Mac software? Uhh...ime simply not interested in working that hard on stuff that should be handled be the OS. Yes, Ive looked at TransSkel, PowerPlant, etc. Compared even to Visual BASIC they _suck_. Until there is something like Visual C++ (if there is and i havent seen it, please tell me! and i dont mean multi-thousand dollar packages.), ile leave 'Mac' programming to those who want it. All these defenses of mac-programming here confuse me; do you folks WANT to work that hard on non-essentials? Doesnt anyone wonder why Doom will be running on SGI and anything that runs linux before it runs on Macs? In fact, ile make a prediction: Doom will run as a linux app on PowerMacs before it runs as a System 7.x app. Still, i am impressed by the skill of those who can do this well. I wont be one of them, even though i love my powermac. damir gt7092d@prism.gatech.edu +++++++++++++++++++++++++++ >From Jens Alfke Date: Mon, 25 Jul 1994 22:17:57 GMT Organization: Apple Computer Jon W!tte, d88-jwa@hemul.nada.kth.se writes: > I can envision a future where OpenDoc works the wonders it's supposed > to do, but as you say: it's all about adoption. And adoption right > now is not feasible; there's not even a sanctioned way of using a > scroll bar... Hmm, you mentioned this once before in private e-mail. To do scrolling you just use two frames; it's really almost exactly the way it works in MacApp with a scroller view embedding the view to be scrolled. There is a new recipe that describes how to do scrolling, which I can e-mail you. Really, is this the main objection you have to OpenDoc? These things can seem tricky, but recall all the problems you must have had figuring out how to do scrolling and growing windows when you first learned to program the Mac ... I know that moving the scrollbars around and invalidating the proper areas of the window gave me fits. It's just a matter of learning new things. And, back to the theme of this thread, the OpenDoc Parts Framework will take care of the grungy details of scrolling for you. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon Wätte) Date: Tue, 26 Jul 1994 10:02:53 +0200 Organization: Royal Institute of Theoretical Theology In article <1994Jul25.221757.24322@gallant.apple.com>, Jens Alfke wrote: >Hmm, you mentioned this once before in private e-mail. To do scrolling you >just use two frames; it's really almost exactly the way it works in MacApp >with a scroller view embedding the view to be scrolled. There is a new recipe >that describes how to do scrolling, which I can e-mail you. Why wasn't that on the a6 source CD? Indeed, the way I looked at it, you had to get at the root view to install your scrollbar there, and that didn't really work very well with embedding. There were also printing problems, but I can live with them (who wants a scrollbar on their printout? :-) >Really, is this the main objection you have to OpenDoc? These things can seem No; it's the easiest objection. I could go on about what compiling in CFront/MPW does to my productivity, but I won't :-) There's also this undefined thing called memory layout. What if you want to know how much memory you have to play with for caching issues, or want to do your own "virtual memory" by purging blocks to disk? There's no supported way of finding this out; you just have to assume your component will have "enough" for some default. >And, back to the theme of this thread, the OpenDoc Parts Framework will take >care of the grungy details of scrolling for you. Any year now. We were expected to talk about starting commercial part development in the June Munic kitchen, when SOM wasn't there, embedding was a black art, CFront was the only useable tool, ... NO WAY! I think OpenDoc is a good idea, but it has to stabilize at least SOMEWHAT, and the tools mess has to be sorted out before I can spend time on business on it. Cheers, / h+ -- Jon Wätte Hagagatan 1 113 48 Stockholm Sweden +++++++++++++++++++++++++++ >From d88-jwa@hemul.nada.kth.se (Jon Wätte) Date: 25 Jul 1994 07:11:30 GMT Organization: The Royal Institute of Technology In <30u5jq$fvg@acmex.gatech.edu> gt7092d@prism.gatech.edu (Damir Smitlener) writes: >looked at TransSkel, PowerPlant, etc. Compared even to Visual BASIC >they _suck_. Visual Basic is not in the same cathegory as PowerPlant or TCL. Visual Basic is in the same cathegory as HyperCard 2.2 (which does AppleScript as well) >Until there is something like Visual C++ (if there is and i havent >seen it, please tell me! and i dont mean multi-thousand dollar >packages.), ile leave 'Mac' programming to those who want it. Why not pay a few thousand dollars for a good package? You paid a lot for you Mac, you're going to earn your living with it, so you'd better have decent tools, right? As for a cheap tool, try Symantec C++ 7.0, which comes with an interface builder (and the Think Class Library version 2.0) which closely parallells Visual C++. >All these defenses of mac-programming here confuse me; do you >folks WANT to work that hard on non-essentials? Doesnt anyone No; we DON'T work hard on essentials. Either we did it once before, and copy/paste into a new project, or we use one of the many good environments/frameworks available. But if you're the typical lazy integrator consultant type, I'm not surprised you don't want to do the research necessary before condemning a platform you haven't used for any extended period of time. -- -- Jon W{tte, h+@nada.kth.se, Mac Software Engineer Deluxe -- What we need is a good GNU [...] licence manager implementation. -- Raphael Manfredi +++++++++++++++++++++++++++ >From amundson@phenom.physics.wisc.edu (James F. Amundson) Date: Mon, 25 Jul 1994 22:51:55 -0600 Organization: Division of Information Technology In article , nagle@netcom.com (John Nagle) wrote: > There's also the "Nerdworks" library, which is a free class > library available on Apple's "ftp.apple.com", and there's a book that > goes with it. This is a weak, but workable class library. Hey! I'm interested in that! The problem is, I've looked all through "ftp.apple.com" and found nothing. "dir-files-all" had no instances of "nerd" or "works". Anyone care to point me to it? Thanks, Jim Amundson +++++++++++++++++++++++++++ >From hpoppe@ncar.ucar.edu (Herb Poppe) Date: 26 Jul 1994 15:40:23 GMT Organization: National Center for Atmospheric Research In article amundson@phenom.physics.wisc.edu (James F. Amundson) writes: > In article , nagle@netcom.com (John Nagle) wrote: > > > There's also the "Nerdworks" library, which is a free class > > library available on Apple's "ftp.apple.com", and there's a book that > > goes with it. This is a weak, but workable class library. > > Hey! I'm interested in that! The problem is, I've looked all through > "ftp.apple.com" and found nothing. "dir-files-all" had no instances of > "nerd" or "works". Anyone care to point me to it? I couldn't find it either and I looked in directories other than /dts; e.g., /pub. Is the "book that goes with it" in paper or electronic form? Herb Poppe National Center for Atmospheric Research (NCAR) hpoppe@ncar.ucar.edu P.O. Box 3000 (303) 497-1296 Boulder, CO 80307 USA +++++++++++++++++++++++++++ >From jpurlia@qualcomm.com (John Purlia) Date: 26 Jul 1994 17:09:26 GMT Organization: Qualcomm, Inc. In article <30voj2$j37@news.kth.se>, d88-jwa@hemul.nada.kth.se (Jon Wätte) wrote: > In <30u5jq$fvg@acmex.gatech.edu> gt7092d@prism.gatech.edu (Damir Smitlener) writes: > >All these defenses of mac-programming here confuse me; do you > >folks WANT to work that hard on non-essentials? Doesnt anyone > > No; we DON'T work hard on essentials. Either we did it once > before, and copy/paste into a new project, or we use one of the > many good environments/frameworks available. But if you're the > typical lazy integrator consultant type, I'm not surprised you > don't want to do the research necessary before condemning a > platform you haven't used for any extended period of time. Exactly!! I have a standard "John's Generic App" I use to start off just about every project I begin. All the standard event handling code is there for handling menus, updates, clicks, idle time, etc... I wrote it once and it takes all of a couple hours to plug in specifics for a new project. The time is spent doing it right the first time and I believe EVERY Mac programmer should go through this exercise in order to comprhend what goes on "behind the scenes". Why? Because this basic understanding is essential if you ever want to take your applications beyond the basic elements provided by a framework. What if you need to implement some special user interface element not provided by the framework, or want to be extra nice to your users and manage updates within your windows by carefully considering how regions are validated and invalidated so as to reduce unnecessary (read, ugly) redrawing? You'll be much better equipped to produce extra functionality and refinement in your app's if you've taken the time -- once -- to build your own basic application. Toss in a liberal dose of attention to c.s.m.p, develop, Inside Mac, Tech Notes and sample code snippets, and the rest is cut'n'paste. -- John ........................................................................... John Purlia : My brain; not my company's brain. My brain says... jpurlia@qualcomm.com : Applelink AM0470 : "Newton could never live on Via de la Valle, NewtonMail: JPurlia : but it would be right at home on Cruel Lucille" +++++++++++++++++++++++++++ >From Jens Alfke Date: Tue, 26 Jul 1994 22:07:34 GMT Organization: Apple Computer Jon W!tte, h+@nada.kth.se writes: > Why wasn't that [recipe] on the a6 source CD? I said it was new! Joshua just finished writing it a few weeks ago. > No; it's the easiest objection. I could go on about what compiling > in CFront/MPW does to my productivity, but I won't :-) We've switched to CodeWarrior/PPC for our development (although scpp should still work.) Will that make you happy? ;-) Really, I hate MPW just as much as you do, if not more. > There's also this undefined thing called memory layout. What if > you want to know how much memory you have to play with for > caching issues Well, that's really an issue with any memory scheme that doesn't fit you into a predeclared partition size, i.e. almost any memory manager other than the normal Mac one. Yes, it's a slightly different world. But the user will appreciate not having to set partition sizes, esp. not for every individual document! And it would really be infeasible to know how much memory any particular document needed... Your part is free to use the Mac memory manager, by the way, as long as it allocates stuff in temp memory. > NO WAY! I think OpenDoc is a good idea, but it has to stabilize at > least SOMEWHAT, and the tools mess has to be sorted out before I > can spend time on business on it. Well, that's the difference between alpha and beta. Alpha tends to be messier and more unstable. On the other hand, if you start developing with alpha software, you have more time to learn how the stuff works and more time to write code. It's a trade-off anyone has to make. I hope you'll try out the beta release when it ships (nope, I'm not allowed to make any statements about schedule...) --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From Mark Hanrek Date: Tue, 26 Jul 1994 21:12:04 GMT Organization: The Information Workshop >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> Jens Alfke wrote: >> >> And, the OpenDoc Parts Framework will take >> care of the grungy details of scrolling for you. >> >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Jon W!tte writes: > > Any year now. > > We were expected to talk about starting commercial part development > in the June Munic kitchen, when SOM wasn't there, embedding was a > black art, CFront was the only useable tool, ... > > NO WAY! I think OpenDoc is a good idea, but it has to stabilize at > least SOMEWHAT, and the tools mess has to be sorted out before I > can spend time on business on it. > Jon, >From your point of view, it seems you feel the OpenDoc team has made some big mistakes. >From my point of view, which is simply "one other point of view", I have a high regard for the tough and appropriate choices the OpenDoc team has made. Who's perspective is the more accurate one? - --- The Answer There IS a problem here, and it has a symptom, and it has a cause. The SYMPTOM is the the inaccurate perception of something. The CAUSE is the non-regard for the way in which information is handled. - -- Pervasiveness Jon, you are not to blame for your inaccurate assessment of the OpenDoc development. You, along with all the rest of us, are not provided with the properly sequenced information needed so that we CAN form an accurate perception, or develop the skills to utilize that knowledge in an appropriate amount of time. And "OpenDoc" is no different than any other software subject. - -- A Metaphor It's almost as though all the "bits of knowledge" are just dropped into a pile in the middle of the room, and if we REALLY want to participate, it is up to us to just dive in and sort it all out. But wait! If I really want to be accurate here... ... I must add that many, if not most, of those pieces only exist for a short period of time, and disappear before you have a chance to grab 'em. But that's okay. Fresh batches of new DIFFERENT pieces are continuously dumped into that pile. To be more accurate still... ... there isn't just one pile, but there are at least 12 (at last count). Do you have access to all those piles? You could spend a week chasing a bug that was solved in one of those piles that you missed! Are we programmers, or must we be "pile-masters" as well? - -- Action Items The PROBLEM is so huge it is like an epidemic of cancer. The SOLUTION is easily attainable. We can't ignore this anymore. Mark Hanrek The Information Workshop +++++++++++++++++++++++++++ >From ross@bnr.ca (Ross Brown) Date: Wed, 27 Jul 1994 11:37:27 -0400 Organization: Bell-Northern Research In article , Mark Hanrek wrote: > Are we programmers, or must we be "pile-masters" as well? Apple's APIculture has turned us all into coder bees! ;-) -- Ross Brown Macintosh/UNIX Systems Integration Bell-Northern Research Ltd. ross@bnr.ca +++++++++++++++++++++++++++ >From Jens Alfke Date: Wed, 27 Jul 1994 21:13:03 GMT Organization: Apple Computer Mark Hanrek, hanrek@cts.com writes: > You, along with all the rest of us, are not provided with the properly > sequenced information needed so that we CAN form an accurate perception, > or develop the skills to utilize that knowledge in an appropriate amount > of time. In all seriousness I'd like to ask what we [the OpenDoc team] could do better. You have the architecture description, you have (preliminary) API documentation and recipes, you have sample code, you have hours of WWDC videos, you even have the full source code to all of OpenDoc. There is also a mailing list (OpenDoc-Interest) where one can ask questions, which usually get answered by the engineering team. Keep in mind that what you have is an _alpha_ release and is quite preliminary. The documentation isn't really there yet, but Tech Pubs is in high gear right now putting it together. The beta release will be better documented; if you find that the effort needed to understand the alpha release is not worth the benefit in early use of the software, then you can wait for the beta release. > The PROBLEM is so huge it is like an epidemic of cancer. > The SOLUTION is easily attainable. You titled this section "Action Items" but didn't provide any. If the solution is easily attainable, what is it?? Again, I'm not being sarcastic... --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world --------------------------- >From Ned Mantei Subject: What does "reentrant" mean? Date: 19 Jul 1994 10:12:51 GMT Organization: Neurobiology, ETH-Zurich In view of the recent thread on "reentrancy and the Power Mac runtime model", I would appreciate an explanation of the term "reentrant". Thanks. Ned Mantei Dept. of Neurobiology , Swiss Federal Institute of Technology CH-8093 Zurich, Switzerland +++++++++++++++++++++++++++ >From decartwr@newstand.syr.edu (Dana Cartwright 3rd) Date: 19 Jul 1994 11:22:35 GMT Organization: Syracuse University, Syracuse NY, USA Ned Mantei (mantei@neuro.biol.ethz.ch) wrote: : In view of the recent thread on "reentrancy and the Power Mac runtime : model", I would appreciate an explanation of the term "reentrant". Well, conceptually it's simple, although in practice it gets a bit more complex. "Reentrant" simply means "software which does not modify itself". But read on.... Originally, computer software was NOT reentrant. John von Neuman, inventor of the "von Neuman" computer from which all modern computers are descended, indeed thought that the essence of a computer was that it could modify its own software on the fly, that is, to be a computer meant that it *had* to have the capability of having self-modifying code. And the world bought into this notion. It took DECADES to realize that he was wrong (on this one point--he was a great man, but he slipped slighly on this point). Modern programmers who only write application software may find the concept of "reentrant" a bit puzzling; if you write in C and don't do tricky things, you automatically and painlessly get reentrant code. Ditto all other languages above assembler. But what get you in trouble are "store to memory" operations which go directly to a fixed memory location. For example, on the Mac, all those lousy low-memory globals violate re-entrancy, if you write to them. What's the point of all this? Well, reentrant software has the property that you can (a) in effect run multiple copies of the software without actually having multiple copies sitting around; all the "copies" can execute from a single master copy (since it's read-only, everyone can read from the same copy), and (b) pre-emptive multi-tasking ONLY works with reentrant code. OK, I'm tired of typing....there is much more which could be said, but that's the gist of it. +++++++++++++++++++++++++++ >From Gavin@UMich.EDU (Gavin Eadie) Date: Tue, 19 Jul 1994 10:32:44 -0400 Organization: University of Michigan In article <30gd1r$h44@newstand.syr.edu>, decartwr@newstand.syr.edu (Dana Cartwright 3rd) wrote: > Ned Mantei (mantei@neuro.biol.ethz.ch) wrote: > : In view of the recent thread on "reentrancy and the Power Mac runtime > : model", I would appreciate an explanation of the term "reentrant". > > Well, conceptually it's simple, although in practice it gets a bit more > complex. "Reentrant" simply means "software which does not modify itself". > But read on.... > Strictly speaking, this is misleading because "software which does not modify itself" is not necessarily reentrant. The word 'reentrant' is the clue - it is software which can be 'entered' again and again. Imagine, for example, a subroutine which performs some action and it is called by some application. While that subroutine is halfway done, and interrupt is taken and the interrupt processing code also calls the subroutine. For this to cause no trouble the subroutine must be reentrant. It's true that if the subroutine modified itself this would, probably, cause trouble (though self modification is possible in reentrant code if you're careful); it's also the case that if the routine modified global variables, that would cause trouble too. But the real definition is only that the routine can be entered multiple times 'simultaniously' and still perform desired actions ... Gav -- Gavin Eadie // U of Michigan Information Systems +++++++++++++++++++++++++++ >From dubois@primate.wisc.edu (Paul DuBois) Date: 19 Jul 1994 11:33:00 -0500 Organization: Castra Parvulorum >From article <30g8v3$5a7@elna.ethz.ch>, by Ned Mantei : > In view of the recent thread on "reentrancy and the Power Mac runtime > model", I would appreciate an explanation of the term "reentrant". It means you can use it twice before it crashes. -- Paul DuBois dubois@primate.wisc.edu +++++++++++++++++++++++++++ >From resnick@uiuc.edu (Pete Resnick) Date: Tue, 19 Jul 1994 15:14:10 -0500 Organization: University of Illinois at Urbana-Champaign Dana's article is almost completely wrong. In article <30gd1r$h44@newstand.syr.edu>, decartwr@newstand.syr.edu (Dana Cartwright 3rd) wrote: >Well, conceptually it's simple, although in practice it gets a bit more >complex. "Reentrant" simply means "software which does not modify itself". No, reentrant only means "able to start execution while already executing in another context". There can be self-modifying code that is reentrant, and there can be non-reentrant code that is not self modifying. The characterization that Dana presents is completely false. >Originally, computer software was NOT reentrant. John von Neuman >[...]indeed thought that the essence of a computer was that >it could modify its own software on the fly, that is, to be a computer >meant that it *had* to have the capability of having self-modifying >code. Universal Turing machines are self-modifying. I don't thing von Neuman came up with that. The key to a von Neuman machine is that *code is in memory*. >And the world bought into this notion. It took DECADES to realize >that he was wrong... No! Do you think that every program should be in ROM?? The code of a Macintosh is modified *every time* you open an application. Loading new code into memory is modifying code. This is *EXACTLY* what we want computers to do. Using pure ROM for code is completely outdated. There are certain parts of code that we often don't want modified and so take troubles to put in memory that is treated as temporarily unmodifiable, but the world has not thought any the less of von Neuman machines in this regard. >Modern programmers who only write application software may find the >concept of "reentrant" a bit puzzling; if you write in C and don't >do tricky things, you automatically and painlessly get reentrant >code. Ditto all other languages above assembler. Wrong again. Use the Time Manager on the Macintosh. Use the Device Manager with completion routines. Then go and write some results to some memory in a pointer which you allocated in your main loop. Now you are not reentrant and you haven't done anything particularly "tricky". The key to reentrancy is that you need to make sure your code can be called from somewhere else even if it is already in the middle of running. >But what get you in trouble are "store to memory" operations which >go directly to a fixed memory location. For example, on the Mac, >all those lousy low-memory globals violate re-entrancy, if you >write to them. It's not just low-memory globals. It's any constant memory location that your program has access to. >What's the point of all this? Well, reentrant software has the >property that you can (a) in effect run multiple copies of the >software without actually having multiple copies sitting around; >all the "copies" can execute from a single master copy (since >it's read-only, everyone can read from the same copy Again, being read-only doesn't make it reentrant. >(b) pre-emptive multi-tasking ONLY works with reentrant code. That's simply false. The operating system can perfectly well deal with code that is not itself reentrant in a pre-emptive multi-tasking environment. pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Doctoral Student - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet: resnick@uiuc.edu +++++++++++++++++++++++++++ >From coopem@panix.com (Marc Cooperman) Date: 20 Jul 1994 01:41:37 GMT Organization: Jumpstart Technologies, Inc. The practical definition: "re-entrant" routines can be called again and again from unforseen places in your code, at unforseen times, and they won't break, like all that other C code you've written If you program linearly (you can trace a single execution path through your code that does not double back on itself) you don't have to worry much about this if you program event driven code (like, on a Mac, you know...) that's got a million disgusting permutations to how it can run, you may have "re-entrancy" problems, although it is possible to write safe code by accident A general rule - a re-entrant procedure should operate on its own copies of data (automatic variables) wherever possible. If you must change a value passed in by reference, you probably want to lock the code, to prevent it from re-entering, before the changes are complete. Either that, or hold the caller responsible for providing memory to store results and ensuring proper calling sequence - never write to global variables within the library! +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Wed, 20 Jul 1994 16:00:47 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) decartwr@newstand.syr.edu (Dana Cartwright 3rd) writes: >Ned Mantei (mantei@neuro.biol.ethz.ch) wrote: >: In view of the recent thread on "reentrancy and the Power Mac runtime >: model", I would appreciate an explanation of the term "reentrant". >Originally, computer software was NOT reentrant. John von Neuman, >inventor of the "von Neuman" computer from which all modern computers >are descended, indeed thought that the essence of a computer was that >it could modify its own software on the fly, that is, to be a computer >meant that it *had* to have the capability of having self-modifying >code. > >And the world bought into this notion. It took DECADES to realize >that he was wrong (on this one point--he was a great man, but he >slipped slighly on this point). No, the "B-box", the first index register, was invented in Britain in the mid-50s. Before index registers, the only way to subscript an array was to store into the address part of instructions. Once index registers were invented, most of the need to modify code during execution went away. Once index registers were invented, the big remaining problem was storing subroutine return points. Using a stack fixed that one, along with providing a separate set of local variables for each invocation of a function. In C-type languages, functions that have no static variables are generally reentrant. It's sharing of resources between separate invocations of the same function that breaks reentrancy. John Nagle +++++++++++++++++++++++++++ >From Jens Alfke Date: Wed, 20 Jul 1994 19:51:52 GMT Organization: Apple Computer Ned Mantei, mantei@neuro.biol.ethz.ch writes: > In view of the recent thread on "reentrancy and the Power Mac runtime > model", I would appreciate an explanation of the term "reentrant". "Re-entrant" means a call to a subroutine that is already executing. A recursive call would be the most straightforward example. This could include indirect recursion where A calls B, B calls C, and C calls A. You can also get re-entrancy if a routine triggeredy by an interrupt calls a function that was already executing when the interrupt occurred, or if a process-switch happens while the function is executing and the next process to run also calls that function. Most of the Mac OS and Toolbox routines are not re-entrant; that is, they will not work properly when called re-entrantly. This is why you can't call Memory Manager routines from an interrupt (you might have interrupted a MM routine, so the heap structures might be in an inconsistent state.) It's also why you can't have multiple Standard File dialogs open at the same time (the Std File package uses several low-memory globals, and two instances of it would fight over those globals.) This is one of the major things that has to be fixed with the OS for the Copland and Gershwin releases. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From mem8321@u.cc.utah.edu (Mark Miller) Date: 24 Jul 1994 17:21:36 -0600 Organization: University of Utah Computer Center, Salt Lake City, Ut. In article <30gd1r$h44@newstand.syr.edu>, Dana Cartwright 3rd wrote: >Ned Mantei (mantei@neuro.biol.ethz.ch) wrote: >: In view of the recent thread on "reentrancy and the Power Mac runtime >: model", I would appreciate an explanation of the term "reentrant". > >Well, conceptually it's simple, although in practice it gets a bit more >complex. "Reentrant" simply means "software which does not modify itself". >But read on.... > For a program to be reentrant, it must satisfy one of the following three conditions: 1. Use no global variables 2. Be programmed VERY carefully to account for a small number of shared globals. 3. Be used with a linker / loader that creates a new global data segment for each instance of the program running. Allowing each instance to use its own segment either requires referencing all global variables from a register base (A5?) or having different address spaces for each instance with an MMU. Other than these conditions, and not using self-modifying code, reentrant programs may do anything else that is legal under a multitasking environment, including accessing shared system globals, as long as proper resource locking and task switching procedures are followed. - Mark. +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 25 Jul 94 17:33:19 +1200 Organization: University of Waikato, Hamilton, New Zealand In article <30gd1r$h44@newstand.syr.edu>, decartwr@newstand.syr.edu (Dana Cartwright 3rd) writes: > > Originally, computer software was NOT reentrant. John von Neuman, > inventor of the "von Neuman" computer from which all modern computers > are descended, indeed thought that the essence of a computer was that > it could modify its own software on the fly, that is, to be a computer > meant that it *had* to have the capability of having self-modifying > code. > > And the world bought into this notion. It took DECADES to realize > that he was wrong (on this one point--he was a great man, but he > slipped slighly on this point). No, he wasn't wrong. What happened is that certain people have chosen to misunderstand the essence of his idea. "Self-modifying" code conjures up visions of nasty low-level assembly hacks, and, yes, I've seen a few in my time. But a better concept is "generating code at run-time". As soon as you put it this way, you start to see that there isn't anything inherently evil about it. It's a neat technique, quite easy to use in a controlled way from a high- level language, and on the Mac in particular, it solves a whole class of very fiddly problems (passing data to callback/completion routines etc) in one stroke. Lawrence driving on the left of the Information Superhighway +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 25 Jul 94 17:47:07 +1200 Organization: University of Waikato, Hamilton, New Zealand In article <30ut20$ql@u.cc.utah.edu>, mem8321@u.cc.utah.edu (Mark Miller) writes: > > For a program to be reentrant, it must satisfy one of the following > three conditions: > > 1. Use no global variables And what, pray tell, are the CPU registers, if not global variables? > 2. Be programmed VERY carefully to account for a small number of shared > globals. Ah, you contradict point 1, which is just as well. The operative word is not "small". The operative word is "consistency". Consider the entire RAM of your machine. Consider the entire file system on your hard disk. These constitute large collections of global data, being operated on by dozens, nay, hundreds of concurrent processes running in your machine all at the same time. How do you think they avoid stuffing each other up? There are various techniques in use: * Demarcation of responsibility. Not every process needs access to every bit of data at the same time. * Interlocks for those cases where two processes _do_ need access to the same bit of data at the same time. By obeying a few carefully-chosen conventions, you can manage reentrant access to an arbitrarily large amount of shared global data. > 3. Be used with a linker / loader that creates a new global data segment > for each instance of the program running. Allowing each instance to > use its own segment either requires referencing all global variables > from a register base (A5?) or having different address spaces for each > instance with an MMU. There is an alternative approach, typified by VAX/VMS. Most code under VMS is reentrant. This particularly includes shared libraries. User programs can have any number of shared libraries linked into them, and a library can't depend on occupying the same address space in one program invocation as in another. The VAX has no base registers, like A5 on the Mac, or like I understand the PowerPC architecture has. So all that's guaranteed is that each library maps into its own contiguous section of memory space. Its code and data are adjacent to each other, so providing all intra-library references use relative addressing, things continue to work. Of course, inter-library references are a different matter. This is handled by adding a "fixup" section to the library: all code references to other libraries go indirect via the fixup section, and there is also a table of references within library data structures which need fixing up. Lawrence chuffing along the Information Railroad (if you think that's less cool than tooling along the Information Superhighway, just wait until the next level crossing). +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Tue, 26 Jul 1994 11:20:05 +0800 Organization: Department of Computer Science, The University of Western Australia In article <1994Jul25.173319.31386@waikato.ac.nz>, ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) wrote: >No, he wasn't wrong. What happened is that certain people have chosen to >misunderstand the essence of his idea. "Self-modifying" code conjures up >visions of nasty low-level assembly hacks, and, yes, I've seen a few in my >time. Hey, I've perpertrated a few "nasty low-level assembly hacks" in my time (: -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia But the nastiest one ever was the self-modifying Pascal under CP/M (: --------------------------- End of C.S.M.P. Digest **********************