Well, it turns out that I don't actually work for anybody at the moment and haven't since June, February, September last year, 2011/12, 2003/04 or 2002 depending on which of my former associates' ejaculations can be believed. So I guess that they can't object to anything I write on the basis of Intellectual Property ownership, or that I'm bringing the company into disrepute, and so on.
MS had a project to do a multitasking DOS 4...
I'm not entirely sure about this but my recollection of the reference manuals (from an ICL computer) suggest that it also introduced DLLs, OS functions (which were somewhat OS/2-ish) provided by named entry points and so on. In short, it was very much a prototype of ideas that MS reused to good effect some years later.
DR noticed this. Its CP/M-86 was late, expensive and so lost out to MS...
DR had MP/M-80 on bank-switched 8-bit systems: Grey Matter was using one into the 90s. CP/M-86 was the analogue of CP/M-80, CCP/M-86 was to CP/M-86 what MP/M-80 was to CP/M-80. One interesting distinction though was that while CP/M-80 came as a binary BDOS to which the OEM's BIOS was concatenated, all of the -86 OSes (including MS-DOS) were supplied to OEMs as .obj files which had to be built into a bootable operating system using a linker.
It only offered it through OEMs at first. You couldn’t buy it at retail.
DR were an utter pain in the arse to deal with. Not only that but they engendered an atmosphere in which even OEMs would refuse to talk to developers, and I even- while working for one of them- had difficulty getting urgently-needed technical info from one of the programmers when I was on a customer site. In the early days, MS was comparatively open and easy to get along with... but this is peripheral to the main bit I want to talk about.
But IBM co-owns DOS, and it did not lose interest. It continued to develop it for years, including the new features from the embedded MS-DOS within Win9x. The result was IBM PC DOS 7, then PC DOS 2000 (briefly bundled with VirtualPC!) and finally IBM PC DOS 7.1. IBM eschewed MS's editor and BASIC, replacing them with a version of its own OS/2 and mainframe editor E, and replacing QBASIC with REXX. It's an interesting OS.
And unlike just about everybody else, IBM had the source of DOS's BDOS and they did rather more than tweak it so that it called a BIOS in ROM. In the mid-80s I had the unpleasant experience of using IBM RIC cards which were comms processors supported by a realtime executive sitting on top of PC-DOS. And when you scratched the surface- which regrettably I had to do- you found that it relied heavily on parts of DOS being fully reentrant: this was described accurately in Ralph Brown's Interrupt List but I don't think that most people believed what they read.
The interesting question is where did this stuff, which I suspect was introduced somewhere around DOS 3.0, come from? I've seen a suggestion that IBM put code into DOS to support a product called VM/PC on the XT/370 https://en.wikipedia.org/wiki/PC-based_IBM-compatible_mainframes#Personal_Computer_XT/370 and that IBM gave it back to MS so that they didn't have to support it: possibly this is it.
There might also have been stuff in DOS to support IBM TopView, but my understanding is that the major thing that TopView mandated was that programs which wanted to write to the screen had to advertise which area they were interested in using an int 10h function which could be hooked by the TopView TSR if present.
Finally, I don't know how many other of Liam's readers have actually got their hands dirty with this stuff, but there were some real nasties in different BIOSes in the IBM AT era since some of them did things like invoking int 15h before EOI while others did the EOI first. I'm now 62, and I can do without that sort of fun.
Re: Liam on DOSliam_on_linuxJuly 26 2019, 12:17:54 UTC
I know what you mean. I suspect it's like my occasional urge to run OS/2 again. After a few hours failing to get it to install, I remember why I left.
There were several strands of late DOS development that _nearly_ led to a much more capable OS.
Everyone who was there are the time remembers MS-DOS 5/6 and DR-DOS 5/6, with built-in 386 memory management, so you could get ~620-630 kB of free base memory, even with CD drivers, a disk cache, a mouse driver, a regional keyboard with command-line editing, sound card drivers, etc.
With a bit more work you could fit a network stack in there as well.
And both MS and DR bundled decent enough graphical shells.
As I see it, there were 3 possibilities for the future development of DOS.
1. OS/2 -- but it flopped because IBM insisted v1 ran on 80286s. 2. DR-DOS 6, GEOS, DESQview/X: multitasking, an Motif GUI, even X.11 3. Windows
Windows didn't so much extend DOS as replace it with a whole new OS layered on top. GEOS did something similar.
But there was nearly an alternative timeline, where Microsoft's skunkworks project to resurrect Windows didn't happen, and third parties did it instead.
Where by 1990 or so, DOS got networking as standard, multitasking as standard, a GUI based on existing Unix standards, and TCP/IP.
Where it became possible to port *nix apps to DOS, and for DOS to be a useful member of a *nix network. Big servers running *nix, but instead of dumb terminals or X terminals, networked DOS PCs with Telnet, SSH, FTP, X.11 and so on.
If that had happened, Linux would never have been. BSD would have developed instead, but probably as a server OS, not a end-user workstation.
OS/2 2 would probably still have happened, and would have been an expensive alternative to cheap TCP/IP-networked graphical DOS machines.
It's an interesting alternate history, but then I remember how much of a pain it was to configure DOS -- or OS/2.
How much easier Win9x and NT were. How Win9x worked with almost all existing hardware and software, which NT didn't but gave you Unix-grade reliability instead.
MS had a boxed "Workgroups for DOS" product that was fairly decent, controlled by the standard "net use" etc. commands. I'm not sure, but I think I ran it with PC-DOS on occasion.
DR-DOS added more file timestamps and password protection, but the latter was a very weak "security by obscurity".
/However/, one of the things that mitigated against DOS being used as a TCP/IP client was that while all the stacks (or at least the ones I've looked at) had APIs that were broadly based on Berkeley Sockets their actual binary calling conventions were completely different... and by that I mean that WGfD and the DOS clients that came with NT and OS/2, not to mention the DOS API in WfWG and definitely not to mention the stacks from FTP Software and the rest completely lacked binary compatibility.
On the server side, DOS would have been problematic due to limited (documented) multitasking: it was difficult to set up a thread to wait for activity on a specified port or socket.
Re: Liam on DOSliam_on_linuxJuly 27 2019, 09:22:17 UTC
I don't remember that name, but from Googling, MS Workgroups for DOS was just a form of branding for the client I've mentioned.
Strongly agree re the TCP/IP stack compatibility problem. That was a biggie and I should have mentioned it. Even when DR-DOS included a peer-to-peer network, it was not only incompatible with MS peer-to-peer networking, the drivers were incompatible with MS drivers. It was possible to configure it so both types of driver would work in a single stack (either Netware Lite on NDIS, or Windows on ODI drivers) but the result was a machine with so little DOS memory left that almost no apps worked.
And the stacks supported by DV/X are very rare and hard to find these days. The stacks that are still around and work on recent-ish network interfaces, DV/X doesn't support.
DV/X also had a compatibility problem: Unix font filenames didn't fit into 8.3. Quarterdeck had to munge the filenames down, meaning that to port an app, you needed to rewrite the font handling.
This is why long filename support would have been important -- but it came along too late.
I suppose my greater point is that the pieces were there. They didn't come together in time, but they could have.
E.g. if Novell had bought Quarterdeck, rather than Symantec buying them.
Novell, via DR, had a DOS with built-in multitasker bundled with a network stack. QD had a superior memory manager, a richer multitasker with text-mode windowing or an even richer one with graphical windowing.
And Novell had an interest in Linux.
There could have been a 2-level product range here, like MS had with Win9x and NT.
Low-end: DR-DOS, TCP/IP, and a choice of full-screen, text-mode windowed or graphical windowed multitasking depending on system spec and compatibility.
Or, high end, Linux with a compatible network stack and a comparable selection of apps.
As I said... I'm just daydreaming about an alternate universe.
As for the server issue: for Unix-style TCP/IP networking, QD had an answer and could handle that. DV/X was both an X client and server: Unix machines could attach and run DOS apps natively on x86 hardware, but with UI displaying and working on a UNIX machine on SPARC, POWER, MIPS or whatever.
On the DOS side, I put in a lot of 3Com 3+Share network servers. That was a full rich DOS-based server OS offering file & print, over NetBEUI. I also put in SAGE MainLAN, Netware Lite and other DOS-based P2P networks with DOS-based servers, just for file and print. For that, older protocols were fine: NetBEUI, IPX/SPX, DECnet, AppleTalk, all worked.
MS had a project to do a multitasking DOS 4...
I'm not entirely sure about this but my recollection of the reference manuals (from an ICL computer) suggest that it also introduced DLLs, OS functions (which were somewhat OS/2-ish) provided by named entry points and so on. In short, it was very much a prototype of ideas that MS reused to good effect some years later.
DR noticed this. Its CP/M-86 was late, expensive and so lost out to MS...
DR had MP/M-80 on bank-switched 8-bit systems: Grey Matter was using one into the 90s. CP/M-86 was the analogue of CP/M-80, CCP/M-86 was to CP/M-86 what MP/M-80 was to CP/M-80. One interesting distinction though was that while CP/M-80 came as a binary BDOS to which the OEM's BIOS was concatenated, all of the -86 OSes (including MS-DOS) were supplied to OEMs as .obj files which had to be built into a bootable operating system using a linker.
It only offered it through OEMs at first. You couldn’t buy it at retail.
DR were an utter pain in the arse to deal with. Not only that but they engendered an atmosphere in which even OEMs would refuse to talk to developers, and I even- while working for one of them- had difficulty getting urgently-needed technical info from one of the programmers when I was on a customer site. In the early days, MS was comparatively open and easy to get along with... but this is peripheral to the main bit I want to talk about.
But IBM co-owns DOS, and it did not lose interest. It continued to develop it for years, including the new features from the embedded MS-DOS within Win9x. The result was IBM PC DOS 7, then PC DOS 2000 (briefly bundled with VirtualPC!) and finally IBM PC DOS 7.1. IBM eschewed MS's editor and BASIC, replacing them with a version of its own OS/2 and mainframe editor E, and replacing QBASIC with REXX. It's an interesting OS.
And unlike just about everybody else, IBM had the source of DOS's BDOS and they did rather more than tweak it so that it called a BIOS in ROM. In the mid-80s I had the unpleasant experience of using IBM RIC cards which were comms processors supported by a realtime executive sitting on top of PC-DOS. And when you scratched the surface- which regrettably I had to do- you found that it relied heavily on parts of DOS being fully reentrant: this was described accurately in Ralph Brown's Interrupt List but I don't think that most people believed what they read.
The interesting question is where did this stuff, which I suspect was introduced somewhere around DOS 3.0, come from? I've seen a suggestion that IBM put code into DOS to support a product called VM/PC on the XT/370 https://en.wikipedia.org/wiki/PC-based_IBM-compatible_mainframes#Personal_Computer_XT/370 and that IBM gave it back to MS so that they didn't have to support it: possibly this is it.
There might also have been stuff in DOS to support IBM TopView, but my understanding is that the major thing that TopView mandated was that programs which wanted to write to the screen had to advertise which area they were interested in using an int 10h function which could be hooked by the TopView TSR if present.
Finally, I don't know how many other of Liam's readers have actually got their hands dirty with this stuff, but there were some real nasties in different BIOSes in the IBM AT era since some of them did things like invoking int 15h before EOI while others did the EOI first. I'm now 62, and I can do without that sort of fun.
MarkMLl
Reply
There were several strands of late DOS development that _nearly_ led to a much more capable OS.
Everyone who was there are the time remembers MS-DOS 5/6 and DR-DOS 5/6, with built-in 386 memory management, so you could get ~620-630 kB of free base memory, even with CD drivers, a disk cache, a mouse driver, a regional keyboard with command-line editing, sound card drivers, etc.
With a bit more work you could fit a network stack in there as well.
And both MS and DR bundled decent enough graphical shells.
But more was coming...
* DR-DOS 6's TASKMAX, a lightweight multitasker _as standard_.
https://books.google.cz/books?id=Xz0EAAAAMBAJ&lpg=PA85&ots=Is6kRI38p_&dq=%22dr%20dos%22%20%22taskmax%22&pg=PA85#v=onepage&q=%22dr%20dos%22%20%22taskmax%22&f=false
* DESQview/X, a standard X.11 GUI on top of the best, stablest, richest DOS multitasker.
http://toastytech.com/guis/dvx.html
Tech notes: https://archive.org/details/desqview-x-booklet
There were even some 3rd party apps: https://www.cs.cmu.edu/~bmm/dvx.html
* GEOS, a different DOS multitasking GUI:
https://tedium.co/2019/06/20/geoworks-geos-history/
* MS Network Client 3, given away for free with NT -- a standard TCP/IP stack for DOS.
http://www.kompx.com/en/network-setup-in-dos-microsoft-network-client.htm
(
There are others: http://www.jacco2.dds.nl/samba/dos.html
There's a server, too! http://www.windowsnetworking.com/j_helmig/dosservr.htm
)
* Long file names support came to DOS later on, too
https://www-user.tu-chemnitz.de/~heha/hs/what_lfn.en.htm
As I see it, there were 3 possibilities for the future development of DOS.
1. OS/2 -- but it flopped because IBM insisted v1 ran on 80286s.
2. DR-DOS 6, GEOS, DESQview/X: multitasking, an Motif GUI, even X.11
3. Windows
Windows didn't so much extend DOS as replace it with a whole new OS layered on top. GEOS did something similar.
But there was nearly an alternative timeline, where Microsoft's skunkworks project to resurrect Windows didn't happen, and third parties did it instead.
Where by 1990 or so, DOS got networking as standard, multitasking as standard, a GUI based on existing Unix standards, and TCP/IP.
Where it became possible to port *nix apps to DOS, and for DOS to be a useful member of a *nix network. Big servers running *nix, but instead of dumb terminals or X terminals, networked DOS PCs with Telnet, SSH, FTP, X.11 and so on.
If that had happened, Linux would never have been. BSD would have developed instead, but probably as a server OS, not a end-user workstation.
OS/2 2 would probably still have happened, and would have been an expensive alternative to cheap TCP/IP-networked graphical DOS machines.
It's an interesting alternate history, but then I remember how much of a pain it was to configure DOS -- or OS/2.
How much easier Win9x and NT were. How Win9x worked with almost all existing hardware and software, which NT didn't but gave you Unix-grade reliability instead.
I think I'm glad it worked out the way it did.
I think.
Reply
DR-DOS added more file timestamps and password protection, but the latter was a very weak "security by obscurity".
/However/, one of the things that mitigated against DOS being used as a TCP/IP client was that while all the stacks (or at least the ones I've looked at) had APIs that were broadly based on Berkeley Sockets their actual binary calling conventions were completely different... and by that I mean that WGfD and the DOS clients that came with NT and OS/2, not to mention the DOS API in WfWG and definitely not to mention the stacks from FTP Software and the rest completely lacked binary compatibility.
On the server side, DOS would have been problematic due to limited (documented) multitasking: it was difficult to set up a thread to wait for activity on a specified port or socket.
MarkMLl
Reply
Strongly agree re the TCP/IP stack compatibility problem. That was a biggie and I should have mentioned it. Even when DR-DOS included a peer-to-peer network, it was not only incompatible with MS peer-to-peer networking, the drivers were incompatible with MS drivers. It was possible to configure it so both types of driver would work in a single stack (either Netware Lite on NDIS, or Windows on ODI drivers) but the result was a machine with so little DOS memory left that almost no apps worked.
And the stacks supported by DV/X are very rare and hard to find these days. The stacks that are still around and work on recent-ish network interfaces, DV/X doesn't support.
DV/X also had a compatibility problem: Unix font filenames didn't fit into 8.3. Quarterdeck had to munge the filenames down, meaning that to port an app, you needed to rewrite the font handling.
This is why long filename support would have been important -- but it came along too late.
I suppose my greater point is that the pieces were there. They didn't come together in time, but they could have.
E.g. if Novell had bought Quarterdeck, rather than Symantec buying them.
Novell, via DR, had a DOS with built-in multitasker bundled with a network stack. QD had a superior memory manager, a richer multitasker with text-mode windowing or an even richer one with graphical windowing.
And Novell had an interest in Linux.
There could have been a 2-level product range here, like MS had with Win9x and NT.
Low-end: DR-DOS, TCP/IP, and a choice of full-screen, text-mode windowed or graphical windowed multitasking depending on system spec and compatibility.
Or, high end, Linux with a compatible network stack and a comparable selection of apps.
As I said... I'm just daydreaming about an alternate universe.
As for the server issue: for Unix-style TCP/IP networking, QD had an answer and could handle that. DV/X was both an X client and server: Unix machines could attach and run DOS apps natively on x86 hardware, but with UI displaying and working on a UNIX machine on SPARC, POWER, MIPS or whatever.
On the DOS side, I put in a lot of 3Com 3+Share network servers. That was a full rich DOS-based server OS offering file & print, over NetBEUI. I also put in SAGE MainLAN, Netware Lite and other DOS-based P2P networks with DOS-based servers, just for file and print. For that, older protocols were fine: NetBEUI, IPX/SPX, DECnet, AppleTalk, all worked.
Reply
Leave a comment