mcdonald@uxe.cso.uiuc.edu (02/03/89)
>This is not in the least limited to a single program. He showed me four >programs that did this in the few minutes I was there. He has now found >several others, including an old Mac mainstay, MacWrite. >Public domain software is a special problem. Much of this is (or was, >before the Mac II) written with little regard to compatibility, and >tested only on whatever machine the author has on his desk. And for good reason. When I tried programming a MAC, it was devilishly difficult to get any good, useable info. It all looked like it was written for Pascal, and I was using Fortran. Besides, Apple clearly stated "One Mac, the same, Now And Forever". They never mentioned Multifinder or anything else. I wrote a perfectly 100% legal Fortran program that won't run on a Mac II. This has NEVER and I mean NEVER happened on any other computer in the 25 years I have been programming! A 100% (and I DO mean 100%) legal Fortran program should continue to run. Programs I wrote under VMS 1.00 run fine under 5.0. Programs I wrote under 1.1 of OS360 ran until I got sick of IBM ( :-( ). Programs under under MS-DOS 2.1 run fine under 4.01, as well as multitask under Windows 386 (they all run under regular Windows, but only the 100% Fortran or ANSI C ones multitask.) Why is the Mac different?
rang@cpsin3.cps.msu.edu (Anton Rang) (02/06/89)
In article <46100273@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > [ ... ] I wrote a perfectly 100% >legal Fortran program that won't run on a Mac II. This has NEVER >and I mean NEVER happened on any other computer in the 25 years I have >been programming! A 100% (and I DO mean 100%) legal Fortran program >should continue to run. Programs I wrote under VMS 1.00 run fine >under 5.0. [ ... ] Well, the more operating-system dependent things there are in a program, the less likely it is that it will continue to run under future versions of the OS. If you wrote a "100% legal" FORTRAN program which doesn't use any of the OS's features, it should run under any version. But if you're using system calls, well, things may eventually break. I agree that Apple (maybe) should have done a better job of keeping things compatible--but I think that MultiFinder is a *tremendous* piece of software, since nearly all existing software still works with it! Apple's mistake (well, IMHO) was letting people play with global variables and giving them access to too much of the OS's internals. The only way to maintain 100% compatibility at this point would be for Apple to create a virtual machine for programs to run under. This is a big project, but could be worth it (anybody out there working on it?). Anton (Oh, and speaking of VMS, my $GETDEV call went away in 5.0, in favor of $GETDVI. Broke my program. Of course, they warned me 5 years in advance :-). +---------------------------+------------------------+----------------------+ | Anton Rang (grad student) | "UNIX: Just Say No!" | "Do worry...be SAD!" | | Michigan State University | rang@cpswh.cps.msu.edu | | +---------------------------+------------------------+----------------------+
siegel@endor.harvard.edu (Rich Siegel) (02/06/89)
In article <46100273@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >And for good reason. When I tried programming a MAC, it was devilishly >difficult to get any good, useable info. It all looked like it >was written for Pascal, and I was using Fortran. Besides, Apple >clearly stated "One Mac, the same, Now And Forever". They never >mentioned Multifinder or anything else. I wrote a perfectly 100% >legal Fortran program that won't run on a Mac II. This has NEVER > >Why is the Mac different? Actually, what Apple says is that programs that follow the guidelines in Inside Macintosh will run correctly on current and future Macintosh architectures, which includes everything from the Mac 128 to a Mac SE/030, 128K to 8MB of RAM, Mac OS or Unix. The catch is that a program generator (compiler/linker combination, in other words) must also produce a program that follows the guidelines. If your Fortran environment, for example, masks master pointers with $00FFFFFF to clear the attributes, your program probably won't work under the next OS. If your Fortran compiler's runtime libraries assume that they're the only application on the machine (i.e. no MultiFinder) it will break now. --Rich Rich Siegel Staff Software Developer THINK Technologies Division, Symantec Corp. Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel Phone: (617) 275-4800 x305 Any opinions stated in this article do not necessarily reflect the views or policies of Symantec Corporation or its employees.
t-stephp@microsoft.UUCP (Stephen Poole) (02/06/89)
In article <46100273@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >And for good reason. When I tried programming a MAC, it was devilishly >difficult to get any good, useable info. It all looked like it >was written for Pascal, and I was using Fortran. Besides, Apple >clearly stated "One Mac, the same, Now And Forever". They never >mentioned Multifinder or anything else. I wrote a perfectly 100% >legal Fortran program that won't run on a Mac II. This has NEVER >and I mean NEVER happened on any other computer in the 25 years I have >been programming! A 100% (and I DO mean 100%) legal Fortran program >should continue to run. Programs I wrote under VMS 1.00 run fine >under 5.0. Programs I wrote under 1.1 of OS360 ran until I >got sick of IBM ( :-( ). Programs under under MS-DOS 2.1 run fine under >4.01, as well as multitask under Windows 386 (they all run under regular >Windows, but only the 100% Fortran or ANSI C ones multitask.) > >Why is the Mac different? The Mac is not as different as you think. It's ridiculous to believe that poorly written code which bypasses recommended methods of accomplishing something through OS routines is going to necessarily run under future releases of the operating system. The vast majority of Mac code which WAS properly written functions just fine on more recent machines with more recent operating system versions. It's easy to conceive of reasons why your 100% legal FORTRAN program no longer works. Possibilities include the generation of code by the compiler that was not in accordance with Apple's guidelines for compatibility with future releases, code that was self modifying and thus gets hosed because of the 68020's instruction cache, and coding on your part that utilized low-level OS functions in a manner which was not likely to keep working as the operating system evolved. Just because your program was 100% FORTRAN legal hardly means that it was 100% Macintosh OS legal. In fact, it obviously was not if it breaks on the II. The same thing can most assuredly happen under MS-DOS. Consider the different manner in which a C program receives argv[0] under DOS 2.x and DOS 3.x and 4.x. The simple reality is that MS-DOS is considerably less complex than the Macintosh operating system and has remained far more static. Despite this, don't kid yourself that there aren't a host of DOS 2.x and 3.x programs that trash completely under DOS 4.x. The bottom line, I guess, is that there are an awful lot of programmers who don't quite play by the rules and then bitch interminably when a new machine or operating system release comes out that changes something upon which their ill-behaved program relied. It seems to me that Apple has done a pretty good job of upgrading MacOS without breaking their own rules. -- -- Stephen D. Poole -- t-stephp@microsoft.UUCP -- Mac II Fanatic -- -- -- -- I'm just an Oregon Tech Software Engineering co-op at Micro- -- -- soft. Believe me, nobody here pays attention to my opinions! --
kucharsk@uts.amdahl.com (William Kucharski) (02/07/89)
In article <46100273@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > > >And for good reason. When I tried programming a MAC, it was devilishly >difficult to get any good, useable info. It all looked like it >was written for Pascal, and I was using Fortran. Besides, Apple >clearly stated "One Mac, the same, Now And Forever". They never >mentioned Multifinder or anything else. I wrote a perfectly 100% >legal Fortran program that won't run on a Mac II. This has NEVER >and I mean NEVER happened on any other computer in the 25 years I have >been programming! A 100% (and I DO mean 100%) legal Fortran program >should continue to run... (Various comments about old programs still running deleted) It could be that the compiler you used to create said program WASN'T producing 100% legal Macintosh code. Basically, I've found that if you try as much as possible to play by the rules of the games (read: treat Inside Macintosh as a bible) the rules won't be changed from under you (or at least _too_ badly :-) ). Of course, your mileage may vary. -- William Kucharski ARPA: kucharsk@uts.amdahl.com UUCP: ...!{ames,decwrl,sun,uunet}!amdahl!kucharsk Disclaimer: The opinions expressed above are my own, and may not agree with those of any other sentient being, not to mention those of my employer. So there.
lsr@Apple.COM (Larry Rosenstein) (02/08/89)
In article <00hRU1eOR21010a14Eo@amdahl.uts.amdahl.com> kucharsk@amdahl.uts.amdahl.com (William Kucharski) writes: >producing 100% legal Macintosh code. Basically, I've found that if you >try as much as possible to play by the rules of the games (read: treat >Inside Macintosh as a bible) the rules won't be changed from under you (or at >least _too_ badly :-) ). In my experience, it also depends on how cautious the developer is. It is virtually impossible for us to write down all the things you shouldn't do. A good example is with the styled TextEdit. A few program broke when that came out because we added a handle to the TEHandle. Some programs were creating TEHandles by cloning an existing one instead of calling TENew. This caused problems because the new handle was shared between TEHandles. There was no explicit rule against doing this (although you could argue that this was a case of manipulating data structures directly). This is an example where the programmer should think about what s/he is doing. Bypassing the TENew call, should have raised a red flag, even if you couldn't think of an explicit reason why it might be a bad idea. Whenever you try to do something a bit out of the ordinary, that's the time to think about how it might fail in the future. -- 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
kucharsk@uts.amdahl.com (William Kucharski) (02/08/89)
In article <560@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >In article <00hRU1eOR21010a14Eo@amdahl.uts.amdahl.com> kucharsk@amdahl.uts.amdahl.com (William Kucharski) writes: > >>producing 100% legal Macintosh code. Basically, I've found that if you >>try as much as possible to play by the rules of the games (read: treat >>Inside Macintosh as a bible) the rules won't be changed from under you (or at >>least _too_ badly :-) ). > >In my experience, it also depends on how cautious the developer is. It is >virtually impossible for us to write down all the things you shouldn't do. > (Example concerning styled TextEdit deleted) Oh, by no stretch of the imagination did I mean to be flaming Inside Macintosh (seriously!). I agree that the majority of programs that "blow up" when moving to a new Macintosh design or new System do so because of the programmer's not thinking about the consequences of his/her actions. I've just found that it's a lot easier to think through such consequences when you _do_ take Inside Mac as gospel. While I agree that you can't possibly document everything a programmer _shouldn't_ do, if you follow Inside Mac you will have a far easier time than if you take a "Apple be damned" attitude towards things. Sorry for any confusion my earlier posting may have caused... -- William Kucharski ARPA: kucharsk@uts.amdahl.com UUCP: ...!{ames,decwrl,sun,uunet}!amdahl!kucharsk Disclaimer: The opinions expressed above are my own, and may not agree with those of any other sentient being, not to mention those of my employer. So there.