Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!apple!Apple.COM!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Need some MF help
Message-ID: <1227@internal.Apple.COM>
Date: 6 Apr 89 21:14:40 GMT
Sender: usenet@Apple.COM
Distribution: na
Organization: Objects-R-Us,  Apple Computer, Inc.
Lines: 59
References:<1562@neoucom.UUCP> <28399@apple.Apple.COM> <43464@XAIT.Xerox.COM>

In article <43464@XAIT.Xerox.COM> dee@XAIT.Xerox.COM (Donald Eastlake) 
writes:

> The way I try to guess if MultiFinder is running is by checking for the
> temporary memory assignment traps.  

This is probably the best technique known to man.  (Sounds better when you
phrase it that way. :-)  Anything that looks at heap 
addresses, where resources get loaded, etc. is probably likely to break.

> dynamicly generate windows in my application with stepped locations and
> I don't want to cover the volume, etc., Icons that MF likes to put down
> the right edge of the screen.  I also have a "cover sheet" feature to

As people pointed out, this is not needed with the latest MultiFinder that 
includes Set Aside.  It is easy for the user to get into the Finder and 
set aside all the other application.  Given that I could set aside 
applications, I would want applications to create windows using whatever 
the best width is.

Checking for MultiFinder is not the right thing to do in any case.  What 
you want to know is whether there are things on the desktop.  A future 
version of MultiFinder might provide a way to access the desktop, and then 
you have this extra code in your program that isn't necessary, your users 
have to widen their windows manually, etc.

Conversely, A/UX may support the Finder one day, so checking for 
MultiFinder won't fork in that case.

> I suspect that 90%+ of large real applications and a significant
> proportion of smaller programs check for MF one way or the other.  Many

I doubt that.  The only arguments I've see concern the Launch trap (which 
few programs use) and your arguement about covering icons.  I doubt that 
many programs worry about covering icons.

> While I am sending this message, I'd like to put in my vote for a couple
> of new traps:
>         TrapExist ( trapnumber ) or the like would do the obvious thing

The code to do this is relatively easy, but you're right it should be put 
into a library.  The problem with making it a trap is that how do you test 
whether that trap exists?  If the glue code does this, then you might as 
well put the full code for TrapExist in there as well.

>         ApplicationTrap ( ... ); this trap would be guaranteed to never
> be used by Apple but the application would have license to patch it. 

What would you do with this?  The only thing it seems good for is to allow 
2-byte subroutine calls in an application, which would be much slower than 
the usual calls.  This might have been a good idea for the 128K Mac, but 
today I can't imagine that you would save enough RAM space to make the 
performance hit worthwhile.

Larry Rosenstein, Apple Computer, Inc.
Object Specialist

Internet: lsr@Apple.com   UUCP: {nsc, sun}!apple!lsr
AppleLink: Rosenstein1