Hi,

I have mostly used Watcom C/C++(And some Borland/Turbo C) during the DOS era, and moved to Microsoft Visual C++ after going to Win9X, however the version 6.x message:

llm wrote on 2026-06-11, 07:35:

This program cannot be run in DOS mode.

Most likely means that the compiler is setup to compile Windows programs and not DOS ones, so it might be fixable by simply running the compiler with a different flag or a slight adjustment to the makefile.

I'm not sure what is going on with 7.x, so I cannot comment on that.

MagefromAntares wrote on 2026-06-11, 08:08:

I have mostly used Watcom C/C++(And some Borland/Turbo C) during the DOS era, and moved to Microsoft Visual C++ after going to Win9X, however the version 6.x message:

im analysing debugformat of old Microsoft compilers so im trapped 😀

llm wrote on 2026-06-11, 07:35:

This program cannot be run in DOS mode.

Most likely means that the compiler is setup to compile Windows programs and not DOS ones, so it might be fixable by simply running the compiler with a different flag or a slight adjustment to the makefile.

the compiler is still building DOS exe and the compiler itself prints the message not the resulting executeable

it seems a DPMI bug with dosbox and the DOS32X extender

llm wrote on 2026-06-11, 08:18:

im analysing debugformat of old Microsoft compilers so im trapped :) […]
Show full quote

MagefromAntares wrote on 2026-06-11, 08:08:

I have mostly used Watcom C/C++(And some Borland/Turbo C) during the DOS era, and moved to Microsoft Visual C++ after going to Win9X, however the version 6.x message:

im analysing debugformat of old Microsoft compilers so im trapped 😀

llm wrote on 2026-06-11, 07:35:

This program cannot be run in DOS mode.

Most likely means that the compiler is setup to compile Windows programs and not DOS ones, so it might be fixable by simply running the compiler with a different flag or a slight adjustment to the makefile.

the compiler is still building DOS exe and the compiler itself prints the message not the resulting executeable

it seems a DPMI bug with dosbox and the DOS32X extender

Oh sorry, I misinterpreted that it was the compiled .exe making the error messages 😁.

Although then it most likely means that version 6.x is simply not meant to be run under DOS. The 7.x is a more curious case, however it wouldn't be out of character for M$ to making it so that their 7.x version of compiler only to run with DOS Extenders that M$ officially approve, so it might not be a bug with Dosbox, but a "feature" to make it run only with M$ approved extenders.

MagefromAntares wrote on 2026-06-11, 08:37:

Although then it most likely means that version 6.x is simply not meant to be run under DOS. The 7.x is a more curious case, however it wouldn't be out of character for M$ to making it so that their 7.x version of compiler only to run with DOS Extenders that M$ officially approve, so it might not be a bug with Dosbox, but a "feature" to make it run only with M$ approved extenders.

the extender is builtin the CL.EXE and its does not run on dosbox - that does not mean it wont run on a real DOS (didn't test it so far)

llm wrote on 2026-06-11, 08:49:

MagefromAntares wrote on 2026-06-11, 08:37:

Although then it most likely means that version 6.x is simply not meant to be run under DOS. The 7.x is a more curious case, however it wouldn't be out of character for M$ to making it so that their 7.x version of compiler only to run with DOS Extenders that M$ officially approve, so it might not be a bug with Dosbox, but a "feature" to make it run only with M$ approved extenders.

the extender is builtin the CL.EXE and its does not run on dosbox - that does not mean it wont run on a real DOS (didn't test it so far)

Hmm, if the extender is directly built into the EXE then it is possible that M$ played the same game as with some versions of Windows, that it will only run on original MS-DOS and other implementations of DOS like DR-DOS or even Dosbox are incapable of running it.

Think about it: why would a program have a DOS stub that prints "This program cannot be run in DOS mode" if it was meant to be DOS compatible...

jmarsh wrote on 2026-06-11, 09:36:

Think about it: why would a program have a DOS stub that prints "This program cannot be run in DOS mode" if it was meant to be DOS compatible...

i've read something before with relation to some DOS32X problem and dosbox - so i thought the message was misleading

i've found a ready to use WinXP SP3 x86 VM in between

5.x => builds without problem
6.x => This program cannot be run in DOS mode.
7.x => builds without problem

could it be that 6.x maybe only runs on 3.x or maybe Win95? that will be a install party - installing Win 3.x/Win95/98 with all this speed-etc. fixes is such a mess 🙁

installing Win 3.11 in dosbox - from Win 3.11 command prompt

5.x => builds without problem
6.x => This program cannot be run in DOS mode.
7.x =>
run-time error R6914
- DOSX32 : can not initialize device : VPFD.386 (with or without win /3)

jmarsh wrote on 2026-06-11, 09:36:

Think about it: why would a program have a DOS stub that prints "This program cannot be run in DOS mode" if it was meant to be DOS compatible...

This means it's Win32. "DOS mode" refers to the booting-to-MS-DOS option of Windows 95. DOSBox does not support running Windows 95 applications (posting about it outside the dosbox forum won't avoid the rule), and a lot of "oh win95 just runs on dos" led to a lot of misconceptions on what a DOS app is, even if it doesn't open a window.

I just tried a C/C++ 6.0 image I found and the first thing the setup asked is whether I wanted OS/2 or DOS EXEs. Maybe you've got the OS/2 ones.

jakethompson1 wrote on 2026-06-11, 20:51:

I just tried a C/C++ 6.0 image I found and the first thing the setup asked is whether I wanted OS/2 or DOS EXEs. Maybe you've got the OS/2 ones.

that gave me the hint - i did the setup correct but my fault was to copy all files of the install images into one setup folder
so the CL.EX$ for DOS was replaced by the CL.EX$ for OS/2 before setup - im stupidly thought that the setup would handle copying all files together gracefully (and no same named files) 🙁
(LINK.EXE and LIB.EXE were fully working only the CL.EXE was the problem in my testing...)

now im redoing the setups for MS C 5, 6 and 7 cleanly

thanks for all the tips/ideas so far

everything is working now

5.x, 6.x => can build without problem on dosbox
7.x => builds without problem in XP VM

question: is there any possibility to get 7.x running on dosbox (vanilla,X,staging) to ease my testing?

1run-time error R6901
2- DOSX32 : This is a protected-mode application that requires DPMI 
3(DOS Protected Mode Interface) services. Examples of hosts that provide 
4these services include:
5  - a DOS session under Windows 3.x in enhanced mode
6  - Qualitas' 386MAX or BlueMAX version 6.x

its not stating that it needs to be windows around but some DPMI service

tested HX Extender HDPMI32.EXE v2.23, Borland C 5.02 32RTM.EXE and CWSDPMI.EXE r7 - the error result changes and then crahes

ask the HX Extender author: https://github.com/Baron-von-Riedesel/HX/issu … ment-4691564042

seems to be some unclean programming in C 7.0

so i will use XP for my tests