Using the MS-DOS 4 release to compile programs 

I created a small program that prints 9 lines of ASCII text including a date consisting of the day, month and year to stdout and then exits. Here is the result of executable size comparison (all files are stripped and thus without debugger symbols). (DJGPP) GCC 4.7.1 = 60928 Bytes Open Watcom C/C++ 1.9 = 14076 Bytes Microsoft C 5.10 = 10099 Bytes Note that the two binaries generated by the Open Watcom and Microsoft compilers could fit into the 16 KiB L1 cache of the late i486 and Pentium processors. If the program were running in a loop, that alone would be relevant to performance. The GCC binary doesn't even fit into the 32 KiB L1 cache of the Pentium 2. Only the L2 cache is large enough starting with the Pentium Pro. All programs run in Real Mode on an 8086, except the GCC binary, which requires a 386 and a DJGPP go32 DOS extender. It is therefore the only one that is written in 32 bits. The other two are 16 bits. The almost identical program written in Real Mode *assembler,* but without the function for reading the date, requires less than 350 bytes.

Thanks, I'm glad you think so 😃

More to come. I'm trying not to be "all programming all the time" but we'll definitely come back to more programming exmaples.

@@freedosproject 👍💯

Oops, I did! The 'sys' directory contains locking.h, stat.h, timeb.h, types.h and utime.h. I didn't spot that when I looked at the DIR listing.

One reason could be better compatibility with old programming books written for the Microsoft C compiler. Not all early C compilers were ANSI compatible. Some had their proprietary extensions. Another one could be lower RAM requirements. It may require less RAM than the 16-bit version of gcc. When it comes to code optimization, especially program speed, modern compilers are probably better. However, the MS compiler could have been optimized for generated program code size since memory was expensive back then. In the end you will have to test it and directly compare who performs better where. In any case, the later 32-bit C compilers from Microsoft for Windows were still very bad at the time. They were only significantly improved after the release of Windows NT 3.1. Which meant that Windows NT 3.5 ran significantly more efficiently than its predecessor. The slow speed of Windows NT 3.1 was the main reason for Microsoft to improve the compiler.

I agree, I prefer the newer open source compilers like OpenWatcom and IA-16 GCC. We also have BCC and a few other open source compilers that are older but work fine. The MS compiler is interesting for some. And it's interesting that they included the binaries for free in the MS-DOS 4.00 BAK source code release. Another legit free (gratis) proprietary compiler is Borland Turbo C 2.01 and Borland Turbo C++ 1.01, which you can download from Embarcadero's museum, if you don't mind registering a free account with them. We have a link to them from our website under the 'Developer' section. Works great on FreeDOS - I did a video a while back about TurboC++ on FreeDOS and the IDE was super slow in that video because it doesn't run well under JEMMEX; boot "without drivers" and the IDE runs fine.

Borland also released a version of Turbo C++ as freeware years ago which is arguably an easier compiler to use if all you want is to target 16-bit DOS.

OMG, I should totally do a video on that! :-)

Microsoft C 5.1 shown in this video is from 1988, the same year MS-DOS 4.0 was released. ANSI/ISO C was ratified two years later. From memory MSC 5.0 was their first to support ANSI/ISO C. Trivia: Most of the early OS/2 1.x C source code from 1986-7 was written in K&R syntax.

I was curious after seeing this comment, but watching closely, the second .EXE was around 7k, too.

@@TSteffi Oh, I must have read the wrong row. My bad!

@@Maxjoker98 No problem. 🙂 In fact, the [corrected] ARRAY.EXE at 14:16 is 7,825 .. and after copying the libs and includes, the recompiled ARRAY.EXE at 19:04 is also 7,825. So it's the same size (i.e. nothing "broke" when copying files to a new "CC" directory)

Windows 3.1 seems to work with some tinkering. DESQView I think runs out of the box, but I haven't tried it.

You can run Windows 3.x in Standard Mode on FreeDOS. Jeremy (kernel developer) has an in-development version of the FreeDOS kernel that runs Windows 3.11 in Enhanced Mode .. I'm hoping that can get released so we can share it. But you can find it in his GitHub. You can also use other graphical environmnets on FreeDOS, too. See my other videos for OpenGEM and Seal.

Ah, the joys of undefined behavior. “Everything appears to work just fine at first, but then sometime later something weird happens” is surprisingly common.

No, you could (manually??) use EMS or XMS (286+), if available. Or use overlays or swap to disk.

You also can't allocate more than 64K at a time unless you use the "huge" memory model. The easiest way around both this and the 640K limit is to use Watcom's wcl386 compiler to build 32-bit DOS4G executables.

library

@@OpenGL4ever yet it never gets pronounced correctly