I grew up on 68k Macs so DOS was never something I thought much about aside from the occasional boot disk to run some firmware procedure later on when later Windows was well established.
Then later from a retrocomputing standpoint, I've come to see it is pretty fascinating:
1) The sheer volume of commercial software.. which is readily available on winworld, vetusware, and archive.org. A lot of it with sometimes awesome character-mode UIs (Borland's early IDEs are really spectacular, Lotus 1-2-3, and WordPerfect are still taken seriously by some users).
2) The memory model is quixotic and an interesting homage to the chaotic evolution of x86 that most later operating systems elide by requiring a 386. The 286 and 386 have drastically different protection schemes. EMS and XMS. The eventual DOS extenders and standards like VCPI, DPMI. It's honestly a mess but somehow interesting to see how people solved difficult problems.
If anything, a lot of the modern developer experience has suffered compared to the early Borland IDEs. One would easily say we regressed.
They were focused, immediate and effective.
If anything today you'd miss the code navigation features (go to definition, go back, go forward), and of course LSP is actually very useful and once you don't have it, it hurts (instant errors, ease of refactoring...)
Give me something like the Borland IDEs (FAST!) and some of the modern features (they can be slower, they're only as fast as the LSP server implementation anyway) and I'm there!
I did a proof of concept quickly, mostly while learning to write code editors, but I have not gotten it to a point of being useful [1]
The Free Pascal software distribution includes a FLOSS look-alike of Borland's character-mode IDE for Pascal. If you can track down RHIDE, that's a similar look-alike IDE that runs in MS-DOS (it does require 386+ since it uses a DOS extender) and compiles C/C++ using gcc. (One version of it is distributed as part of the FreeDOS "development" packages.) It would be nice to recreate a broadly similar look and featureset starting from a modern text-mode editor such as the newly released MS-EDIT, aiming for modern IDE infrastructure like LSP and DAP. Such a project may find quite some use for, e.g. remote system administration tasks using ssh.
If anyone here is interested, a DOS game jam was announced recently for a streaming event called DOSember. https://itch.io/jam/dosember-game-jam Starts in a couple of weeks and lasts for three months.
DOS is an interesting platform because it can run on old hardware, and then basically anything else by way of emulation (such as in browsers) or via DOSBox.
If networking can be plumbed up, it's probably a legitimate and fun application platform for some uses that's worthy of investing time building on either for fun or for something real.
With some emulators (at least DOSBox-X) you can enable modern graphics modes that show up in SVGA in the emulated DOS and can be supported by DOS software just like any other modes. Anyone making DOS software today that isn't going explicitly for a retro look can try to detect and support a few modes like 1920x1080 and only fall back to more common old modes when necessary.
> If networking can be plumbed up, it's probably a legitimate and fun application platform for some uses that's worthy of investing time building on either for fun or for something real.
It's probably well suited to being a game console platform, too.
I've been playing around with raylib/raygui for cross-platform game/app development. It would be cool if it could target DOS. It probably could, but it sounds way beyond my current knowledge.
Yeah, I think the hard part would be graphics libraries for anything 3D.
I've always had a bucket-list item along the lines of "constructing basic game playing graphics primitives from scratch using the SVGA address offset for output".
MS-DOS (and games for it) ran on 486s, at the end. Writing MS-DOS games for a computer running many hundreds/thousands of times faster would probably allow for many more different types of approaches that could not be done on slow machines.
Note that DOS development tools aren't strictly necessary to make DOS software,
as with help of HX DOS Extender [0], one may use any tooling that lets you produce Win32 PE exe files, of course, preferably with inline assembler to access hardware directly.
As someone old enough to have live through it, I always found TASM much better than MASM, in terms of tooling.
In both cases, still much better than traditional UNIX assemblers, desiged to massage C's output as another build stage, than to actually code by hand.
For anything written from scratch, I would recommend fasm or nasm.
I prefer the latter, because the documentation is better and there's a way to specify target cpu (e.g. 8086) and get errors when instructions aren't compliant.
For development it is convenient that PC-BASIC exists, that is a pure Python implementation of GW-BASIC that has its own partial 1999s PC emulator built in.
Not mentioned is the https://pcjs.org/ site which purports to let you emulate various machines in your browser, select from different disk images, and overall seems full-featured, though it is confusing and presents some difficulty when trying getting it to work on some configuration besides the pre-baked ones that you can come across.
Seems a bit obsessed with open source when abandonware like Borland C++ 3.1 and Pascal 7.0 are amazing.
Also, missing the very important, closer to primary sources, physical dead tree resources that are needed as reference to program things.
- Black Book of Graphics Programming (Special Edition) (now FOSS)
- Programmer's Guide To The EGA, VGA, And Super VGA Cards (3rd Edition)
- PC-Intern (where I learned how Central Point, Norton, and later FreeBSD made "GUI" with sub-character graphical pointers in text mode through custom fonts)
- Undocumented PC
- Undocumented DOS
- PC Interrupts (and) Uninterrupted Interrupts (Ralf Brown)
- Microsoft MS-DOS Programmer's Reference
- The Programmer's PC Sourcebook: Reference Tables for IBM PCs and Compatibles, PS/2 Systems, EISA-based Systems, MS-DOS Operating System Through Version 5
- (various hardware books by MindShare)
- Also useful would be real BIOS dumps and (dis)assembly, and MS-DOS source
- Emulators are no substitute for the real thing because the problem is that no emulator (commercial or otherwise) is faithful to the quirks, capabilities, and limitations of real hardware (in system, protected mode debuggers/profilers sure are nice though compared to triggering lockup, spontaneous reboot, or a beeping deadlock). If anyone remembers Bochs, its floppy behavior definitely doesn't act or look anything like a real FDC. (I submitted some patches for it many moons ago in college.)
(Yep, I own a "braindead" 286, 386DX, 486DX-100, Am5, and P5, P2, P Pro, and P4.)
Because if something can't work on real hardware and original OSes, then it's probably make believe. Prefer to make honest, real things wherever feasible.
I grew up on 68k Macs so DOS was never something I thought much about aside from the occasional boot disk to run some firmware procedure later on when later Windows was well established.
Then later from a retrocomputing standpoint, I've come to see it is pretty fascinating:
1) The sheer volume of commercial software.. which is readily available on winworld, vetusware, and archive.org. A lot of it with sometimes awesome character-mode UIs (Borland's early IDEs are really spectacular, Lotus 1-2-3, and WordPerfect are still taken seriously by some users).
2) The memory model is quixotic and an interesting homage to the chaotic evolution of x86 that most later operating systems elide by requiring a 386. The 286 and 386 have drastically different protection schemes. EMS and XMS. The eventual DOS extenders and standards like VCPI, DPMI. It's honestly a mess but somehow interesting to see how people solved difficult problems.
If anything, a lot of the modern developer experience has suffered compared to the early Borland IDEs. One would easily say we regressed.
They were focused, immediate and effective.
If anything today you'd miss the code navigation features (go to definition, go back, go forward), and of course LSP is actually very useful and once you don't have it, it hurts (instant errors, ease of refactoring...)
Give me something like the Borland IDEs (FAST!) and some of the modern features (they can be slower, they're only as fast as the LSP server implementation anyway) and I'm there!
I did a proof of concept quickly, mostly while learning to write code editors, but I have not gotten it to a point of being useful [1]
[1] https://imgur.com/a/BexhJ12
The Free Pascal software distribution includes a FLOSS look-alike of Borland's character-mode IDE for Pascal. If you can track down RHIDE, that's a similar look-alike IDE that runs in MS-DOS (it does require 386+ since it uses a DOS extender) and compiles C/C++ using gcc. (One version of it is distributed as part of the FreeDOS "development" packages.) It would be nice to recreate a broadly similar look and featureset starting from a modern text-mode editor such as the newly released MS-EDIT, aiming for modern IDE infrastructure like LSP and DAP. Such a project may find quite some use for, e.g. remote system administration tasks using ssh.
If anyone here is interested, a DOS game jam was announced recently for a streaming event called DOSember. https://itch.io/jam/dosember-game-jam Starts in a couple of weeks and lasts for three months.
DOS is an interesting platform because it can run on old hardware, and then basically anything else by way of emulation (such as in browsers) or via DOSBox.
If networking can be plumbed up, it's probably a legitimate and fun application platform for some uses that's worthy of investing time building on either for fun or for something real.
With some emulators (at least DOSBox-X) you can enable modern graphics modes that show up in SVGA in the emulated DOS and can be supported by DOS software just like any other modes. Anyone making DOS software today that isn't going explicitly for a retro look can try to detect and support a few modes like 1920x1080 and only fall back to more common old modes when necessary.
Yeah that's really cool how flexible the graphics are.
> If networking can be plumbed up, it's probably a legitimate and fun application platform for some uses that's worthy of investing time building on either for fun or for something real.
It's probably well suited to being a game console platform, too.
Heh, you might be onto something there :)
I've been playing around with raylib/raygui for cross-platform game/app development. It would be cool if it could target DOS. It probably could, but it sounds way beyond my current knowledge.
Yeah, I think the hard part would be graphics libraries for anything 3D.
I've always had a bucket-list item along the lines of "constructing basic game playing graphics primitives from scratch using the SVGA address offset for output".
MS-DOS (and games for it) ran on 486s, at the end. Writing MS-DOS games for a computer running many hundreds/thousands of times faster would probably allow for many more different types of approaches that could not be done on slow machines.
[delayed]
Someone needs to add the PC Games Programming Encyclopedia to this list. It was what I used to learn back in the 90s, a brilliant resource.
https://www.phatcode.net/articles.php?id=247
Note that DOS development tools aren't strictly necessary to make DOS software, as with help of HX DOS Extender [0], one may use any tooling that lets you produce Win32 PE exe files, of course, preferably with inline assembler to access hardware directly.
[0] https://github.com/Baron-von-Riedesel/HX
For those looking for modern MASM-compatible assembler, try JWasm: https://github.com/JWasm/JWasm
It's a fork of OpenWatcom assembler.
As someone old enough to have live through it, I always found TASM much better than MASM, in terms of tooling.
In both cases, still much better than traditional UNIX assemblers, desiged to massage C's output as another build stage, than to actually code by hand.
Anyway thanks for the heads up.
For anything written from scratch, I would recommend fasm or nasm.
I prefer the latter, because the documentation is better and there's a way to specify target cpu (e.g. 8086) and get errors when instructions aren't compliant.
I agree - nasm is excellent. I've used it for pretty much all my MS-DOS projects (games and demos).
Ah yes I forgot to mention both tools are also still under active development. I mostly use JWASM to compile samples from old MASM books/tutorials.
16-bit Borland C++ is also available: https://winworldpc.com/product/borland-c/20
GW-BASIC is fun. Microsoft released it with a MIT license and then someone forked it to make it compile and actually work:
https://codeberg.org/tkchia/GW-BASIC
For development it is convenient that PC-BASIC exists, that is a pure Python implementation of GW-BASIC that has its own partial 1999s PC emulator built in.
http://robhagemans.github.io/pcbasic/
The Free Pascal compiler can produce DOS executables as well.
I really enjoyed seeing the tools that provide an MS-DOS ecosystem.
I didn’t know there was an open source version of the Watcom compilers and a 16-bit library to support them.
DJGPP was the primary development platform for MAME when it was limited to MS-DOS. It certainly got the job done.
Microsoft included almost a full 1988 toolchain (masm, C, make, etc) in their MIT licensed MSDOS repo last year: https://github.com/microsoft/MS-DOS/tree/main/v4.0/src/TOOLS
There is no source code, but at least the license makes it free to use and redistribute. The C compiler seems very close to supporting ANSI C89.
As the header files state 1988 as last year, this would be around Microsoft C 5.0 or C 6.0 probably.
Not mentioned is the https://pcjs.org/ site which purports to let you emulate various machines in your browser, select from different disk images, and overall seems full-featured, though it is confusing and presents some difficulty when trying getting it to work on some configuration besides the pre-baked ones that you can come across.
I would like to see 16-bit Rust
> I would like to see 16-bit Rust
8-bit Rust would be even better.
https://www.reddit.com/r/rust/comments/uvshco/can_you_write_...
Seems a bit obsessed with open source when abandonware like Borland C++ 3.1 and Pascal 7.0 are amazing.
Also, missing the very important, closer to primary sources, physical dead tree resources that are needed as reference to program things.
- Black Book of Graphics Programming (Special Edition) (now FOSS)
- Programmer's Guide To The EGA, VGA, And Super VGA Cards (3rd Edition)
- PC-Intern (where I learned how Central Point, Norton, and later FreeBSD made "GUI" with sub-character graphical pointers in text mode through custom fonts)
- Undocumented PC
- Undocumented DOS
- PC Interrupts (and) Uninterrupted Interrupts (Ralf Brown)
- Microsoft MS-DOS Programmer's Reference
- The Programmer's PC Sourcebook: Reference Tables for IBM PCs and Compatibles, PS/2 Systems, EISA-based Systems, MS-DOS Operating System Through Version 5
- (various hardware books by MindShare)
- Also useful would be real BIOS dumps and (dis)assembly, and MS-DOS source
- Emulators are no substitute for the real thing because the problem is that no emulator (commercial or otherwise) is faithful to the quirks, capabilities, and limitations of real hardware (in system, protected mode debuggers/profilers sure are nice though compared to triggering lockup, spontaneous reboot, or a beeping deadlock). If anyone remembers Bochs, its floppy behavior definitely doesn't act or look anything like a real FDC. (I submitted some patches for it many moons ago in college.)
(Yep, I own a "braindead" 286, 386DX, 486DX-100, Am5, and P5, P2, P Pro, and P4.)
Because if something can't work on real hardware and original OSes, then it's probably make believe. Prefer to make honest, real things wherever feasible.
Kudos for Borland compilers, I only got into Microsoft compilers with Visual C++ 5.0 onwards.
Even for Windows, Microsoft never produced anything C++ that was as good as OWL, VCL, Firemonkey.
Or since the theme is DOS, Turbo Vision.