Xref: utzoo comp.sys.mac.programmer:5494 comp.sys.mac:29780 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!hc!lll-winken!uunet!brunix!omh From: omh@brunix (Owen M. Hartnett) Newsgroups: comp.sys.mac.programmer,comp.sys.mac Subject: Re: Need some MF help Keywords: MultiFinder Message-ID: <3668@brunix.UUCP> Date: 9 Apr 89 03:32:35 GMT References: <1562@neoucom.UUCP> <28399@apple.Apple.COM> <3637@brunix.UUCP> <28638@apple.Apple.COM> Sender: news@brunix.UUCP Reply-To: omh@zaphod.UUCP (Owen M. Hartnett) Organization: Brown University Department of Computer Science Lines: 110 In article <28638@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >In article <3637@brunix.UUCP> omh@zaphod.UUCP (Owen M. Hartnett) writes: >>In article <28399@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >> >>>If you do have a valid reason for needing to know if MultiFinder is running, >>>please let me know! So far it's been a battle, with developers saying "We need >>>to know!" and Apple saying "No you don't!". Finding a legitimate reason for >>>knowing would put an end to this contest. >>> >> >>Why does there have to be a reason? Why not just put up a flag in Sysenvirons? >>Apple DTS always seems to have the attitude that it knows best what >>developers should know about (or rather, not know about). > >From one point of view, DTS *DOES* know best what developers should know >about. We know what is coming down in the future. We know what changes are >being made to the System Software. Based on this knowledge, we try our best to >prevent developers from burning themselves. We try to quide them down the road >of Future Compatibility. That's our job. So when we make position statements >like this, it is with these reasons in mind. Believe me, it's NOT because our >egos are too large to even consider that developers have brains of their own. >If they were that large, I wouldn't be asking the question that I did. > I don't mean to imply that your egos are too large - I'm saying that you've reserved a *lot* of areas as "stuff you shouldn't know." Witness the entire Printing Manager. I know your motives are pure, but we both can see what the result of this is: If there is a need to know something, Programmers will implement a hack. Just look at the responses to this posting that appeared previously, there were several methods to find out if MF is running, some good, some bad, all verboten and tenuous. And... if there's a legitimate feature that should be implemented, then somebody like Microsoft will implement it (i.e. printing closer to the page margins than the LaserWriter driver allows) and then you'll have to support it because you won't want to break a MS product which has sold millions. Now if Ashton-Tate or Informix uses another method, then there's another method to deal with. Meanwhile, smaller developers without the time or resources to invent such hacks have to leave them out of their programs, while the big software houses are being, albeit grudgingly, subsidized by Apple. What I'm saying is that we should have more information available to us. Please consider the plight of the software developer who obeyed all the rules, but by doing so was forced to leave out features which his larger competitors were able to use. Don't get me wrong here - I know the work that went into writing Inside Mac and the technotes - which was tremendous. It's just that things which will enable valuable features are often sacrificed to future compatibility. >> ... There may be >>developers out there with legitimate need to know - to fix bugs, to implement >>a novel feature, or for reasons yet unknown. > >Could you expand on this? > > - "To fix bugs": What bugs need to be fixed that require the knowledge > that MultiFinder is running? You've already pointed out the sublaunching problem. Were I to attempt sublaunching without reading the previous articles and relying on the printed material, I'd be in Dire Straits. > - "To implement a novel feature": What kind of features? I would like > to know about them. So far, most features that developers want > to implement revolve around questions like "Are there icons > on the desktop?", or "How do I safely sublaunch?", or "Am I > able to unmount an MFS disk", NOT "Is MultiFinder active?" Suppose someone wanted to know if a file was in the trash? Why, because it's a configuration file, and if it exists, then rewrite the file, but if it doesn't, create a new one. Under MF, the file could be in the unemptied trash, but there's no reliable way to tell. > - "For reasons yet unknown": Until those reasons DO become known, there > is no reason for checking for MultiFinder. I can't see a > developer saying "Gee, let's check for MultiFinder. I don't > know why, but it might come in handy in the future." > Just looking at the responses here shows that a number of programmers have already implemented ways to effect this. Maybe they've just written this code for the fun of it, but I know I only write code when I have a need for it. And there are some *excellent* programmers on this net. Besides, does DTS feel that confident that any particular application *won't* have a need? And if a legitimate need does crop up, will the developer get a stone wall at DTS? [comments about misusing documentation deleted to make inews happy] >As a major computer company, Apple has to be responsible about the kinds of >information it gives out. We cannot in good conscience give out information to >developers that they can use to hang themselves. This is Tech Support's >current stance. Do you disagree with it? Do you think that DTS should supply >the rope? If we did, do you think that the customers who constantly have to put >up with broken software could ever forgive us? > Believe it or not, I do appreciate your concerns. But rather than giving up ropes that we can use to hang ourselves, we'd really love to see some ladders to save ourselves with: Apple-approved methods of solving problems that won't break in the future. (I know, I'm asking for a lot! But you guys invented that great computer and now we're all spoiled!) Owen Hartnett Brown University Computer Science omh@cs.brown.edu.CSNET