DOS ain't dead

rr

Berlin, Germany,
20.05.2008, 15:08

@ mr

question about including/linking

> My starting point is: I`ve compiled some win32 console applications on
> WinXP with Visual Studio.

What VS version?

> goal #1: On WinXP I want now to compile a 16 bit real mode executable for
> DOS. The exe should become at best a standalone exe. Working without
> himem/emm386/jemmex (and use only conventional memory).
>
> goal #2: On WinXP I want now to compile a 32 bit protected mode executable
> for DOS. The exe should become at best a standalone exe. Working together
> with himem/emm386/jemmex (and using memory >1024).
>
> Is goal #1/#2 feasible with HX? In case #1/#2 what files do I need to
> include or link?

AFAIK task #1 is not possible with VS and/or HX. For real mode executables a different compiler is required, e.g., Open Watcom C/C++ or old Turbo C++ 1.01 (both free).

---
Forum admin

mr

20.05.2008, 15:17

@ rr

question about including/linking

Post reply

> > My starting point is: I`ve compiled some win32 console applications on
> > WinXP with Visual Studio.
>
> What VS version?

2005 and maybe later 2008.

> > goal #1: On WinXP I want now to compile a 16 bit real mode executable
> for
> > DOS. The exe should become at best a standalone exe. Working without
> > himem/emm386/jemmex (and use only conventional memory).
> >
> > goal #2: On WinXP I want now to compile a 32 bit protected mode
> executable
> > for DOS. The exe should become at best a standalone exe. Working
> together
> > with himem/emm386/jemmex (and using memory >1024).
> >
> > Is goal #1/#2 feasible with HX? In case #1/#2 what files do I need to
> > include or link?
>
> AFAIK task #1 is not possible with VS and/or HX. For real mode executables
> a different compiler is required, e.g., Open Watcom C/C++ or old Turbo C++
> 1.01 (both free).

Maybe also DJGPP?

rr

Berlin, Germany,
20.05.2008, 16:03

@ mr

question about including/linking

Post reply

> > AFAIK task #1 is not possible with VS and/or HX. For real mode
> executables
> > a different compiler is required, e.g., Open Watcom C/C++ or old Turbo
> C++
> > 1.01 (both free).
>
> Maybe also DJGPP?

No. DJGPP's GCC always generates protected mode binaries.

---
Forum admin

Rugxulo

Usono,
20.05.2008, 21:42

@ rr

question about including/linking

Post reply

> > > AFAIK task #1 is not possible with VS and/or HX. For real mode
> > executables
> > > a different compiler is required, e.g., Open Watcom C/C++ or old
> Turbo
> > C++
> > > 1.01 (both free).
> >
> > Maybe also DJGPP?
>
> No. DJGPP's GCC always generates protected mode binaries.

Actually, DJGPP's GCC always outputs 32-bit code, and it's the libraries and stub which use and require DPMI. DJ did make a patch for 16-bit code generation, but you're stuck to not using any libraries, startup code, or even "long"! So, for 16-bit code, your best bet is probably OpenWatcom (faster resulting code than TC++ as well as being open source).

Also see the BIG "C" compiler comparison thread.

rr

Berlin, Germany,
20.05.2008, 22:09

@ Rugxulo

question about including/linking

Post reply

> > No. DJGPP's GCC always generates protected mode binaries.
>
> Actually, DJGPP's GCC always outputs 32-bit code, and it's the libraries
> and stub which use and require DPMI. DJ did make a
> patch for 16-bit code
> generation, but you're stuck to not using any libraries, startup code, or
> even "long"!

That's why I "peculated" this information. ;-)

---
Forum admin

marcov

20.05.2008, 22:00

@ rr

question about including/linking

Post reply

> > > AFAIK task #1 is not possible with VS and/or HX. For real mode
> > executables
> > > a different compiler is required, e.g., Open Watcom C/C++ or old
> Turbo
> > C++
> > > 1.01 (both free).
> >
> > Maybe also DJGPP?
>
> No. DJGPP's GCC always generates protected mode binaries.

He didn't say realmode. He said 16-bit.

Oops, he said realmode. Nevermind. Djgpp, wouldn';t have genned them anyway

flox 20.05.2008, 16:34 @ mr	question about including/linking Post reply
	MR...why do you want to compile 16-bit programs? Wouldn't 32-bit DOS programs also ok?

mr 21.05.2008, 13:29 @ flox	question about including/linking Post reply
	> MR...why do you want to compile 16-bit programs? Wouldn't 32-bit DOS > programs also ok? I thought them are the most compatible ones.

Japheth

Germany (South),
20.05.2008, 15:32

@ mr

question about including/linking

Post reply

> Is goal #1/#2 feasible with HX? In case #1/#2 what files do I need to
> include or link?

Yes, at least #2. There are examples provided in HXDEV which show how this is done.

---
MS-DOS forever!

Khusraw 21.05.2008, 07:30 @ mr	question about including/linking Post reply
	Does the program use only the standard C library? If this is true, then you can reach goal #1 by changing the compiler with one that supports 16-bit real mode. If not, as I presume, only goal #2 is reachable. AFAIK there is no development package which emulates Windows calls for 16-bit RM target.

mr 21.05.2008, 13:32 @ Khusraw	question about including/linking Post reply
	> Does the program use only the standard C library? If this is true, then you > can reach goal #1 by changing the compiler with one that supports 16-bit > real mode. If not, as I presume, only goal #2 is reachable. AFAIK there is > no development package which emulates Windows calls for 16-bit RM target. std + those which have been ported to dos... That`s also worth a consideration.

Khusraw 21.05.2008, 16:15 @ mr	question about including/linking Post reply
	> std + those which have been ported to dos... > That`s also worth a consideration. If it uses only standard C calls + libraries ported to 16-bit RM DOS, there should be no problem for you to find a suitable free C compiler. I recommend you Digital Mars.

Rugxulo

Usono,
27.05.2008, 03:49

@ Khusraw

question about including/linking

Post reply

> > std + those which have been ported to dos...
> > That`s also worth a consideration.
>
> If it uses only standard C calls + libraries ported to 16-bit RM DOS,
> there should be no problem for you to find a suitable free C compiler. I
> recommend you
> Digital
> Mars.

I've never tried Digital Mars, but it's still developed at least (good). However, compared to OpenWatcom, it doesn't (easily) run on DOS, it's 32-bit DOS extender isn't very friendly (e.g. with WinXP), and it's closed src (not able to be modified/patched). But it supports exception handling in 16-bit DOS (or something like that, no idea) at least. Not sure how good the optimizations are, though. Also, the free downloadable (non-CD) version doesn't have some utils.

DOS386

31.05.2008, 02:21

@ mr

question about including/linking

Post reply

> My starting point is: I`ve compiled some win32 console applications on
> WinXP with Visual Studio.

Good start :-)

> goal #1: On WinXP I want now to compile a 16 bit real mode executable for
> DOS. The exe should become at best a standalone exe. Working without
> himem/emm386/jemmex (and use only conventional memory).

> Is goal #1 feasible with HX?

NO. As already suggested, use WATCOM: Win32 host, DOS16RM target. But compiling DOS stuff on DOS is better :-)

VCC will NOT produce 16-bit code (except some 20 years old versions maybe) ... 32 bit at best (the future has 64 or 128 bits :clap: )

> goal #2: On WinXP I want now to compile a 32 bit protected mode executable
> for DOS. The exe should become at best a standalone exe.

Then use DPMI and include HDPMI32 / LOADPEX, no need to care about HIMEM/JAM ;-)

> In case #1/#2 what files do I need to include or link?

If you use a formally Win32 compiler, you have to link in the static Win32 emulation stuff from HX. This will bloat the executable (big problem, but DGJPP is even worse here).

FloX wrote:

> MR...why do you want to compile 16-bit programs? Wouldn't 32-bit DOS programs also ok?

16-bit is good if code fits into 64 KiB and totally hogs cca 480 KiB at most ... using 8086 instructions only.

If you need more, it's indeed better to design a fully 32-bit application, rather than pick a fight with XMS/EMS/MZ-Overliars/... that can't be really won, as 20 years of experience have shown :-|

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

question about including/linking (DOSX)

question about including/linking

question about including/linking

question about including/linking

question about including/linking

question about including/linking

question about including/linking

question about including/linking

question about including/linking

question about including/linking

question about including/linking

question about including/linking

question about including/linking

question about including/linking

question about including/linking