Is DJGPP not an option? I prefer MinGW32 GCC 4.7 (win32) and DJGPP (DOS32)

OzzFan wrote on 2026-07-10, 22:58:

MSVC Cons:

• Cannot target Win32s or Win32

I may be misunderstanding what you're referring to here but isn't MSVC what comes with every visual/developer studio? Those can target win32 just fine.

OzzFan wrote on 2026-07-10, 22:58:

Are there any good reasons to care about ensuring if other people can compile using the same compiler, or should I let them worry about that?

What compiler do you use for your retro coding and why?

I do retro programing for fun. So I use the tools I want to use and where I am comfortable with (mostly good old Borland stuff) and don't worry about other people.

If I would be creating a huge project and want others to collaborate than it's another story and in your case I would choose Open Watcom. But than again it's retro. So most projects aren't that big and most probably wouldn't attract a huge number of people who want to participate anyway.

My advice: use the one you like the most. 😀

I used djgpp for my last project ( BIOSDUMP - extract the BIOS without a hardware programmer )

Pros:
The editor is good, as well as the documentation
It compiles to 32 bits and comes with a dos extender which you can embed into the program you're writing
Cons:
It's a bit slow to compile programs with
Not sure about code density, speed, etc as I have not ran any comparisons

I did not try to link with asm code but the documentation shows how to do it. GAS is the assembler and it should be possible to use either intel or at&t syntax.
I'm just a hobbyist with little experience but I hope this helps.

leileilol wrote on Yesterday, 00:03:

Is DJGPP not an option? I prefer MinGW32 GCC 4.7 (win32) and DJGPP (DOS32)

I should have specified I'm mostly writing for real mode DOS or Win16 applications, but I've been developing Win32s versions of my Windows programs on the side.

Fish3r wrote on Yesterday, 00:07:

OzzFan wrote on 2026-07-10, 22:58:

MSVC Cons:

• Cannot target Win32s or Win32

I may be misunderstanding what you're referring to here but isn't MSVC what comes with every visual/developer studio? Those can target win32 just fine.

MSVC 1.52c is DOS/Win16 only. I have to use MSVC 2.2 or higher to get Win32, which isn't a huge problem for me.

The newer compilers for MSVC that support targeting Win32 are going to have much better compilers and give you better optimized code.

Visual Studio 2019 seems to be the last version that supports targeting Win32 without any shenanigans.

I don't much like GCC as I have had issues with it in the past where turning full optimization on creates code that crashes, while the same code with full optimization works perfectly fine when compiled with MSVC.

Have you looked at Digital Mars? It's the evolution of the Zortech compiler, and still maintained (maybe?) like OpenWatcom.

jakethompson1 wrote on Yesterday, 03:08:

Have you looked at Digital Mars? It's the evolution of the Zortech compiler, and still maintained (maybe?) like OpenWatcom.

I have, and I even bought a copy of it. It pretty much has the same pros and cons of the Symantec compiler, except it has an extra oddity in that to compile projects I have to go into the settings and either check or uncheck "Ignore capitalization." This happens regardless of what project I make, which tells me something is broken within the source headers/includes and no one has bothered to fix it. Maybe I'm being too cautious, but I have concerns about using a compiler whose headers/includes are broken. I don't really think it is being maintained anymore.

For simple Winblows tools, I tend to use LCC, for more complex stuff I sometimes resort to MVSC

To crank out capabable & SMALL tools for DOS (and Winblows with my DVM virtual machine), I pretty much only use my own Micro-C/PC toolset,
there's an amazing extra understanding of a toolset when you've written it yourself!

That's very cool! I'm no quite there yet to be able to build my own compiler.

You don't say whether you're coding C or C++. For C++ you'll have trouble moving between compilers. If you do plan to share code and want to keep compiler options open, you should compile on all of them and build with whatever you like. You mention assembly, which if you intend to share code... good luck without those assembler-specific macros. (Then again, there was a separate free macro thing... was it m4?) You also don't mention the notorious optimization bug in microsoft's compiler that affected every other version from 1982 to 2000 at least, including their C & C++ compilers. (Loops were optimized to go from negative up to 0--what was that instruction that bumped cx?-- but were optimized to store the size in a byte, and they failed to sign extend into a 16 or 32-bit register.) BTW, I used Borland & Watcom (paid, not open), and VC a bit, and there are a ton of optimizations to include assembly, cut file sizes, optimize, etc, but you need to learn them and they're very watcom-specific. I thought open-watcom kept all of that stuff, though I can't be sure about all the optimizations. Also, consider using the windows resource editor from one toolset with the compiler from another. I did that all the time because (I forget which) one of them was able to do a lot more--there's at most a tiny edit to an include that's completely portable once done (iirc), and I seem to remember at least one slight incompatibility in particular controls that can be worked around with a quick edit--or don't use that particular editor. At least that's how I remember things from 30 years ago.

I don't understand why you include NT at all. It's a completely different beast. Personally, I wouldn't bother with compatibility to include both DOS & NT. I'd make a split somewhere, though exactly where is a tough decision. I don't see how you actually have a project that spans all that. Libraries?

Some great questions! Let me fill in the blanks.

SiBurning wrote on Today, 02:24:

You don't say whether you're coding C or C++.

I write a suite of utilities for DOS and Windows 3.1x. Some utilities are written in C89 and others in C++ (pre C++ 98). C89 seems to be a natural fit for Win16 API (Win32 API too), so I use that when I don't need "extra" features like classes. However, I've written a DOS TUI framework for my applications using C++'s inheritance and encapsulation model.

SiBurning wrote on Today, 02:24:

You also don't mention the notorious optimization bug in microsoft's compiler that affected every other version from 1982 to 2000 at least, including their C & C++ compilers. (Loops were optimized to go from negative up to 0--what was that instruction that bumped cx?-- but were optimized to store the size in a byte, and they failed to sign extend into a 16 or 32-bit register.)

I wasn't aware of said bug, but now I am. I'll have to look into that more. As best I can tell, I haven't been bitten that by bug in my programs yet.

In a similar fashion, I was just bitten by an Open Watcom library bug when porting my applications from MSVC to OW. It seemed I hit a rare occurrence when writing a Win16 application with the data structures I was using caused the application to crash on exit every time. This is what made me want to switch back to MSVC and also what prompted this thread so I could get ideas and perspectives from others.

SiBurning wrote on Today, 02:24:

BTW, I used Borland & Watcom (paid, not open), and VC a bit, and there are a ton of optimizations to include assembly, cut file sizes, optimize, etc, but you need to learn them and they're very watcom-specific. I thought open-watcom kept all of that stuff, though I can't be sure about all the optimizations.

There are a lot of options in Open Watcom, but it doesn't seem that the GUI is well organized to easily locate the appropriate options. From what I'm reading online, it looks like using the command line compilers and linkers net you better results than the GUI. While I do love the command line, it seems it defeats the purpose of using a GUI.

MSVC is at a real disadvantage when it comes to assembling .ASM files. Symantec can do it if you have MASM installed - it will simply call it to perform the compile and then link the object to the project. Open Watcom comes with WASM which is almost as good as MASM but seems to be a bit more picky.

I do like that with Open Watcom and Symantec I can target other OSes like Windows 9x or NT. Watcom can even target OS/2 applications if I ever decide to write for that. But with the aforementioned bug, Watcom's flexibility doesn't seem worth the hassle of bad binaries.

SiBurning wrote on Today, 02:24:

Also, consider using the windows resource editor from one toolset with the compiler from another. I did that all the time because (I forget which) one of them was able to do a lot more--there's at most a tiny edit to an include that's completely portable once done (iirc), and I seem to remember at least one slight incompatibility in particular controls that can be worked around with a quick edit--or don't use that particular editor. At least that's how I remember things from 30 years ago.

That's an interesting idea. I remember in the Open Watcom options that it can read/save resource scripts in MSVC format for compatibility, so maybe that would solve my problem with Watcom's terrible resource editor.

SiBurning wrote on Today, 02:24:

I don't understand why you include NT at all. It's a completely different beast. Personally, I wouldn't bother with compatibility to include both DOS & NT. I'd make a split somewhere, though exactly where is a tough decision. I don't see how you actually have a project that spans all that. Libraries?

I only mention NT because it is my development OS. I write my programs on Windows NT 3.51 since it is far more stable than real DOS + Windows 3.1 and it allows me to use an interface similar to the Windows 3.1x utilities I'm writing.

However, in parallel to writing my Windows 3.1x utilities, I've also written Win32s versions of most of them, which NT provides a decent platform for writing and testing (though real Windows 3.1 with Win32s always remains the best test platform for that).