Hi, yes I'm sure there are. 🙂

What comes to mind:
- Open Watcom
- Free Pascal
- NASM
- SCC (small C Compiler)
- GCC (DOS port)

But I'm not up-to-date, sadly.
I do often simply use my old stuff from the 90s in a VM.
There's still so much to tinker with left. 😅

Edit: I know it's a bit of cheating, but HX DOS Extender can run text-mode programs for Win32 (PE executables).
If a GUI application doesn't use menus, it may work, too. DOSBox belongs into that category.

Edit: Allegro was cool. Didn't MEKA use it, too?

Jo22 wrote on 2023-07-08, 11:31:

I do often simply use my old stuff from the 90s in a VM.

This is probably the easiest, do you use virtual box or pcem or something else? Although coding on a fully period-correct hardware is a tempting though 🤔 I'm probably gotten too used to modern conveniences so I'd just run the code on real machine every now and then to check there is no funny business.

Jo22 wrote on 2023-07-08, 11:31:

If a GUI application doesn't use menus, it may work, too. DOSBox belongs into that category.

I'm after the classic VGA 320 x 200 (or rather the cult classic 320 x 240) with 256 colors. Initially I was planning to use Mister ao486 core as the dev platform but I read it isn't really feasible/accurate/stable so I abandoned that idea.

Jo22 wrote on 2023-07-08, 11:31:

Edit: Allegro was cool. Didn't MEKA use it, too?

Would not surprise me, it was used by tons of that midddle-late-era (free/shareware) DOS indie devs. Got my first training wheels off of programming with DJGPP/Allegro. Now with a lot of more xp under the belt would be interesting to see what is really possible within that system.

Open Watcom V2 (https://github.com/open-watcom/open-watcom-v2) is under active development and a fully DOS/Win16/OS2 able compile suite (with debugger etc.) but you can also cross build your DOS stuff with the Win64 or Linux variant (as i do)
->got a cross C and C++ compiler (wc,wcc), Linker (wlink) and Assembler (wasm) and a IDE

UniLink (http://unilinker.com/.ftp-UniLink) is a extreme feature-rich linker that still can link DOS stuff and is very active in development

NASM (https://www.nasm.us/) all you can want Assembler

UASM64 (https://github.com/Terraspace/UASM) also under active development (MASM compatible assembler - but with less errors and better error diagnostic) - use this one to assemble IDA disassembly output

MASM from Microsoft comming with VStudio - even the VS2022 version is still able to assemble DOS stuff - you only need a DOS able linker - like UniLink/Watcom wlink or some 16bit linkers

so coding can be easily done in a todays OS - only debugging is a little more complicated
but in the end you can still use good old Borland C++3.1 for your DOS development

llm wrote on 2023-07-08, 13:15:

Open Watcom V2

Exactly what I was looking for, I'll check it out, thanks.

llm wrote on 2023-07-08, 13:15:

NASM (https://www.nasm.us/) all you can want Assembler

Well, I like my code being readable. I hate when I have to choose between performance and maintainability. For self-contained algorithms sure, although there is an argument to be made that modern compilers produce better ASM than you can craft by hand.

llm wrote on 2023-07-08, 13:15:

but in the end you can still use good old Borland C++3.1 for your DOS development

Seems like a legendary compiler for sure but if I remember correctly it wasn't able to handle the protected mode. Not sure if I ever managed to get my hands into it, luckily there was a port of gcc for free as an alternative. Would be nice to explore its features today. Did it ever support the first C++ 98 standard? Would be pain to use for me if not 😁

I'm seeing lots of assemblers already - here's one more: FASM.

Does cross compiling for DOS on modern host count? I think I saw someone putting a .NET app on Win3 at some point so there may be additional options there.

There's DJGPP versions running on Windows and Linux that target protected mode DOS as output. I'd use OpenWatcom if I wanted to make real-mode output though.

doublebuffer wrote on 2023-07-08, 13:57:

llm wrote on 2023-07-08, 13:15:

but in the end you can still use good old Borland C++3.1 for your DOS development

Seems like a legendary compiler for sure but if I remember correctly it wasn't able to handle the protected mode. Not sure if I ever managed to get my hands into it, luckily there was a port of gcc for free as an alternative. Would be nice to explore its features today. Did it ever support the first C++ 98 standard? Would be pain to use for me if not 😁

Yeah, I think if you wanted DOS protected mode using official Borland products, you needed to get Borland C++ 4.0 and then the Power Pack for DOS add-on, but Borland C++ 4.0 no longer had a DOS IDE (it was for Windows 3.x). Perhaps there were third-party DOS extenders that supported 3.1?

And no, it definitely predates C++ 98! The Borland C++ 3.0 box says it implements "all of C++ 2.1 including nested classes and templates" and I think the 3.1 box referred to 2.1 too. Maybe it's similar to 98? Borland C++ 4.5 doesn't have the STL though - it has it own templates - so I found that painful. I think the original STL may have been ported to 4.5 though. Not sure what 3.1 came with.

If you don't mind your executables requiring DPMI, DJGPP still looks nice. I haven't used it for a long time, but I see it has relatively modern GCC and Emacs at least. Shame about Allegro! There may be some limitations in GCC due to short file names from what I read previously, but it looks like you can have most of C++20!

elszgensa wrote on 2023-07-08, 15:48:

Does cross compiling for DOS on modern host count? I think I saw someone putting a .NET app on Win3 at some point so there may be additional options there.

Open Watcom can already do that. It's entirely possible to build DOS programs from a Linux host, as well as using the IDE with Windows.

.NET to Win 3.x (NT or not) was some kind of experimental feature for .NET 5.0 back then... not sure if the possibility ever entered formal .NET releases, namely .NET 6.0 or even 7.0...

LSS10999 wrote on 2023-07-09, 05:01:

.NET to Win 3.x (NT or not) was some kind of experimental feature for .NET 5.0 back then... not sure if the possibility ever entered formal .NET releases, namely .NET 6.0 or even 7.0...

At first I thought that sounded like it would be nice and powerful with lots of modern features that can be used, but slow due to the use of managed code. However, it sounds like it is/was the opposite - it's native-compiled code which will run under Win32s, but even just to display a message box (all the demonstration did) required direct API calls, apparently. I guess WinForms/WPF/whatever don't just magically work on old Windows versions.

I'd be tempted to learn C# - or maybe one of the other supported languages - if I could actually easily produce a working GUI using this. I'm currently learning a bit of Delphi 1.0 and refreshing my Pascal skills which I haven't used for about 25 years in order to make a Windows 3.1 GUI application.

As for DOS, a comment on https://hackaday.com/2020/02/09/c-the-languag … s-3-11-and-dos/ suggested that the .NET code wasn't really being translated to native DOS code but rather something which required https://github.com/Baron-von-Riedesel/Dos64-stub ('small stub that allows to run "bare" 64-bit PE binaries in DOS', I guess it's like HX DOS Extender).

doshea wrote on 2023-07-09, 06:07:

As for DOS, a comment on https://hackaday.com/2020/02/09/c-the-languag … s-3-11-and-dos/ suggested that the .NET code wasn't really being translated to native DOS code but rather something which required https://github.com/Baron-von-Riedesel/Dos64-stub ('small stub that allows to run "bare" 64-bit PE binaries in DOS', I guess it's like HX DOS Extender).

A stub? I see parallels to OS/2 and "Family Mode" programs using "Family API".
These essentially were OS/2 programs with a built-in OS/2 runtime.
They could natively under OS/2, but also more or less under plain DOS.

https://www.landley.net/history/mirror/os2/hi … s213/index.html

https://www.os2museum.com/wp/os2-history/os2-1-0/

https://osfree.org/doku/en:docs:os2:api🎻

That reminds me a bit of Windows 3.1/DOS hybrid EXEs (Windows Setup) or Carbon applications on Power PC Macs, too.

Edit: If you enjoy doing a bit of Windows 3.x development, please have a look at MS Quick C for Windows 1.0. .
It's a cute little compiler that runs completely on Windows 3.x and doesn't require DOS environment variables to be set up etc.
If you have tinkered with DOS-based 16-Bit Windows SDK before, you may remember how messy this can be at times.

Quick C also can create similar pseudo-textmode applications like Turbo Pascal for Windows can.
They helped at making DOS-based source code run on Windows without much alteration.
To do so, they simulated MS-DOS prompt (inverse colour).
The resulting programs are essentially MS-DOS look-alikes running on Windows 3.x.

Edit: It just comes to mind because the C programming handbook my father has in his book shelve mentioed MS Quick C for Windows.

Open Watcom is great, especially if you want to do cross compiling from Linux. It has all your target types down.

However, don't try to use it with Allegro. In that case stick with djgpp. There are much newer versions of GCC available now, so don't go trying to use the bundle from the DJ delorie site. Again, you can grab a cross compiler version of it these days.

I use both. Djgpp for Allegro work, and Open Watcom for non Allegro (and real mode) stuff.

Oh, and the last release of Allegro for DOS (4.x) still builds perfectly fine with the latest djgpp/GCC.

I have some notes about building it with GCC 12.x on Linux here: https://www.target-earth.net/wiki/doku.php?id … blog:pcdevtools

I personally use OpenWatcom on a Linux desktop for development. I develop against DOSBox as my normal development cycle and then every once in a while I test on an actual period correct system.

OpenWatcom supports all the vintage targets you need like DOS/16 bit, DOS/32 bit, Windows/16 bit, Windows/32 bit, etc. The only thing it doesn't support is MFC for Windows like the original Watcom release did as it needs a licence from Microsoft to distribute the SDK.

OpenWatcom comes with the WASM assembler which seems to be mostly compatible with MASM 5 syntax/features, which is clunky and inconvenient. This is a bit old and I would highly recommend to use JWASM as an alternative instead, which is a fork of the original WASM and highly extended feature wise to be more MASM 6+ compatible plus a lot more.

https://www.japheth.de/JWasm.html

megatron-uk wrote on 2023-07-09, 19:21:

I use both. Djgpp for Allegro work, and Open Watcom for non Allegro (and real mode) stuff.

This is what I also though of doing, and for exactly those use-cases as well. As a first exercise I think I will do something in real mode / mode X and see what kind of performance I get from bog-standard 386SX VGA.

megatron-uk wrote on 2023-07-09, 19:25:

I have some notes about building it with GCC 12.x on Linux here: https://www.target-earth.net/wiki/doku.php?id … blog:pcdevtools

Super-useful, bookmarked!

After re-introducing myself to dos graphics programming I am almost fully loaded now. However, I could learn more, so if anyone has a link or pdf to the original spec of the VGA I'd be grateful.

I found this page, but it only covers the most basic (albeit useful) case, write mode 0, but anything else is left for experiments: https://wiki.osdev.org/VGA_Hardware#Write_mode_3

It would be interesting to learn what this write mode 3 actually does or supposed to do from the original docs. I think I already found one optimization trick which wasn't even covered in Abrash's black book of graphics programming, trying that out when I get the dev environment set up.

You can probably find some interesting old school books here:

https://www.pcjs.org/documents/books/programming/

doublebuffer wrote on 2023-07-10, 12:02:

After re-introducing myself to dos graphics programming I am almost fully loaded now. However, I could learn more, so if anyone has a link or pdf to the original spec of the VGA I'd be grateful.

I found this page, but it only covers the most basic (albeit useful) case, write mode 0, but anything else is left for experiments: https://wiki.osdev.org/VGA_Hardware#Write_mode_3

It would be interesting to learn what this write mode 3 actually does or supposed to do from the original docs. I think I already found one optimization trick which wasn't even covered in Abrash's black book of graphics programming, trying that out when I get the dev environment set up.

The IBM VGA/XGA manual has the entire VGA documentation: http://mcamafia.de/pdf/ibm_vgaxga_trm2.pdf

Gmlb256 wrote on 2023-07-10, 20:28:

The IBM VGA/XGA manual has the entire VGA documentation: http://mcamafia.de/pdf/ibm_vgaxga_trm2.pdf

Thank you! I knew when google doesn't yield anything, someone here would know.

doublebuffer wrote on 2023-07-10, 20:40:

Gmlb256 wrote on 2023-07-10, 20:28:

The IBM VGA/XGA manual has the entire VGA documentation: http://mcamafia.de/pdf/ibm_vgaxga_trm2.pdf

Thank you! I knew when google doesn't yield anything, someone here would know.

The IBM VGA/XGA manual is fairly comprehensive, but it's missing one thing - a disassembly of the VGA BIOS.
Believe it or nor, but there was a time in which computer manuals contained such a thing.
The Sharp MZ-80 series for example, has a manual that comes with a disassembly of the monitor program.

Edit: This might be also interesting; the data book of the Paradise VGA Professional Card.
The Paradise chip saw practical application.
Its 800x600 16c mode wasn't being unheard of, either.

http://bitsavers.trailing-edge.com/components … e/19_PVGA1A.pdf