Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!hyc From: hyc@math.lsa.umich.edu (Howard Chu) Newsgroups: comp.os.misc Subject: Re: Re: terminology (Macintosh OS (was: 68000 and Workstations.)) Message-ID: <1990Jun17.135522.21278@math.lsa.umich.edu> Date: 17 Jun 90 13:55:22 GMT References: <6480@amelia.nas.nasa.gov> <880002@iftccu.ca.boeing.com> Sender: usenet@math.lsa.umich.edu Organization: University of Michigan Math Dept., Ann Arbor Lines: 141 In article <880002@iftccu.ca.boeing.com> bressler@iftccu.ca.boeing.com (Rick Bressler) writes: > >> And what you call "freedom of choice" is not free--it not only takes >>user's money but pain. Mac OS is free for all Mac users. How much does >>Window cost? And Presentation Manager? You can buy a decent Plus for the >>price of Presentation Manager and I'd rather choose a Mac Plus. Cycle for cycle, an Atari ST is faster than a Mac Plus. > >I maintain that there is a price here. The price is portability. If >every computer in the world ran the MAC OS I'd agree with you. I don't >think that this is likely to happen. It seems that you are arguing for >standard API's and if that is the case, I couldn't agree with you more. If Digital Research had been a little more agile, GEM might have made it big-time. Even as things are today, it's pretty simple to port GEM applications between the 68000-based ST and an 8086-based PC. >I remember reading a review a while ago about a set of libraries >available for the PC that when linked with MAC applications written in >C, would run on a PC with virtually the same look and feel of the >original application on the MAC. (Sorry I can't remember the source, >damaged short term memory I guess :-) I don't know from personal >experience how well this package actually works, but in principle it >should be possible to run just about any operating system/application >look-alike on most any hardware platform. ( I'm not saying I'd >necessarily like the *challenge* of doing this myself :-) I remember seeing something similar to this, but I don't remeber the details either. It *was* a pretty long time ago... There was another company marketing a library that would allow you to write C code on any system, using their library functions, which would automatically invoke analogous functions in the target machines "native" graphics library. I.e., it was targeted for SunView, X, MS-Windows, and Mac Toolbox. I don't remember seeing much come of this, either. (But it *did* seem like a great, reasonable idea...) > >The main point here is that this provides at least one dividing line >between operating system and application. Obviously the PC at this >point is not running the Mac operating system, but it certainly is >running a MAC application. True, the interface is not supplied with the >PC but then the MAC supplies only it's own API flavor as well. The >point is that the operating system portion is not portable, the API is. Good Point. >part you don't care about is the OS. Admittedly under this definition >the MAC still bundles together an OS and an API, but as in the PC >example above, the OS and the API *can* still treated separately. It >could even be done on the MAC, admittedly with a major re-structuring of >its current 'OS'. Indeed. An OS should be powerful and flexible enough that you can pair it up with whatever user interface you want, and that interface will run with tolerable responsiveness. On the Mac, the interface is nearly inseparable from the OS. On the PC, well... Anyway. The Atari ST comes with GEM in the OS ROM, so it resembles the Mac's level of OS/API integration. But you can completely forsake the graphical interface if you want, and just run CLI style, or you can run a CLI in a window. It's flexible, and it's snappy. (Unlike Windows on a PC, where you need at least a 25MHz 386 for tolerable performance...) > >Certainly you can run PC applications on the MAC but only with the >purchase of hardware that in effect converts the MAC to a pc :-). You can run PC and Mac applications on the ST. With a switcher utility you can alternate between any environment, at will. I can set up my Mega-4 with 1Meg of memory devoted to a software PC emulator, 1Meg to Mac emulation, 1Meg to native Atari TOS, and 1Meg for Minix or anything else I can load up. Can't run all 4 simultaneously, but it gets the job done. Especially since all of 'em can operate off the same disk drives. > >> And too much freedom in such fundamentals as OS gives nothing but >>pain--and interface is such a precious fundamental that I think it should >>be integrated in OS--it's like car's cockpit. Imagine you gas pedal is on >>the left and you drive with joystick, not Steering wheel. I always have >>trouble driving in Japan but the only difference there is left and right. >>GUI is even more chaotic but the one of the Mac is not only the most confort- >>able but also consistent. Consistency counts more than freedom in case of >>interface. Huh? Too much freedom in the OS gives nothing but pain? So you'd rather be running something like Apple DOS, I take it. Well, if that's how you feel, you're welcome to it... The Mac GUI is hardly the most comfortable, nor is it even self-consistent. But of course, it's suddenly become obvious that this argument is between two distinct classes of computer users. You obviously see a computer as a simple appliance, and want to use it as such. In your eyes it is the functional equivalent of a toaster oven. A little more flexible than a toaster, but it's got well-defined functions and limits to its functionality. You have a clear understanding of its functions, and are happy to use it within those limits. The other class of computer users think of computers as general-purpose devices. Flexibility is a pre-requisite here. One typically is looking for new and interesting ways to use a computer. In effect, exploring just how generally the device may be applied. With a GUI cast in concrete as the Mac's is, you're basically being handed a machine with a manual that says "Instructions for use: ..." with cookbook style, step-by-step sequences to do such & such task. This is all well and good, for doing such & such task, but leaves no room for imagining how to do something that isn't described in the Instructions. In the case of the Mac, the OS fights you every step of the way whenever you try to do something New and Interesting that the Mac designers didn't account for. The Mac is inherently a limited machine; it can only do things according to the step-by-step instructions handed to you from the designers. A flexible system doesn't prevent you from encoding and using step-by-step cookbook preocedures, and also allows you to design your own procedures whenever you want. It's easy to get a GUI running on a Unix system, that will still be able to run all preexisting Unix applications. It's tough to do the reverse on a Mac... (And on the Atari ST, it's all there already...) >> Plus also don't forget to note you can customize Mac with INITs and >>CDEVs, also absent from Windows, OS/2, Unix, et al. You don't need CDEVs or INITs for Unix. The equivalent is called a TSR in DOS and Atari TOS. Note that you can also completely replace the standard GEM desktop on the ST, as well as customizing various parts of it. I suppose such things as the Mini-Finder on the Mac can be considered replacement desktops, but the Mini-Finder is too limited for use as a general purpose interface to an operating system. > >> I agree. Then why only Apple include GUI as standard interface still? >>Xwindow is not standard OS. Windows and OS/2 is more like application than >>OS in a sense you have to buy it separately. IBM/Clone is not Windows >>but Mac is indeed Mac by itself and system GEM is standard on the Atari ST. > >I think each manufacturer is going to bundle their API with their own >hardware. The key question is how many *other* API's are available for >a given hardware platform. Well, in the Unix world, the X library is standardized. The interface that's presented to the user will probably depend on the vendor's whims, but you won't have to rewrite an X application to work with someone else's interface. This is definitely the best way to go, for maximum flexibility. -- -- Howard Chu @ University of Michigan ... the glass is always greener on the side ...