Is there any modern compiled language with native compilers for 32-bit MS-DOS?

23 points by hansor ↗ HN
Hi.

I heard a lot about NIM, V-LANG, ZIG, GO, RUST and other "small, simple and portable - as C" languages, which seems perfect fit for port to some old and resource starved systems.

Most of those languages leverage some GCC or LLVM/Clang heavily - which is "cheating", as they can't provide small, portable, standalone compiler for 32-BIT DOS systems.

Which modern language have some native 16/32bit MS-DOS compiler that can under MS-DOS environment with 2MB of RAM?

Except FreePascal and DJGPP.

38 comments

[ 2.9 ms ] story [ 85.7 ms ] thread
The two places I would look are:

1. Oberon. It certainly qualifies as a modern language, it was designed for doing systems work, there is an MS-DOS compiler from ETHZ, and the language is single pass and designed by one of the masters to be easily and quickly compiled.

2. Forth. Something like Pygmy Forth can be a great development environment for constrained systems.

Forth is not new and not very expressive...

I'm unable to find Oberon or Oberon 2 MS-DOS compiler binaries anywhere.

Can you help me locate such compiler? Free Oberon project looks like DOS, but it's Windows version in reality.

How do you define modern? For FORTRAN 77 there is BC-fortran, g77, and Microsoft Fortran 5.1.
Actively maintained and younger than 20 years.
Besides the existing comments, I would add Modula-2 to the mix, given how some modern languages are just redoing it with C like syntax.
C is itself Modula-2 with (exactly) C syntax. It is hard to imagine a definition of modern that would include Modula-2.
On the contrary, it doesn't do bounds checking, strong typing, modules, co-rotines, explicit unsafe, exceptions, objects, garbage collection for GC types.

C is completely unlike the original Modula-2, and even less so when compared with the extended standard from the late 80's.

As for an actual definition, Zig is one of those that come to mind.

My Modula-2 book doesn't mention most of those things. The Modula-2 it describes was about equivalent to C with syntax modernizations and a nod to modules. I suspect you may be conflating it with a later effort, maybe Modula-3.
Time to update your Modula-2 book past 1978 first ISO standard, here Extended ISO Modula-2:

https://modula2.awiedemann.de/manual/comp3.html

Which alongside Modula-2+, served as influence to Modula-3.

Stuff C definitely doesn't have, even when compared with 1978 Modula-2 standard:

- Proper strings with bounds checking

- Proper arrays with bounds checking

- Type safe enumerations

- Set types

- Arrays with enumerated types as indexes, flexibility to set lower and upper bounds

- Explicit unsafe code

- Reference parameters

- Nominal types

- Subranges

- Explicit casts for several cases where C would do implicit casts or type promotions

- Co-routines

Wait, there was a 32-bit version of MS-DOS? Or did the 16-bit version have some support for running 32-bit programs?
A lot of DOS programs using 32-bit CPUs would embed a "DOS extender" which would take care of the switch to 32-bit mode and needed translation of interrupts and device accesses, forming another layer of mini-OS on top of DOS while leaving the "launch application from DOS" flow unchanged to the user. Windows 3.1 also had Win32s which provided partial compatibility for 32-bit Windows applications, though that wasn't directly related.
The defacto support, such as it was, was "run DOS/4GW".

An actual MS-DOS running in protected mode would be an interesting thing. Win95/98 might qualify(I don't know enough details, but it did identify as DOS versions 7/8, and they dropped support for pre-386 CPUs).

(comment deleted)
Use Watcom C/C++, it's freely available and fully supports protected mode extenders on MSDOS. It might be a bit dated but it works and generates pretty tight code.
I was asking about some new languages. C and C++ are quite old.
These new languages are way too big to build themselves on MS-DOS and there are already good compilers. And the runtime will be huge too, compared to native hosted compilers designed for a constrained platform. Nobody does embedded Rust or Go or whatever you have.
>Nobody does embedded Rust

Oh yes they do.

Rust is used for embedded work because (like C and unlike most languages) it is easy to arrange for the output of a Rust compiler to work without any runtime library.

No they don’t. I’ve never ever heard of embedded Rust. Not saying it’s impossible but it just doesn’t happen.
There has been a massive amount of embedded rust activity for at least 5 years.
I just checked and while it’s promoted on the Rust site I can’t find a single embedded Rust product. If it existed it would surely be mentioned by the Rust Internet Defense Force. I certainly can’t find any evidence of “massive” Rust activity in embedded in the last half decade.
Some relevant search terms: Oxide Computer, Ferrous Systems, Oxidize - The Embedded Rust Conference.
That's what I'm asking about. Those NIM, V-LANG etc claims to be super small and fast languages - but yet, they do not have small standalone compilers.

In contrast there are plenty of C/C++ compilers - but I'm not interested in those languages(boring and DJGPP[gcc/g++ for DOS) are too big for machine with 120MB of disk space).

C is old. C++20 is as modern as anything, and more than most.
But C++20 is very different from the dialect supported by an old Watcom compiler. :)
True, but there is no need to confine oneself to an old Watcom compiler just to generate 80286 code. We had cross compilers even back then.
As old I meant date of creation of language. C++ is over 30 years old now, even if it changes A LOT between versions.

For example NIM is "new", same with Rust.

(comment deleted)
There is no point in actually running build tools on a target MS-DOS system. Modern compilers are perfectly capable of running on a practical development system while compiling to code for a different, target platform.

Then, you can use any fully modern language you can find a cross compiler toolchain for. C++ is the most widely supported, so offers the most choices.

>There is no point in actually running build tools on a target MS-DOS system

You see my point is that I'm deep into retro-computing thing.

I would like to learn some new, fresh language instead C, C++, BASIC or PASCAL, but on my real old hardware - so I could test various stuff and FELL the "speed" of my 25Mhz CPU :)

I used to compile Gcc 1.x on my 16 MHz 68010-based Apple SE/30 -- first with Apple's compiler, and later previous versions of itself. Enough was enough. Any machine you can build today will be retro 30 years from now.

But what is more fun than artifical retro is programming microcontrollers. A project that needs a hundred or a thousand microcontrollers puts an upper bound on their cost and complexity, and so real, practical limits on their individual absolute capacity. At the end you get something you built yourself that you probably couldn't buy at any price.

You can program microcontrollers in C++20, and use all the most powerful features of the language, which mostly happen at compile time on your host/development machine, downloading the resulting binary into your microcontrollers. You can debug on your host with gdb, talking bit-serial to a tiny gdb stub you have included in the code running on your microcontroller.

If you want to use a newer language, Rust or Zig are probably not much harder to get generating code for microcontrollers.

Have you tried D language? The D language author is the same author of Zortech C++, the first native C++ compiler for 16/32 bit MS-DOS. Perhaps if you have any problems in compilation, he probably can help.

[1]http://www.edm2.com/index.php/Zortech_C%2B%2B

OK this is interesting lead!

So what you are saying is that some oldish version of DLANG compiler can actually run on MSDOS as it does have Zortech C++ compiler from 1993 as backend?

This is still "cheating" - but VERY promising! Thank you sir.

Any chance for link to actual MSDOS compiler in such old version?

Why should modern languages care about legacy targets? Some do care about modern small 8-32bit targets, sure. But DOS is only needed for UEFI, and there we have an ecosystem, modern languages don't care about.

2MB RAM is a lot. Most of my devices are about 16K RAM, some much less. Lua, picoc, micropython and ulisp are common, but there are also much better modern, safer languages.