thecloud@pnet06.cts.com (Ken Mcleod) (06/14/88)
Well, after looking more closely, I discovered the reason why various
cdev's were breaking under System 6.0: they check for the presence of
certain packages in the System file (usually PACK 7 or PACK 4) that
no longer exist! (except in the ROM). Even Apple's Sample cdev in IM V
does this (although there's a brief disclaimer that you "really should"
check for the packages in ROM). Ouch.
Then there's the MultiFinder test. Most sample source code I've seen
(actually, ALL) checks for MultiFinder's presence by testing to see
whether the WaitNextEvent trap is implemented. Now, in System 6.0,
it's implemented ALL THE TIME, whether you're in MF or not. So if
application X assumes it's running under MultiFinder when it isn't,
well, look out.
Question: how do you detect MultiFinder's presence or absence under 6.0?
Ken McLeod ========================= ....... ======================
UUCP: {crash uunet}!pnet06!thecloud :. .: Chief Weapons of UNIX:
ARPA: crash!pnet06!thecloud@nosc.mil :::.. ..::: "Fear, surprise, and
INET: thecloud@pnet06.cts.com //// ruthless efficiency."dan@Apple.COM (Dan Allen) (06/16/88)
In article <227@hodge.UUCP> thecloud@pnet06.cts.com (Ken Mcleod) writes: > > Well, after looking more closely, I discovered the reason why various >cdev's were breaking under System 6.0: they check for the presence of >certain packages in the System file (usually PACK 7 or PACK 4) that >no longer exist! (except in the ROM). Even Apple's Sample cdev in IM V Actually PACKs 4 (SANE arithmetic), 5 (SANE transcendentals), and 7 (binary-decimal conversions) are in all ROMs since the MacPlus. They are ALSO in every system file Apple has ever shipped. No shipping system files do NOT have PACKs 4,5, and 7, although they could be removed if apps didn't check. In certain cases the System versions of the PACKs may have bug fixes, but unless there are ROV# resources to override the ROM PACKs, the ROMed versions are used. Dan Allen Software Explorer Apple Computer
korn@eris.berkeley.edu (Peter "Arrgh" Korn) (06/18/88)
In <227@hodge.UUCP>, thecloud@pnet06.cts.com (Ken Mcleod) said: >... > Question: how do you detect MultiFinder's presence or absence under 6.0? You don't. You can check for the presence or absence of the WNE() call. You can also check for the presence or abscence of the "temporary memory allocation" calls that mark both MultiFinder 1.0 & 6.0. If these calls will be there, and in the same form in MultiFinders > 6.0 is a matter that only a few people in Apple have the answers too, and I wouldn't even bet on that (as it's awfully hard to predict what will happen in the future when so very much is changing). Apple has given sample code (in tech note #158) that demonstrates how to check for the above two things. They also have said (in that same tech note) that one shouldn't check specifically for the presence of MultiFinder, but rather only specific features that it offers (or has offered in 1.0 & 6.0). Actually, if you will limit yourself to a 1.0/6.0 ONLY test (which was your initial question), testing for temporary memory calls will work. But nothings guaranteed beyond 6.0. Perhaps Apple will address this (for issues such as 'document launching' and such) in some way... Honestly though, I really don't see it as such an issue; if the service isn't available you simply don't use it (specific checks for specific services). Peter -- Peter "Arrgh" Korn korn@ucbvax.Berkeley.EDU {decvax,dual,hplabs,sdcsvax,ulysses}!ucbvax!korn
eacj@batcomputer.tn.cornell.edu (Julian Vrieslander) (06/19/88)
>> Question: how do you detect MultiFinder's presence or absence under 6.0? >You don't. You can check for the presence or absence of the WNE() call. I think someone said in a previous note that WNE is always available in 6.0, even when MultiFinder is not running. I don't know if this is so, since I have not gotten my copy of the 6.0 stuff yet. But I wonder... what happens if this is so, and you test for WNE, find it's implemented, and use it in your event loop, and MultiFinder is NOT running? In other words, is it safe to use WNE under "UniFinder?" -- Julian Vrieslander (607)255-3594 Neurobiology & Behavior, W250 Mudd Hall, Cornell University, Ithaca NY 14853 UUCP: {cmcl2,decvax,rochester,uw-beaver,ihnp4}!cornell!batcomputer!eacj INTERNET: eacj@tcgould.tn.cornell.edu BITNET: eacj@CRNLTHRY
thecloud@pnet06.cts.com (Ken Mcleod) (06/19/88)
I appreciate ALL information, even if it's prefaced with "you shouldn't
do it, it may/might/will break, but..."
For the combination of System 6.0 and MultiFinder 6.0, checking the
MFDispatch trap ($A88F) against the unimplemented trap WORKS. Thanks, Rich.
I'm writing a utility that diplays a 'system configuration' dialog, not
unlike the Finder's About box. It looks pretty foolish if I display a
"MultiFinder Active" string when in fact only WaitNextEvent is "active".
For that matter, it looks foolish to display "Total Memory: 192K" or
whatever value I (used to be able to) derive from MemTop. I realize MF
is doing its best to hide "the rest of the machine" from me, but the
Finder is somehow privileged with this information; what am I missing?
Question #2: How do I determine the TOTAL amount of RAM installed, under MF?
Ken McLeod ========================= ....... ======================
UUCP: {crash uunet}!pnet06!thecloud :. .: Chief Weapons of UNIX:
ARPA: crash!pnet06!thecloud@nosc.mil :::.. ..::: "Fear, surprise, and
INET: thecloud@pnet06.cts.com //// ruthless efficiency."goldman@Apple.COM (Phil Goldman) (06/20/88)
In article <232@hodge.UUCP> thecloud@pnet06.cts.com (Ken Mcleod) writes: > Question #2: How do I determine the TOTAL amount of RAM installed, under MF? There is a temporary memory call, _MFTopMem, that gives the actual value of _TopMem under MultiFinder. Although the service always existed, the glue was not made public in the first release of the MultiFinder developer's package -- it will be available in new releases. The glue is something like: #define OSDISPATCH 0xA88F #define mfTopMemSel 22 #define MFTopMem() \ cMFTopMem(mfTopMemSel) pascal Size cMFTopMem(SW) short SW; extern OSDISPATCH; but this is *not* official. If you plan to use the glue, please use the version put out through APDA. -Phil Goldman Apple Computer
lsr@Apple.COM (Larry Rosenstein) (06/21/88)
In article <227@hodge.UUCP> thecloud@pnet06.cts.com (Ken Mcleod) writes: > > Then there's the MultiFinder test. Most sample source code I've seen >(actually, ALL) checks for MultiFinder's presence by testing to see >whether the WaitNextEvent trap is implemented. Now, in System 6.0, >it's implemented ALL THE TIME, whether you're in MF or not. So if >application X assumes it's running under MultiFinder when it isn't, >well, look out. You must not have looked at the sample code in the Tech Notes. The Tech Notes on MultiFinder have been very clear that you cannot test for the existence of MultiFinder by looking for the WaitNextEvent trap. As you discovered, WaitNextEvent is always installed under System 6.0. > Question: how do you detect MultiFinder's presence or absence under 6.0? The question is what about MultiFinder do you want to know. Apple does not want people writing code that depends on MultiFinder being present or absent, since future systems might migrate some MultiFinder features into a non-MultiFinder environment (as with WaitNextEvent). So far, it is only possible to test for 2 particular MultiFinder-related services: WaitNextEvent and temporary memory allocation. I have heard from people who want to know whether or not the Launch trap can return to the caller. That is a valid request, and I believe Tech Support is looking into a solution. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 27-AJ Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
lsr@Apple.COM (Larry Rosenstein) (06/21/88)
In article <5212@batcomputer.tn.cornell.edu> eacj@tcgould.tn.cornell.edu (Julian Vrieslander) writes: > >your event loop, and MultiFinder is NOT running? In other words, is it >safe to use WNE under "UniFinder?" Under System 6.0, WaitNextEvent is always implemented. It works exactly the same way whether or not MultiFinder is running. The sleep and mouseRgn parameters are used in either case. While sleeping, the system will call SystemTask for you to feed CPU time to DAs and drivers. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 27-AJ Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
fry@huma1.HARVARD.EDU (David Fry) (06/21/88)
In article <12523@apple.Apple.COM> lsr@apple.apple.com.UUCP (Larry Rosenstein) writes: > >> Question: how do you detect MultiFinder's presence or absence under 6.0? > >The question is what about MultiFinder do you want to know. Apple does not >want people writing code that depends on MultiFinder being present or >absent, since future systems might migrate some MultiFinder features into a >non-MultiFinder environment (as with WaitNextEvent). > What do I do when I want a certain lengthy process to be done in the background, so the user can switch to another applicaition if he wants, but I want to check for the existence of MultiFinder before wasting the extra CPU time catching events (so I know if he switched out) and calling WNE while in the background? As for now, I'll just have to do it all the time. David Fry fry@huma1.harvard.EDU Department of Mathematics fry@huma1.bitnet Harvard University ...!harvard!huma1!fry Cambridge, MA 02138
adail@pnet06.cts.com (Alan Dail) (06/22/88)
A reason to check for multifinder that should (but isn't) be supported by
Apple is to so that zoomed windows don't cover up the finder icons. Since
the system doesn't automatically adjust the zoomUp size when multifinder is
running, it would be nict to have app/das adjust it only when multifinder is
running. It is a pain to have to resize all windows to get ad the HD and
trash.
Alan Dail
UUCP: {crash uunet}!pnet06!adail
ARPA: crash!pnet06!adail@nosc.mil
INET: adail@pnet06.cts.comlsr@Apple.COM (Larry Rosenstein) (06/24/88)
In article <236@hodge.UUCP> adail@pnet06.cts.com (Alan Dail) writes: >A reason to check for multifinder that should (but isn't) be supported by >Apple is to so that zoomed windows don't cover up the finder icons. Since This was mentioned at the MacHack conference. The response was that Apple doesn't want applications to have code that is tied to the way the current Finder works. Having the applications responsible for not covering up the Finder's icons incorrectly puts the burden on the application, and inconveniences the user if the window ends up too narrow. The burden should be on the system to provide a way to access icons on the desktop, and I think there are people considering this problem already. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 27-AJ Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
dudek@csri.toronto.edu (Gregory Dudek) (06/24/88)
In article <4798@husc6.harvard.edu> fry@huma1.UUCP (David Fry) writes: >In article <12523@apple.Apple.COM> lsr@apple.apple.com.UUCP (Larry Rosenstein) writes: >> >>> Question: how do you detect MultiFinder's presence or absence under 6.0? >> >>Apple does not >>want people writing code that depends on MultiFinder being present or >>absent > >What do I do when I want a certain lengthy process to be done in >the background, so the user can switch to another applicaition >if he wants, but I want to check for the existence of >MultiFinder before wasting the extra CPU time catching events >(so I know if he switched out) and calling WNE while in >the background? As for now, I'll just have to do it all the >time. > If you do a lengthy computation without checking periodically for events, you may cause a variety of problems for DAs & spoolers even if MF isn't running. If it takes *that* long to check for events, then maybe you're looking too often. Greg Dudek -- Dept. of Computer Science (vision group) University of Toronto Reasonable mailers: dudek@ai.toronto.edu Other UUCP: {uunet,decvax,linus,pyramid, dalcs,watmath,garfield,ubc-vision,calgary}!utai!dudek ARPA: user%ai.toronto.edu@relay.cs.net
DN5@PSUVM.BITNET (D. Jay Newman) (07/01/88)
Actually, I was glad when they made WaitNextEvent a standard system trap, but
I wish they had made many of the other multi-finder calls available. The
most important (from my point of view) is the temporary memory allocation
calls. Under unifinder, they would just revert to standard memory allocation,
but under multifinder, they would grab from wherever multifinder gets them
from (system heap?).
I feel that WaitNextEvent and the temp memory calls are the most important
calls available, and I shouldn't have to write large sections of code twice,
depending on which finder I am running under.
Another thing, I would like to see the Color Quickdraw code patched for the
Plus/SE machines, so that the color calls would revert to the basic b/w calls.
This can't be too hard, can it? Again, why write twice the code so that the
user can have optional color (I thought that the Mac Interface Guidelines
tried to let the user have as much information and convinience as possible,
and I interpret that to mean that if color can be useful, and color is
available, give him color--if color isn't available, then use b/w). Apple
seams to be making this hard right now. Maybe later, when we all have
68020 machines, with color monitors, then this won't matter, but for now...
Jay, etc...
ps.
I LIKE black and white!tecot@apple.UUCP (07/13/88)
In article <46753DN5@PSUVM> DN5@PSUVM.BITNET (D. Jay Newman) writes: >I feel that WaitNextEvent and the temp memory calls are the most important >calls available, and I shouldn't have to write large sections of code twice, >depending on which finder I am running under. I'd like to correct a misconception. You are either running under MultiFinder OR the classic single-tasking OS. The Finder is an APPLICATION, just like MacWrite. >Another thing, I would like to see the Color Quickdraw code patched for the >Plus/SE machines, so that the color calls would revert to the basic b/w calls. >This can't be too hard, can it? Again, why write twice the code so that the >user can have optional color (I thought that the Mac Interface Guidelines >tried to let the user have as much information and convinience as possible, >and I interpret that to mean that if color can be useful, and color is >available, give him color--if color isn't available, then use b/w). Apple >seams to be making this hard right now. Maybe later, when we all have >68020 machines, with color monitors, then this won't matter, but for now... The reason this isn't done is because it would cost over 4K of system heap space. _emt
sbb@esquire.UUCP (Stephen B. Baumgarten) (07/13/88)
>In article <46753DN5@PSUVM> DN5@PSUVM.BITNET (D. Jay Newman) writes: >>Another thing, I would like to see the Color Quickdraw code patched for the >>Plus/SE machines, so that the color calls would revert to the basic b/w calls. >>This can't be too hard, can it? Again, why write twice the code so that the >>user can have optional color (I thought that the Mac Interface Guidelines >>tried to let the user have as much information and convinience as possible, >>and I interpret that to mean that if color can be useful, and color is >>available, give him color--if color isn't available, then use b/w). Apple >>seams to be making this hard right now. Maybe later, when we all have >>68020 machines, with color monitors, then this won't matter, but for now... > >The reason this isn't done is because it would cost over 4K of system heap >space. > > _emt 4k? Is this a typo or have you guys totally lost it? By not backpatching, each application that wants to support both color and b/w has dozens of duplicated calls, making programming difficult and applications grow in size. The code for handling color is always going to have to be there; why force applications to carry around the extra baggage of code that will never get used on a Plus/SE (or vice versa)? -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." {uunet,cmcl2}!esquire!sbb | - David Letterman
tecot@Apple.COM (Ed Tecot) (07/17/88)
In article <480@esquire.UUCP> sbb@esquire.UUCP (Stephen B. Baumgarten) writes: >In article <13829@apple.Apple.COM> Ed Tecot writes: >>The reason this isn't done is because it would cost over 4K of system heap >>space. > >4k? Is this a typo or have you guys totally lost it? By not backpatching, >each application that wants to support both color and b/w has dozens of >duplicated calls, making programming difficult and applications grow in >size. The code for handling color is always going to have to be there; >why force applications to carry around the extra baggage of code that will >never get used on a Plus/SE (or vice versa)? Actually it IS a typo. I should have written: ONE reason this isn't done is because it would cost OVER 14K of system heap space. 4K is simply what is required to build the extended trap dispatch table required for Color Quickdraw. In addition, there is all the conversion of data structures (pixMap cGrafPort, gDevice, etc.) and parameters so they can be passed to the equivalent b/w routines. There are 211 routines and vectors in CQD. If each routine requires 40 bytes of glue on average, that is almost 8K more. Add in the additional data structures and globals that would have to be added so that these calls would make sense (cWmgrPort, etc.) and you've exceeded 14K. And we haven't even discussed making glue for the Palette Manager and the color portion of the Menu Manager (which would have to be done as well). And not to mention a few months of an engineers time for code which does effectively nothing! For comparison, the new styled TextEdit weighs in at less than 10K, the Notification Manager is 3K, the Sound Manager <4K. I remember not too long ago, when people were complaining that HyperCard and MultiFinder won't fit in 1 Meg and that system heap space was being gobbled up at an alarming rate. What happened? _emt
tecot@Apple.COM (Ed Tecot) (07/17/88)
In article <14108@apple.Apple.COM> I wrote: >ONE reason this isn't done is because it would cost OVER 14K of system heap >space. I forgot to add that such a change might not even work! By necessity, the trap table would have to be moved to a completely new location. The addition of these traps would make the Mac Plus and SE look much more like a II. Some applications that don't run on a II now would most likely fail with such a change. I can see it now: "System 7.0 sucks because so-and-so crashes". Is such a change worth the loss of these applications? I'd be inclined to bet that most of you would say yes. I'd also bet that the other million-and-a-half (my guess) Mac users would say no. Who would you support? _emt
dudek@ai.toronto.edu (Gregory Dudek) (07/22/88)
In article <14108@apple.Apple.COM> tecot@apple.apple.com.UUCP (Ed Tecot) writes: >Add in the additional data structures and globals that >would have to be added so that these calls would make sense (cWmgrPort, etc.) >and you've exceeded 14K. And we haven't even discussed making glue for the >Palette Manager and the color portion of the Menu Manager (which would have >to be done as well). And not to mention a few months of an engineers time >for code which does effectively nothing! Effectively nothing!!! I can hardly believe I read this! As it stands now, the efforts of that lost software engineer will be multiplied many times over by the piles of effort expended by anybody who tried to make their application run on both the Mac II in color and older Macs. Furthermore, applications will be larger & harder to maintain and Mac II applications without Mac SE/+ compatibility may even appear. A (possibly optional) 14K and a few months of time seems a very small price to pay to avoid this chaos and loss of consistency. > >For comparison, the new styled TextEdit weighs in at less than 10K, the >Notification Manager is 3K, the Sound Manager <4K. > Great! Spend 10K on some minor texedit features (although I like 'em) or 4K (plus the sounds space) for some cutsie sounds, but "economize" on the 14K that would prevent a major system incompatibility from occurring! Gregory Dudek -- Dept. of Computer Science (vision group) University of Toronto Nice mailers: dudek@ai.utoronto.ca UUCP: {uunet,decvax,linus,pyramid, dalcs,watmath,garfield,ubc-vision,calgary}!utai!dudek ARPA: user%ai.toronto.edu@relay.cs.net