PC DOS Reimagined
pcjs.org
pcjs.org
Vendor1: "Yes. We have a special install for it, carefully distribute the files among floppies, and you can do it."
Vendor2: "Yes, we can do it. It has a special install, blah blah blah."
Me: "Yes. It costs $200 extra and comes with a hard disk."
The question never progressed to Vendors 4 and 5, the question never came up again from anybody. That marked the end of the floppy-only era as far as I was concerned :-)
It still took some more years before we could stop distributing the compiler on a stack of floppies and go with a CD.
P.S. The price of a "hard card" (a hard disk on an expansion plug-in card) was $200 at the time.
As someone who has worked supporting a commercial compiler, it never ceases to amaze me how companies will pay 6 figures per seat for development tools, and then install them on a 5 year old machine that wasn't fit for the title "workstation" when it was brand new.
Well, because the dev shop buys the dev tools, but general desktop IT buys the computers, with policies around limiting number of different builds in the organization for IT convenience, and distribution policies for new machines based on internal politics (if you are in th chain of command above the head of the unit in charge of the hardware, or politically connected to someone in that position, you and your staff can get newer, better machines, whether or not you have a real business need, and even if that means denying someone else with a real business need.)
Or, at least, I've seen enterprise shops like that.
...and I'm saying this as a developer myself.
https://mobile.twitter.com/vasudevram/status/127075265940270...
Every day I was there they could have bought a faster machine with the amount of money they were paying me to wait for builds to complete. They were developing embedded software, so the "dogfooding their customer's machines" was non-sensical.
If you do this, your programmers will leave your company. And your competitors will offer them better computers.
You'd need all software companies to sync and do this, or at least a large majority.
Windows
Celeron
2-4gb ram
5400rpm hard drive
No administrative privileges
Shitty antivirus installed
1080p monitor
Well, now you often have an overreaction to this problem, when web developers work on their Javascript frontends and Electron applications on the latest, beefiest Macbooks and blazing fast internet speeds and get completely out of touch with what their end users might be using. (This comment was written on an i9, 64gb RAM Macbook Pro provided by my employer).
The IBM PC (and clone) hardware was progressing rapidly at the time: from an 8-bit 8088 @ 4.77Mhz with 64-256K RAM to much much faster 16-bit 80286/80386 systems @ 16Mhz+ with 2-4MB RAM in just a few short years.
As a consequence of this rapid progress, the software of the era didn't really exist for long enough to get heavily optimized and [with the exception of certain games] never pushed the PC/XT hardware to anywhere near its full capabilities.
The software evolved far more slowly because of this-- you still had a lot of "It supports an 8088" or "it supports CGA" until the early 1990s.
> from an 8-bit 8088
the 8088 was a 16-bit processor choked by pushing data through an 8-bit data bus.
> 16-bit 80286/80386 systems
Depending on exactly what period and systems you mean, this should probably be:
16-bit 8086/80286 (8086, of which the 8088 was the 8-bit-bus copy, was obviously earlier than 8088, but used later in PC clones)
Or
16-/32-bit 80286/80386 (the 386 was a 32-bit processor.)
It was also famously called "braindead", mostly because switching into 286 Protected Mode to make use of its new features pretty much meant turning off 8088/8086 compatibility (unless you used some horrible tricks).
When the 80386 came along with its real 32bit register set and address space, and significantly increased compatibility even in Protected Mode through vm86 and a few other additions, it really made a tremendous impact in comparison.
And while DOS was still 16bit, it would now often run in memory managers (e.g. QEMM, EMM386...) as a vm86 task in Protected Mode, making some good use of some of the new 32bit features.
For it to have finished up in 1982, it likely started development before or just as the original IBM PC hit the market. At the time, there wasn't a huge installed base of can't-afford-to-break 8086 code, or much of a precedent for backwards compatibility on a wholesale platform change for PCs. They may well have figured anyone trying to build a 286 system would be targeting a fully protected-mode OS, and the non-protected mode support was more of a stopgap for compatibility and bootstrap purposes.
I don't know or remember much about what the 286 was used for (besides IBM PS/2 systems), but I as well wouldn't be surprised if it was more targeted towards things like PBXs and industrial control, where Protected Mode without DOS compatibility made perfect sense...
The big one was the 80186/188-- basically an 8086/8088 with a few onboard timers and serial controllers and a few enhanced instructions, but the new goodies were not in a PC-compatible design. You do see them quite often in embedded devices.
The more interesting one was the 80376-- a 386 which was protected-mode only, but also missed other key features so it wasn't just "take a 386 oS and change the bootloader."
The non-compatible goodies of the 80186 play a big role in making it not IBM compatible, but other things as well. In many ways it was a bit better, e.g. high resolution (but monochrome) text and graphics, and no 640k barrier.
The 80376 is an interesting beast because it got rid of 16bit support entirely--any 16bit segment descriptors were invalid.
The main speedups from 8088 -> 80286 were moving from an 8-bit to a 16-bit external data bus and also the 80286's dedicated address generation unit which made calculating operand effective addresses much much faster.
And the 80386, when running DOS programs in 16-bit real mode, was mostly just a glorified but very fast 80286. Especially the 80386DX with its 32-bit memory bus. It took a while for software like Desqview, EMM386, and Windows 3.1 (in 386 enhanced mode) to take advantage of the 80386's advanced features.
The poor little 8088 had to squeeze both its instruction stream and the data stream through a tiny 8-bit bus, so it's really not that much different from say the Z80 (widely considered an 8-bit CPU) which nonetheless can do (limited) 16-bit operations on some of the internal registers.
"Bitness" is usually held to refer to the size of a processor's main register set, so the size of data units it is capable of processing internally most of the time, ignoring special cases. By that common definition the 8088 is definitely a 16-bit CPU. Especially as it was a modification of the 16-bit 8086 design and fully code compatible with it, the modification being that 8 bit data bus which slowed down talking to the outside world.
Similarly the 386SX is a 32-bit unit. They took the original 386 and modified it in much the same way, giving it a 16-bit data bus to allow it to be used on much cheaper motherboard designs being the main defining change. The 386DX actually came first technically because it was essentially the original 386 lines renamed once the SX variants came along.
The Z80 could perform a limited set of 16 bit operations such as partially 16-bit multiply (8-bit inputs to a 16-bit output) but was definitely an 8-bit unit overall as the majority of it's inwards were (and the majority of the 8088s innards were 16-bit, and the 386's (original/DX, or SX) were 32. If we count instruction outputs and not general purpose register size then the 6502 family would be 9-bit not 8 as most of its arithmetic instructions output 9 bits (the main 8, plus overflow in the flags register).
The 486 would not be called 80-bit because of its floating point unit having 80-bit registers for intermediate operations, and early-ish Pentiums were still 32-bit when 64-bit chewing MMX instructions were added (in fact the very first Pentiums had 64-bit data busses so they could pump data into the on-die cache twice as fast to try keep up with the demands of the fast pipelined internals but where still considered 32-bit as said internals were).
There are some CPU/GPU/other-PU designs where the distinction is rather muddy, but for Intel's main lines and those inheriting from them I'd say their bitness is pretty well defined.
I still remember all the peer group pressure we had due to hardware evolution: Bought a fast 486DX2? Well, I bought my Pentium 60. Got RAM? Well, I bought EDO-Ram.
Memories... :D
LOAD "FILE",8
Computers with MS-DOS and CPM were different in that you would load a proper shell and launch basic from there. I seem to recall (I was 9 years old at the time) the original IBM PC having a less capable BASIC that could use a cassette tape for storage built in that would boot if you did not have a floppy drive or disk in the boot drive when the machine started.
BASIC, in its upgraded version "BASIC 7.0" (compared to the C64's "BASIC 2.0") was quite obviously still the "main mode" and the one that supported all the C128's features.
However, there was also a third mode, a "C64 compatibility mode", which removed (almost) all of the new features and presented itself exactly like a C64 would, same ROM and all.
The issue does not seem entirely clear cut, but from the looks of it, while apparently the newer CP/M 3.0 used there does seem a bit slower than earlier versions, the majority of the reasons seem indeed pretty specific to the C128.
At one point the hard drive failed and the PC booted into basic from ROM.
BASIC as a shell was more capable than DOS. There is no reason to have DOS instead of BASIC other than it has fewer features to be implemented.
For all the bashing BASIC gets for favoring unstructured programming, you could do a lot in it as a first gear programming language. Think of the amount of bash scripts that shuffle strings around and ask if you would not rather program in e.g. python if it gave immediate access to files.
As a programming language, Basic was more suited to be a shell than DOS was suited to be a programming language. :) that's probably why I avoided learning dos batch programming like mad.
Unfortunately Microsoft did everything in its power to kill it.
> "If you're going to kill someone there isn't much reason to get all worked up about it and angry. Any discussions beforehand are a waste of time. We need to smile at Novell while we pull the trigger." - Jim Allchin, Microsoft Co-President, on a memo about DR-DOS.
I'll show myself out.
That was acceptable for a quick dial-up-and-toss-a-mail-packet session, but not for door games or chat, so the prospect of being able to run something in an _alternate_ task, not a _parent_ task, was incredibly attractive.
I think 8 bit micros (Apple II, Commodore 64) are closer. They booted up into BASIC and their DOS was an extension to BASIC.
The other 8-bit micro I used personally was the TRS-80 Model 1. It would boot directly to BASIC but their was no DOS as part of this basic. To use a floppy drive a DOS boot disk was required. There were a few different DOS's available for the machine. The official DOS available from Tandy was TRS-DOS.
Apple ProDOS had similar stuff...
It was the last good OS they ever shipped.
But Xenix does not run DOS or Windows programs like OS/2 does. Microsoft needed the backwards compatibility to be able to sell the next DOS. When Microsoft split from IBM for OS/2 Microsoft's OS/2 NT 3.0 became Microsoft Windows NT 3.1
I wonder if XEDOS ever existed as actual code, as opposed to simply an item in a roadmap.
As the IBM PC became Microsoft's passport to success, they ditched the Unixness of Xenix and embraced the CP/M-ness of PC-DOS. That's why people do dir in Windows instead of ls.