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.
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.
8-bit Rust would be even better.
It's a fork of OpenWatcom assembler.
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.
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.
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.
Comes down to around 2 MB after cleaning up a bit. 1.4 MB if only keeping support for one memory model. Runs fine in DOSBox, so this is an easy way to make a project self-contained, building from within the target platform with no external dependencies.
I did not had an environment to try it out, great that I didn't land that far off just from my memories. :)
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.
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.
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]
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.
Even for Windows, Microsoft never produced anything C++ that was as good as OWL, VCL, Firemonkey.
Or since the theme is DOS, Turbo Vision.
* Gambit-C 3.0 for MS-DOS (https://gambitscheme.org/3.0/gc30-dj.zip)
* MIT-Scheme 7.3 for DOS: (https://groups.csail.mit.edu/mac/ftpdir/scheme-7.3/pc/)
Both need a 386+.
* PC-Scheme/Geneva (https://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/...) Bytecode compiler, runs on 8086+, can use up to 2MB of EMS memory.
whitten•5mo ago
I didn’t know there was an open source version of the Watcom compilers and a 16-bit library to support them.
3036e4•5mo ago
https://github.com/open-watcom/open-watcom-v2/discussions/27...