eugene@wilbur.nas.nasa.gov (Eugene N. Miya) (06/04/90)
Ah, it's good to know that on all levels of CS there is inconsistency
(Re: program versus procedure, I mean I know how I would answer this).
Just last week Dave Patterson (you know RISCs) was for consistency in computer
architecture teaching [ideas]. The wonders of the Tower of Babble.
I'm glad I got out of the IBM-biased world. It makes things oh so much
more confusing. 8)
--e. nobuo miya, NASA Ames Research Center, eugene@orville.nas.nasa.gov
{uunet,mailrus,other gateways}!ames!eugene
Time to leavebressler@iftccu.ca.boeing.com (Rick Bressler) (06/07/90)
> 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. 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. 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 :-) 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. How about this for a partial working definition: When you create an application the part you worry about is the API, the 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'. 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 :-). > 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. Ah. What are the fundamentals? I suspect that as long as we have multiple computer manufacturers this will be a problem. That is why I favor better dividing lines between OS and API. Why be stuck with a BMW when a Fararri comes along. If for the sake of argument I allow that the MAC GUI is currently the best user interface, do you really believe that all advances will stop here? If the user interfaces are separate applications, it will always be possible to develop an API to new and old operating systems, and preserve old code. Indeed the vendors will be compelled to support the popular API's when they bring out new hardware and OS software. > Plus also don't forget to note you can customize Mac with INITs and >CDEVs, also absent from Windows, OS/2, Unix, et al. Well you can do this under DOS too, and to a far less extent under Windows / OS2. I wonder, is IBM/MICROSOFT moving backwards? While I personally enjoy playing with such versatility, It doesn't seem consistent with what I perceive as a call on your part for standards. > 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 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. Rick.
ac08@vaxb.acs.unt.edu (06/07/90)
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. > > 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. A lot of the portability is being taken care of by the people who write and rewrite compilers... a well-written C program ought to run on most any machine (if the dialect of C is consistent across platforms). Once you have the base code laid out, it's just interface.... :) (Yes, I know that's a gross oversimplification, but I have seen some stuff that runs on *anything* with a good compiler...) > > 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 :-) > You might be able to get it to *run*, but as far as looking like Mac apps, I wouldn't bet on it... Let's just say this must have been either a dream or deceptive advertising. The PC just doesn't have the right stuff built into it's ROMs to get away with this... you can see how improbable this is by looking at Windows 3.0, then comparing it to a Mac Plus... unless you have a *very* fast 286 or a nice 386 with a lot of memory, it looks like a kludgy Mac on Valium... not to mention that you're still riding on top of MS-DOS. > > > 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 :-). > Sorry. Not true. SoftPC (to name one) lets you run MS-DOS apps on an unmodified Mac... with the right setup, you might be able to run A/UX, Mac applications, and MS-DOS applications... all at the same time... with memory protection under A/UX... [other subjects deleted] > > Ah. What are the fundamentals? I suspect that as long as we have > multiple computer manufacturers this will be a problem. That is why I > favor better dividing lines between OS and API. That's why I prefer blurring them even more! Sooner or later, we might get away from the whole distinction/division of "OS" and "Applications." When you buy a new program, the OS would just reach out and merge the features of that application with the body of the operating system... ;) There are some systems that do this right now, but not in a fully integrated fashion. Could be fun. >>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 > > 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. > > Rick. The answer to "Why only Apple..." is that the other folks want to *sell* their add-ons... :) So far, the majority of add-on interfaces (Windows, X-Windows, etc) are cosmetic changes slapped over a text-oriented machine to make it look like a Mac. Once people discover just how little improvement there is, they get this "Graphical OS sucks" attitude... ;) The Amiga OS looks like it has promise, but the graphical side of it is *not* in the Mac league- and that's due to the lack of consistency. Give them another generation or two, and who knows...? C Irby ac08@vaxb.acs.unt.edu ac08@untvax
bressler@iftccu.ca.boeing.com (Rick Bressler) (06/09/90)
[some stuff deleted] >> 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. > >A lot of the portability is being taken care of by the people who write and >rewrite compilers... a well-written C program ought to run on most any >machine (if the dialect of C is consistent across platforms). >Once you have the base code laid out, it's just interface.... :) >(Yes, I know that's a gross oversimplification, but I have seen some stuff >that runs on *anything* with a good compiler...) > I don't want this to degenerate into a discussion of Apple vs World, although I fear there may be some overtones of this. I am using this as an example only, there are many others. The original thread related to the dividing line between OS and application. My intent here was to provide one possible view. In this particular case above, I think we are talking about a *different* kind of portability. I'm sure that code written for the MAC will compile with *many* compilers. (C should be and slowly is becoming standardized :-). Linking and executing is another matter altogether, because so many of the functions called by MAC applications are built into the OS (in ROM even) rather than in *portable* libraries. > >> >> 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... the [ some of my comments deleted ] > >You might be able to get it to *run*, but as far as looking like Mac apps, >I wouldn't bet on it... > > >Let's just say this must have been either a dream or deceptive advertising. >The PC just doesn't have the right stuff built into it's ROMs to get away >with this... you can see how improbable this is by looking at Windows 3.0, >then comparing it to a Mac Plus... unless you have a *very* fast 286 or a nice >386 with a lot of memory, it looks like a kludgy Mac on Valium... not to >mention that you're still riding on top of MS-DOS. > >> I don't know that there are any magical properties of Apple hardware. It makes no difference if static code is loaded into RAM or ROM. I'm sure that if these libraries do indeed perform as advertised, they emulate much of the MAC ROM. If you will agree that code that jumps to hard ROM locations is ill behaved, the physical location of the code shouldn't be an issue. In fact, I'd rather have this code in RAM. In general RAM is faster and I can do my upgrades with a disk rather than a screw driver. I think Apples intent in putting their OS and API in ROM was to cut down on piracy and enforce a proprietary architecture. That idea is failing and I believe Apple is realizing it. Witness the opening up of the MAC architecture. It seems to me that given the same screen resolutions (this might require a specialized monochrome board and a really tiny monochrome monitor in some cases :-) you should be able to duplicate exactly any particular program or OS you cared to put the effort into. I worked on an IBM PC 370 for a time. While a PC based box, it was *object* compatible with IBM mainframe 370's. (There was additional hardware in the box) without getting into the merits (or demerits :-) of working in IBM land, it was interesting that IBM didn't even sell compilers for this box. You were supposed to download the compiler object modules from your mainframe! (for a license fee of course :-(). >> >> 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 :-). >> > >Sorry. Not true. SoftPC (to name one) lets you run MS-DOS apps on an >unmodified Mac... with the right setup, you might be able to run A/UX, Mac >applications, and MS-DOS applications... all at the same time... with memory >protection under A/UX... > This is good to know. If I ever wind up with a MAC project, I'll be sure to find the command line interface you mentioned. That is indeed a step in the right direction. I wonder how long it will be before somebody feels a need to do the reverse with the MAC (or has it already happened?) It is interesting to note that lots of systems now emulate DOS. You can run it under many *NIX systems, the MAC and I expect others. Wonder why more systems aren't running the MAC applications? Is it because there is no demand? Is it because that until recently the MAC was a very closed architecture and as such was too difficult to duplicate? Is it because the operating system is so intermixed with the API that it is difficult to separate? However limited the architecture, I believe DOS has owed some of its success to its portability and sharply defined line between OS and application. Again, I don't feel that hardware has *anything* to do with it. I maintain that given equivalent display hardware you ought to be able write an application that would run identically on just about any hardware platform. > >> >> Ah. What are the fundamentals? I suspect that as long as we have >> multiple computer manufacturers this will be a problem. That is why I >> favor better dividing lines between OS and API. > >That's why I prefer blurring them even more! >Sooner or later, we might get away from the whole distinction/division of >"OS" and "Applications." When you buy a new program, the OS would just >reach out and merge the features of that application with the body of the >operating system... ;) >There are some systems that do this right now, but not in a fully integrated >fashion. Could be fun. Sounds like you're figuring that all user environments will be the same in the future and that there will be only one computer manufacturer. Perhaps you don't ever want your code to run on any platform but your MAC. I would prefer the MAC API to be available on *many* different hardware platforms so that as well as simply compiling, MAC applications will link and run! While we're at it, lets go ahead and support some of the *other* popular API's. If the support for all these different API's has to be built into all operating systems, there won't be much room left for applications until large disks get *much* cheaper. (The MAC probably has an advantage here as it can handle more disk drives) I don't know how much room the MAC OS takes up (much of it is in ROM, and I'm not sure I like that) but I have heard that OS/2 for example requires 5-10MB of disk space. (It also is up to around 1.5M lines of code??!!) If everybody gave you everything you'd run out of space in a hurry. In the near term I would support the purchaser being given a choice at purchase time of which API they would like supplied with the system. Then, if they want to run multiple API's, they could be purchased separately. From the user level, I agree with you. The user shouldn't have to worry about the difference. Users should be able to pick the API they like and run it under *any* OS. As developers and hardware designers, we need to be aware of these issues. (Or have things changed *that* much in the last 15 years since I've been in school). [stuff deleted] > >The answer to "Why only Apple..." is that the other folks want to *sell* >their add-ons... :) > >So far, the majority of add-on interfaces (Windows, X-Windows, etc) are >cosmetic changes slapped over a text-oriented machine to make it look like >a Mac. Once people discover just how little improvement there is, they get >this "Graphical OS sucks" attitude... ;) > Well, the Amiga is sort of a text based system slapped over a graphical machine. (Like the MAC, text operations are emulated in graphics and are *slow* compared to a *real* text based display. :-) Obviously, With improvements in graphics hardware this does not have to be the case, but we aren't there yet. I guess that my point here is that APPLE *is* like all the rest. It gives you *only* its GUI, not *everything* as I understood you to say. When is Apple going to supply X-WINDOWS (or name your favorite non- Apple interface :-) so that those applications can run on an Apple platform without the added cost of porting them to the Apple GUI? (My original idea here was the cost of porting between various OS's and API's right?) When are they going to give away a command line environment? (Why you ask? Because I and many others LIKE it :-) Perhaps as you say there are inexpensive solutions in some cases, but it certainly isn't the manufacturer giving them away. Are you suggesting that the current Apple hardware and software is *the one true* computing platform? I wouldn't make such a claim for any computer system I've seen so far. There are some good ones and some not so good ones, but I've not yet seen one that *can do it all* :-), Apple seems to be doing a relatively good job of allowing many different API's and even what I would consider to be OS's running on their systems. Now if only the other vendors would catch on! Indeed if they don't, Apple may well wind up with a *very* large share of the small computer market. At any rate, sorry to be so long winded about this. Since I think I've done the best job I can expressing my delusions/ideas, I'll continue to watch this from the sidelines for a while. Thanks for listening. -Rick-
hyc@math.lsa.umich.edu (Howard Chu) (06/17/90)
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 ...