sam@neoucom.UUCP (Scott A. Mason) (04/04/89)
Hello,
Just a few quick and hopefully not too difficult questions for the
Mac gurus out there.
Firstly, what is the standard way of checking for MultiFinder
existence?
Lastly, what is the standard way of keeping track of the windows,
so that it can be redrawn or updated after a MF switch?
(I hate it when upon returning from the Finder in MF, I find my
window has been erased by all the folders)
Thanks for the info.
--
--------------------------------------------------------------------------------
"If it ain't broke, don't fix it," and certainly don't blame me.
UUCP: {pitt, scooter, hal, cwjcc}!neoucom!sam INTERNET: sam@neoucom.UUCP
Scott A. Mason, Coordinator of Systems Operations, NEOUCOMkeith@Apple.COM (Keith Rollin) (04/05/89)
In article <1562@neoucom.UUCP> sam@neoucom.UUCP (Scott A. Mason) writes: > >Firstly, what is the standard way of checking for MultiFinder >existence? There currently is no way to determine if MultiFinder is running, but that's mostly because we haven't seen a need for this. In DTS, we've found that almost all of the people who ask this questions really want to find out if WaitNextEvent or the MFMemory calls are implemented. In those cases, there are documented methods for finding this out. Just check out Technotes #158, 177, 180, and 205 (the answer's in one of them). 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. So far, there is only one valid reason that I know about, and this will be resolved with a future release of the System Disk. It revolves around sub- launching and whether or not you need to save open documents and configura- tions. If you have a reason other than this, again, please let me know! >Lastly, what is the standard way of keeping track of the windows, >so that it can be redrawn or updated after a MF switch? >(I hate it when upon returning from the Finder in MF, I find my > window has been erased by all the folders) This shouldn't be happening. If the Finder is obscuring your windows, and your application is brought to front, you will get an update event (as long as your event mask allows them). ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
oster@dewey.soe.berkeley.edu (David Phillip Oster) (04/05/89)
In article <1562@neoucom.UUCP> sam@neoucom.UUCP (Scott A. Mason) writes: >Firstly, what is the standard way of checking for MultiFinder >existence? The standard, from Apple is "Don't even try to do this". Most people do it by checking to see if the end of the system heap is close to the beginning of the application heap. If it is, no multifinder. >Lastly, what is the standard way of keeping track of the windows, >so that it can be redrawn or updated after a MF switch? You've missed the fundamental point of Mac (or X for that matter) programming. Mac programs work by associating a data structure with a window. During the course of the program, it mutates the data structure. There is a "Draw()" function in the program, that can prowl the data structure, drawing as it goes. Call this in response to an Update event, or if you wish to print, call it with the a grafport from the Printer Manager. The specific data structure is what is appropriate for _your_ program. Some programs use an offscreen GrafPort, which they mutate by standard draw commands, but most use higher level data structures than just the raw pixels. (Thus allowing zooming, panning, or other alternate views of the same data.) "Draw()" defines a function from the internal data structures to screen graphics. Many programs define the inverse of this function "Pick()" which lets the user select an object on the screen with the mouse.
dee@XAIT.Xerox.COM (Donald Eastlake) (04/07/89)
In article <28399@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >In article <1562@neoucom.UUCP> sam@neoucom.UUCP (Scott A. Mason) writes: >>Firstly, what is the standard way of checking for MultiFinder >>existence? >There currently is no way to determine if MultiFinder is running, but that's >mostly because we haven't seen a need for this. ... >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. The way I try to guess if MultiFinder is running is by checking for the temporary memory assignment traps. The reason I want to know is that I 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 cover all of my windows after some period of user inactivity. For convenience I also contrain it from the right edge under MultiFinder. I suspect that 90%+ of large real applications and a significant proportion of smaller programs check for MF one way or the other. Many of them may not need to but quite a few have arguably good reasons to do so. By refusing to authorize a way to do this, Apple is guaranteeing problems for these applications in the future. In fact, if the goal of Apple is to make it easy to generate programs that will be compatible into the future an authorized way to meet a purely psychological need to know if MF is present seems reasonable to me. Sometimes you should assume the customer is right even if you think you know better. It has always been easy to find out if Switcher is present and I don't know of that every causing any particular problems. 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 with get trap addresses and the guaranteed undefined trap returning a Boolean. Why make everyone do it the hard way? And glue could check the ROM version... ApplicationTrap ( ... ); this trap would be guaranteed to never be used by Apple but the application would have license to patch it. Sort of like ApplScratch but in the trap number space. -- +1 617-969-9570 Donald E. Eastlake, III ARPA: dee@XAIT.Xerox.COM usenet: {cbosg,decvax,linus}!cca!dee P. O. Box N, MIT Branch P. O., Cambridge, MA 02139-0903 USA
svc@well.UUCP (Leonard Rosenthol) (04/07/89)
In article <1562@neoucom.UUCP>, sam@neoucom.UUCP (Scott A. Mason) writes: > > Firstly, what is the standard way of checking for MultiFinder > existence? I think I will take the Apple party line on this one - YOU CAN'T! You should not have any need to detect that MF is running. If you need a particular 'feature' of MF like WNE or the MF Mem routines, then simply test for them and if they exist you can use them - but that does NOT imply that MF is running. {I still think Apple should add a isMFRunning field to the SysEnvRec} > Lastly, what is the standard way of keeping track of the windows, > so that it can be redrawn or updated after a MF switch? > (I hate it when upon returning from the Finder in MF, I find my > window has been erased by all the folders) Seems to me that if you have the proper bits sets in the SIZE resource to tell the O.S. that you are MF friendly/aware and that your application handles Update/Activate events properly you should have no problems... -- +--------------------------------------------------+ Leonard Rosenthol | GEnie : MACgician Lazerware, inc. | MacNet: MACgician UUCP: svc@well.UUCP | ALink : D0025
lsr@Apple.COM (Larry Rosenstein) (04/07/89)
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
lsr@Apple.COM (Larry Rosenstein) (04/07/89)
In article <1227@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: > This is probably the best technique known to man. (Sounds better when you As soon as re-read this message I realized I made a mistake. I should have said "the best technique known to man or woman". :-) Sorry. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
dee@XAIT.Xerox.COM (Donald Eastlake) (04/08/89)
In article <1227@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >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. ... >> 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. ... What is this Set Aside feature and is it really easier than just being able to click on the icons?? >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. I suppose but users want convenient software RIGHT NOW and I am not going to make my product inferior because of edicts from the thought police. Even when wonderful new MultiFinders do come out, there will be enclaves of people running the old version for YEARS. These users would otherwise get to manually narrow their windows etc. I started out ignoring Switcher. Too bad my first Beta test site uses it on most of their Macs. I quickly got my program to tolerate Switcher at least although I only do background stuff under MultiFinder. >> 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. Well, if people are supposed to do various things re MultiFinder because there will be a hypothecial new MF/System sometime in the future, why not put this in because, taking the same point of view, real soon now all MACs will have the nifty AD 1990 ROM with this built in and the glue code will be trivial to non-existent. -- +1 617-969-9570 Donald E. Eastlake, III ARPA: dee@XAIT.Xerox.COM usenet: {cbosg,decvax,linus}!cca!dee AppleLink: D2002 Box N, MIT Branch PO, Cambridge, MA 02139 USA
lsr@Apple.COM (Larry Rosenstein) (04/08/89)
In article <43549@XAIT.Xerox.COM> dee@XAIT.Xerox.COM (Donald Eastlake) writes: >What is this Set Aside feature and is it really easier than just being able >to click on the icons?? The lastest MultiFinder adds a Set Aside item to the Apple menu. Slecting this hides all the applications and grays out the application icon in the Apple menu. Holding down the Option key changes the item to Set Aside Others. If you do this in the Finder, then you will have access to all the Finder icons (subject to where Finder windows are). There are other power-user features, but that's the basic idea. Set Aside gives the user a way to click on the icons, even if an application's window happens to be covering them, although it requires 1 extra step. >I suppose but users want convenient software RIGHT NOW and I am not going >to make my product inferior because of edicts from the thought police. As always, the price you pay for now listening to the "thought police" is a risk that your program won't work as you might desire on future systems. If you are willing to take that risk and/or provide "unexpected" updates to your program then you should go ahead and add the feature. One of Tech Support's jobs is to warn developers of upcoming changes. Often they cannot talk about the exact new feature that's coming, and can only warn not to do something right now. It is usually worthwhile to listen to what they say, and decide if you want to ignore the warning. Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
tim@hoptoad.uucp (Tim Maroney) (04/08/89)
In article <28586@apple.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >The lastest MultiFinder adds a Set Aside item to the Apple menu. Slecting >this hides all the applications and grays out the application icon in the >Apple menu. Holding down the Option key changes the item to Set Aside >Others. If you do this in the Finder, then you will have access to all the >Finder icons (subject to where Finder windows are). There are other >power-user features, but that's the basic idea. > >Set Aside gives the user a way to click on the icons, even if an >application's window happens to be covering them, although it requires 1 >extra step. Provided, that is, that you're a power user and someone has explained the feature to you. The term "Set Aside" in the menu is meaningless without an explanation, but it suggests that you shouldn't use it unless you know how to "Bring Back". Most users of computers are not power users and are afraid to try things that they can't figure out beforehand, even if it's less scary-sounding than "Set Aside". Sorry, Larry, but this is not a solution. The only real solution on the table is to modify the Finder so that it conforms to the Macintosh User Interface Guidelines. You would think Apple would *want* to do this instead of applying a half-baked patch to the problem. The word on the street is that the Finder code is godawfully bad and no one can understand it well enough to make major changes. If that's the real reason Apple isn't willing to bring the Finder into line with other applications, then it is well within the resources of Apple to rewrite the Finder from scratch. But please, spare us these lame-o power-user-only pseudo-solutions. I can't think of anything less Mac-like. >As always, the price you pay for not listening to the "thought police" is a >risk that your program won't work as you might desire on future systems. The price of being in the "thought police" is that people expect you to police your own thoughts as well. Otherwise you risk them thinking you are a hypocrite. (Not you in particular, Larry, but Apple in general seems to have a policy of preaching but never practicing.) -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Our newest idol, the Superman, celebrating the death of godhead, may be younger than the hills; but he is as old as the shepherds." - Shaw, "On Diabolonian Ethics"
omh@brunix (Owen M. Hartnett) (04/08/89)
In article <28399@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >In article <1562@neoucom.UUCP> sam@neoucom.UUCP (Scott A. Mason) writes: >> >>Firstly, what is the standard way of checking for MultiFinder >>existence? > [comments deleted] >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). There may be developers out there with legitimate need to know - to fix bugs, to implement a novel feature, or for reasons yet unknown. If the information is available, and properly documented that there should be no reasons for using it (that we are currently aware of), then the programmer will know he has to take the responsibility for using it. True, some developers will misuse it, but then it's their problem. Apple should endeavor to make as much information available as possible, and let us developers write some "insanely great" applications with it. -Owen Owen Hartnett Brown University Computer Science omh@cs.brown.edu.CSNET
keith@Apple.COM (Keith Rollin) (04/09/89)
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. > ... 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? - "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?" - "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." >If the information is available, and properly documented that there >should be no reasons for using it (that we are currently aware of), then >the programmer will know he has to take the responsibility for using it. > >True, some developers will misuse it, but then it's their problem. Apple >should endeavor to make as much information available as possible, and let >us developers write some "insanely great" applications with it. It's not just the developer's problem. It's Apple's problem and it's the customer's problem. If a developer writes a program that misuses information, the customer loses out when their program breaks when they upgrade to the next version of System Software. And Apple loses out because we get blamed for breaking that software. The customer doesn't know what is going on behind the scenes; all they know is that their Macintosh doesn't work, and that Apple makes Macintoshes. You should read our Customer mail! We've already seen the misuse of MultiFinder information happen. When System 6.0 came out, WaitNextEvent was implemented all of the time. Many applications subsequently failed to work properly. This was despite warnings about this in Technotes. 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? > >Owen Hartnett >Brown University Computer Science > ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
dee@XAIT.Xerox.COM (Donald Eastlake) (04/09/89)
In article <28586@apple.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >As always, the price you pay for now listening to the "thought police" is a >risk that your program won't work as you might desire on future systems. If >you are willing to take that risk and/or provide "unexpected" updates to >your program then you should go ahead and add the feature. I suppose that following the rules decreases the probability of unexpected updates but history shows that conscienctiously following all the rules is no guarantee of avoiding them. >One of Tech Support's jobs is to warn developers of upcoming changes. Often >they cannot talk about the exact new feature that's coming, and can only >warn not to do something right now. It is usually worthwhile to listen to >what they say, and decide if you want to ignore the warning. Checking a cross reference for my program, I find yet a third place where I check for "MultiFinder". My program is security oriented and one of its features is to clear out a Mac as much as possible including parameter RAM and memory. Unfortunately, under MultiFinder low memory lies and you have to do a special call to find out about physical memory limits (unless you want to poke around yourself which seems really hairy with all the different flavors of memory mapping/folding on different Macs). (By the way, my program dispatches on the processor type to do things to clear different processor internal registers so it may need an update for the 68040, etc., anyway.) To summarize, if I were to follow Apple's advice and not test for MultiFinder, user would find my program obscuring icons by putting windows over the right side of the screen, they would get confusing error message saying they could not eject a volume because it was busy when they try various operations on an MFS disk (for some things my program unmounts the disk and then remounts it), and my program would be unable to achieve one of its operational requirements because it could not clear memory. The advice not to check for MultiFinder but rather to check for specific capabilities is excellent. Too bad its inapplicable because no way was provided to check for a number of said capabilities. -- +1 617-969-9570 Donald E. Eastlake, III ARPA: dee@XAIT.Xerox.COM usenet: {cbosg,decvax,linus}!cca!dee AppleLink: D2002 Box N, MIT Branch PO, Cambridge, MA 02139 USA
omh@brunix (Owen M. Hartnett) (04/09/89)
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
dudek@ai.toronto.edu (Gregory Dudek) (04/10/89)
In article <3637@brunix.UUCP> omh@zaphod.UUCP (Owen M. Hartnett) writes: > >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). There may be >developers out there with legitimate need to know - to fix bugs, to implement >a novel feature, or for reasons yet unknown. > >If the information is available, and properly documented that there >should be no reasons for using it (that we are currently aware of), then >the programmer will know he has to take the responsibility for using it. > >True, some developers will misuse it, but then it's their problem. It's not true that it's merely "their problem" is some (commercial) developers write bad software. For any machine, it success or failure is, to a large extent, determined by the commercial software that exists for it. This is particularly true for the Mac. As we all know, the consistency of the 3rd party software has being a major factor in its success. If apple expects to make all or many of MF's features standard aspects of the OS itself, it would be just asking for trouble by encouraging people to build MF-dependent applications. If you are simply asking for short-term solutions that will cease to work very soon, then just test for the temporary memory allocation calls or something like that. 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
sbb@esquire.UUCP (Stephen B. Baumgarten) (04/11/89)
In article <28638@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: > - "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?" Here's a useful feature not currently supported by the System: it's nice to be able to shrink down or partially hide your windows when you're not frontmost. Versaterm is a good example of a program that does this. It lets the user decide whether or not to shrink its main window, and if so, what size it should be and where on the screen it should be located. In some ways, this is even better than having the application zoom down to an icon; since the window is still visible, you can always watch what's going on, even when the application is in the background. Of course, if you have a 19" monitor this isn't so much of a problem, but most Mac users don't and must suffer with overly cluttered 9" screens. I understand what you guys in DTS are saying, but it seems to me that the world is full of budding Microsoft's (i.e., people and companies who do what they want, regardless of the "official" line), and if you don't provide a legal way to do something, saying "don't do this" won't prevent it from being done. I think you have to look at the end result, which currently is that people are doing all sorts of terrible (by DTS standards) things to check for the existence of Multifinder. Give them a "legal" way to do it and you have at least a small chance that things won't all break with the next System release. -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." cmcl2!esquire!sbb | esquire!sbb@cmcl2.nyu.edu | - David Letterman
alibaba@ucscb.UCSC.EDU (Alexander M. Rosenberg) (04/11/89)
>> 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 What if one wanted an app to talk to code preloaded by an INIT, hmm? Can you say cheap IPC? I thought you could. ------------------------------------------------------------------------------- - Alexander M. Rosenberg - INTERNET: alibaba@ucscb.ucsc.edu - Yoyodyne - - Crown College, UCSC - UUCP:...!ucbvax!ucscc!ucscb!alibaba- Propulsion - - Santa Cruz, CA 95064 - BITNET:alibaba%ucscb@ucscc.BITNET - Systems - - (408) 426-8869 - Disclaimer: Nobody is my employer - :-) - - - so nobody cares what I say. - -
dee@XAIT.Xerox.COM (Donald Eastlake) (04/11/89)
In article <28638@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >In article <3637@brunix.UUCP> omh@zaphod.UUCP (Owen M. Hartnett) writes: >>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. ... I don't have any problem with guidelines. I don't even have problems with guidelines that Apple software breaks. It is fine for DTS to want some motivating informatin before they release some info and to release it with caveats. But that is not really what is going on with MultiFinder. What we have is a deliberate attempt to make it impossible for the developer to find out if MultiFinder is running. You can find out the version number of the System File, you can find out the version number of the Finder, you can find out the version number of AppleTalk, your hardware processor, whether you have a floating point coprocessor, etc., etc., etc. Of course programs should not lightly be made dependent on such things. But with all of these myriad other version dependencies available, it is just absurd that such an attitutde of deliberate conceilment has deveoped for MultiFinder. You can easily check for Switcher and I don't notice it causing the world to fall apart. I have not done much with AUX so I don't know if there is any easy way to check for it, but there should be. SysEnvirons should return the MultiFinder version number and/or a multi-tasking field with perhaps various values for none (0), Switcher active (1), MutliFinder active (2), and maybe other values for AUX or future systems. >We've already seen the misuse of MultiFinder information happen. When System >6.0 came out, WaitNextEvent was implemented all of the time. Many applications >subsequently failed to work properly. This was despite warnings about this in >Technotes. This WAS NOT the misuse of MultiFinder information. If Apple were not wedged on this subject and had provided some approved method of checking for MultiFinder, such as a version number in SysEnvirons, 90% + of these problems would probably not have occured. >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? The above is ABSOLUTE BULLSHIT. There is already so many cubic miles of rope available in the Macintosh system to hang oneself that it does not bear talking about. Can you name any significant facility of the Mac that CANNOT be used to hang oneself??? This insane quest for perfect safety, which I can not realy believe is DTS policy, is the recipie for absolute paralysis. The Mac prospered as an open and flexible system. I guess it is reasonable, as things grow up, for the release of internals details to get a bit more closed. But the wedged conceilment of the presence of MultiFinder is way at the other end of the spectrum, totally un Mac-like, and really quite sad. -- +1 617-969-9570 Donald E. Eastlake, III ARPA: dee@XAIT.Xerox.COM usenet: {cbosg,decvax,linus}!cca!dee AppleLink: D2002 Box N, MIT Branch PO, Cambridge, MA 02139 USA
tim@hoptoad.uucp (Tim Maroney) (04/11/89)
In article <6849@saturn.ucsc.edu> alibaba@ucscb.UCSC.EDU (Alexander M. Rosenberg) writes: >>> ApplicationTrap ( ... ); this trap would be guaranteed to never >>> be used by Apple but the application would have license to patch it. > >What if one wanted an app to talk to code preloaded by an INIT, hmm? > >Can you say cheap IPC? I thought you could. Wouldn't work under MultiFinder, or under UniFinder if more than one INIT wanted to use this mechanism. There are a variety of other tricks you can use; one that's recommedned by Apple (or used to be) is to allocate a locked block in the System Heap containing some trademarked string, then the address of a rendezvous point; you can then search for the string from the bottom of the system heap and find the rendezvous point that way. There are also a variety of almost-guaranteed appraoches you can do with trap patches. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "When errors are found in old research, the relevant theories are re-examined. When facts contradict theory, theory gets dumped. Is that why the NLP people are unwilling to research their facts?" -- Jerry Hollombe on sci.psychology
austing@Apple.COM (Glenn L. Austin) (04/12/89)
In article <6849@saturn.ucsc.edu> alibaba@ucscb.UCSC.EDU (Alexander M. Rosenberg) writes: >What if one wanted an app to talk to code preloaded by an INIT, hmm? What I did to implement a control key on the Mac Plus was to provide additional functionality to the existing calls. In other words: (in C) if ((eventMask == 0) && ((theEvent & 0xF8000000) == 0xF8000000) /* do my code */ else /* standard event call */ This allowed me to take an "illegal call" and make it a "call to my function" Note that I don't condone this, it just was convenient for my application (converting the command key to a control key). ----------------------------------------------------------------------------- | Glenn L. Austin | The nice thing about standards is that | | Apple Computer, Inc. | there are so many of them to choose from. | | Internet: austing@apple.com | -Andrew S. Tanenbaum | ----------------------------------------------------------------------------- | All opinions stated above are mine -- who else would want them? | -----------------------------------------------------------------------------
mnkonar@smallberries.SRC.Honeywell.COM (Murat N. Konar) (04/12/89)
All this stuff about being able to tell whether MF is running
or not may soon be moot. I seem to recall that eventually,
there will be no UniFinder and that MultiFinder will always
be running. Any one at DTS care to comment? (Unofficially,
of course. :) )
____________________________________________________________________
Have a day. :^|
Murat N. Konar Honeywell Systems & Research Center, Camden, MN
mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)snow@dinl.uucp (john snow) (04/12/89)
I don't know if my problem qualifies as a good reason for knowing if multifinder is running, but it sure annoys me. I am developing a communications program which allows users to carry on conversations over the appletalk network. The origional version was written for the finder so the node had to lock itself out of the net anytime the user opened a DA. The new version is written for multifinder so now it can function in the background while the user does something else, **if it's running under multifinder**. So what should I do with this application? Use one of the unapproved methods and take my chances on it breaking later; write two versions, one for use under finder and one for multifinder; not write a program that takes advantage of the multifinder capabilities; or should I use an Apple approved method for determining the presence of multifinder so my program will work forever more??? Just wondering. John Snow
austing@Apple.COM (Glenn L. Austin) (04/13/89)
In article <992@dinl.mmc.UUCP> snow@dinl.uucp (john snow) writes: >I don't know if my problem qualifies as a good reason for knowing >if multifinder is running, but it sure annoys me. I am developing >a communications program which allows users to carry on conversations >over the appletalk network. The origional version was written for >the finder so the node had to lock itself out of the net anytime the >user opened a DA. The new version is written for multifinder so now >it can function in the background while the user does something else, >**if it's running under multifinder**. So what should I do with this >application? If you specify System 6.0 or later (preferably 6.0.2 or later), you can simply write it to use the MF WaitNextEvent call instead of GetNextEvent. Also, why lock the program out of the net when a DA is open? You still had control of events in your program when a DA was opened. If you removed this limitation to the program, you wouldn't have to worry about MF running or not. Just make sure your program can handle suspend and resume events, can run in the background (very easy -- just set the "can background" bit and be prepared for null events), and your program will work under both finder and MF. ----------------------------------------------------------------------------- | Glenn L. Austin | The nice thing about standards is that | | Apple Computer, Inc. | there are so many of them to choose from. | | Internet: austing@apple.com | -Andrew S. Tanenbaum | ----------------------------------------------------------------------------- | All opinions stated above are mine -- who else would want them? | -----------------------------------------------------------------------------
urlichs@smurf.ira.uka.de (Matthias Urlichs) (04/14/89)
In comp.sys.mac.programmer sbb@esquire.UUCP (Stephen B. Baumgarten) writes:
<
< Here's a useful feature not currently supported by the System: it's
< nice to be able to shrink down or partially hide your windows when
< you're not frontmost.
<
< Versaterm is a good example of a program that does this. [...]
.MILD FLAME ON
Ever heard about "Suspend-Resume events" ???
.MILD FLAME OFF
< I understand what you guys in DTS are saying, but it seems to me that
< the world is full of budding Microsoft's (i.e., people and companies
< who do what they want, regardless of the "official" line), and if you
< don't provide a legal way to do something, saying "don't do this"
< won't prevent it from being done. I think you have to look at the end
< result, which currently is that people are doing all sorts of terrible
< (by DTS standards) things to check for the existence of Multifinder.
< Give them a "legal" way to do it and you have at least a small chance
< that things won't all break with the next System release.
<
Well, but what if the next System release doesn't distinguish at all whether
MF is running or not?
The fact(s) that the Notification Manager will completely stop the foreground
application, or that I only have to copy a few more PD programs onto my
hard disk to get the most spectacular crash (if not running under Desktop
Manager), are more pressing problems than putting in a feature no one
has any legitimate use for.
The above is strictly my personal opinion!
BTW, yes I know about the problem with _Launch, but that will be adressed
shortly (or so I hope). And yes, I know that you want to leave space for
the Finder's icons when zooming out and if MF is running, but having a
check box in your preferences is the better way to do it. So there.
--
Matthias Urlichs -- Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- FRG
urlichs@smurf.ira.uka.de -- ++49+721-621127@PTTstores@unix.SRI.COM (Matt Mora) (04/28/89)
In article <20319@srcsip.UUCP> mnkonar@src.honeywell.com (Murat N. Konar) writes: > >All this stuff about being able to tell whether MF is running >or not may soon be moot. I seem to recall that eventually, ^^^^ Are you sure that its moot and not moof :-) -- ___________________________________________________________ Matthew Mora SRI International stores@SRI.COM ___________________________________________________________