DOS ain't dead

According to David Lindauer (and indirectly, Japheth), it seems that FreeDOS, unlike other DOSes, is unable to run BCC 5.5 (circa 2000) under HX. That was as of two months ago, and I haven't heard back from him (just replied yet again since I downloaded it today ... no re-registration required, thankfully). Anybody have any idea? I haven't tried it yet in pure FreeDOS, but it's not too hard to do (8 MB download, 50 MB once installed).

In other odd news, I had heard recently that Embarcadero no longer offers the free Turbo C++ Explorer 2006 for download. It turns out that it's true! Kinda annoying for people who wanted to be able to get TASM32 5.3 (latest/last version). Although, to be honest, TC++ 2006 never installed for me anyways (Vista), so I can't say I hugely blame them. And I guess TASM is semi-moot since YASM and WASM both partially support its syntax now. But still ....

EDIT: WDOSX does seem to support it (C, not C++ though, no exception support??), but either way it's still fairly bloated compared to OpenWatcom or DJGPP. So that's kinda a letdown.

> According to David Lindauer (and indirectly, Japheth), it seems that
> FreeDOS, unlike other DOSes, is unable to run
> BCC 5.5 (circa
> 2000) under HX. That was as of two months ago, and I haven't heard back
> from him (just replied yet again since I downloaded it today ... no
> re-registration required, thankfully). Anybody have any idea? I haven't
> tried it yet in pure FreeDOS, but it's not too hard to do (8 MB download,
> 50 MB once installed).

This can't be a general problem, because it works for me. JWasm happens to supply a makefile for BCC, and I can run this makefile in FreeDOS (good idea to install a cache before trying this). The compiler spits out a lot of warnings, but it does so in Win32 as well. The JWasm binary which is finally created runs without problems.

---
MS-DOS forever!

> This can't be a general problem, because it works for me.

Apparently, he says it's only related to system() and only on FreeDOS. But he hasn't tested 2039 yet.

> Although, to be honest, TC++ 2006 never installed
> for me anyways (Vista), so I can't say I hugely blame them. And I guess
> TASM is semi-moot since YASM and WASM both partially support its syntax
> now. But still ....

Since they seem to have canned TD 2006 too, which installed perfectly fine on Vista, I doubt the Vista bit is the reason.

> EDIT: WDOSX does
> seem to support it (C, not C++ though, no exception support??), but either
> way it's still fairly bloated compared to OpenWatcom or DJGPP. So that's
> kinda a letdown.

What, run "bloat" or compile "bloat", and what exactly is this "bloat" anyway?

> Since they seem to have canned TD 2006 too, which installed perfectly fine
> on Vista, I doubt the Vista bit is the reason.

Kinda weird on their part, though, right?

> What, run "bloat" or compile "bloat", and what exactly is this "bloat"
> anyway?

One .EXE in particular (though admittedly not the biggest project) isn't as small as the DJGPP (2.03p2) one, even.

> Apparently, he says it's only related to system() and only on FreeDOS. But
> he hasn't tested 2039 yet.

Who ? David Lindauer ? Of course it would be nice to know the bug symptoms and what FreeDOS does wrong.

> is unable to run BCC 5.5 (circa 2000) http://downloads.embarcadero.com/free/c_builder

The download link doesn't work:

> javascr***:downloadItem('http://altd.embarcadero.com/download/bcppbuilder/
> freecommandLinetools.exe', 24778, 3,

> 'Export restrictions', 'EXPORT CONTROLS ON THE PROGRAMS
> Selecting the "I Agree" button is a confirmation of your agreement that you comply,
> now and during your use of the product, with each of the following statements:

> - You are not a citizen, national, or resident of, and are not under
> control of, the government of Burma/Myanmar, Cuba, Iran, Sudan, North Korea,
> Syria, nor any country to which the United States has prohibited export.

But I am

> - You will not download or otherwise export or re-export the Programs, directly
> or indirectly, to the above mentioned countries nor to citizens, nationals or
> residents of those countries.

Oh well ...

> - You are not listed on the United States Department of Treasury lists of Specially
> Designated Nationals, Specially Designated Terrorists, and Specially
> Designated Narcotic Traffickers, nor are you listed on the United States
> Department of Commerce Table of Denial Orders.

But I am

> You will not download or otherwise export or re-export the Programs, directly
> or indirectly, to persons on the above mentioned lists.

Oh well ...

> You will not use the Programs for, and will not allow the Programs to be used
> for, any purposes prohibited by United States law, including, without limitation,
> for the development, design, manufacture or production of nuclear, chemical
> or biological weapons of mass destruction.

But that's exactly what I intended to do

> EXPORT RESTRICTIONS
> You agree that U.S. export control laws and other applicable export and
> import laws govern your use of the programs, including technical data.

> You agree that neither the programs nor any direct product thereof will be
> exported, directly, or indirectly, in violation of these laws, or will be used for
> any purpose prohibited by these laws including, without limitation,
> nuclear, chemical, or biological weapons proliferation.');

That's why Arachne doesn't support JS

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

> > Apparently, he says it's only related to system() and only on
> FreeDOS. But
> > he hasn't tested 2039 yet.
>
> Who ? David Lindauer ? Of course it would be nice to know the bug symptoms
> and what FreeDOS does wrong.

Yes, David, and he never supplied any sample code, so I can't say for sure. (Japheth probably knows but is busy working hard as always, heh.)

> > - You are not a citizen, national, or resident of, and are not under
> > control of, the government of Burma/Myanmar, Cuba, Iran, Sudan, North
> Korea,
> > Syria, nor any country to which the United States has prohibited
> export.
>
> But I am

Heh, God forbid they use a freakin' compiler. Oh noes! (BTW, I thought somebody said you were from Switzerland.) Anyways, I'm pretty sure this is less their idea than obeying some weird U.S. law.

> Yes, David, and he never supplied any sample code, so I can't

Somewhat hard to debug "someone said that something doesn't work"

He is known to love the BCC compiler besides his own, BTW, if you are in contact with him, did he say anything about his CC386 ?

BTW, MinGW got finally updated to GCC 4.4.0 : http://mingw.org/wiki/Getting_Started

OTOH Sherpya wrote http://oss.netfarm.it/mplayer-win32.php :

> Sep 27, 2009: I'm evaluating llvm to build mplayer since gcc versions > 4.2 are almost unusables

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

> > Yes, David, and he never supplied any sample code, so I can't
>
> Somewhat hard to debug "someone said that something doesn't work"
>
> He is known to love the BCC compiler besides his own, BTW, if you are in
> contact with him, did he say anything about his CC386 ?

No, he didn't say much, just that he had issues with system() with both compilers under FreeDOS. Haven't heard anything else, sorry.

> BTW, MinGW got finally updated to GCC 4.4.0 :
> http://mingw.org/wiki/Getting_Started
>
> OTOH Sherpya wrote http://oss.netfarm.it/mplayer-win32.php :
>
> > Sep 27, 2009: I'm evaluating llvm to build mplayer since gcc versions >
> 4.2 are almost unusables
>
>

I know there are changes, but it isn't THAT bad, AFAICT. Then again, I don't know the details. (But I do somewhat dislike MinGW for using MSVCRT, just asking for trouble IMHO.) I wish more people used OpenWatcom.

> > BTW, MinGW got finally updated to GCC 4.4.0 :
> > http://mingw.org/wiki/Getting_Started
>
> Then again, I
> don't know the details. (But I do somewhat dislike MinGW for using MSVCRT,
> just asking for trouble IMHO.) I wish more people used OpenWatcom.

I upgraded my mingw before some weeks :) Yes it's dependent on msvcrt but it allows make very small exe files. If it is not acceptable for you just go for cygwin which do all the things own way but needs ~2MB DLL :P

---
DOS gives me freedom to unlimited HW access.

> I upgraded my mingw before some weeks :) Yes it's dependent on msvcrt but
> it allows make very small exe files. If it is not acceptable for you just
> go for cygwin which do all the things own way but needs ~2MB DLL :P

I'm not on my other computer, so I can't test every compiler (e.g. Cygwin, OW 1.8 instead of 1.7, BCC55), but here's a quick look:


 Directory of C:\windows\system32

04/13/2008  06:12 PM            57,344 msvcirt.dll
08/18/2001  06:00 AM           565,760 msvcp50.dll
04/13/2008  06:12 PM           413,696 msvcp60.dll
03/18/2003  01:14 PM           499,712 MSVCP71.dll
01/05/2002  01:37 PM           344,064 MSVCR70.DLL
02/20/2003  09:42 PM           348,160 MSVCR71.dll
04/13/2008  06:12 PM           343,040 msvcrt.dll
08/18/2001  06:00 AM           253,952 msvcrt20.dll
04/13/2008  12:30 PM            61,440 msvcrt40.dll
               9 File(s)      2,887,168 bytes
               0 Dir(s)  68,122,759,168 bytes free

[ WinXP ] Tue 11/10/2009>upxlist
     43520 ->     20480   47.06%    win32/pe     bef-cc386.exe
     10240 ->      8192   80.00%    win32/pe     bef-mingw.exe
      9216 ->      6656   72.22%    win32/pe     bef-tinyc.exe
     46592 ->     26112   56.04%    win32/pe     bef-watcom.exe

[ WinXP ] Tue 11/10/2009>scrndump win32-cc-compare.txt


N.B. IIRC, the BCC55 (Win32) compile of BEF.C was approx. 80k uncompressed.

MinGW is probably a little smaller and faster, but it's not much (although I don't have any big projects to compare, so take that with a grain of salt). Also, Cygwin (unless you pay them) requires your app be GPL (or similarly open source), esp. if you redistribute the .DLL (which needs you to host the .DLL's srcs, which are kinda big, 11 MB .tar.bz2, IIRC). But at least Cygwin can be bugfixed.

And anyways, I don't prefer Cygwin over MinGW, obviously I prefer DJGPP (or OpenWatcom)!

I think that msvcrt dlls are default present on windows system so for mingw progs you just provide a few kb binary but for cygwin you need big extra dll. I don't have experiences with OW but both mingw and cygwin use gcc and some standard libs which is good for source code compatability with djgpp or linux gcc, etc.

> And anyways, I don't prefer Cygwin over MinGW, obviously I prefer DJGPP
> (or OpenWatcom)!

I don't compare mingw/cygwin with djgpp because I use mingw only for progs using winapi or some specific windows functions that's impossible with djgpp. for other cases I prefer djgpp, it's then possible to compile it under mingw or linux (if some dos/bios specific not used).

---
DOS gives me freedom to unlimited HW access.

> I think that msvcrt dlls are default present on windows system

Which MSVCRT? Which Windows? I don't think they are compatible, for the most part, hence you're kinda on your own. I'm not sure MinGW (or anybody) runs on anything older than Win2k. If that's fine with you, fine. Otherwise, don't expect it to work. (And I think some HX apps don't work with Vista's MSVCRT.DLL, but I could be wrong, I never tried too much.)

> so for mingw
> progs you just provide a few kb binary but for cygwin you need big extra
> dll.

You only need to download it once, though, and like I said, if you develop some open source app, it doesn't need to distribute the .DLL with it (but you'll need to ship srcs too if you do include it).

> I don't have experiences with OW but both mingw and cygwin use gcc
> and some standard libs which is good for source code compatability with
> djgpp or linux gcc, etc.

If something relies on GCC, it's not very portable. The standards are not written by GNU. Sadly, however, GCC still doesn't fully implement C99 yet, MSVC probably never will, OpenWatcom lacks POSIX (as does Cygwin), and even Cygwin is more Unix-y than Windows (almost). In other words, it's harder getting something working on several compilers than it probably should be.

Actually, if you get the MinGW runtimes, you can build MinGW-ish apps from Cygwin ("-mno-cygwin", IIRC), best of both worlds.

> I don't compare mingw/cygwin with djgpp because I use mingw only for progs
> using winapi or some specific windows functions that's impossible with
> djgpp. for other cases I prefer djgpp, it's then possible to compile it
> under mingw or linux (if some dos/bios specific not used).

The days of one app to rule them all (and in the darkness bind them) are over. You can no longer rely on Win32 apps working everywhere nor Linux apps nor DOS apps, etc. It's really annoying.

> Which MSVCRT? Which Windows? I don't think they are compatible, for the
> most part, hence you're kinda on your own.

I have msvcrt.dll in my Win98SE and all my mingw apps run fine there. If you don't use newer winapi funcs it's not problem under win9x.

> You only need to download it once, though, and like I said, if you develop
> some open source app, it doesn't need to distribute the .DLL with it (but
> you'll need to ship srcs too if you do include it).

Well but in some special cases, e.g. when need to copy prog on floppy to some old PC with windows it's faster to copy e.g. 8kB exe than loading 2 floppies. Of course on modern PC where you don't count the size it doesn't matter some megs+

> If something relies on GCC, it's not very portable. The standards are not
> written by GNU. Sadly, however, GCC still doesn't fully implement C99 yet,
> MSVC probably never will, OpenWatcom lacks POSIX (as does Cygwin), and even
> Cygwin is more Unix-y than Windows (almost). In other words, it's harder
> getting something working on several compilers than it probably should be.

Hm I didn't have problems with it. I use GCC under DOS, Win, Linux, ARM and AVR MCUs and most of code doesn't need changes. Of course except HW dependent stuffs. Yes cygwin is much more "Unix-y" but also slower due to providing this compatability layer.

> Actually, if you get the MinGW runtimes, you can build MinGW-ish apps from
> Cygwin ("-mno-cygwin", IIRC), best of both worlds.

Interesting, I didn't know this feature.

> The days of one app to rule them all (and in the darkness bind them) are
> over. You can no longer rely on Win32 apps working everywhere nor Linux
> apps nor DOS apps, etc. It's really annoying.

I don't understand, what one win32 app? I make separated dos, win, elf binaries.

---
DOS gives me freedom to unlimited HW access.

> > Which MSVCRT? Which Windows? I don't think they are compatible, for the
> > most part, hence you're kinda on your own.
>
> I have msvcrt.dll in my Win98SE and all my mingw apps run fine there. If
> you don't use newer winapi funcs it's not problem under win9x.

Well, most of what I meant is that developers no longer test (or care) about anything older than XP.

> > You only need to download it once, though, and like I said, if you
> develop
> > some open source app, it doesn't need to distribute the .DLL with it
> (but
> > you'll need to ship srcs too if you do include it).
>
> Well but in some special cases, e.g. when need to copy prog on floppy to
> some old PC with windows it's faster to copy e.g. 8kB exe than loading 2
> floppies. Of course on modern PC where you don't count the size it doesn't
> matter some megs+

With decent compression (PAQ et al.) you can shrink the Cygwin .DLL to 400 or 500k. Its sources ultra-compressed are still about 7 or 8 MB, though.

> > In other words, it's harder getting something working on
> > several compilers than it probably should be.
>
> Hm I didn't have problems with it. I use GCC under DOS, Win, Linux, ARM
> and AVR MCUs and most of code doesn't need changes.

Inline assembly, C99, and libc are all vastly different, so it's a bit harder than it sounds (not to mention big/little-endian, INT_MAX, etc).

> > Actually, if you get the MinGW runtimes, you can build MinGW-ish apps
> from
> > Cygwin ("-mno-cygwin", IIRC), best of both worlds.
>
> Interesting, I didn't know this feature.

Still uses MSVCRT, though. It wouldn't be that bad except there is no real free alternative (no drop-in replacement, I mean, unless you run under WINE, assuming it even works there).

> > The days of one app to rule them all (and in the darkness bind them)
> are
> > over. You can no longer rely on Win32 apps working everywhere nor Linux
> > apps nor DOS apps, etc. It's really annoying.
>
> I don't understand, what one win32 app? I make separated dos, win, elf
> binaries.

Which is yet another pain. But no, I mean you can't even rely on a DOS app to run on all DOS-compatibles and Windows anymore. Win32 doesn't run on all Win32 anymore, and many ELFs require specific libraries (or even kernels) which is bad for compatibility (e.g. FreeBSD still doesn't have Linux 2.6 emulation). Virtualization helps, but it's still way too slow and bloated to be a quick fix.

> Well, most of what I meant is that developers no longer test (or care)
> about anything older than XP.

I do. And I like there are people who trying to rise up win9x with new API funcs - project KernelEx.

> Inline assembly, C99, and libc are all vastly different, so it's a bit
> harder than it sounds (not to mention big/little-endian, INT_MAX, etc).

I don't use much of C99 extension and those I used works on all system, inline asm is count to HW stuffs, in libc I had one problem with format string for long long which is %llu but under mingw needs %UI64 or so. Compiler doesn't say any warning but just truncate the output. ARM and AVR use little endian, no prob.

> Which is yet another pain. But no, I mean you can't even rely on a DOS app
> to run on all DOS-compatibles and Windows anymore. Win32 doesn't run on all
> Win32 anymore, and many ELFs require specific libraries (or even kernels)
> which is bad for compatibility (e.g. FreeBSD still doesn't have Linux 2.6
> emulation). Virtualization helps, but it's still way too slow and bloated
> to be a quick fix.

And what do with it? Start to programm in Java or C#? No thanks (useless for light embedded system).

---
DOS gives me freedom to unlimited HW access.

> (not to mention big/little-endian, INT_MAX, etc).

Endianness shouldn't matter unless your program directly accesses (network/file) structures which are transfered to other systems. With the CRT, you access files either in text mode or byte by byte (where you can simply add support to the code which directly reads and writes the file).

> Still uses MSVCRT, though. It wouldn't be that bad except there is no real
> free alternative (no drop-in replacement, I mean, unless you run under
> WINE, assuming it even works there).

I'd assume either it works under WINE, or WINE provides it's own replacement.

> Virtualization helps, but it's still way too slow [...] to be a quick fix.

It's no quick fix if it's slow.

---
l

> don't know the details. (But I do somewhat dislike MinGW
> for using MSVCRT, just asking for trouble IMHO.)

Bad for HX still, ReactOS has one but Japheth found out it would be evil ...

> I wish more people used OpenWatcom.

Me too, but no inline ASM, and no ASM generation ...

> Virtualization helps

with what problem ?

> but it's still way too slow and bloated to be a quick fix.

I doubt vir*** will shrink before the universe does

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

> > don't know the details. (But I do somewhat dislike MinGW
> > for using MSVCRT, just asking for trouble IMHO.)
>
> Bad for HX still, ReactOS has one but Japheth found out it would be
> evil ...

Yes, as you and Japheth discussed a while back, neither WINE nor ReactOS have a drop-in replacement for MSVCRT (at least, nothing we can use directly).

> > I wish more people used OpenWatcom.
>
> Me too, but no inline ASM, and no ASM generation ...

It has inline assembly, either via "pragma aux" or "asm {", but the no .ASM generation is because, for speed, it generates the .OBJ file directly. (You have to use WDIS to get .ASM from it).

> > Virtualization helps
>
> with what problem ?

The fact that all OSes have incompatible binaries!

> > but it's still way too slow and bloated to be a quick fix.
>
> I doubt vir*** will shrink before the universe does

Isn't the universe expanding anyways?

> It has inline assembly, either via "pragma aux" or "asm {"

yeah, you can if you insist, but will hardly ever compile MPLAYER & Co ...

> but the no .ASM generation is because, for speed, it generates the .OBJ file
> directly. (You have to use WDIS to get .ASM from it).

For the heck of speed I have to use WDIS or OBJCONV instead of direct ASM output

> > > Virtualization helps
> > with what problem ?
> The fact that all OSes have incompatible binaries!

Cheaper and better: ignore the incompatible non-DOS OS'es and their incompatible binaries!

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