The many derivatives of the CP/M operating system Its new licence says that "CP/M and its derivatives" are free for anyone to modify and redistribute. But which derivatives? The original Intel 8080 version of CP/M had a relatively brief reign: it appeared in 1974, just seven years before the IBM PC launched with PC DOS. The PC, and its many clones running MS-DOS, rapidly …
Back in the day I was using something called - IIRC - SDOS, or maybe SD/OS which was either a rebadged CP/M or a knock-off. It came with a system built on S100 boards from a company called SD. There seemed to be no difference at all from CP/M except for the name. We accumulated all sorts of freeware, even Algol (probably as a compiler) although the main language used was Microsoft FORTRAN.
SD Systems, perhaps?
For some reason this tickled a node in my lizard hindbrain ... dug through the archived bookmarks and found this:
https://www.retrotechnology.com/herbs_stuff/
The specific page you might be interested in[0] is here:
https://www.retrotechnology.com/herbs_stuff/s_sd.html
That should keep you occupied for the weekend ... pour yourself a beer before digging in.
[0] At least in the context of your post ... lots of other interesting old stuff in those pages.
My first computer was a KayPro II. It started out with CP/M. However, as soon as it became available I switched to ZCPR, a much more powerful CP/M derivative. I thought it was the cat's meow, and used it until about 1990. By that time, the KayPro had gone from 64K to 128K with bank switching (for printer spool and the like), and double sided floppies.
Best wishes,
Bob
I have laid my grubby mitts on Concurrent DOS - cost me NZ$70.00 in 1995 - but I was never in a position to run in as a faux-server with a couple of terminals or so. And what was much, much worse, iirc, it didn't do DOS games particularly well. But I suspect that was because DOS games tend to write to hardware directly, whereas Concurrent DOS, as something that could work as a server terminal, didn't do direct-to-hardware writing.
I would be delighted to get my grubby mitts on the source trees of it and its multiuser "cousin". I might even dig out my old assembler books and have another go at learning 8086 assembler.
I started my professional programming life using CCP/M on some ICL hardware - each hosting 3 users per PC on colour terminals. The 3 ICL PCs were networked with co-ax (100Kb or1Mb?) around the site. We programmed with the Dataflex 3GL using WordStar as the editor writing a stock and repair control system for a large workshop. Must have been around 1985/6 time. I remember having the rebuild the OS for changes in hardware and peripherals, go through an on-screen questionnaire for each item to set the parameters. Kids don't know how easy things are now!
MicroLAN was 1.25 Mbit/sec. It originated on Cogar desktop machines in 1976. Cogar was bought by Singer Business Machines and then ICL bought part of SBM. ICL produced the Cogar machines as ICL 1500 series (not to be confused with the ICT 1500s). The replacement machines were the ICL DRS20 series which still used 1.25Mbit/sec MicroLAN to connect servers and workstations.
I worked on DRS20, including a prototype, using Retained mode (1500 emulation) and Native mode 8085AH2.
The ICL PC2 (8085 and 8086), Quattro (8086) and Quattro-XM (80286 plus bank switching) were desktop machines with serial terminals running MP/M-2, Concurrent-CP/M, Concurrent-DOS or Concurrent-DOS-XM as appropriate. There was a network system available to connect these computers together using DR-NET software over a token ring by connecting to the synchronous port of the machine. I still have one of the adaptors here. It wasn't MicroLAN though.
An enhanced version of MicroLAN was used to connect DRS303 and DRS305 terminals to DRS300 computers or link computers together. It was still 1.25Mbit.sec.
i still have some of this kit laying around here, a ton or two of it was thrown out a year or so ago.
Didn't Microlan use something called "rotating master", presumably to veer round a token ring patent? Or was that the Drs 300 version ?
The whole CPM saga on ICL hardware digs straight into why the company went out of manufacturing. Written as someone who remembers recommending ITT XTRA as the only viable route if you wanted to run Lotus and were an ICL shop.
That sounds like the DRS range of kit, you had it easy, I had to hand build the configuration files in the earlier release. The menu driven configuration program didn't allow us to build the configs we'd been rolling out so I had to edit the files after completing the config. one typo and nothing worked and it was back to square 1.
DOS was not a derivative of CP/M. It did not copy neither source code, nor on-disk structure from it. And mostly everything that CP/M and DOS had in common was also copied by CP/M from other operating systems that "inspired" it, like the TOPS-10, and included things like filename.extension thing, the naming of most built-in command line utilities, or even the concept of an API.
It was merely Gary Kildall who kept insisting that DOS (and really any OS that came after CP/M and wasn't absurdly distinctive in its concept) merely copied CP/M, which was in many ways similar to how Steve Jobs also always accused other OSes having copied the Mac OS - while in reality the Mac OS was also just a blatant copycat of the Xerox Alto (and not Apple's or especially Jobs' invention by any means), just like CP/M was copying the OSes that came before it.
This post has been deleted by its author
[Article author here]
Did I say that PC DOS, MS-DOS or indeed QDOS were derivatives? I did not intend to.
DR-DOS 100% *was* a derivative, yes.
But the _design_ of Paterson's QDOS, later 86-DOS, definitely was. He took the CP/M manual and wrote a compatible OS that used the on-disk data structures of MS' Disk BASIC. This is well documented.
It is also widely misunderstood to mean that 86-DOS was based on CP/M code, which it was not.
> DR-DOS 100% *was* a derivative, yes.
DR-DOS was not a derivative of CP/M, it was a derivative of Concurrent-DOS with (most of) the multi-tasking and multi-user stripped out. C-DOS was a derivative of MP/M-2 via Concurrent-CP/M. MP/M was a completely different set of code from CP/M.
I used (and programmed for) DR-DOS since version 3.0. DRI DOS-Plus (which I have on a BBC Master 512) was also a derivative of Concurrent-DOS and retained some of the multi-tasking. One of the features of DR-DOS was that it would run in ROM because the code segments were 'pure'
I think we interpret inheritance differently.
Concurrent DOS was Concurrent CP/M plus the PC-MODE emulator, which I carefully described in the article with links to documentation.
Therefore, Concurrent CP/M is a derivative of CP/M-86.
Concurrent CP/M was CP/M-86 merged with MP/M-86.
Both CP/M-86 and MP/M are derivatives of CP/M.
That means DR-DOS was a derivative of a derivative of a derivative of the original CP/M.
In my book, a derivative of a derivative, repeated as many times as you like, *is still a derivative*.
So, yes, DR-DOS is 100% a derivative of CP/M.
It is the same as a human being a descendant of another human: whether the ancestor is that person's parent, or grandparent, or great-grandparent, or great-great-great-great-great-grandparent, they remain an ancestor, and the contemporary person remains a descendant. There is no mysterious lessening of descendant status; it doesn't stop applying after 2 or 4 or 8 generations.
The 286 and 386 versions of Concurrent DOS were rewrites. You _might_ have a case there, but DR-DOS inherits from the native x86 version of CP/M which was ported from the 8080.
DR-DOS 7 will boot and run on an 8086. So will CP/M-86. They are both native Intel code, and not protect-mode OSes or anything.
> Both CP/M-86 and MP/M are derivatives of CP/M.
There may well be a case for saying that CP/M-86 is a derivative of CP/M in that the structure of the code of the BDOS and the CCP are much the same and could be regarded as a code enhancement and/or conversion from the original.
MP/M was completely new code. the base code in the system was the interrupt system and the 256 queues. It also had bank switching. The BDOS in CP/M was simplistic and used a single 'thread'. That is once a request was made it ran without interruption until the request was completed. In MP/M and all later multi-xx DRI systems a request was queued and return was made to the system. On appropriate hardware this resulted in the CPU being used for other tasks while the disk was moving the tracks, waiting for rotation and transferring the blocks. At the end of this it signalled that the request was completed and the requesting task was put back on the queue to to scheduled at the next interrupt.
i don't know what you count as 'derivatives'. Certainly all DRI systems had a CP/M-like API, but so did MS-DOS and clones of which there were many. There are even emulators that run CP/M programs on Unix/Linux or Windows.
> DR-DOS inherits from the native x86 version of CP/M which was ported from the 8080.
NO. DR-DOS (and DOS-Plus) derived from Concurrent-DOS, NOTt from CP/M-86. In the original versions it used the same source code tree which was completely separate from CP/M-86.
I have several CONUG newsletters with articles, some written by Gary, that explain this.
> Concurrent CP/M was CP/M-86 merged with MP/M-86.
This is just dogma. Concurrent-CP/M did not need to be 'merged' with CP/M-86, it was MP/M-86 with added multiple virtual screens replacing MP/M's screen switching code. That is MP/M, MP/M II, MP/M-86 could switch terminal sessions using Ctrl-D. This would hibernate the current program and switch to a different session. Concurrent-CP/M could maintain several sessions per screen without having to hibernate the programs that were in background.
> So, yes, DR-DOS is 100% a derivative of CP/M.
It is actually completely irrelevant what you consider to be 'derivatives' for the purposes of this license. The only relevant usage is what DRDOS Inc thinks is "CP/M and its derivatives' and that semms to be entirely CP/M itself plus, probably, CP/M-68K and CP/M-Z8000.
There's lots of confusion about the implications of a right to "derivative" works in the (US) copyright sense both in this post and the article.
In your comment above it's not clear whether you're saying QDOS and 86-DOS are both "derivatives," but let's be very clear that the "_design_" bit doesn't fit US copyright. Copyright protects original* expression not design or function. Design and function are the domain of patent law.
Neither QDOS or 86-DOS would be a "derivative" within the meaning of the copyright law if they were just functionally "compatible" systems based on manuals (i.e., information about their design) because the particular way they were expressed (i.e., literally written) was not copied.
More fundamentally, the article is misleading because an infringing* derivative work isn't forfeited entirely to the copyright holder. For example, the rights to prepare* and distribute* derivative works are separate from the rights about actual copying. A derivative work will typically have material owned by the underlying work's copyright holder and, separately, material that's still owned by the derivative work's author (namely, the original* and protectable* expression that the derivative work author added). You always have to think about those rights and their remedies separately, because that's how copyright works--it's not a single unitary "copyright" but a bundle of rights.
The underlying work's copyright holder remedy is _not_ any sort of automatic right to the infringing derivative work's protected expression. And infringing derivative works aren't punished by making them public domain. (In general, copyright law is not meant to be punitive, even if that's sometimes the result.)
* indicates legal jargon; like the word "derivative" they indicate legal conclusions that can't be reached until various requirements, doctrines, and exceptions have been applied. As with the word "derivative," it would be a serious mistake to assume their meaning is obvious without an understanding of copyright law.
Disclaimer: I happen to be a lawyer, but this is just my personal opinion. It's not legal advice and should not be relied on for any purpose. You shouldn't believe anything you read online, anyway.
Thanks for that.
It is not completely clear to me if you are replying to me, or to GF22, or to Richard Plinston.
I am not maintaining that any SCP, MS or IBM flavour or variant of DOS is derivative of CP/M.
However, I *am* maintaining that CP/M-86, MP/M-86, DR-DOS and the other DR OSes that are not protect-mode rewrites *are* derivatives. Written by the same company, based on the same code, possibly ported to other CPU architectures.
The original CP/M-80 was written in a Pascal-like high-level language designed and implemented by Dr Kildall: PL/M. This was in principle amenable to automated translation to Pascal, and the Pascal dialect DR used was also a DR product, so they could modify the language or compiler if needed.
So it is plausible that even the high-level-language ports and rewrites of CP/M did use some original code.
> based on the same code,
While CP/M-86 may well be based on some of the same PL/M code for the BDOS, with modifications to handle the segmentation required by the 8086, MP/M, MP/M II, and the various Concurrent-xxx and further derivatives of those were complete rewrites with no common code.
The BIOSes were also completely different code, some of the utilities may have been retained.
Even DR-DOS was a derivative of Concurrent-DOS (with multi-tasking/user removed) and was _not_ a derivative of CP/M-86 with FAT and .EXE support added.
> DOS was not a derivative of CP/M
CP/M was developed on DEC machines when Gary was contracted to work for Intel to write a PL/M compiler that ran on DEC to produce 8080 code, so of course it looked like other DEC software.
QDOS (Quick and Dirty OS) was Patterson's original port of CP/M to the 8086 in order to develop an OS for the 8086 version of the SCP Zebra. SCP were full DRI OEM licence hoders with all the CP/M source code that DRI would release (as were Microsoft for the Z80 Softcard that was their major revenue in 1980). The CP/M BDOS was written in PL/M and DRI did not release the source code for that but there were 'annotated decompilers' available for CP/M 1.3 that produced 8080 assembler code from the binary. There was also an 8080 to 8086 translator provided by Intel that would convert the assembler code. It is alleged that this is how QDOS was originally developed. It was brought up on a 8086 Zebra initially by creating a CP/M disk with the QDOS OS on it and then switching processor borads and booting QDOS, thus this did have the CP/M disk format. Later Microsoft provided the FAT disk system from 'Stand-Alone BASIC and this was incorporated to create 86-DOS (otherwise known as SCP-DOS) which was licenced to ibm and MS.
It is alleged that Gary Kildall was able to bring up a DRI copyright message on a PC-DOS 1.0 system and IBM settled with DRI by agreeing to sell CP/M-86 alongside PC-DOS (but never updated from 1.0), gave him money, and rewrote the BDOS to create PC-DOS 1.1 and MS-DOS 1.25.
Having used 86-DOS and having perused through the 86-DOS documentation, my impression is that 86-DOS was more of a clean sheet implementation than what you imply. What was copied from CP/M was the API, with system calls using pretty much the same function call numbers and registers as CP/M to allow fairly straightforward translation of CP/M assembly source code for Z-80's to 86-DOS assembler. The difference was that the native cal interface was to use INT 21H as opposed to a jump instruction to 00H (memory is fuzzy on the exact address). 86-DOS did have a compatible jump sequence which then called the INT 21H interface.
FCB's were used for API compatibility, but file sizes were known to the individual byte and not to the individual sector. The FAT's borrowed from M$ Disk BASIC were very different from CP/M's file handling. 86-DOS did have a utility "READCPM" specifically for reading CP/M formatted disks.
86-DOS was a bit more UNIX like in the command structure than CP/M, the COPY command worked more like "cp" in UNIX than "PIP" in CP/M. The "CON", "AUX" and "PRN" were treated more like files than in CP/M. COMMAND.COM had a lot more internal commands (e.g. COPY, ERASE, support for .BAT files) than the CP/M's command interpreter.
86-DOS did not freeze when attempting to read/write from an open floppy disk drive.
The assembly code translate utility shipped with 86-DOS was designed for translating Z-80 assembly code to source code for the 86-DOS assembler - which was really fast.
DEBUG.COM was mostly an expansion of the monitor code on EPROM used on SCP computers.
OTOH, I have no doubt that Tim Paterson was using a CP/M machine to bring up 86-DOS, presumably with a version of the 8086 assembler written to run on CP/M.
> COMMAND.COM had a lot more internal commands (e.g. COPY, ERASE, support for .BAT files) than the CP/M's command interpreter.
Yes, on an 8086/8088 there was usually much more RAM than on a 64Kb (or less) 8080/Z80 machine so utility code could be incorporated in a larger CCP. CP/M did have a SUBMIT utility though.
> 86-DOS did not freeze when attempting to read/write from an open floppy disk drive.
No, it crashed the program!! On CP/M the BDOS checked that the _correct_ disk was inserted. MS-DOS (at least until 3.1) did not check, if a disk with open files was swapped then MS-DOS would happily overwrite this new disk and corrupt it.
> The FAT's borrowed from M$ Disk BASIC were very different from CP/M's file handling.
Yes it was and it was very slow on large random accessed files. I developed COBOL applications for business that could run on DRX (DRS20), MP/M, Concuurent-xxx. These used ISAM files for their data. When ported to MS-DOS they ran really slow compared to the DRI based systems. The problem was traced to the FAT index. Every random access had to start at the first block of the file and track down the FAT table to get to the data block requested. Using DR-DOS to format the disk allowed me to increase the cluster size to 8K while MS-DOS FORMAT only formatted to 2K clusters. This reduced the FAT table access by 4 times and gave an overall performance increase of 3 times.
The CP/M based file systems were archaic but accessing randomly gave a reasonable performance because each directory entry had a larger range of blocks and thus fewer disk accesses.
Unix/Linux INode systems are much better at random access to files than either of those above.
According to Kildall what happened was an artifact of the times.
86-DOS wasn't a port of CP/M. It was a re-write that used the same API. Gary told me several years later that he didn't think it was a direct rip-off, just an unauthorized use of the published API. Back then, such use wasn't codified into law, wasn't illegal, and in fact it was completely normal. SCP was legally allowed to do what they did, and MS was legally allowed to purchase it and re-license it to a third party. Just as MS did later with AT&T Version 7 UNIX, which MS distributed as Xenix ... and everybody+dog did porting BASIC to all and sundry.
Trying to vilify somebody for actions back then based on today's law (or even worse, perceptions) just makes one look silly.
RIP Gary, you cantankerous old fart
> Just as MS did later with AT&T Version 7 UNIX, which MS distributed as Xenix ...
Actually, MS Xenix predated 86-DOS/MS-DOS by a couple of years and wasn't 'later'.
> and everybody+dog did porting BASIC to all and sundry.
'Porting' usually refers to using a particular set of source code and modifying it to run it on a different OS or machine. The BASIC language was originally developed by Kemeny and Kurtz in 1964. Many somewhat different languages were later developed and called BASIC even if they were fundamentally differernt from K&K's. While MS did *port* their MS-BASIC to many different machines, including the Apple II (in conjunction with Applesoft) i doubt that company could be called 'everybody+dog".
The word you were grasping for is probably 'implementing'.
Xenix shipped for the first time in January of '81, but it wasn't yet Microsoft. It was plane-jane Version 7 UNIX, as shipped by Bell Labs. Second ship was March of '81, still plain-jane Version 7. That was the only two ship dates for Xenix before MS-DOS in August of '81. So technically you are correct, in that Xenix came first ... but it was hardly a blockbuster big seller. And it was Xenix in name only. A rose, by any other name ...
I know what "port" means. And that's what it was ... Everybody (nearly!) used existing source code as a reference and framework when implementing[0] (happy now?) their version of all kinds of programs on new hardware. Including various versions of BASIC. Source wasn't nearly as jealously guarded as it is today [0], making this kind of thing normal.
[0] Despite the efforts of Bill Gates ... I have a first-gen Xerox[0] of his "Open Letter to Hobbyists" in my trophy case.
[1] I'm allowed to use the term ... it was actually from a Xerox machine at SLAC.
> And it was Xenix in name only
Microsoft had licenced the use of Unix source code in 1978 but did not have a licence to use the name UNIX so it called it XENIX. Yes, that was its name. MS announced the product in August 1980.
> Everybody (nearly!) used existing source code as a reference and framework
Microsoft was very protective of its source code. While many were implementing some form of BASIC, usually incompatible, they were not doing so by using MS source code. The implementations of MS-BASIC on many different machines was done by MS themselves or under strict licence conditions. Even DRI had its 'Personnal BASIC' which owed nothing to MS source.
You should note that Bill gate's letter was complaining about the distribution of the binary loadable BASIC interpreter (initially on paper tape) and not of the source code which was only ever on DEC machines where it was cross-compiled to the target machine.
"That was the only two ship dates for Xenix before MS-DOS in August of '81."
MS-DOS 1.0 was a very slightly modified version of 86-DOS 1.14, with earlier versions of 86-DOS shipping in late 1980. SCP was licensing 86-DOS to other companies making 8086 systems running on the S-100 bus, specifically Lomas Data Products. The LDP ad in the June 1981 issue of BYTE featuring 16 bit OSes was the only reference to what was to become MS-DOS, with the ad referring to it a SCP-DOS.
I beg to differ. The original versions of MS-DOS, pre 2.0, used CP/M system calls. Version 2.0 added pseudo-Unix calls but still retained the 'jump around' backwards compatibility, the reason for the "A20 switch" that I think even exists in modern Intel x86 processors.
The only improvement MS-DOS made over CP/M was a single disk format. CP/M floppy formats were vendor specific although there was a neat program for the PC ("Uniform") that allowed to you access them.
Incidentally, CP/M stands for "Control Program/Monitor" and should be a good guide to exactly how (un) complicated this piece of code is.
> The only improvement MS-DOS made over CP/M was a single disk format.
The IBM PC originally had 5.1/4 160Kb disks, 320Kb double sided, then 180Kb 9 sector and 360Kb double sided. The IBM PC Jnr had 3.5inch 720Kb while the AT had 1.44Kb.
While PC clones followed the IBM formats. other manufacturers made MS-DOS machines that were not clones and they had a variety of different formats. There were utiliiites that could read these various different formats, just as there were for CP/M, granted there were much fewer for MS-DOS.
With hard drives MS kept the 32Mbyte paritition limit well past its 'use by' date and this led to various PC manufacturers (Compaq, Wyse, etc) and drive makers changing their versions amd/or drivers to support larger disks in incompatible ways. It was IBM that eventually rewrote the code into PC-DOS 4 and passed this back to MS to make 4.01* that finally made compatible hard disks with >32Mbyte partitions.
* not to be confused with MS-DOS 4.0 and 4.1 which were [sort of] multi-tasking versions also referred to as 'European DOS' because they were used by Siemens and ICL as well as Wang.
> CP/M floppy formats were vendor specific
CP/M came out when 5.1/4 disk drives were very new and the electronics for drive controllers were slow and expensive. This meant that 'tricks' had to be used to get the best performance for the least cost.
Some used variable speed drives (eg Apple II), some used hard sectored disks with 10 index holes (eg North Star) because the controllers could not keep adequate timing from a single index per revolution. Most could not read or write sequential blocks, they were to slow to be ready so if the blocks were sequentially numbered around the track it would take 8 revolutions to read a complete track. By interlacing and numbering as, say, 1,4,7,2,5,8,3,6 it would only take 3 revolutions. All these were vendor specific.
By the time the IBM-PC and MS/PC-DOS came out 7 years later the controller electronics were much more capable and these tricks were no longer required.
Many things in your post are incorrect.
1. The Apple II did not use variable-speed drives. You are probably thinking of the much later Macintosh.
2. The first 5.25" floppy disk controllers were no slower than later later ones* and hard sectoring was not because controllers were too slow to do soft sectoring. All controllers were capable of reading and writing a full track in a single revolution: this is exactly how formatting a diskette works. Most programs for doing a sector-by-sector copy of a disk read tracks – whether the sector numbering was interleaved or not – in a single revolution as well.
3. The interleaving was due to the _operating systems_ being slow because they weren't willing to dedicate buffer space for a full track and were otherwise too slow to finish their own processing of a sector _after_ it had been read into memory but before the next sector came up. (The FDC was perfectly capable of immediately reading the next sector if the OS/application had been ready to do so.)
4. The NEC D765AC FDC used in the original IBM PC was not significantly more capable than early chips such as the Western Digital FD1771. The improvements in FDCs between the mid-'70s and early '80s were mainly in integration and requiring less support circuitry.
*Modulo the FM vs. MFM thing, and support for even higher densities, which I won't get into here. Note that the very early Western Digital FD1781 even supported double density because it used external modulation and demodulation circuitry; later chips that had higher levels of integration and brought this circuitry into the chip were often less capable than this because they didn't use modulation circuitry capable of supporting double-density operation.
> 1. The Apple II did not use variable-speed drives.
Yes, they did. https://collections.museumsvictoria.com.au/articles/1087
> hard sectoring was not because controllers were too slow to do soft sectoring.
https://en.wikipedia.org/wiki/Hard_sectoring :
"""Data read and write is faster in this technique than soft sectoring as no operations are to be performed regarding the starting and ending points of tracks."""
One is faster the other is slower!
That takes me back.
Back in the eighties before PCs were ubiquitous in offices I worked for a company that sold a strange little device that connected to an electronic typewriter to run word processing software. We also developed and sold other packages for things like accounts and payroll to run on these machines. They were usually twin floppy drives and used a CP/M derivative called OS/M.
We also sold Comart machines running Concurrent CP/M or Concurrent DOS.
Oh those were the days. Driving all over the country to rebuild linked list "databases" when somebody decided to unplug the machine before saving their data.
Complete with Specialix paddles supporting up to 16 users on RS-232 to dumb terminals, I imagine.
As Comart was about the size of large microwave oven (but heavier), it would be left on an office side bench with the paddle trailing underneath. Needless to say, that became a complete rats' nest rather quickly.
I used to work on BRIDOS systems in the late 80s. It was a wierd multi-user CP/M that supported up to 8 users by having a separate Z80 card for each user in a central box. A 9th card was the system master that managed shared resources such as printers and disks.
It also had an interesting security flaw that I discovered by accident. The system had 2 levels of users: normal users and superusers that could do anything on the system. The various user boards sent messages to the main system board to interact with disks/printers/etc. A superuser message was distinguished by having a single bit set in the message header. If you executed a program as a normal user that sent a message to the system board with the superuser bit set then the OS decided that you must be a superuser and promoted you granting you all rights on the system.
I was using a Data General Nova3. That had the RDOS operating system which I managed to 'hack' to make a 2 user system - each in their own workspace but sharing a floppy disk (or two). I wrote an Asset Management system sharing the disk for two users - it worked great, with my own home grown indexing system to guarentee retrieval of any record in under 1 second - for either user.
Those were the days - I couldn't do it now.
Alan
I used CP/N at school (The ROM'able network variant) on a RML Link 480Z connected to a 380Z server running MP/M II. This was enhanced with software from The Methodist College Belfast(?) that allowed network logins and provided primitive security. My first software development job at age 16 in 1988 was writing time recording software for accountants in CBASIC under Concurrent DOS. I loved it, CBASIC was a lovely language, big shame DR never did much with it. CBASIC was available for PC-DOS, CP/M86 and CDOS so we were able to provide our software for a wide range of machines such as Apricot, Sirius, the Future FX series and IBM PCs. My boss wrote a clever libraries for different networks (DR/Net, MS-Net and Novell) that we linked in as we needed. Later the software was ported to Xenix using the Minnow Bear MB86 CBASIC to C transpiler and last I heard it had been ported back to the PC under Windows using the same to allow the use of 64 bit integers and very large files.
For my next job I worked for Graffcom Systems who produced the Accounts II range of accounting software. This again was written in CBASIC for DOS and MS networks. With some clever assembly they also ported it to text mode OS/2. I believe it was the first UK accounting suite running on OS/2 and they sold around 2 copies! The technical director at Graffcom was a genius, to put it mildly, and wrote a CBASIC compatible compiler for UNIX that used a runtime much like Java does today. Using this we ported the software to SCO Unix, ICL DR/NX (DRS 300 and 3000) and the IBM PS2 / 6150 and RS6000 running AIX.
I still get misty eyed when I read about CP/M. It's a real shame CDOS wasn't more popular. For business apps it really was a better DOS than DOS.
I'm not certain, but I think my first use of CP/M was on an Exidy Sorcerer (had a Z80) with an external dual floppy box.
Later I spent an absolute fortune for a big S-100 system with dual-processor board, dual floppies, graphics card, disk controller card, system control card, SRAM card, extended DRAM card, and a partridge in a pear tree. Many of the boards were "CompuPro" from Godbout. They included the BIOS source for the hardware.
I wrote a RAM disk system using the 256K expanded memory. The CPU board had a register you could output to which controlled the upper 8 bits of the 24 bit S-100 address as output by the 8085 CPU (the floppy controller board did the full 24 bit). With care, and some "interesting" use of the DMA controller on the disk controller card, I was able to switch back and forth among the 64K "segments", saving a few bytes (4?) in the CPU registers for going between the main bank (bank 0) and a bank of my RAM disk. I created CP/M program "cache", which accepted "on", "off" and "flush". "flush" took all dirty contents from the expanded memory and wrote it to the active floppy. I was quite proud of this setup. Made programming on the system *much* faster, and with far far less "GRONK-CLUNK" going on.
I also recall a local store had a business system for sale running MP/M. It did indeed support multiple simultaneous users. Very expensive system, however.
Yeah, I know - replying to my own comment is tres tacky.
But, in a moment of weakness I went looking, and I found the 8080 assembler for the cache setup. There was another option "cache recover" - not real sure what that did, but I expect it assumed valid cache contents after a system reset/reboot.
Code is nicely commented, but would take considerable effort to really understand.
And yes, it transfered 4 bytes per bank switch.
Exidy Sorcerer, a name to conjure by. I made h/w mods and hand-coded BIOS enhancements to get mine to do what I wanted. Also had a boat-anchor S-100 system (Cromemco?) with 8" floppies and more s/w & h/w mods to support my own custom music composing s/w that accepted keyboard entered music notation and output wave-table renditions in 4-8 part harmony via a couple of s-100 D-A convertors. (I was working on a commission for an a symphonic piece.) It took mucho machine-language tweaking of the inner loop of the playback s/w to get the Z80 to read and output 4-8 wave tables in realtime. I still have the Exidy in the attic someplace. Fun days. I loved the Z80, which had a much better instruction set than the 8086.
Think of it as an assignment statement.
Destination = Source
Later (much), Dec introduced the Dec Command Language (DCL) interpreter, which converted:
copy source destination
Into
pip destination source
But those of us that had to use more than one type of Dec system or O/S would generally go straight to the underlying utility as DCL was not always available.
(Surprisingly IIRC, RT-11 was one of those that did - I preferred RSX myself, though VMS was OK too; my first Dec O/S was TOPS-10 (sigh) those were the days!)
Being very old, I'm a sucker for these articles since they bring back memories that the industry, and my brain, are losing.
But the comment "It would be terrific to see at least some of these products' source code released, and to see them running again today, expanded and enhanced and updated." bothers me. In all cases I have knowledge of the answer is no.
I can't think of any enhancement you could make to any part of C/PM that would merit, say, inclusion in the Linux kernel.
Now I'm going to search for the best Elvis recording of Memories.
In Linux or something? Oh, ye gods, no.
What I would like to see, though...
The whole DOS family is nearly dead now. Very little modern hardware has DOS drivers. DOS networking didn't support TCP/IP back in the day; as per my recent article about DECnet, even the launch versions of WfWg 3.11 and NT didn't include TCP/IP by default.
Similarly, all versions of Win9x only support SMB v1, which is now deprecated. This also applies to all 32-bit only versions of NT, up to and including XP.
If someone installs FreeDOS on a PC now, they probably won't be adding new device drivers, because there aren't any. DOS support for TCP/IP is limited.
And pre-386 PCs are over 25 years old and probably mostly dead of capacitor failure.
One of the big limitations of Multiuser DOS was that it wasn't really a DOS kernel and you couldn't install DOS device drivers or a DOS network stack on it.
*That doesn't matter any more*.
Today, if the source was open, someone could cut out IPX/SPX or anything except TCP/IP, and it could be a standalone multitasking 386 OS for old PCs. No networking, no multiuser, just a multitasking non-networked standalone DOS that could use up to 4GB of RAM to run lots of DOS sessions.
That sounds quite good to me. I could use that.
CompuPro did a 8088/Z-80 dual CPU board, and wrote MP/M 8-16 to take advantage of it. It would transparently run 8-bit code on the Z-80 and 16-bit code on the 8088, thus the name.
My first job out of community college was wrangling these on an ARCNET network, and they also had 40MB hard drives. They mainly ran dBASE II.
Edit: It took over payroll from the IBM System/34... at which point we discovered the S/34 had been doing payroll WRONG for years. That was a nasty surprise. I can still see the look on our chief accountant's face.
Or you know, they could have just dropped the price to something reasonable...
NAAAAAAH.
I remember when Borland priced everything at $99 and people went apeshit. It pretty much put them at the top of the heap, because they were the only ones affordable to a typical college student. This was when C compilers were at least $300, maybe $500-$1000.
"This was when C compilers were at least $300, maybe $500-$1000."
I used PCC for a long time ('79ish to the mid '90s), without spending a dime.
It was good enough to write BSD with. It was also included as a part of the distribution, until the release of 4.4BSD in '93 when GCC took over that duty.
We did so much with so little, pushing via sharp coding limited memory and hardware.
For millions of mainstream hobbyists and pros -- no matter the brand...Tandy / Radio Shack, IBM, Commodore, Apple, Atari, etc. -- each OS was wonderfully unique, and upgrade announcements were not interpreted as "same-old crap, new version number."
Times were exciting. We remember the Amiga's red-and-white checkered, 3D bouncing ball.
Today, we have mainstream monotony induced by monopoly bloatware.
Windows versions annoy, rather than excite. It is with dread and resignation that we face Micro$oft's force-fed OS upgrades.
I do not remember "app" beginning to be used as common shorthand until roughly 2005, and it didn't really take off until the release of the first iPhone (2007?) ... Prior to that, "Application Software" was used in contracts (and by suits), "program" was used by everybody else. Smaller programs were called "utilities" or "tools". Some used "executable files" (or .exes) and ".com files" on DOS. There was also separation of binaries, filters and scripts.
But APPS? Not so much. Not in my memory, anyway. With one exception ... the proverbial "killer app" (mid 1980s?), which was mostly just used as a term in the media and by certain rah-rah types in marketing (see: iPhone, above).
Moderately tangential (but wanted to mention his name anyway) memory is getting hazy but I seem to recall after MS threw together its seat-of-the-pants OS for the Altair Paul Allen realised while on the plane going to see the proprietor for a demo that they had not yet written the boot code. So he wrote it on the plane.
> MS threw together its seat-of-the-pants OS for the Altair
You are very generous in calling it an 'OS'. The stuff written for the Altair was just a BASIC interpreter* and it was loaded into the machine using paper tape created on a DEC machine.
* It is also alleged that the core of the BASIC interpreter was created from an open source BASIC available on DEC machines and used by Bill Gates at Harvard. The math routines needed a complete rewrite for the 8080 written by Monte Davidoff.
At some point in the 80s we were using both PCs and some strange things called Sages running CP/M 68K.
The Sages were configured with the hard disk partitioned into 2MB chunks (the limit) with
A = operating system and tools
B = source code
C / D / E etc. = customer data or more copies of the source code
P = floppy drive
(the idea being that the number of had disk partitions depended on the size of the hard disk but P was always the floppy)
So in summary
PC = A: floppy C: system
Sage = P: floppy A: system
Now, a moment's inattention on a Sage, you format the floppy FORMAT A: - bye bye OS and tools (getting the OS back on was a pain and for some reason involved the UCSD P-system as well)
The other fun property of Sages was hard disks very brittle and averse to the computer being dropped.
Well it was a few years into the 1990s that auto park became a feature on hard disks.
I may have trashed the odd hard disk through forgetting to park the damn thing before disassembling the computer to move it. Particularly annoying if I wasn't sure and then had to reassemble the damn thing just to boot it up to park the drive.
" Origin story
The original CP/M was designed for the Intel 8080, although later most people ran it on Zilog's enhanced chip, the Z80. That's how come CP/M ran on the Amstrad CPC, PCW, and even the ZX Spectrum +3… and a compatible OS on MSX machines, mainly in Japan."
It was also availble for the BBC Micro/Master with the use of the Z80 co-processor.
How did that even work? Didn't remap the RAM into the bottom 48K of the machine? Normally on the Spectrum the first 16K is the ROM, and most CP/M (Z80) programs assumed a start address if 0x0100. Unless CP/M programs intended for the Spectrum had to be rebuilt for the odd memory layout.
An external interface could replace the bottom 16k of ROM with RAM. But on a pre-128k Spectrum that would still leave the problem of the video RAM being fixed at 0x4000, which is a tad low for a CP/M system. (Not a problem on a 128, as you could put the video RAM at 0xC000 and page it out when not using it).
MSX-DOS was in no way based on CP/M and provided effectively a clone of MS-DOS on the Z80 MSX machines, hence the name. CP/M compatibility was at best an afterthought and would have been useless until the later MSX2 provided standard 80-column support.
I found that a little annoying in the article as well, because MSX-DOS compatibility with CP/M is probably comparable with the early non-IBM PCs running MS-DOS compatibility with PC-DOS on an original PC. Most commercial CP/M applications that were sold for MSX were re-written for compatibility and to take advantage of the much richer feature set. Borland's Turbo compilers come to mind.
> MSX-DOS was in no way based on CP/M and provided effectively a clone of MS-DOS
What you say is nonsense because MS-DOS itself is 'based on CP/M' design (if not on source code) because it implements the same BIOS/BDOS/CCP structure and it implements the same CP/M API with only minor variations. It even supports the same 'page zero' structure (in the PCB on MS-DOS) including the FCBs and the 'call 05H' interface. MS-DOS 1 could only run .COM '8080 mode' programs which were structurally identical to CP/M .COM programs.
While MSX-DOS was not 100% compatible to CP/M it could not run MS-DOS programs at all, not even .COMs.
> CP/M compatibility was at best an afterthought
No.Wrong. CP/M compatibility was the _whole_ point of MSX-DOS (and of MS-DOS 1.x). Without it there would have been _no_ application programs that would run on it, at least in the first several months, and no point for anyone to buy the system.
> What you say is nonsense because MS-DOS itself is 'based on CP/M' design (if not on source code) because it implements the same BIOS/BDOS/CCP structure and it implements the same CP/M API with only minor variations. It even supports the same 'page zero' structure (in the PCB on MS-DOS) including the FCBs and the 'call 05H' interface. MS-DOS 1 could only run .COM '8080 mode' programs which were structurally identical to CP/M .COM programs.
I was running .EXE files on 86-DOS 1.14, though suspect earlier versions of 86-DOS were .COM only. My understanding was doing a "call 05H" was re-directed to doing an INT 21H software interrupt. MS-DOS 2.0 brought in file handling that did not use FCB's - bringing a complaint that the new method reduced the number of open files allowed.
FWIW, PC-DOS 1.0 was a slightly modified 86-DOS 1.14, and PC-DOS 1.1 was he IBM version of MS-DOS 1.25. The SCP release of MS-DOS allowed booting from a DSDD 8" floppy, in conjunction with a new monitor EPROM, previously SCP machines needed to boot from an 8" single density floppy.
> Most commercial CP/M applications that were sold for MSX were re-written for compatibility and to take advantage of the much richer feature set. Borland's Turbo compilers come to mind.
Turbo-Pascal 3.x, for example, was produced in four versions: CP/M-80, CP/M-86, MS-DOS and PC-DOS. The first three had a configuration program which set the terminal type used. The MS-DOS version could be set to 'ANSI' and this would work on an IBM-PC or close that had ANSI-SYS configured in CONFIG.SYS. But other terminals could be configured for non-IBM-PC machines (DEC Rainbow) or those using serial terminals (Wyse 60, DEC VT52, etc). The CP/M-xx versions had dozens of terminal types to select from.
MSX-DOS 1.x could run the standard CP/M-80 version without a 'rewrite'. It did need to be on an MSX-DOS disk though. It seems that it was rather limited and could only use console mode (ie scrolling text) because MSX-DOS did not support ANSI.SYS. Certain libraries, such as Popolony2k, were available that used INLINE assembler code to access MSX facilities.
Surely CP/M was just a code loader with a standardised filesystem library. It didn't manage any other resources. I'd considered MP/M as the first PC operating system.
But all this simply reminds me of the genius of Dennis Ritchie and Ken Thompson in creating Unix in 1969!!!. The daddy of nearly ALL currently developing operating systems.
Fancy doing a similar family tree of Unix?
No, CP/M wasn't an OS. It was a glorified program loader. Same for MS-DOS and PC-DOS. And (IMO) MP/M. In a program loader, the user can fully control all of the hardware without requiring permissions to be set. An OS has complete control of the hardware (pace root/administrative access capabilities, of course).
Both have their place in computing.
Arguably. the first actual OS for a PC[0] was 1969's Bell Labs OS that came to be called Unics (not a typo). One should also give a nod to the Xerox Alto in 1973.
[0] "PC" defined as a machine designed to be used by a single person, in other words a personal computer.
> No, CP/M wasn't an OS. It was a glorified program loader.
It never claimed to be an 'OS', it was a Control Program, that is what 'CP' stood for. It was, however, a subset of an OS, a DOS: Disk Operating System, providing that functionality without the other parts that would make it a full 'OS'.
> And (IMO) MP/M.
MP/M provided many more facilities including multi-tasking, multi-user, bank switching ,networking (DR-NET), RAM disks, and, no, programs could not 'take control' of all the hardware.
> [0] "PC" defined as a machine designed to be used by a single person,
The first computer that I 'used' was a small mainframe ICL 1901. I often ran it alone, changing the tapes and disks, loading the paper in the printer, the cards in the reader and starting the programs. You seem to calling this a "PC".
The first computer to be _called_ a 'personal computer' was the Apple II in adverts in 1978.
"The first computer that I 'used' was a small mainframe ICL 1901. I often ran it alone, changing the tapes and disks, loading the paper in the printer, the cards in the reader and starting the programs. You seem to calling this a "PC"."
If it was designed for a single operator, it could, to all intents and purposes, be considered a PC (although the business that parked your happy arse in front of it might argue the "personal" point). As another example, I sometimes make a case for my IBM 1401 being a PC (mine's a '63, but they were first sold in '59).
"The first computer to be _called_ a 'personal computer' was the Apple II in adverts in 1978."
At the Homebrew Computer Club we were calling such machines of any make or model "PCs" or "Personal Computers" in 1975. It was was fairly common usage at Unis around here before that. I wonder where Jobs & the Woz got the term? Answers on a postcard.
Wow an O/S blast from the past, my 1st computer back in early '80's was an LSI Octopus running C/PM, that evolved in to C-DOS or MU/DOS.
I had a small network of 4 machines running m/user Axis accounts, WP, a DBase from Sensible Solution all linked to a HASLAR telex box.... state of the art back then, envy of all my competitors.... Cost a small fortune then, but was worth it......
I recall considering other PC's of the day e.g. ACT Sirius, even some UNIX (Uniplex?) and DEC boxes, ....and even toyed with the original Osbourne portable which was the size of small suitcase... ;)
a reminder of how old I am now....
Great times, the mid 80s to early 90s.
Worked at LSI Computers Ltd using the LSI System M-Three (CP/M), System M-Four (CP/M-86/80, Concurrent CP/M-86/80 and MS-DOS), System M-Five, aka LSI-Octopus (Concurrent CP/M-86/80 and Concurrent-DOS) and early AT class PCs networked using ARCNET.
Spent most of my time programming in Sensible Solution 4GL or assembler, compiled BASIC and C for the Systems AXIS suite of accounting, costing, payroll, etc. packages.
Still have and tinker with some of those old LSI Computers systems.
I owned a CPC6128 and I dabbled with Turbo Pascal (eventually making a career out of the later versions) and BCPL. I even wrote a virus for CP/M in assembler. It wasn't a particularly subtle virus (you'd have to be daft not to wonder why the disk was so active when all you'd asked was for a directory listing) and it only worked on bootable floppies - and possibly only those targeting the CPC variant - but still it could propagate itself.
The Apricot F1 had GEM as well as fibre optic keyboard and mouse connectors.
US tech litigation was just another example of how US businesses limited external competition. Everyone in the US was suing or being sued by everyone else to keep control of the market.
Classic example of the misuse of law to throttle innovation.
Not at all, no.
For instance Amstrad shipped its first PCs, the PC1512 range, with GEM in 1986:
https://www.i-programmer.info/history/machines/1364-alan-sugar-and-the-fall-of-amstrad.html?start=1
Apple sued over GEM implementing various Apple UI mechanisms, such as pull-down menus, drive icons on the desktop, overlapping windows, and so on.
So, DR removed those things from version 2 of PC GEM. (They remained in Atari ST GEM.)
Instead, PC GEM had drop-down menus: put the mouse pointer over the menu and it opens *without clicking*. Windows are tiled, not overlapping. There was a "drives" window with the disk icons in it, so they are not on the desktop. (This is also the model adopted with Windows 95, of course.)
The result was GEM/2. This was the version supplied with the Amstrads:
https://www.seasip.info/Gem/versions.html
The above link also details the functional improvements carried out in later versions of GEM.
After Caldera made GEM GPL FOSS in 1999, the FreeGEM put back in all the improvements that Apple had forced DR to remove, and all the API improvements and things from GEM/4 and GEM/5.
That is what is in the modern FOSS version of GEM, which is what is optionally included in FreeDOS, from which I took that screenshot.
Having learn in mainframes ( jcl and vm/370) was very easy to me use cpm 2.2 I'm my first personal computer an msx computer's with 80. In that computer I made a lot of Fortran, c and dBase programming. A couple of years before that I switched to a more capable Pc compatible using v. 20 processors, compatible with z80, and also using cpm emulator in 8088 nec computers. My last cpm experience was Dr dos, they could network well before dos or windows could. We installed in scada systems in the middle 90s, because of this networking capability. I've seen some projects still using rom drdos, for remote terminal units. We aware that even today satellites use 8088 as a controller,because of its space certified characteristics.
> My last cpm experience was Dr dos,
An interesting comment because DR-DOS could not run CP/M software
> they could network well before dos or windows could.
MP/M was originally developed in 1978 to be a network server for CP/M workstations using DR-NET. As it was also a multi-user system that could be used with relatively cheaper serial terminals it found its niche there.
Our first office micro (in 1981 I think) was a Sirius1 with twin variable speed diskettes, running CPM/86. It came with dBase11, Supercalc and Micromodeller
It's a long time ago, but I clearly remember that the machine would hang, losing any unsaved work, if you tried to print without the printer connected. (BDOS ERROR...).
We soon upgraded to MSDOS1 and added a huge external 5MB Winchester. With no subdirectories, I recall formatting as drive letters C to Z...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
