OS research thread...

[venos]

CP/M Plus is CP/M 3.1. What I've never seen is CP/M 3.0 -- I've looked at various boot discs that claimed to be CP/M 3.0, but in all of them S_BDOSVER still returned 31h. It's possible that there never was a CP/M 3.0; I've seen it reported that the 3.0 number was returned by MP/M II.

CP/M 1.x doesn't have a system call to return the version number, which makes it a little more awkward to work out what version something is.

Thanks, corrected

[James]

VirtualBox works on OS/2, iirc.

[WinPC]

Always good for a giggle. This never saw the light of day, sadly

What is this supposed to be, exactly? It looks like just another virtualization package to me.

[James]

Always good for a giggle. This never saw the light of day, sadly

What is this supposed to be, exactly? It looks like just another virtualization package to me.

You know, for somebody who's running a thread on OS research, you're awfully picky about what you want to look at.

[WinPC]

Always good for a giggle. This never saw the light of day, sadly

What is this supposed to be, exactly? It looks like just another virtualization package to me.

You know, for somebody who's running a thread on OS research, you're awfully picky about what you want to look at.

I'm not being "picky", and I'm not insulting os2fan2 or anything like that, nor am I criticizing anyone either. I'm just asking, since I don't really understand what that particular post is supposed to mean.

I have nothing against the post at all; on the contrary, I agree that it is extremely interesting, whatever it is. Just that I am not really sure what it is referring to, which is why I asked.

[os2fan2]

The picture i posted is an 'emulator', not a 'virtual pc'. At least that's how IBM described it. From what i can guess, it's pretty much like WinOS2 or a DOS vm in OS/2 or Windows, or DOSBox. It's also the third piece of 'vapourware' from IBM that i have seen. More like a working alpha or unstable beta, than vapourware in MS style terms.

The first was 'Workplace Shell for DOS'. Like other strange terms, this actually returns results on google. It looks like WPS Windows, with some icons changed. It was supposed to be a shell program (like DOS Shell), but it never made the necessary stability to go prime-time. I first saw a picture of it for the 7,0 beta, but it was first tauted for the 6.3 vers. DOS 6.3 just slipped out too early, although the 6.3 in Warp Connect PPC did in fact contain a proper version of rexx etc.

The second was the 'Warp 4 makeover', was basically something they did with Object Desktop 2.0 on Warp 3. Unfortunately, the punters thought they were getting OD20 with OS/2 4, so it didn't help Stardock much.

This third is the emulator thing shown above. But with OS/2 4 in the release, and IBM's PPC's severely numbered by Florida's tax grab, it seemed that not much came from this.



This is clearer when you click on it. It's at full-size.

[os2fan2]

DOS 1 to 4 belong to the age of 'ms-dos clones'.

What was happening here was that IBM's BIOS was secret, and while other people could source the same bits and pieces to make an IBM-PC, the key ingredient was the BIOS, which one could not get. This meant that calls not handled by MS-DOS, such as the video layer, were handled differently by different machines. So one had stickers on period softwars, saying 'for IBM compatables' or 'for Tandy' or 'for XYZ'.

It's pretty much like you see console games 'for X-Box' or 'for Sony PS/3' or whatever.

IBM put a lot of money out there for companies like sierra and lotus to make software for the IBM PC. It pretty much was not the hardware that killed Tandy, it was the (lack of) software. Once one has the software market sown up, one can charge higher prices etc. None the same, IBM PCs were pretty reliable.

PC-DOS 4 was the last of this era, but not well recieved, because many of its innovations were not ready for prime time. None the same, DOS 4 (both of them) would be a test-bed for ideas that would appear in OS/2. Most people stuck with DOS 3.31 etc, simply because it was more suited for the period hardware.

By this time, one is lapping at the 32 MB hard disk limit, and the 640K ram disk limit. Compaq solved the first with FAT16 (bigfat), and Quaterdeck got around the second (himem). Microsoft cloned both without paying royalities.

DOS 5 to 7 belong to the age of 'IBM compatibles'.

Compaq and American Megatrends reversed-engineered IBM's BIOS, and produced a clone good enough to run software designed for the IBM PC. This brought in the age of 'IBM Clones', which followed the same calls as the IBM BIOS. In the end, even IBM made IBM Clones (eg the Aptiva, thinkcentres). DRI brought out a retail upgrade DOS: "DR-DOS 5". This was so much better than any of microsoft's offerings that they had to get down and do some hard coding to get their new DOS out.

DOS 5 was a pretty good DOS in its day. It was the last joint DOS, and it is the reason that both IBM's OS/2 and Windows NT use it. MS-DOS 5 utilities run without modification under any Windows NT, for example, and some of the DOS 5 utilities actually match the NT stuff. By this time, the IBM/Microsoft agreement was ending. IBM was allowed to enter the upgrade market for non-ibm boxes, so one could buy PC-DOS 5.02 to run on a Compaq. IBM's DOS versions were made for the 386, for example.

DRI responded with a fleshed out DOS 6.0, festooned with lots of third-party utilities, a proper inline help system, disk compression (program size was beginning to outstrip hard disk size).

MS-DOS responded with MS-DOS 6, which matched feature for feature. But much of it was crippled. Even the compression raised serious doubts about data reliability. It was also patent-infringing, which meant that even after they fixed it in 6.2, they had to pull it in 6.21. The DOS was sold to OEMs by the rather confusing title of 'MS-DOS 6 and Additional Tools', with no clear meaning here. The additional tools were a series of crippled tools licenced from Norton.

The microsoft/ibm split started to move apart, so even though IBM had licence to the MS-DOS code, and even the Windows 3.1 code, they chose not to buy the microsoft 'additional tools', but rather an old version of 'centre-point's utility set, which one could upgrade by voucher to the 'latest version'. A new editor, and several inches of dead tree accompanied the three releases IBM-DOS 6.0, PC-DOS 6.1, and PC-DOS 6.3.

Apart from the obviously crippled, some of the MSFT utilities were positively dangerous. For example, MSAV would rarely reach results as good as detecting 33% of viruses in the wild, when those of the retail market (such as viruscan and thunderbolt av), and IBMAV, routinely got better than 90%. Even things like becker tool's AV (becker tools sold little booklets with attached diskette, generally regarded as margin-ware), routinely outstripped it. Yet people thought because they loaded the MSAV tsr, they were automatically protected.

Disk compression none the less attracted considerable attention in the press, largely because DBLSPACE.000 was inherently unstable, and loss of data was not that uncommon that Microsoft had to release 'step-up' disks (ie disks that would upgrade DOS 6 to DOS 6.2, along with all of the built fixes for dblspace.bin.).

The appearence of MS-DOS 6.22 was delayed to a point where the IBM/Microsoft split entered the next phase. Released the same day as Wfw 3.11, these were bundled together in a way that made including other vendor's dos more expensive: you paid for a licence of ms-dos 6.22 with wfw 3.11, regardless of what dos you actually installed. The appearence of win 3.11 came as a result of some serious questioning about the legalities of including what was a competitive market: read, for example, the various networks supported in win.310.

Both MSFT and IBM issued much-cheaper step-ups to the last versions of their DOS. (ie 15$ vs 100$).

One of the big differences between 3.10 and 3.11, is the shift from OS/2 to Windows NT as the preferred network server. This is one of the biggest 'bait-and-switch' things Microsoft was accused of at the time. Microsoft was pushing OS/2 under the agreement, but dropped the thing like a hot potato as soon as they were legally allowed, and generally mothballed the development of the software.

Certian 'technological improvements' were added to Windows 3.11 to provent it running under "OS/2 for Windows" for example. It is still questionable whether these improvements were in part commercially driven.

We now turn to DOS 7. Both DRI and IBM released a version of DOS 7, that included Stacker. Although it does look like that DOS was fast becomming a windows loader, and its viability to run was thus based, DR-DOS was further out of the market, than IBM (who still had access to recent DOS code).

PC-DOS introduced a number of quite interesting things, not found in earlier DOS versions. Apart from becoming more SAA complient (ie IBM's grand vision of cross-platform UI, like UNIX had), it included, for the first time, a command-line calculator! (acalc). You really could do with PC-DOS, something what people have been asking for years: do a calculation at the command prompt. But Boca Raton had its run, would soon close, and Austin decided that enough was enough: IBM's PC operating systems would go into a long death.

Windows 95 and OS/2

In its day, OS/2 was the geek OS, like Linux is now. If you really wanted to be serious PC user, you needed your little dedicated OS/2 partition, complete with boot manager. Lots of good things came of OS/2, and it was considerably stabler than DOS / Windows. You could even do multitasking.

OS/2 2.1 could run Windows without an installed copy of Windows. Its Win-OS/2 calculator actually worked, unlike Microsoft's one, which required no less than Wall-street journal to shame Micorosoft to release a fix for it. You could buy an "OS/2 for Windows", which means that if you had Windows 3.10, you could use OS/2 and run that copy under DOS and under OS/2.

There was things like 'team os/2', which used to attend computer shows, and help vendors and help users in general with DOS and Windows stuff. OS/2 gradually started to capture a sizable section of the market.

The other 'killer' was that the Progman/Winfile interface, dating back to the 1980, were generally inferior to the DOS menu programs that OEMs were installing on their computer, and generally inferior to the offerings of a large shell after-market, which managed to rise to being the third-largest kind of Windows software.

Windows 95 changed things. It was generally considerably superior to the previous MS-DOS / Windows, although being the same code. Some things were not -so- aggressive, but then there is a good deal of alpha-code in Wfw311. None the less, 95 saw the death of things like DOS columns, debug-scripts that used to populate PC-Magazine, and programs written in GW-BASIC.

OSR2 looks so much like OS/2, that one can't help but wonder if it was put there for confusion. In any case, hard disks were begining to lap the 504 MB boundry, even the 4G and 8G boundries were within some sort of common-ness. OS/2 could always get around the 504 boundry, and you could install bits on the partition over the 504MB boundry, to save space. An 800 GB disk did not need to be split into two with a software driver. OS/2 could see it. LBA was the magic here. In stead of using Cylinder, Head, Sector addressing, the sectors were just numbered and this number was passed to hardware to retrieve: LBA is logical block addressing. You would tell it, sector xxxxxxxxxxx, and the hardware would find some ccccc.hhh.ssss to retrieve the data.

It took some doing, but it probably was as much Boca Raton's closure as anything Microsoft that killed off OS/2 at IBM.

[Battler]

By this time, one is lapping at the 32 MB hard disk limit, and the 640K ram disk limit. Compaq solved the first with FAT16 (bigfat), and Quaterdeck got around the second (himem). Microsoft cloned both without paying royalities.

Microsoft did not clone Compaq's BIGFat - they wrote their own modification of FAT to support partitions larger than 32 MB (hard disks larger than 32 MB were supported before that but required to be split in multiple partitions, something FAT16 got around). Their implementation actually differs. It was Digital Research that later cloned the Compaq implementation, creating incompatibilities with Microsoft's - from what I understand, Microsoft's implementation added a new sector field, while the Compaq implementation (also used by DR) extended the old one.

The microsoft/ibm split started to move apart, so even though IBM had licence to the MS-DOS code, and even the Windows 3.1 code, they chose not to buy the microsoft 'additional tools', but rather an old version of 'centre-point's utility set, which one could upgrade by voucher to the 'latest version'. A new editor, and several inches of dead tree accompanied the three releases IBM-DOS 6.0, PC-DOS 6.1, and PC-DOS 6.3.

Except Microsoft's Anti-Virus, MSBACKUP, etc. were also based on the same set of Central Point tools. Even the file names are basically the same, with Microsoft obviously adding MS do them, eg WN*.DLL becomes MS*.DLL, and the .OVL files have MS added to their names. But it's still the same software nonetheless.

Apart from the obviously crippled, some of the MSFT utilities were positively dangerous. For example, MSAV would rarely reach results as good as detecting 33% of viruses in the wild, when those of the retail market (such as viruscan and thunderbolt av), and IBMAV, routinely got better than 90%. Even things like becker tool's AV (becker tools sold little booklets with attached diskette, generally regarded as margin-ware), routinely outstripped it. Yet people thought because they loaded the MSAV tsr, they were automatically protected.

IBMAV was identical to MSAV, except possibly having a newer virus database. Both were based on CPAV, the Central Point Anti-Virus.

The appearence of MS-DOS 6.22 was delayed to a point where the IBM/Microsoft split entered the next phase. Released the same day as Wfw 3.11, these were bundled together in a way that made including other vendor's dos more expensive: you paid for a licence of ms-dos 6.22 with wfw 3.11, regardless of what dos you actually installed. The appearence of win 3.11 came as a result of some serious questioning about the legalities of including what was a competitive market: read, for example, the various networks supported in win.310.

This is wrong. First, Windows for Workgroups 3.11 (its files are dated November 1993) was released in early November 1993. MS-DOS 6.21 came in early 1994, followed by MS-DOS 6.22 in May or June 1994 (its files are dated May 31st, 1993). So they were definitely not released the same day. And both were also sold separately, especially as Windows for Workgroups 3.11 came almost half a year before MS-DOS 6.22 (and like 3 months before MS-DOS 6.21).
Also, you forget to mention, that Microsoft was sued over DoubleSpace, so they removed it in MS-DOS 6.21, and then they came up with "DriveSpace" for MS-DOS 6.22, which however was just renamed DoubleSpace with an extra new compression algorithm added (in addition to the old one). I did a test once, where I renamed all DBLSPACE.* files to DRVSPACE.* on a compressed drive, and it then loaded perfectly fine with no problems without DBLSPACE.BIN but only with DRVSPACE.BIN, showing Microsoft never removed any code, but just pretended they did and renamed the program.

The other 'killer' was that the Progman/Winfile interface, dating back to the 1980, were generally inferior to the DOS menu programs that OEMs were installing on their computer, and generally inferior to the offerings of a large shell after-market, which managed to rise to being the third-largest kind of Windows software.

The Program Manager/File Manager interface hardly dates much to the 1980's considering it first appeared in Windows 3.0 which was released to the public in 1990. And how was it inferior to the DOS menu programs? I think you're mixing up here with the earlier MS-DOS Executive interface, which was inferior to those menu programs, though it was evidently popular enough that Microsoft kept it as an option in Windows 3.0, all the way up to and including Windows 3.10.034e, which is the latest Build we have to still include MS-DOS Executive as an option. By 3.10.061d, it was completely removed, though we don't know when exactly that happend - my question here is, did 3.10.043d to 3.10.043f have MS-DOS Executive or not?

Also, to add another perspective on the effects of the popularity of Windows 3.x and later (and NT for more serious use) - not only did they cause the downfall of IBM OS/2 and IBM's software division in general - in Japan, they caused the downfall of proprietary architectures such as the NEC PC-9801 or Fujitsu FM-Towns, as for the first time a popular OS existed that was also able to run the exact same software on all three platforms (PC, PC-98, FM-Towns). By the turn of the century, PC-98 and FM-Towns were so much in decline that NEC and Fujitsu just discontinued their two respective platforms and at least NEC switched to producing regular PC's.
BTW, I'd say that if there's a place on Earth where IBM's PC DOS had a bigger market share than Microsoft MS-DOS, that would be Hong Kong, Macau, and Taiwan, which use Traditional Chinese, which IBM PC DOS was localized into and had support for, while MS-DOS was neither localized into it nor even had support it, even well into the Windows 9x era (Windows 98 Second Edition Traditional Chinese still does not include DOS support for Traditional Chinese, though by then the importance of DOS had diminished greatly already), though E-Ten's Chinese System did an equally good job and worked in all flavors of DOS (MS-DOS, PC DOS, and most likely even DR-DOS) so maybe MS-DOS was also used in combination with the E-Ten Chinese System.

[os2fan2]

Except Microsoft's Anti-Virus, MSBACKUP, etc. were also based on the same set of Central Point tools.

IBM used a special full version, basically a back-version. Microsoft would not pay the full pennies, and used a hobbled version of it. Regarding MSAV vs IBMAV, the two are as different as chalk and cheese. I read the glossies when these were doing their respective runs.

The thing about renaming DBLSPACE.* to DRVSPACE.*, does not imply code was not removed. IO.SYS in 6.22 actually looks for both DRVSPACE and then DBLSPACE in the boot sequence. Renaming one to the other will still ensure that it gets loaded. Much of the switches in the proggies match.

Paras were deleted in the edit, including the removal of dblspace in 6.21. None the same, because 6.21 is essentially 6.20 with a hand full of file changes (the fc /b detects about four files or something.), then 6.21 will load dblspace if it is present. You can even run 6.20's dblspace under it.

DrvSpace is API complient with DBLspace. That means that the user switches work the same way, as i found merging drvspace and dblspace in my msdos7 help project. Still, just because there is a command 'drvspace mount' and one 'dblspace mount', it does not mean that the underlying compression is the same. There's probably a 'stacker mount' command too, still. your result is interesting.

In any case, by the time i got around to disk compression, the system was booting 19 operating systems, (maybe 23), and so having something like dagspace on there would ensure that most did not boot. Get a real disk compression, like "Stacker 4.0 for OS/2 and DOS". Even the PC-DOS manual knows about it.

The Program Manager/File Manager interface hardly dates much to the 1980's considering it first appeared in Windows 3.0 which was released to the public in 1990. And how was it inferior to the DOS menu programs? I think you're mixing up here with the earlier MS-DOS Executive interface, which was inferior to those menu programs, though it was evidently popular enough that Microsoft kept it as an option in Windows 3.0, all the way up to and including Windows 3.10.034e, which is the latest Build we have to still include MS-DOS Executive as an option. By 3.10.061d, it was completely removed, though we don't know when exactly that happend - my question here is, did 3.10.043d to 3.10.043f have MS-DOS Executive or not?

progman/fileman was written by IBM in dear old England, included for OS/2 1.2 or something. Google for 'OS/2 1.2' and look at the pictures, complete with -1989 copyright date. Control panel had the same icon, but the innards of the OS/2 control resembled the 2.x stock. In my Windoze K7654 project, progman's windows is changed to 'Desktop Manager' to match this use in OS/2.

Reading this post, one gets the assumption that Microsoft wrote everything, and that in the days of Windows 3.0 and 3.1, machines typically booted into Windows. No, until Microsoft forced the copyright issue, the typical machine booted into a DOS menu, eg Packard Bell had their own, as did IBM and whatever. There's even a copy of the IBM one on the server. A menu might point you off to a number of DOS apps (Wordperfect, Lotus 1-2-3, Multimate), and games (Civ, Doom), as well as a mob of utilities fixed to run DOS.

The DOS menu program that came with my computer looked something like this. You could put primary programs on the front page, or you could put groups inside groups. Even the dos progman (in dosshell) allows this. In Windows, Progman was seen as an advert for the MDI interface: the open window hold 'documents' (ie groups), the groups hold 'items'. And that's it.



Yes, i know what MSDOS.EXE is. My box had Windows 3.00 on it, and we upgraded it in the shop to 3.10, which had just hit the market. The tapes i have for it are pretty much first-day issue stuff. No, in those days, Windows was an application you ran from a DOS menu, and exited it to do DOS stuff afterwards. You did not live in Windows like you do now. People called it things like 'Windoze' because it was dead slow on that hardware. Even down to things like saying 'speed kills: use Windows'. At work, they used Amipro 3.0. This has a little alphabet on its splash-screen. You could get as far as saying letters to 'R' or 'T' while it displayed this screen. Amislo indeed. The DOS programs they replaced were considerably spritier.

The file dates were in essence some symbolism before the RTM date. So one often sees dates that reflect '11' (eg 1993.11.1 or 31.05.1994 The time is set to the date version. You can set these options in their 'diskette image' program. Still, i have a manual here "Microsoft Windows & MS-DOS 6.2 (Operating System Plus Enhanced Tools)", and i've seen similar tomes on MS-DOS 6.22 and Windows 3.11.

It probably was wrong to say they were released together, but they soon forgot about the older stuff. I gave up on MS-DOS after version 5, going straight to the much superior pcdos 6.1. Still, one generally avoids installing all of the rubbish that comes with DOS, because in those days, space was much more restrictive, and if you had better, you used that. I used Thunderbyte AV at the time.

You should really try to set a fully working system up with 80 MB hard disk, and 4 MB ram. You soon learn to prune off the rubbish. A full Windows 3.1 install is something like 10-15 MB. Add a 5 MB Dos install, and you have a quarter of the disk taken up, and it does nothing. Civ for DOS is 3 MB, but if you have the multiple versions from the CD on there, this can multiply up to 15 MB. I did a bit of hex editing and cut this down to 5 MB. Any decent windows word processor comes in at 10-15 MB, and a similar layout for a spreadsheet. Most OEM machines come with a couple of MB of rubbish, some marginally useful. NDW comes in at 15 MB, i got it down to just under a half a meg in the end. A programming language typically weighed in in the megs, but most of these were avoidable if you didn't do that sort of thing.

Even the Windows 3.10 resource kit tells you what files are deletable, and how you can patch the install tape see, eg Windoze K7564 which started life during 1994. It's just that reconfiguring Windows on each install, was a bit of a pain, so one just touched up the install tapes, and prehaps did an SI diskette for the rest. (Burning a CD in 1995 was an outsource-thing costing 100$ a stick, and usually involved delivery of a computer with the layout on it. By 1997, the burner was still 600$, and the diskettes were 20$ a disk. One tried not to waste too much on this sort of thing!).

[Battler]

IBM used a special full version, basically a back-version. Microsoft would not pay the full pennies, and used a hobbled version of it. Regarding MSAV vs IBMAV, the two are as different as chalk and cheese. I read the glossies when these were doing their respective runs.

Except the files aren't that different, neither for eg. Backup, neither for the Anti-Virus, at least as far as MS-DOS 6.22 and PC DOS 6.3 are concerned. I've used both and I clearly remember the names not differing that must. Maybe in PC DOS 7.0, the IBM Anti-Virus and other tools got a boost, but by then Microsoft left serious DOS business already and demoted MS-DOS to a simple boot loader for Windows 9x.

The thing about renaming DBLSPACE.* to DRVSPACE.*, does not imply code was not removed. IO.SYS in 6.22 actually looks for both DRVSPACE and then DBLSPACE in the boot sequence. Renaming one to the other will still ensure that it gets loaded. Much of the switches in the proggies match.

Paras were deleted in the edit, including the removal of dblspace in 6.21. None the same, because 6.21 is essentially 6.20 with a hand full of file changes (the fc /b detects about four files or something.), then 6.21 will load dblspace if it is present. You can even run 6.20's dblspace under it.

DrvSpace is API complient with DBLspace. That means that the user switches work the same way, as i found merging drvspace and dblspace in my msdos7 help project. Still, just because there is a command 'drvspace mount' and one 'dblspace mount', it does not mean that the underlying compression is the same. There's probably a 'stacker mount' command too, still. your result is interesting.

When I tested it in a virtual machine, I made sure that after upgrading to MS-DOS 6.22, no trace of old MS-DOS 6.20 DBLSPACE.* program files were left, not even DBLSPACE.BIN on the boot drive. The compressed stuff did not load. Then I simply renamed the compressed drive's files from DBLSPACE.* to DRVSPACE.*, and they loaded without problems, clearly showing the code of DriveSpace can load DoubleSpace just fine, proving the whole requirement to "convert or add DBLSPACE.BIN to boot drive" DriveSpace gives you useless, and most likely only done to make everyone think they actually removed the old code.
Obviously, codded was added to DriveSpace, likely even a new compression algorithm, but the old code was evidently never removed, which is further evidenced by the fact MS-DOS 6.22's DRVSPACE.* program files were bigger than MS-DOS 6.20's DBLSPACE.* files.

In any case, by the time i got around to disk compression, the system was booting 19 operating systems, (maybe 23), and so having something like dagspace on there would ensure that most did not boot. Get a real disk compression, like "Stacker 4.0 for OS/2 and DOS". Even the PC-DOS manual knows about it.

I thought DoubleSpace was based on code stolen from Stacker. Or maybe they only stole some code then made their own framework around it.

progman/fileman was written by IBM in dear old England, included for OS/2 1.2 or something. Google for 'OS/2 1.2' and look at the pictures, complete with -1989 copyright date. Control panel had the same icon, but the innards of the OS/2 control resembled the 2.x stock. In my Windoze K7654 project, progman's windows is changed to 'Desktop Manager' to match this use in OS/2.

Yes, the old Desktop Manager has the same functionality and similar looks, but do we have any real evidence that they used the same code? Desktop Manager wasn't even MDI, while Program Manager was, even in Windows 3.0.

Reading this post, one gets the assumption that Microsoft wrote everything, and that in the days of Windows 3.0 and 3.1, machines typically booted into Windows. No, until Microsoft forced the copyright issue, the typical machine booted into a DOS menu, eg Packard Bell had their own, as did IBM and whatever. There's even a copy of the IBM one on the server. A menu might point you off to a number of DOS apps (Wordperfect, Lotus 1-2-3, Multimate), and games (Civ, Doom), as well as a mob of utilities fixed to run DOS.

How exactly does Microsoft copyright affect other people's ability to write their own menu software for DOS? And I don't see how Program Manager doesn't do just the same - pointing you off to a number of applications, and games.

The DOS menu program that came with my computer looked something like this. You could put primary programs on the front page, or you could put groups inside groups. Even the dos progman (in dosshell) allows this. In Windows, Progman was seen as an advert for the MDI interface: the open window hold 'documents' (ie groups), the groups hold 'items'. And that's it.

Well, yeah, putting groups inside groups was not possible in Program Manager, which is one of the things the Windows 95 desktop interface improved on it. However, it wasn't that bad and it was certainly way better than MS-DOS Executive which it replaced.

Yes, i know what MSDOS.EXE is. My box had Windows 3.00 on it, and we upgraded it in the shop to 3.10, which had just hit the market. The tapes i have for it are pretty much first-day issue stuff. No, in those days, Windows was an application you ran from a DOS menu, and exited it to do DOS stuff afterwards. You did not live in Windows like you do now. People called it things like 'Windoze' because it was dead slow on that hardware. Even down to things like saying 'speed kills: use Windows'. At work, they used Amipro 3.0. This has a little alphabet on its splash-screen. You could get as far as saying letters to 'R' or 'T' while it displayed this screen. Amislo indeed. The DOS programs they replaced were considerably spritier.

Yeah, I know that in the old days you didn't live in Windows like you do now. My first PC was an Amstrad 80386SX which ran with German MS-DOS 5.0, later English MS-DOS 5.0 and Windows 3.1. Even after we got Windows 3.1 onto it, we still spent most of the time in DOS. And yes, Windows was slow. I remember at my mother's workplace though, they were transitioning from using MS-DOS 5.0 and WordStar to using Windows 3.1 and Microsoft Word 2.0.

The file dates were in essence some symbolism before the RTM date. So one often sees dates that reflect '11' (eg 1993.11.1 or 31.05.1994 The time is set to the date version. You can set these options in their 'diskette image' program. Still, i have a manual here "Microsoft Windows & MS-DOS 6.2 (Operating System Plus Enhanced Tools)", and i've seen similar tomes on MS-DOS 6.22 and Windows 3.11.

Well, while I do agree there is some symbolism in Microsoft file dates and times - especially the times, which were eg. 5:00 in MS-DOS 5.00, 6:00 in MS-DOS 6.00, 6:20 in 6.20, and so on. Also, 3:10, 3:11, etc. in the respective Windows versions, though for example 9:50 in Windows 95. The dates though, not really. First, Microsoft is an US-based company so they looked at the dates in the US format: 11-11-93, 05-31-94, etc. Your 31-0 symbolism goes away immediately from the MS-DOS 6.22 RTM date when you look at it in the US format.
Also, I used to have separate manuals for Windows 3.1 for Central and Eastern Europe, and MS-DOS 6.20, plus an addendum for the new features in MS-DOS 6.22.

It probably was wrong to say they were released together, but they soon forgot about the older stuff. I gave up on MS-DOS after version 5, going straight to the much superior pcdos 6.1. Still, one generally avoids installing all of the rubbish that comes with DOS, because in those days, space was much more restrictive, and if you had better, you used that. I used Thunderbyte AV at the time.

Much superior? I think PC DOS 6.x is about the same as MS-DOS 6.x in terms of functionality and performance. And Thunderbyte Anti-Virus was excellent, though later on, the DOS scanner that came with Inoculate-It Anti-Virus was also good (it helped me get rid of the Tai-Pan and Anti-EXE viruses in DOS).

You should really try to set a fully working system up with 80 MB hard disk, and 4 MB ram. You soon learn to prune off the rubbish. A full Windows 3.1 install is something like 10-15 MB. Add a 5 MB Dos install, and you have a quarter of the disk taken up, and it does nothing. Civ for DOS is 3 MB, but if you have the multiple versions from the CD on there, this can multiply up to 15 MB. I did a bit of hex editing and cut this down to 5 MB. Any decent windows word processor comes in at 10-15 MB, and a similar layout for a spreadsheet. Most OEM machines come with a couple of MB of rubbish, some marginally useful. NDW comes in at 15 MB, i got it down to just under a half a meg in the end. A programming language typically weighed in in the megs, but most of these were avoidable if you didn't do that sort of thing.

I know the deal, I've been there and done that, even though I was but a child back then. My first PC (the Amstrad 80386) had a 40 MB hard disk, and its successor, the 486, had at best 249 MB, so I know just how bad it was at the time. I even occasionally relive it in my virtual machines, especially in the one in which I do my work on my MS-DOS 6.40 project, and in which I regularly run out of space on just about all 3 virtual drives and have to clean up. It can be quite a pain. And yeah, it's a must to remove anything that you don't really need, otherwise it just uselessly clogs up the hard disk space.

Even the Windows 3.10 resource kit tells you what files are deletable, and how you can patch the install tape see, eg Windoze K7564 which started life during 1994. It's just that reconfiguring Windows on each install, was a bit of a pain, so one just touched up the install tapes, and prehaps did an SI diskette for the rest. (Burning a CD in 1995 was an outsource-thing costing 100$ a stick, and usually involved delivery of a computer with the layout on it. By 1997, the burner was still 600$, and the diskettes were 20$ a disk. One tried not to waste too much on this sort of thing!).

Yeah, I remember the days, and I remember when burning a CD was consider a high-end endeavor that only those with loads of money could afford. It was quite a revolution when one day, blank CD's started costing like €1/piece and anyone's PC had a CD writer in it. It took me some time to adapt, I was all too used to the old system of using 3.5" floppies as the primary removable storage.

[WinPC]

The problem here is that none of these operating systems handle everything properly. I mean, they all have their various advantages and disadvantages.

For example, MS-DOS and Windows 3.x were not quite as stable as OS/2 or Windows NT, but they were very lightweight, and could accommodate low-end hardware a great deal, not to mention compatibility with nearly all applications on the market, something which the other operating systems had trouble with.

OS/2 and Windows NT both, on the other hand, had greater stability, as well as high performance on a powerful enough system, making them excellent to use in corporate environments. And OS/2 from OS/2 2.0-onwards was apparently more consumer-oriented than Windows NT was (although also perfectly suitable for business use), whereas Windows NT was aimed strictly at businesses for use on workstations and servers.

Both had generally good compatibility with existing programs, but they also probably introduced new issues, including probably compatibility with existing hardware (at least with Windows NT, which required a relatively powerful system and did not run so well on lower-end hardware), as well as with compatibility with certain existing software (again, Windows NT had problems in that regard; in testing its pre-release builds, I found several compatibility issues with certain DOS-based programs that could only be fixed by booting back into MS-DOS 6.0).

You also had the FAT disk format, which could only support up to 2 GB of disk space on a single partition, as well as the proprietary HPFS and NTFS formats, which supported much more theoretical disk space, but were not compatible with DOS, Windows 3.x, or even Chicago, later Windows 95 (which at the time was still in development).

And as Battler pointed out, all of the DOS-based operating systems had their issues. I mean, probably, MS-DOS had certain features while DR-DOS and IBM-DOS had other features, etc...

And finally, which operating system is "better" is entirely subjective. While I greatly appreciate the fact that MS-DOS and Windows 3.x offered a great deal of support for current software of the time period, as well as the ability to run on low-end hardware, not to mention being extremely expandable with the amount of feature add-ons released for it while still entirely at the user's own choice (Video for Windows, Win32s, WinG, TCP/IP, etc...), at the same time, I also see where OS/2, Windows NT, and similar operating systems offered a great deal of performance, stability, and security.

I'm not sure about OS/2, but Windows NT 3.1 did not have a "command line-only" mode, which could be rather problematical. I remember while working with a pre-release build of Windows NT 3.1 (I believe that it was Build 404, but it might have been Build 438), I had installed a network driver that caused the operating system to crash whenever the system was booted up (basically, a blue screen STOP error). The only way that I had of fixing this was to boot the system with an MS-DOS 6.0 boot disk and rename the .SYS file to something else so that it wouldn't load. And had the attempt at converting the drive to NTFS some time earlier been successful, I wouldn't have even been able to do that.

On the other hand, Windows NT was much more stable and secure than MS-DOS and Windows 3.x were, by a long shot, making it an excellent choice for a workstation or server, especially when dealing with mission-critical applications, as well as projects that merit a great deal of hard work and high performance. And OS/2, from what I can see, was probably very similar in that regard.

All in all, there is no real "one size fits all" approach for any operating system in this case, especially during this particular time period. It really all depends on what your needs are, and what products that you happen to be using it with.

[3155ffGd]

I'm not sure about OS/2, but Windows NT 3.1 did not have a "command line-only" mode, which could be rather problematical. I remember while working with a pre-release build of Windows NT 3.1 (I believe that it was Build 404, but it might have been Build 438), I had installed a network driver that caused the operating system to crash whenever the system was booted up (basically, a blue screen STOP error). The only way that I had of fixing this was to boot the system with an MS-DOS 6.0 boot disk and rename the .SYS file to something else so that it wouldn't load. And had the attempt at converting the drive to NTFS some time earlier been successful, I wouldn't have even been able to do that.

The final version of Windows NT 3.1 has Last Known Good to counter this very problem.

[DeFacto]

@WinPC: it seems that on one hand you're against updating files from the build/etc, and yet on the other hand you cry about missing features that weren't there in the build originally...

[WinPC]

@WinPC: it seems that on one hand you're against updating files from the build/etc, and yet on the other hand you cry about missing features that weren't there in the build originally...

This was a third party network driver, and was not actually shipped with any version of Windows NT 3.1, at least not as far as I know. So really, nothing from Windows NT 3.1 was replaced; all of the operating system components were the same. When I mean components, I'm not usually talking about drivers for different pieces of hardware (unless a compatible one exists from the same time period or earlier), but rather about kernel components, .DLL files, applications, and so on.

Also, 3155ffGd, you are correct. However, I still agree with Battler that DOS and Windows 3.x still had the major advantage of a basic command line mode during the 1990s. I mean, certainly, it was theoretically possible for Windows NT 3.1 and NT 3.5 to have one also, but from what I see, it was probably left out due to Windows NT having a highly specialized purpose during that time period.

[DeFacto]

By "features that weren't there originally" I meant the CLI (which NT lacks), not the network drivers you used...

[WinPC]

By "features that weren't there originally" I meant the CLI (which NT lacks), not the network drivers you used...

I wasn't complaining about Windows NT at all, I was just stating the advantages and disadvantages of both operating systems, with Windows NT having the better security and stability, and MS-DOS and Windows 3.x having better support for current programs (current for the time period) and being easier to service. Either way, the two operating systems were excellent, but they were targeted at different audiences, which is probably why these issues exist.

[os2fan2]

I find it rather astounding that a deeper study of OS/2 has not taken place, since much of Windows comes from OS/2.

Both the Win16 and OS/2 16-bit use the NE format of executables. In any case, it's not really hard to change a line in a header file and a few linkins to crank out Win16 stuff from OS/2 and vice versa. One might look at 'Idlewild' in the WEP 1 package for confirmation of this.

Progman is a direct recompile of PMEXEC code, down to the icons. The claim that PMEXEC and PMFILE originated in IBM UK as an OS2 app is official documentation, not third-party sprook. In fact, it is the icons and general furniture in OS/2 1.x and Windows 3.0, which is the dead giveaway. Icons etc are the sort of thing one pays graphical artists to wrangle, and don't give them out for a song. That PMEXEC annd PROGMAN are using the same icons is enough to suppose the same code is in use. Microsoft certianly had access to the code, and at the time, it was 'OS/2 on the server, Windows on the workstation', complete with a common interface.

I mean, how hard is it to replace the group manager in pmexec from opening a nested list to opening 'documents' (.grp files), and then opening 'objects' in the document? Progman is meant to be an advert for the MDI interface and the DDE interface. SysEdit and Winfile both have MDI, but no one else does: each new instance of a .wri file is a new copy of write.exe. Windows clipboard is quite capable of transferring data from one proggie to another. Likewise, linking help to a winhelp document, rather than a view document does not prove anything either. I mean, if you use IVIEW for windows renamed as view.exe, (in the early ObjectREXX/Win stuff), and then run an OS/2 program, its help is launched in the Windows view. There's no really black magic here.

4DOS is recompiled first to 4OS2 and then 4NT, all off the same code. 4NT long ago lost the DPATH command that OS/2's CMD.EXE and 4OS2 has, but it keeps rexx support and EXTPROC support, both inherited from the OS/2 code. Even in the source-code of DOS 6, doing rounds on the internet, there are '#ifdef os2' statements, even in deltree. This tells us that one could compile the msdos 6 deltree command for OS/2 as a 32-bit OS/2 thing.

If you run PMEXEC in the Presentation manager for NT (3.51 or 4.0), it will actually fetch, by DDE, the groups installed in the Windows shell.

Microsoft even recompiled most of the Windows 3.1 utilities under the WLO project, for OS/2, including Winhelp. One might even look at PMWord and PMExcel to see that they're straight recompiles of the Windows code.

I'm not sure about OS/2, but Windows NT 3.1 did not have a "command line-only" mode, which could be rather problematical.

Setting 'SET PROTSHELL=C:\OS2\CMD.EXE' and 'SET RUNWORKLPACE=C:\OS2\CMD.EXE', is the ticket to run OS/2 in a single full-screen command-line session, rather like DOS pre-windows. You can't run PMSHELL from this, but you certianly can run QEDIT/2, FC2, RAR2 and a lot of other things from here.

PROTSHELL loads the user-interface. This could be completely text-mode, (cmd.exe), or gui (pmexec). Windows loads a protshell by default, and there is little way to change that. In Windows, this is partly included in Explorer.exe, but there is no specific Windows 3.1 proggie that replicates protshell. Maybe gdi.exe?

RUNWORKPLACE is the user shell. Just because you have loaded pmshell as the gui manager, you can still load your own windows manager. In Windows this roughly corresponds to 'shell=' setting in system.ini [boot]. You can even load cmd.exe as the runworkplace. When i set my cd-rom burner up, the runworkplace=filebar.exe. This is a small bar at the top of the screen, which contained a menu, like the mac. When one started an app, the app still collected its icons and windows furniture from protshell. filebar took up much less space than pmshell, since it was not drawing all of the icons etc. This freed up memory for the burner program (gear/os2.).

One should really check out the IBM EWS for OS/2. They were way ahead of what Windows is doing today. The closest thing that Microsoft has is 'powertoys', and they did their hardest to disable them. TweakUI for Vista? - ha. Even the XP version went through two re-writes, and the XP64 version is third-party only.

For example, there's BOOTOS2. This pretty much does for OS/2, in less than 1 MB, and ten years earlier, the sort of thing that BartPE was doing. That means, you could build a lightweight OS/2 session to do a memory intensive thing, or build a bootable disk / partition under 20 MB, that allowed you to recover failed data. BartPE never got down to 20 MB, the smallest i heard was 77 mb, although the one i was making was at the 120mb range. BOOTABLE is much more capable.

In the early days, one could make a single boot disk to boot OS/2 entirely off it. What you get after feeding three or four of the diskettes supplied with WinNT, is not Win32 at all. Win32 can not boot off floppies, unless you're going to put sixty of them in. You get a hacked version of VMS, which is completely unable to run DOS, Windows or OS2 programs not specifically written for that thing.

There's MSHELL and TSHELL. These are really tiny shells that you can load in a PM protshell or CMD protshell, which in essence give you a menu on the left, and running tasks on the right. So you could easily swap to a running task or end it or whatever.

There's TINYEDIT. This is a really tiny editor (9K DOS and 10K OS2), that you can stick on a boot diskette, and edit an errant OS/2 boot file.

Then there's CDD.SYS. Not so much EWS, but this nifty driver gives room in an OS/2 boot, to pause the boot so you could edit config.sys etc in a full CMD session. It is a proper OS/2 line, so the utilities that work in the OS/2 command line, work here too (except those that rely on PMSHELL services).

Then there's UPDCD, a project that allows you to slipstream service packs into OS/2. OS2 comes with different kinds of service pack: the device drivers live in a different (shared) service pack. So, you could update the drivers in an older system, even though the base installs are no longer being done.

How exactly does Microsoft copyright affect other people's ability to write their own menu software for DOS? And I don't see how Program Manager doesn't do just the same - pointing you off to a number of applications, and games.

It did not stop them writing their own menu software, but selling them to the mid-range OEMs. In essence, Microsoft used the outcome of a case 'Monty Python vs ABC' or something, where ABC reduced an MP episode to fit their ad requirements, and MP complained that it ruined their art. Microsoft used the result to suppose that turning the PC on to boot into DOS and then Windows and then PROGMAN, was its 'art', and that OEMs that were licencing DOS and Windows shells were ruining it. Packard Bell used to launch DOS/Win/OEM Shell, or DOS/OEM Shell, before this, and companies like Norton and WilsonWindowWare and Becker were making good money getting OEMs to launch into their own shell in place of progman.

So after a certian time, one had to load directly into an unadorned Windows. It does not stop people putting their own art on top of it later, but the first boot had to be into dos/windows/progman.exe.

IBM never had that problem with OS/2. The redbook 'OS/2 2.11 Power Techniques' spends a good deal of time discussing how to introduce different shells to OS/2.

Well, yeah, putting groups inside groups was not possible in Program Manager, which is one of the things the Windows 95 desktop interface improved on it.

Well, it's really like if the root directory contains only directories, and these contained only folders. No, one provided depth in the menu to put less-used things in a deeper level. You look at any period menu system, and one is not just restricted to a pull-down list of commands. I mean, even dear old Mutly (multimate), had layers of menus. It ran 29th out of 29 in a magazine survey.

It is precisely this reason, and that you could not place things on the desktop, like you could on the Mac and OS/2, that lead to a large aftermarket in replacement shells.

In any case, EXPLORER in Win95/NT4 was nowhere near par with OS/2's PMSHELL, which has a nice set of enhancements in the form of Stardock's Object Desktop (an OS/2 version). This is a set of integrated DLLs and an install file. To link it up, you just ran the install.cmd, and the files would be linked into that desktop. My initial reaction with the NT/95 explorer was that so much was missing that it was pretty laughable. It had some nice features, but there's been a decade of research since progman/winfile, and some of the more recent kids on the block were beginning to hurt msft's grand designs. (ndw springs to mind).

However, it wasn't that bad and it was certainly way better than MS-DOS Executive which it replaced.

Replacing seventies technology with eighties one in a nineties app is hardly bleeding edge. Even Wilsonwindowware's Cmdpost did the msdos.exe thing better than microsoft. msdos.exe was just slightly better than the shell that came with my tandy 100.

Much superior? I think PC DOS 6.x is about the same as MS-DOS 6.x in terms of functionality and performance.

The users who seen both all seemed to agree. PC-DOS 6.x was written primarily for the 386, which is what IBM was flogging at the time. It also used the graphics better. IBM is primarily an OEM, not a software vendor. So they wrote for the current hardware, not something that is dead in the water.

Windows NT was aimed strictly at businesses for use on workstations and servers.

The usual cry from Microsoft in the run of Windows NT 3.x, was 'if you don't know what it is, you don't need it'. The cry from the trade press was particularly scathing about the choice of the Windows 3.x shell (progman/winfile), on the grounds that the familiarity of UI was akin to using 'muttly' as the interface for all word processors. It's not what you call a multitasking UI, and there were plenty of good examples back in the 1990s in the UNIX world.

The thing about calling the command prompt in Windows the 'dos prompt', is as much Microsoft's fault as anyone else. Look at the icon for cmd.exe in WNT 3.x and 4.x, and even in console.dll in 5.0 (2k). This is actually a .cpl in 5.x, so you can 'copy console.dll console.cpl', and you get the icon straight in the control panel, which is a global thing.

In OS/2, you run DOS proggies in the DOS prompt, and OS/2 proggies in an OS/2 prompt. You don't see in the OS/2 mags people talking of the command prompt as the DOS prompt. OS/2 has two command prompts, with different PROMPT strings, (dos = $i$p$g, os2 = [$p]), so you knew even full-screen if you're at the OS/2 or DOS prompt.

On the other hand, Windows NT was much more stable and secure than MS-DOS and Windows 3.x were, by a long shot, making it an excellent choice for a workstation or server, especially when dealing with mission-critical applications, as well as projects that merit a great deal of hard work and high performance. And OS/2, from what I can see, was probably very similar in that regard.

One of the things that kept OS/2 going is that there are plenty of mission-critical stuff that can't afford a workstation reboot. OS/2 was the firstest with the mostest, and much LOB (line-of-business) proggies, expecially mindless ATMs were out there running OS/2 proggies, simply because failure was not an option. Support for Windows 3.1 only just recently ended, because there are an awful lot of appliences out there running Windows 3.1 on DOS. As long as there is no real user input, it's just processing data from the line.

On the other hand, neither Windows or OS/2 are energy efficient enough to survive space. The moon flights were made on programs that you find in your average HP41 calculator - just four of them. Even so, the poor buggers got overloaded, and had to be switched off, and manual control assumed. I wrote a multi-base hp15c calculator clone in a form of basic that makes gwbasic look wonderful and advanced. In all, it took just 6k of code, in a box with a gross addressable memory of 24k.

Once you have your LOB stuff on OS/2 or GWBASIC or whatever, there is little incentive to replace it. The source of LOB code is pretty much something that someone more expert in the subject of the program, rather than coding itself, spent a good time tweaking. Usually, they're moved on, and no longer interested. I spent a good number of days patching a gwbasic program to be Y1999 complient, mostly by removing checks. The name for this is 'dusty decks'. It is not unknown to have emulators running inside emulators running dusty-deck proggies as the LOB demands.

You also had the FAT disk format, which could only support up to 2 GB of disk space on a single partition, as well as the proprietary HPFS and NTFS formats, which supported much more theoretical disk space, but were not compatible with DOS, Windows 3.x, or even Chicago, later Windows 95 (which at the time was still in development).

The tandy 100 had a file system that corresponded to fat5, that is support for a massive 32 files, with a 6.2 name. You could put more onto a device like CAS:, but the in-ram proggies allowed 5 system, and 27 user files, shared with user ram in the same 24k.

fat12 was sufficient for the sort of things that were coming out. It's actually a 16-bit system, but the fat only supports 4096 names, and 65536 sectors (of 512 bytes, gives 32K). It would take many years for 32-k to be exceeded.

The need for a different file-system came during the run of dos 3, around v 3.3 or 3.4. The final form is 'fat 16', allows one to use 65536 names on the disk, and 65536 logical sectors, which could be as large as 32K (ie 64 * 512). The limitation of size then is 9+6+16 = 31 bit = 2G. You can have fat16 larger than this, because Windows supports 64K sectors, but DOS and nearly every one else doesn't

Fat32 uses logical addressing, with 32-bit names over 9-bit sectors. So this gives 41 bits, or 2T. Unfortunately, while windows nt can -read- large hard drives, it can't make them. This is a limitation of NT, in that it supposes that the diskette is restricted to much less (i think it's 4 GB, because it uses byte addressing to read fat, which is how vfat32 works).

Both Windows NT and OS/2 are coming to the same sort of thing that DOS 640k used to: that you simply can't access all of the installed memory, and program data is beginning to get that huge.

MS-DOS 6.30

While we're talking about different versions of MS-DOS, and 'MS-DOS 6.40', it is instructive to look at my project on 'MS-DOS 6.30'. This is a composite 6.20/6.21/6.22 release, bled together into a single package. Simply recomposing it as 6.20 or 6.21 or 6.22, will actually give you binary-identical files for those operating systems.

You can rerun the proggie as 5.0 or 7.0 or 7.1, or 8.0, and do things like test to see if Windows 9x really requires the binary IO.SYS in 7.0 or will anything else do. Microsoft paid out a lot of money to DRI over this particular issue. The expression in the trade press for this was 'diddling edlin', that is, patching edlin so that you could use edlin 3.3 under dos 3.2 or something.

Still, the tape that converts msdos 6.30 into msdos 5.02 or whatever, is simply a 'fc /b' of files, some of which are hand-made, which is then fed into a rexx script, which goes through and modifies the bytes in the file to match. Simple, really. You can even modify it to read '20.45', and try to run the stuff under OS/2.

[venos]

What was happening here was that IBM's BIOS was secret, and while other people could source the same bits and pieces to make an IBM-PC, the key ingredient was the BIOS, which one could not get. This meant that calls not handled by MS-DOS, such as the video layer, were handled differently by different machines. So one had stickers on period softwars, saying 'for IBM compatables' or 'for Tandy' or 'for XYZ'.

A while ago, I stumbled upon what I thought at the time was the source code to DOS. Specifically, I think (my PC is offline U/S at the moment, so don't quote me) it was 3.3 and 6.0. However, to my dismay, they were very, very incomplete, with strange files with the .OAK file extension dotted around, along with a few sources, and many, many object files.

After doing some research, as it turns out, these were OEM Adaptation Kits, or OAKs. That would explain the file extension I saw. Microsoft would partially build the system, but leave certain source files as source files; these would then get bundled onto a floppy disk or 6, and sent to the OEMs, who would then edit and rewrite the code in the source files, and finish the build, so that that specific version of DOS was compatible with their machines. The idea being, that all of the inner workings of DOS, as well as the APIs, were hidden in object files, but the hardware and driver section were freely editable.

As the IBM architecture became more and more standardized, less and less source files were present, and more and more object files took their place. Windows 95 still had an OAK, I think, however shortly after, the idea of the OAK was dropped completely, as almost all PCs were now fully IBM compatible, at least on the source code level, and such kits were no longer of any use. This is ultimately what I believe may have killed all of the different PC variants.

As a matter of course, and largely off topic, as I have two of these OAKs, as soon as my PC is working again, I shall upload them to the FTP. I don't know what category they'd fall under, as they're not full source code leaks, however nonetheless.

[DeFacto]

I believe both of the OAKs you mentioned are on the FTP, but I'm not sure...

[os2fan2]

Here goes the comparison of the supplement utilities of PC-DOS (IBMDOS 6.00) and MS-DOS (6.22), with adjustments for later versions etc. Setup utilities (expand, unpack2, xdf, xdfcopy), not included.

D67 = DRDOS 6, 7
P567 = included in PC-DOS 5, 6, 7.
M567, included in MS-DOS 5, 6, Win9x.
W3 included in Windows 3.x

MSDRIVERS is a package of drivers that Microsoft included in most moving targets up to 1998.

• BASIC: P345, M34. DOS clone of default 8-bit computer-shell. inc GWBASIC.
• QBASIC: QBASIC 1.0 has .BAS files, Editor. This made it into OS/2 and Winnt 3,x 4.x
• INTERLNK: P567, M6, DOS parallel-cable transfer utility.
• EJECT/DRVLOCK P567, etc: Control over removable media only in PC-DOS 5.02 and later.
• MSD: M67, W3, Windows 95 and 98 contain updates to MSD. From MS-OFFICE.
• QCONFIG: P67, EWS opposite to MSD. IBM has MSD in its W3 releases.
• MSDRIVERS: P567, M567, W3 package of himem, emm386, mouse, ramdrive, mscdex, smartdrv.
• DOS6EXE: P67, M67, Choice, deltree, move: do not have specific versioning attached to these.
• DOS7EXE: P7: acalc, crc, dynaload. extension of DOS6 package
• QBASIC 1.1; M6, M7 Updated to read help files.
• UNDELETE: M6, M7, P6, P7: MS did not start, requires DLLs loaded. PC loaded under Windows NT
• WNUNDEL: M6 P67. PCDOS is a more recent version, and remains so.
• DEFRAG: M6, PC67 Norton speedisk, M6 checks DOS version
• SCANDISK; M67. Win9x version handles LFN, Fat32.
• MEMMAKER: M6, IBM has RAMBOOST. Entirely different approaches.
• MSBACKUP: M6, MSFT uses Symantec, Dagspace.
• NETWORK: M6 network utilities on the supplemt disks.
• BACKUP: P67, IBM has many more files, (30 in the DOS set vs 10), IBM uses centre-point,
• SCHEDULE: P67, Sheduling utility.
• PCMCIA: P67, Early kind of USB (hot-mounting hardware)
• PEN: P67, PEN for DOS.
• MSAV: M6, uses CPAV, but hacked. Not very good.
• IBMAV: P67, features large push-button. IBM released versions for OS/2 as well. Runs in DOS 5.
• E EDITOR: P67, dos clone of EPM. P7 supports mouse, menus.
• ADOS: P6, On the MS supplemental disks, but seems to be a filler: IBM funded it.
• DOSSHELL: P67, M6, Microsoft's version moribound from v 6.0 onwards. Both similar to DOS 5 version.
• EDIT2: M7, Win9x editor, runs under DOS 3.3 and later.
• REXX: P7, Rexx processor and support from PC-DOS 7.0. Intended for 6.3, but failed the cut.
• FILEUP: P7: compare and update files in two directories, based on date.
• VIEWIPF: P7 A help system using the OS/2 style INF help files in DOS 7.0
• D??SPACE: M6: disk compression system: Stacker-infringing.
• SSTOR: D6 P6, disk compression system: Woofdom personified.
• STACKER: D7, P7 disk compression system

Failed and misdirected packages include. The dos version was when the app ran or was intended to run.

• MANAGER: M3. A DOS clone of the default Windows shell. 'MS-DOS Manager' OEM release.
• WPSDOS: P67. IBM was readying a clone of the Workplace shell for DOS. Did not make the cut.

[os2fan2]

I actually dismantled every DOS 5.x + into these packages. The packages seem to be entirely independent of each other: that is, you can run Schedule without PCMCIA etc, and they don't seem to require cross-linked files (ie there are few instances where XYZ.OVL is required in two packages.

I've also disuaded Staker 4's editor from using the name 'ED'. It now uses 'SE' (staker edit).

[The Distractor]

I believe both of the OAKs you mentioned are on the FTP, but I'm not sure...

6.0 is not, and I know a 3.x is but i forget what 3.x OAK is on the FTP.

[Battler]

I just found these images on Google...

This is Central Point Backup: http://www.atarimagazines.com/compute/issue124/3-1.jpg .
This is Microsoft Backup: http://www.smartcomputing.com/images/sm ... 3n1204.jpg .

The user interface looks the same to me, showing Microsoft Backup from MS-DOS came from Central Point.

Edit: This is Microsoft Defrag: http://upload.wikimedia.org/wikipedia/z ... MS-DOS.png .
It even says Copyright Symantec, technology from Norton Utilities. Note how the user interface is quite different - no title bar, for one.

Edit: Seems both of us were wrong, the MS-DOS 6.22 MSBACKUP .OVL files contain this copyright string: (C) Copyright Quest Development Corporation 19916.00.00 02/26/93 06:00 am fInAl 02/26/93 . So it seems Microsoft Backup comes from Quest.
Edit #2: Accotring to Wikipedia (http://en.wikipedia.org/wiki/Quest_Development), Quest developed Norton Backup for Symantec and held the entire ownership on the code, so you were right.

The PC DOS Backup files are clearly named CP* though, so they come from Central Point.

[os2fan2]

CPBACKUP uses stac compression, and contains copyright strings from novell and from iomega, but does not mention Norton. My suspicion is that someone (Quest) wrote the logic for backup programs, which could be mounted on a compression driver. IBM's compression (we're looking at 6.30 here), is licenced from Stac, while Microsoft's uses software from dblspace and drvspace. (this is why you can download dblspace for 6.22, to access earlier compressions).

For example, see DBLCONV.EXE and its DBLCDESC.TXT to see the role that msdos compression and backup are related.

[os2fan2]

I suppose this ancient table has a place here too. It's a version table for the MSDRIVER package. This was released with nearly everything that moved. For example, MSD appeared first with WinWord. Anyway, here's the package contents.

Values in brackets are virtualised. For example, there is no dos mouse.com or mouse.sys for 8.30, but it exists in Windows 9x. This prevents mouse 8 updating it, but allows mouse 9 to do this.

Code: Select all

                                   Emm   Ram  Smart
                Pk         Himem   386  Drive  Drv  Mouse  Mscdex  MSD
   Win286  2.11  C 880527  1.0           2.04  1.05
   Win386  2.10  C 880907  2.04          2.10  2.10
   DR-DOS  3.40  C 890630           ?   R1.01
   MS-DOS  4.01  C 890407  2.04   4.00   2.12  2.10
   DRDOS   5.00    900814
   OS/2    2.11    940129  2.10   4.00              (9.01)
   MS-Win  3.00            2.60   4.10   3.04  3.03  7.04  
   B PDS   7.10  U 900624  2.60          3.04  3.03
   MS-Win  3.01  S 901031  2.60   4.10   3.04  3.06  7.04
   MS-WMM  3.07  C 911001  2.60   4.10   3.04  3.06                1.10
   IBMDOS  5.00  S 910509  2.77   4.20   3.06  3.13  7.04
   OS/2 NT                (2.77)                    (8.00) (2.21)  2.00
   MS-DOS  5.00  S 911111  2.78   4.33   3.06  3.13  
   IBMDOS  5.02  S 920901  2.78   4.33   3.06  3.13  8.20          2.00
   MSC     7.00  K 920305  2.78   4.33   3.06  4.00  8.20          2.00
   b 068   3.10    920203  3.03   4.41   3.06  4.00  8.20          2.00 x
   MASM    6.11  K 920305  3.07   4.44   3.06  4.00  8.20
   MS-Win  3.10  S 920310  3.07   4.44   3.06  4.00  8.20          2.00
   MS-WfW  3.30  S 921001  3.07   4.44   3.06  4.00  8.20   2.21   2.00a
   DR-DOS  6.00  C 920407
   MS-Win  3.11  K 931231  3.07   4.44   3.06  4.00                2.00
   MS-DOS  6.00  K 930310  3.07   4.45   3.06  4.10  8.20   2.22   2.01
   IBMDOS  6.00  K 930629  3.09   4.45   3.06  4.10  8.20
   PC-DOS  6.10  K 931116  3.09   4.45   3.06  4.10  8.20
   MS-Fix  6.0a  Z 930601                      4.20
   PC-DOS  6.30  K 931231  3.09   4.48   3.06  5.00  9.01   2.23
   MS-DOS  6.07  C 940101  3.10   5.00   3.07  5.00         2.22   2.01
   MS-DOS  6.20  K 930927  3.10   4.48   3.07  5.00  8.20   2.23   2.01
   MS-DOS  6.21  K 940213  3.10   4.48   3.07  5.00         2.23   2.01
   MS-WfW  3.31  K 931101  3.10   4.48   3.07  5.00         2.23   2.10
   MS-DOS  6.22  K 940531  3.10   4.49   3.07  5.01  8.20   2.23   2.11
   DR-DOS  7.00  C 940126
   PC-DOS  7.00  P 941117  3.15   4.50   3.10  5.10  8.20   2.25
   DR-DOS  7.03  C 980107
   PC-DOS  7.01  C 031002  3.15          3.10  5.10         2.25
   Win-95  3.95  X 950711  3.95   4.95   3.06  5.00 (8.30)  2.25   2.13
   Win-98  3.98  X 990423  3.95   4.95   3.06  5.02 (8.30)  2.25   2.14
   Win-ME  3.99           (3.99)  4.95   3.06  5.02 (8.30)  2.25   2.14

Windows 3.01 and 3.07 are 3.00a and 3.00 mme respectively.

The MS-Fix was an upgrade to the SmartDrv only.  This version incorrectly refuses to load under anything other than DOS 6.  It can be patched to remove this feature.  See below.

Ms Windows 3.10 bld 068 comes with a version of msd that baulks at DR-DOS with the aard test.

Unlike other utilities, the version number for MSCDEX is not stored in text form.  Search the file for MSCDEX, and then look at the bytes proceding it.  Ye will see something like 02 17.  This is the major and minor versions written in hex.  The 17 really means 16 + 7 or 23.  The version is therefore 2.23.

Wfw 3.30 and 3.31 are vers 3.10 and 3.11.

NT and OS/2 dos emulatios derive from DOS 5.0.

MS-DOS does not install the mouse driver if it detects an existing mouse driver present. Ye need to check the source diskettes for said file. 

The mouse driver in PC-DOS 6.3 is not buggy, as earlier thought.  It loads with a large pointer, and it it the pointer as large that is the source of the irritation.  Delete mouse.ini to correct this.

MS-DOS 6.07 is MS-DOS 7.0 beta 1.  It is largely based on MS-DOS 6.00, but has drivers of version 6.20 vintage.  6.27 is allocated to beta 2, which is described in 'unauthorised windows 95'.

PC-DOS 7.10 is an internal version used by IBM and Norton in specific products.  This is largely based on DOS 7.00, with some new files.

Files are usually compressed by one of several means. 


         K    KWAJ    compress v1 (see below)
         S    SZDD    compress v2 (see below)
         U    SZ      mspack (unknown version)
         P            ibm pack2
         C            copy: files uncompressed

Encomp is compress, renamed with version number, to avoid other files of name compress.exe.  Encomp1 is also used to pack older files, eg WLO.

         Win 3.00   SZDD   encomp2 source destin
         DOS 5.x    SZDD   encomp2 sorce destin_
         Win 3.10   SZDD   encomp2 -r source destin
         DOS 6.x    KWAJ   encomp1 -a3 -l -f  source destin
         Win 3.11   KWAJ   encomp1 -a3 -b -e -l -f source destin
.
DOS forms of compress do not store the file extention, eg expand edlin.ex_ will give edlin.ex, not edlin.exe.

The following files are to be used in the DOS and Windoze sets.  The set in the drivers directory will be the PCDOS 7 example.

                                Emm    Ram   Smart
                         Himem   386  Drive  Drv  Mouse  Mscdex
   Windoze 3.02  310592  2.78   4.33   3.06  3.13  7.04
   Windoze 3.12  310594  3.10   4.49   3.07  4.21  8.20
   PC-DOS  7.00  171194  3.15   4.50   3.10  5.10  8.20   2.25
   Win-95  3.95  110795  3.95   4.95   3.06  5.00 (8.30)  2.25

Version 4.21 is the modified version of SmartDrv 4.20

Running SmartDrive 4.2 under versions of DOS other than DOS 6

The following text is taken from Brian Livingstone's More Windoze Secrets. pages 89-90.

The story runs like this.  The copies of SMARTDRV in both MS-DOS 6.0 and Windoze 3.11 did not complete disk writes before displaying the prompt.  This meant, that if ye turn off your computer when the prompt is displayed, then ye can lose data as SMARTDRV has not finished flushing its buffers.  This was fixed in release 4.2.

But to encourage DOS sales, Microsoft made SMARTDRV 4.2 run only under DOS 6.  This didn't help Windoze users who needed the upgrade, but were happy using DOS 3, 4, or 5.

Independent developer Gary Tessler suggests the following patch, which allows SmartDrive 4.2 to run under versions of DOS other than DOS 6.

  Step 1.
      Exit Windows, take the SMARTDRV line out of your AUTOEXEC.BAT, and reboot.
  Step 2.
      Copy SMARTDRV.EXE to SMARTDRV.OLD, then rename SMARTDRV.EXE to SMARTDRV.BIN.
  Step 3.
    At the plain old DOS prompt, in the directory where SMARTDRV.BIN resides, issue the command DEBUG SMARTDRV.BIN.  At Debug's hyphen prompt, type the following lines:

    s 0 ffff 75 0f b4 30
    nnnn: 6636
    e  86636
    90 90
    w
    q

After the S command, ye will see two four digit numbers.  The second number, probably 6636, is the number ye must use in the E command.  After the E command, ye will see a prompt of numbers, at which point ye type 90 (space) 90 (enter) and the rest.

If anything goes wrong, type Q at any hyphen prompt to quit Debug, then copy SMARTDRV.OLD to SMARTDRV.EXE and ye will be back the way ye were. 

If everything goes well, rename SMARTDRV.BIN to SMARTDRV.EXE.  Use this new version in your AUTOEXEC.BAT.  Microsoft, who knew that people would apply this patch, left in the code, the old routine that tests for DOS 3.3, the version that SmartDrive really requires.