leonardr@uxe.cso.uiuc.edu (06/20/88)
thecloud@pnet06.cts.com(Ken McLeod) writes in comp.sys.mac.programmer > 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? > Well..I was just thinking and this is has not been tested but there is not reason why it shouldn't work (for now!)...You could always try to open a file in the System Folder (using the SysVRefNum returned from SysEnvirons) called 'MultiFinder' This will work with current versions, but I would DOUBT that it will work with future systems in which the Finder and MultiFinder are one and the same. But I was just waxing programmatiic. I personally test for the existance of the memory calls as they are only (currently) available when MF is running. Apple has made it clear (and you should have heard the screaming about it at MacHack '88) that there is NO OFFICIAL WAY to test for MF existance. +---------------------------------+-----------------------------------+ + + Any thing I say may be taken as + + Leonard Rosenthol + fact, then again you might decide+ + President, LazerWare, inc. + that it really isn't, so you + + + never know, do you?? + + leonardr@uxe.cso.uiuc.edu + + + GEnie: MACgician + + + Delphi: MACgician + + + + + +---------------------------------+-----------------------------------+