Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!caen!hellgate.utah.edu!csn!kessner!david From: david@kessner.denver.co.us (David Kessner) Newsgroups: comp.sys.amiga.advocacy Subject: Re: 8-bit death Message-ID: <1991May7.063757.804@kessner.denver.co.us> Date: 7 May 91 06:37:57 GMT References: <21135@cbmvax.commodore.com> <1991May3.041705.9907@kessner.denver.co.us> <1991May5.022646.19235@sugar.hackercorp.com> Organization: Kessner, Inc. Lines: 127 In article <1991May5.022646.19235@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1991May3.041705.9907@kessner.denver.co.us> david@kessner.denver.co.us (David Kessner) writes: >>IMHO, the 'bits' of an OS is the largest number it can put in a CPU register. > >I have never, in my experience, seen an O/S with registers. That's hardware. You know exactly what I mean! The OS obviously has to store it's numbers in registers... >> In this light, MS-DOS is a 16 bit OS. Plain and simple. > >Same is true for CP/M. HL on the 8080 is 16 bits wide. IX and IY on the Z80 >are too. Or how about MCP, the O/S I worked on in my last job... the 1802 >has *16* 16-bit registers! That's 12 (or is that 13) more than the 8088. So be it. But _you_ are the only one that wishes to bother talking about CP/M, etc, etc. >> Yes, I include the BIOS in the general scheme of MS-DOS. > >Microsoft doesn't. Well Microsoft still things of a 286 based machine as the ideal multi-media machine! >> Why? For several reasons: >> >> The operating system (and/or device drivers) should deal with any >> hardware differences between machines-- and that is the role of the >> BIOS. > >That doesn't handle the differences between the IBM-PC, HP150, Victor 9000, >TI-PRO, etc... or more recently the Data General 1... The BIOS was limited by a bad inital design. Early on, a lot of programmers learned that the BIOS didn't do many things very well-- namely video/graphics, serial I/O, and a few other things. Then there were many programmers that insisted on going around the OS and access the hardware directly. The BIOS cannot mask the hardware differences when the BIOS is not used. The machines you mentioned have serious compatability problems at the hardware level-- usually in the video circutry. This is a case of a bad design influencing bad programmers yeilding a mess. Otherwise, the BIOS offers a very good hardware independance-- noteably with hard drives, keyboard controllers, simple video, etc. Other things are so standardized that it doesnt make much of a difference. >> The BIOS is highly standardized. In fact, they are (almost) >> interchangeable between machines-- as long as the machines have the > >...exact same bugs and features as the IBM-PC/XT or /AT (including crummy >UARTS that don't support synchronous I/O)... Well, yes. The BIOS is basically the same as it was way back when, with only minor improvements. The UARTs are really not so crummy, but they are strictly async. (In the ten years I have worked with computers, from home computers to mainframes, I have never needed a sync port for a PC). >> The BIOS plays just a large of a role in the MS-DOS world as MS-DOS >> itself does. When you do application programming, you try to call >> BIOS functions rather than MS-DOS functions (their faster, usually), >> etc. > >I'm not discussing bugs and other implementation shortcoming in MS-DOS here. >Just the software architecture. You wanted to know why I thought of the BIOS as part of MS-DOS... And I told you... >> And this makes it a 8 bit OS? > >Yes. The fact that it doesn't provide a hardware-independent application >program interface for these resources. All an O/S is, at the bottom level, >is a resource manager. So that's what I look at: what resources it manages >and how complete the interface. I'll say it again: Your requirements for a 8/16/32 bit OS have nothing to do with 8/16/32 bit numbers. Either change you requirements, or change your terminology (ie, from 8-bit-OS to ??????)-- because what you are saying now does not make sense. >> In the same, MS-DOS should be evaluated by looking at MS-DOS-- not CP/M. > >Why? CP/M was one of its competitors. Great. So I'll look at a FORD and pay for a CHEVY... >> This is more of a function of the hardware than MS-DOS. > >Well look at the fate of computers that did a better job. If MS-DOS had been >a real 16-bit O/S instead of a port of an 8-bit one the HP150, Victor 9000, >TI PRO, and so on would have been successes. No. If MS-DOS/BIOS had been designed properly, and the programmers did not go around the OS and access the hardware directly, then those machines would have been successes. Also, the machines you mentioned were all made when there was still some degree of BIOS incompatability (due in part to IBM's laywers). These problems have been ironed out in todays machines... I don't know about the Data General machine, so I don't include it in the above statement. >> If you cant flame MS-DOS, who can you flame? > >Damn good question. Current suggestions have been OS/2, Windows, and just about anything from Microsoft/IBM... >Peter da Silva. `-_-' >. -- David Kessner - david@kessner.denver.co.us | do { 1135 Fairfax, Denver CO 80220 (303) 377-1801 (p.m.) | . . . If you cant flame MS-DOS, who can you flame? | } while( jones);