I'm pretty sure CP/M 86 was already a thing. I believe there was even Concurrent CP/M 86, which let you run up to 4 (or more?) virtual sessions concurrently. Light years ahead of MS-DOS but nobody wanted it, so DRI dumbed it down and added MS-DOS compatibility and re-released as DR-DOS (still superior to MS-DOS though).
CP/M-86 was definitely a thing, but CP/M-386 was not. By the time the 386 existed, DRI had dropped the CP/M name in favour of Concurrent DOS - though they had MS-DOS compatibility in Concurrent CP/M - and, as you say, eventually renamed it to DR-DOS.
Much as I loved DR-DOS, it did have occasional compatibility hiccups.
Also, it was super common practice to just go direct to undocumented internals. You didn't have a clean API to duplicate, you had all the untamed glory of a CPU with no MMU to deal with, and all the programs that did shonky things because they worked.
cp/m-86 targets 8086, which is no more useful or relevant to 386 protected mode than the original z80 version. Did you think they just picked the 68k version at random?
> cp/m-86 targets 8086, which is no more useful or relevant to 386 protected mode than the original z80 version. Did you think they just picked the 68k version at random?
The big reason for picking the 68K version is it was mainly written in C (initially in Pascal, but they later switched to C.) By contrast, the more famous 8080 versions were largely written in assembly, as was the 8086 version.
Well, CP/M-80 1.x was mostly written in PL/M, a dialect of PL/I developed by Gary Kildall, but CP/M-80 2.x+ was rewritten in assembly for speed; PL/M was still used for some of the utilities. Obviously, C compilers are much easier to come by nowadays than PL/M compilers are.
One of my first jobs, back in the 1980s, was a project for a government department that the supplier (Wang Computers) had bet on MS-DOS being multi-process.
Of course, it wasn't but there was MP/M-86/CCP/M/CDOS/DR-DOS which allowed you to have 4 "users"/virtual TTYs.
So we ended up using that along with some tweaks to the software (including an IBM 3270 emulator, MS-Word/Excel (the DOS versions), and a custom software app) that ended up getting deployed to a few hundred government offices.
Mostly worked except some of the software really didn't like the fact that it was being swapped out of keyboard/screen access.
Just as some off-the-top history, MS-DOS was clearly obsolete, but it hung around for like 10 years too long because people couldn't quit it. It was a DOSSY DOS world.
"Protected Mode DOS" went through the IBM/MS gristmill and became OS/2, which was a compromised product in a lot of ways. Then Windows (still mostly a DOS program) got a little traction, and Microsoft had hired Dave Cutler to write a real OS. And David overthrew Goliath and the rest is history. On topic, nobody really wanted protected-mode DOS or CP/M etc.
Windows 3.0 becoming a hit was something unplanned by Microsoft originally - even the NT team was working with the assumption of using OS/2 API for applications. Win3.0 started out as skunkworks project initially hiding from management under smokescreen of just being one last release of "windows as application library" that some products (including 3rd party ones) were using
MS-DOS became obsolete only at the launch of Windows 95.
Until then, all the applications that could be found for Windows 3.0 or Windows 3.1 looked like worthless toys in comparison with the professional applications that were available for MS-DOS, despite the fact that the latter had to struggle with extended memory or expanded memory in order to use more than 640 kB of memory.
From 1990 to 1995, I had Windows 3.0, then 3.1, then 3.11 and I launched them from time to time, for fun, but to accomplish real work I always had to go back to MS-DOS.
At first Windows 95 was not great for games, so at least through 1996-97 many games were still released for MS-DOS and often only for MS-DOS, or only had Windows ports later.
Looking back from now, I wish that era could have continued much longer, as running MS-DOS games in emulators is so much easier and more stable than to run old Windows games.
Additionally, Microsoft had a first attempt to a gaming API for Windows, which mostly one those of us that were alive back then remember it, given how hard it is to search for it on the Internet.
Really, how come anyone find something about WinG, if they don't know what they are actually searching for?
Wasn't that abbreviation from "pipe"? As in - this is a pipe that you can use to connect terminal to a file, file to a printer... and yes, file to a file (that's cp/copy).
CP/M‑386 is currently in the very early development stages.
Full 32‑bit protected mode implementation with Ring‑3 TPA.
Bootable via 3.5" 1.44MB floppy disk MBR or GRUB Multiboot kernel.
Supports VGA text (0xB8000) and/or COM1 serial (9600/N/8/1, 0x3F8) consoles.
No floppy/hard disk/CD/USB/network/sound/other drivers (yet).
So it boots from a floppy, but has no floppy disk support?
That's not surprising. The page says the kernel is multiboot compliant, which means it can be loaded by existing boot loaders. Whether the kernel later provides a floppy driver is a separate story.
This is also pretty common even if you don't use multiboot. The I/O services exposed by the BIOS or firmware during boot may not be usable once the kernel has started, and thus the kernel has to provide its own drivers.
Yeah, I was a bit shocked to run across the "no AI generated code is in this code base yet", although the project doesn't have an anti-AI contribution policy.
My assumption on the reason that it requires 2M or more is all the memory mapped I/O devices in the first 1M of PC memory. They just wanted to avoid the whole page and set the origin at 2MB.
The question is understandable because EMM/EMS use protected mode in a limited way.
In fact, 386 protected mode could still make use of memory segmentation, with 32-bit segment registers being an upgrade from the 286 protected mode.
But there has been no production OS that continued to use segmentation once 386 mode made 32-bit addressing so easy. In large part because Unix could be ported from flat memory models such as VAX, and m68k.
Therefore, since CP/M-386 is derived from CP/M-68K, it seems straightforward that a flat 32-bit memory model is employed.
ingesting....but not was like "Star trek project" something like this. DR-DOS evolved from CP/M-86 and they added. And "Star Trek" added to DR DOS a multitasker named "Vladivar" (and a port of System 7 GUI). If I remember it correctly, there is these multitasker in DR-DOS 7 that allow pre-emptive tasking in 32 bits protected mode.
I'm pretty sure CP/M 86 was already a thing. I believe there was even Concurrent CP/M 86, which let you run up to 4 (or more?) virtual sessions concurrently. Light years ahead of MS-DOS but nobody wanted it, so DRI dumbed it down and added MS-DOS compatibility and re-released as DR-DOS (still superior to MS-DOS though).
CP/M-86 was definitely a thing, but CP/M-386 was not. By the time the 386 existed, DRI had dropped the CP/M name in favour of Concurrent DOS - though they had MS-DOS compatibility in Concurrent CP/M - and, as you say, eventually renamed it to DR-DOS.
Much as I loved DR-DOS, it did have occasional compatibility hiccups.
Chances are those hiccups weren't without a reason!
https://en.wikipedia.org/wiki/Jim_Allchin#Controversies
Also, it was super common practice to just go direct to undocumented internals. You didn't have a clean API to duplicate, you had all the untamed glory of a CPU with no MMU to deal with, and all the programs that did shonky things because they worked.
MS-DOS truly beat CP/M-86 when it extended the APIs and features in PC/MS-DOS 2.0 (heavily inspired by Xenix), like hierarchical file system.
From then on, applications would target MS-DOS in addition to the curse of being too IBM PC specific
Not 386 though.
cp/m-86 targets 8086, which is no more useful or relevant to 386 protected mode than the original z80 version. Did you think they just picked the 68k version at random?
> cp/m-86 targets 8086, which is no more useful or relevant to 386 protected mode than the original z80 version. Did you think they just picked the 68k version at random?
The big reason for picking the 68K version is it was mainly written in C (initially in Pascal, but they later switched to C.) By contrast, the more famous 8080 versions were largely written in assembly, as was the 8086 version.
Well, CP/M-80 1.x was mostly written in PL/M, a dialect of PL/I developed by Gary Kildall, but CP/M-80 2.x+ was rewritten in assembly for speed; PL/M was still used for some of the utilities. Obviously, C compilers are much easier to come by nowadays than PL/M compilers are.
One of my first jobs, back in the 1980s, was a project for a government department that the supplier (Wang Computers) had bet on MS-DOS being multi-process.
Of course, it wasn't but there was MP/M-86/CCP/M/CDOS/DR-DOS which allowed you to have 4 "users"/virtual TTYs.
So we ended up using that along with some tweaks to the software (including an IBM 3270 emulator, MS-Word/Excel (the DOS versions), and a custom software app) that ended up getting deployed to a few hundred government offices.
Mostly worked except some of the software really didn't like the fact that it was being swapped out of keyboard/screen access.
Just as some off-the-top history, MS-DOS was clearly obsolete, but it hung around for like 10 years too long because people couldn't quit it. It was a DOSSY DOS world.
"Protected Mode DOS" went through the IBM/MS gristmill and became OS/2, which was a compromised product in a lot of ways. Then Windows (still mostly a DOS program) got a little traction, and Microsoft had hired Dave Cutler to write a real OS. And David overthrew Goliath and the rest is history. On topic, nobody really wanted protected-mode DOS or CP/M etc.
Windows 3.0 becoming a hit was something unplanned by Microsoft originally - even the NT team was working with the assumption of using OS/2 API for applications. Win3.0 started out as skunkworks project initially hiding from management under smokescreen of just being one last release of "windows as application library" that some products (including 3rd party ones) were using
MS-DOS became obsolete only at the launch of Windows 95.
Until then, all the applications that could be found for Windows 3.0 or Windows 3.1 looked like worthless toys in comparison with the professional applications that were available for MS-DOS, despite the fact that the latter had to struggle with extended memory or expanded memory in order to use more than 640 kB of memory.
From 1990 to 1995, I had Windows 3.0, then 3.1, then 3.11 and I launched them from time to time, for fun, but to accomplish real work I always had to go back to MS-DOS.
At first Windows 95 was not great for games, so at least through 1996-97 many games were still released for MS-DOS and often only for MS-DOS, or only had Windows ports later.
Looking back from now, I wish that era could have continued much longer, as running MS-DOS games in emulators is so much easier and more stable than to run old Windows games.
Additionally, Microsoft had a first attempt to a gaming API for Windows, which mostly one those of us that were alive back then remember it, given how hard it is to search for it on the Internet.
Really, how come anyone find something about WinG, if they don't know what they are actually searching for?
https://www.gamedeveloper.com/programming/a-whirlwind-tour-o...
https://betawiki.net/wiki/WinG
https://en.wikipedia.org/wiki/WinG
Also it took until DirectX 5, to have it be usable for games.
CP/M - because pip just makes more sense than copy.
It also has an “ed” that will make you miss UNIX’s “ed”. I’ve used it to write programs and it is not fun!
I was a kid at the time, so I only got as far as writing and modifying a few programs in MBASIC.
Anyone that got anything nontrivial to work on those systems deserves much respect.
edilin was in the same page
Wasn't that abbreviation from "pipe"? As in - this is a pipe that you can use to connect terminal to a file, file to a printer... and yes, file to a file (that's cp/copy).
No.
https://en.wikipedia.org/wiki/Peripheral_Interchange_Program
CP/M‑386 is currently in the very early development stages.
So it boots from a floppy, but has no floppy disk support?That's not surprising. The page says the kernel is multiboot compliant, which means it can be loaded by existing boot loaders. Whether the kernel later provides a floppy driver is a separate story.
This is also pretty common even if you don't use multiboot. The I/O services exposed by the BIOS or firmware during boot may not be usable once the kernel has started, and thus the kernel has to provide its own drivers.
First project of this kind on here in a long while that isn't complete AI slop. Well done, really happy to see some people still doing this!
Yeah, I was a bit shocked to run across the "no AI generated code is in this code base yet", although the project doesn't have an anti-AI contribution policy.
Makes it much more impressive.
Careful now. For some reason celebrating not using the slop machine attracts a lot of negative attention.
There's no room for dissent against the slop bot for some reason
>"Compatible with 386 (and later systems) with 2MB (or more) memory."
Looks good!
An order of magnitude (or two!) less code complexity and less memory hungry than most of 2026's bloated Operating Systems...
Well done!
My assumption on the reason that it requires 2M or more is all the memory mapped I/O devices in the first 1M of PC memory. They just wanted to avoid the whole page and set the origin at 2MB.
Does it support flat memory model or its banked like DOS ?
if it runs in 32 bits protected mode, by definition you have flat memory.
The question is understandable because EMM/EMS use protected mode in a limited way.
In fact, 386 protected mode could still make use of memory segmentation, with 32-bit segment registers being an upgrade from the 286 protected mode.
But there has been no production OS that continued to use segmentation once 386 mode made 32-bit addressing so easy. In large part because Unix could be ported from flat memory models such as VAX, and m68k.
Therefore, since CP/M-386 is derived from CP/M-68K, it seems straightforward that a flat 32-bit memory model is employed.
ingesting....but not was like "Star trek project" something like this. DR-DOS evolved from CP/M-86 and they added. And "Star Trek" added to DR DOS a multitasker named "Vladivar" (and a port of System 7 GUI). If I remember it correctly, there is these multitasker in DR-DOS 7 that allow pre-emptive tasking in 32 bits protected mode.