DOS ain't dead

I was poking around recently, and spotted this:
http://ftp.math.utah.edu/pub///mirrors/minnie.tuhs.org/Applications/Portable_CC/
286.zip 08-Aug-2002 20:38 169K
8086.zip 08-Aug-2002 20:38 1.3M
16032.zip 08-Aug-2002 20:39 305K
68000.zip 08-Aug-2002 20:40 504K
README 09-Aug-2002 18:10 145


They were apparently the result of some MIT student projects, involving ports of the original Portable C Compiler (what today's PCC is based on).
The "8086.zip" is definitely a cross compiler, capable of targeting DOS on PC-compatibles.
Judging by date (early 80's), it's K&R C... though I have seen a couple ANSI preprocessors that could be used with such compilers.
NO copyright/license notices are present, unfortunately.
I think the binaries are BSD 4.1 (VAX), though that's a wag.
It definitely won't compile on modern Linux; it seemed like the errors might be cleaned up without too much work.
It would be interesting to check how it builds with "Bruce's C Compiler" or an old GCC on DOS.

This PCC seems to be ancesstor to modern PCC:
http://bsdfund.org/projects/pcc/

I did try compiling it while playing with ELKS. I did manage to compile some of the toolchain (as and ld I think) with bcc but it required some tweaking.

Anyway, porting the modern *BSD pcc would be much smarter thing to do. But I don't see that happening soon. DOS community is really small these days. You can see some activity centered around FreeDOS and DJGPP. Other than that, I think this forum is the most active DOS community ATM (that remind how it almost got shut down ).

Talking about ancient K&R C compilers, there's already bcc. Desmet C is now under GPL too. And you can even download Aztec C 8086 compiler (half) legally. But I don't see the purpose for that. Maybe only as a tiny development environment for 8086/186 based PC with limited memory and hd space (or without hdd)...

> This PCC seems to be ancesstor to modern PCC:
> http://bsdfund.org/projects/pcc/
>
> I did try compiling it while playing with ELKS. I did manage to compile
> some of the toolchain (as and ld I think) with bcc but it required some
> tweaking.

bcc/Dev86 is okay but not perfect. Yes, there's an older DOS-hosted version (0.16.2), but it's fairly minimal, small model (64k + 64k) .COM output only. And I'm not sure the libc is 100% complete, but it's good enough for average things. I compiled "unproto" with it recently, so at least you can use "-ansi" now.

> Anyway, porting the modern *BSD pcc would be much smarter thing to do. But
> I don't see that happening soon. DOS community is really small these days.
> You can see some activity centered around FreeDOS and DJGPP. Other than
> that, I think this forum is the most active DOS community ATM (that remind
> how it almost got shut down ).

Well, admittedly, there's less of a need to port PCC because DJGPP and OpenWatcom already exist. And while their DOS support isn't very active these days, they're already pretty robust and bug-free. (But yeah, GCC uses lots of RAM these days, sadly.)

> Talking about ancient K&R C compilers, there's already bcc. Desmet C is now
> under GPL too. And you can even download Aztec C 8086 compiler (half)
> legally. But I don't see the purpose for that. Maybe only as a tiny
> development environment for 8086/186 based PC with limited memory and hd
> space (or without hdd)...

Desmet C is too minimal, it definitely doesn't have full ANSI libs. But it's okay, I guess, and certainly easier to modify or bootstrap than others. The only problem is (IMHO) trying to decide which .ZIP to download from the website. Apparently the guy had several versions and never finished cleaning up any of them. Also some are more complete than others.

Here's a quick list, corrections welcome. You probably knew some of this already, though.

16-bit
======
Dev86dos 0.16.2 (GPL)
Turbo C 2.01 (requires free online registration)
Turbo C++ 1.01 (nowadays free only to registered C++ Builder owners??)
LSI C-86 3.30 (freeware, non-commercial?)
Pacific C 7.51 (freeware, non-commercial?)
Desmet C (various) (GPL)
Micro C 3.23 (BSD-ish, lacks a fair bit of standard features)

32-bit
======
OpenWatcom 1.9 (386 host, optional 8086 target; OSI approved, FSF hated)
CC386 4.07 (BSD/GPL?)
OrangeC 4.1.25 (BSD?)
DJGPP 2.04 (GCC 4.62) (GPL)
LCC/DJ 4.2 (open source but non-commercial/GPL/LGPL)
EiC 4.3.0 (interpreter, Artistic?)
EMX (GCC 2.8.1) (old but mostly? GPL)

CC386 uses NASM and VALX. DJGPP uses GNU as + ld. LCC/DJ uses NASM + GNU ld + DJGPP 2.01 libc. EMX uses (old) GNU as + ld compiled by itself with own extender(s). The rest use their own tools. (Okay, I don't know, LCC may? use dmr's CPP.)

Just to clarify, I think? this is correct: C only needs a minimal runtime (crt0.o for argc,argv,environ) plus CC (compiler driver), CPP (preprocessor), CG (code generator), COPT (optimizer), AS (assembler), LD (linker). For that you also need headers (ANSI C89 = 15 .h) and a libc.

> bcc/Dev86 is okay but not perfect. Yes, there's an older DOS-hosted version
> (0.16.2), but it's fairly minimal, small model (64k + 64k) .COM output
> only. And I'm not sure the libc is 100% complete, but it's good enough for
> average things. I compiled "unproto" with it recently, so at least you can
> use "-ansi" now.
>

I don't know about its status, but I guess it was mostly meant to be a crosscompiling toolset for ELKS (early Linux kernel subset for 8086-80286). The limitations are the limitations of the original executable format bcc was orignally written for (Minix a.out format). I think this (DOS version) was ported by Robert de Bath. But I don't know how complete it is (haven't played with it). He doesn't seem to work with ELKS or DOS these days. Most of the updates are to boot loader generation code (he still maintains dev86). This is what dev86 is mostly used on *nix platforms these days.

Anyway I don't know how complete is DOS C library. But it comes with a small elks "emulator" to run elks binaries natively. This *might* be used as a stub to port old *nix software, but haven't tried. At least not under DOS. I think I managed to make something similar for Linux some time ago (compiled elks app with stub merged in).

Btw, it seems ELKS is revived in past several weeks. No new features or anything, just bug fixes and general code cleanup. I think this is still only available from git. So, if you played with it earlier, check out the mailing list or git repository. :)

Btw, I don't have any connection to ELKS and haven't contributed any code. I just played around with it. It looked interesting to hack on. But my assembly knowlegde is too weak to make something usefull out of it. I did try porting some C applications (mostly ancient usenet sources and some embedded utilities) with varying success. IE, 8086 version of libc doesn't have math (8087 or emulation) library implemented. A lot of stuff won't work without math library. For example, lua 1.0 seems to compile ok, but can't be linked because of the absence of -lm. And C library is not standardized anyway. ELKS doesn't have stable API. So if you can't hack on as86 (at&t syntax, uses int 80h for system calls like linux), you're much out of luck on extending it.

> Well, admittedly, there's less of a need to port PCC because DJGPP and
> OpenWatcom already exist. And while their DOS support isn't very active
> these days, they're already pretty robust and bug-free. (But yeah, GCC uses
> lots of RAM these days, sadly.)
>

Well, yes. But...

DJGPP C library haven't been touched since 2003. Only updates come frome libsupp. But nothing official. Ports can be a little hacky and not stable. They are mostly crosscompiled nowadays. Or compiled under Windows. No or very little native developement. I tried using gcc 4.6 with djdev 2.03 libs, but had better luck with GCC 3.3.6. It's still modern enough (at least C backend) and supports some of C99. So most stuff compiles ok. GCC 3.3.6 port seems much less memory intensive and stable. The other ports are of varying quality. For example bash port is pretty much buggy.

OpenWatcom, on the other side, is still dependent on DOS4GW and includes some propriatry elements. Yes, there is also DOS32A but it often crashes dosemu and dosbox. Most of OW binaries depend on DOS4GW and toolchain is maybe too large. It would be nice to have a small toolchain without misc utilites and crosscompilers/installer. Only the basic libs and toolchain. On the other side, I'm so used to unix C toolchains I can't get around to use wlink, or even wmake or wcc sometimes. But it does seem to be more stable than DJGPP GNU ports and it has pretty ok C lib. And it has 16-bit backend.

And both toolchains have a hacky implementations of dlls.

> Desmet C is too minimal, it definitely doesn't have full ANSI libs. But
> it's okay, I guess, and certainly easier to modify or bootstrap than
> others. The only problem is (IMHO) trying to decide which .ZIP to download
> from the website. Apparently the guy had several versions and never
> finished cleaning up any of them. Also some are more complete than others.

I think I looked at the source some time ago. I think it was hell to even look at it.

Most of the available versions are non-ANSI. The version he worked on is one of the ones with some ANSI support. But I don't how much it conforms with ANSI. Probably some ANSI draft, because those versions are from late 80's. Most probably before C89/C90 standard. He didn't update the page for years so it's hard to know if he made some success with it.

I didn't play with it much though. Yes, it seems minimal, but that might be interesting for legacy purposes where small size is of concern. Btw, it seems to have 8086-80386 support in later versions.

Micro C is more a limited C subset for embedded applications. Something along the lines of Small C.

32-bit
======
ACC (386, incomplete ?, educational, cardware)

16-bit
======
PCC 1.2b - 1.2d (a freeware version of Desmet C)
Miracle C 1.5 - 1.7 (shareware, req. MS link, comes with cc and clib, limited?)

Limited C subset
================
Ron Cain's Small C 8086/8088 ports (original published in DDJ)
* Project -fbin (diff. versions, req. nasm, modern)
* Small C 2.1 - 2.2 (by James Hendrix, shareware, improved)
* BYTE Small-C 1.0 (Rick Grehan, BYTE Mag., req ms link/masm)
* Caproc Small-C (8088, req. ms link/masm)

Re toolchain:
Generally, it seems to be the practice to have the toolchain similar to the one you mentioned. I don't know if there is some "standard" how to implement C compiler. There seem to be different implementations with some common points.

> I guess it was mostly meant to be a crosscompiling toolset for ELKS.
> The limitations are the limitations of the original executable format bcc
> was orignally written for (Minix a.out format).

Yes, it's mostly known for ELKS. I don't know of anyone else using it very much, outside of what little Linux 386 kernel bootstrapping is (apparently) done. Oh, and maybe? DOSEMU uses it at build time.

> I think this (DOS version)
> was ported by Robert de Bath. Most of the updates are to boot loader
> generation code (he still maintains dev86). This is what dev86 is
> mostly used on *nix platforms these days.

I think he compiled the DOS-hosted version with MS C, but 0.16.2 was a while ago, latest is 0.16.18.

> Anyway I don't know how complete is DOS C library. But it comes with a
> small elks "emulator" to run elks binaries natively. This *might* be used
> as a stub to port old *nix software, but haven't tried. At least not under
> DOS. I think I managed to make something similar for Linux some time ago
> (compiled elks app with stub merged in).

It's missing gettimeofday(), for instance. Other stuff seems mostly there. I haven't checked too closely. I don't think it's quite ANSI C, but it's fairly good anyways (surprisingly).

Yes, (Linux 386) elksemu and doselks.com exist, and I've tried them both. They work. Granted, it's not 100%, but it's fairly good. But don't expect any miracles, i.e. ELKS supports LFNs and fork() which DOS doesn't.

> Btw, it seems ELKS is revived in past several weeks. No new features or
> anything, just bug fixes and general code cleanup. I think this is still
> only available from git. So, if you played with it earlier, check out the
> mailing list or git repository. :)

No, I never barely played with it. I think I even had a hard time booting it up and transferring files. I may have just used some Minix fs tools. Kinda sad that ELKS is so abandoned, worse than FreeDOS even! But yeah, not a lot of 16-bit cpu users these days.

> Btw, I don't have any connection to ELKS and haven't contributed any code.

Ditto.

> I did try porting some C applications (mostly usenet sources and some
> embedded utilities) with varying success. IE, 8086 version of libc doesn't
> have math (8087 or emulation) library implemented. A lot of stuff won't
> work without math library. For example, lua 1.0 seems to compile ok, but
> can't be linked because of the absence of -lm. And C library is not
> standardized anyway.

Don't know, never tried compiling anything heavy-duty. I think it lacks unsigned char and has other weird restrictions. It's probably mostly K&R with a bit of ANSI tacked on after-the-fact, e.g. "-ansi" calls unproto to convert to old-style form for the compiler proper.

> ELKS doesn't have stable API. So if you can't hack on
> as86 (at&t syntax, uses int 80h for system calls like linux), you're much
> out of luck on extending it.

Yeah, I'm not familiar with its asm syntax. I've barely messed with it, only a little out of curiosity / comparison.

> > Well, admittedly, there's less of a need to port PCC because DJGPP and
> > OpenWatcom already exist. And while their DOS support isn't very active
> > these days, they're already pretty robust and bug-free. (But yeah, GCC
> uses
> > lots of RAM these days, sadly.)
>
> Well, yes. But...
>
> DJGPP C library haven't been touched since 2003. Only updates come frome
> libsupp. But nothing official.

CVS version is still updated, even recently, but no, there's been no "official" release since 2003 (2.04 "beta"). 2.04 wasn't nearly as tested in multiple environments as 2.03p2. And it added some questionable stuff that needs peer review (or so I'm told). It's mostly better, though, e.g. symlinks and 4 GB file support (not that FreeDOS supports that, meh).

There has been no release manager with 2.04 beta to see it finalized. I think the last one was Andrew Cottrell (sp?), who's long since AWOL. CWS himself only hacked it to get it working on Win2k/XP, and once that worked he lost interest (though in the past two or three years he's shown some minor interest in getting it "out the door" ... eventually).

There are some people who only use 2.03p2 "stable", e.g. Eli Z., so perhaps there is some minor resistance there. Like I said, it supposedly was tested in all kinds of environments (e.g. native DOS) while 2.04 was mostly only tested in XP.

> Ports can be a little hacky and not stable.

They work fine, but it's always a pain to bootstrap, so they long ago gave up on building in 8.3 SFN. The ports work, but you have to keep in mind the horrible horrible kludges they have to do because POSIX (ahem, Linux) code is so annoying. Keep in mind that GNU only cares for POSIX, nothing else, so it's an uphill battle, to say the least.

> They are mostly crosscompiled nowadays. Or compiled under Windows. No or
> very little native developement. I tried using gcc 4.6 with djdev 2.03
> libs, but had better luck with GCC 3.3.6. It's still modern enough (at
> least C backend) and supports some of C99. So most stuff compiles ok. GCC
> 3.3.6 port seems much less memory intensive and stable. The other ports are
> of varying quality. For example bash port is pretty much buggy.

I think GCC 3.4.4 (2005) was most stable, but 4.1.2, 4.2.3, 4.3.2, 4.4.5, 4.6.2 are good too. None is perfect, believe it or not. C99 is less crucial, IMO, but some projects do use it, so I wouldn't go below 3.2.3. Similarly for decent C++ support, even some require /backwards/ headers last found in 4.2.3.

I just wish it wasn't so slow and bloated. Worse than any of that is the (relatively) high memory requirements these days, which boggles the mind. But hey, beggars can't be choosers.

Yes, Bash is buggy, but you need it for the (God-awful) ./configure abomination.

> OpenWatcom, on the other side, is still dependent on DOS4GW and includes
> some proprietary elements.

You don't need it for 99% of stuff.

> Yes, there is also DOS32A but it often crashes dosemu and dosbox.

Are you using DOS/32A 9.1.2 or only (old) 7.2 included with OW? (I don't know why they never upgraded.) Also keep in mind that neither native DOS, DOSEMU, nor DOSBox are flawless, they all have issues (ironically).

> Most of OW binaries depend on DOS4GW and toolchain is
> maybe too large. It would be nice to have a small toolchain without misc
> utilites and crosscompilers/installer. Only the basic libs and toolchain.

I made a floppy-sized .7z of the compiler with only the 16-bit DOS targets.

ow13-286.7z
ow17a286.7z

So you can slim it down, if necessary. (I didn't bother with 386-only because that seemed redundant to DJGPP, IMO.)

Also, see the "DOS-only" OW 1.9 .7z, it's only 7 MB: FreeDOS / iBiblio / devel / c / openwatcom

> On the other side, I'm so used to unix C toolchains I can't get around to
> use wlink, or even wmake or wcc sometimes. But it does seem to be more
> stable than DJGPP GNU ports and it has pretty ok C lib. And it has 16-bit
> backend.

No LFN support, at least not by default, and even optionally it's only half-finished. So that's a (very minor) drag. Also lacks a lot of POSIX stuff. Keep in mind that I don't personally care, but stupid Linux / GNU only codes (heavily) for POSIX.

But yes, OW is awesome. But admittedly wmake isn't totally compatible with GNU make. If you miss *nix toolsets, try the OWCC.EXE compiler driver, it tries to mimic them for easier use.

> And both toolchains have a hacky implementations of dlls.

DJGPP 2.03p2 only has (very weak) DXE1. 2.04 has DXE3, which is better. DJELF has full .so support. Japheth hacked DJGPP 2.03 to produce DOS-only PE/DLLs with DJGPP libc. OpenWatcom's Causeway/DOS supports .DLLs too. And that's ignoring HX's support (emulation?) of Win32 PEs w/ .DLLs.

> > Desmet C is too minimal, it definitely doesn't have full ANSI libs. But
> > it's okay, I guess, and certainly easier to modify or bootstrap than
> > others. The only problem is (IMHO) trying to decide which .ZIP to
> download
> > from the website. Apparently the guy had several versions and never
> > finished cleaning up any of them. Also some are more complete than
> others.
>
> I think I looked at the source some time ago. I think it was hell to even
> look at it.

I don't know what that means. I didn't look too closely. I just know it was much much much smaller and simpler to build vs. GCC (abomination).

> But I don't how much it conforms with ANSI. He didn't update the page for
> years so it's hard to know if he made some success with it.

Yes, it had ANSI support, but the libc was fairly lacking. It didn't have a lot of things ANSI assumes (e.g. 15 .h files).

> I didn't play with it much though. Yes, it seems minimal, but that might be
> interesting for legacy purposes where small size is of concern. Btw, it
> seems to have 8086-80386 support in later versions.

I doubt the 386 support is very good, but I didn't check. There was also a third-party optimizer, but I didn't try it. Again, it's indeed hard to know which version is "recommended" as he never finished and had so many versions online. And it's clearly not robust enough to build the FreeDOS kernel (nor is BCC/Dev86), at least not without major tweaking.

> Micro C is more a limited C subset for embedded applications. Something
> along the lines of Small C.

I know, I just meant you shouldn't expect "long" to work, for instance, which is kinda inconvenient (though there are workarounds). It's also is tiny or small model only output. But it's open source now (BSD-ish), I just haven't messed with it much. The author even dropped by here once (year ago?). I haven't tried it with JWasm + VAL, but IIRC it also supports A86.

> 32-bit
> ======
> ACC (386, incomplete ?, educational, cardware)

I think I saw somewhere? that this is GPL'd nowadays. It may be on SourceForge, I can't remember. IIRC, it also had some annoying quirks, so I didn't mess much with it.

> 16-bit
> ======
> PCC 1.2b - 1.2d (a freeware version of Desmet C)

Shareware, I thought, but with Desmet C GPL'd, it's moot.

> Miracle C 1.5 - 1.7 (shareware, req. MS link, comes with cc and clib,
> limited?)

Supposedly pretty good, esp. the book, which I was often told "was worth the $20 alone". Then again, that was when people still actively advocated DJGPP as an alternative, heh, my how times change. :-/

> Limited C subset
> ================
> Ron Cain's Small C 8086/8088 ports (original published in DDJ)
> * Project -fbin (diff. versions, req. nasm, modern)
> * Small C 2.1 - 2.2 (by James Hendrix, shareware, improved)
> * BYTE Small-C 1.0 (Rick Grehan, BYTE Mag., req ms link/masm)
> * Caproc Small-C (8088, req. ms link/masm)

See BTTR's Links, JH's Small C is public domain now. But it's too minimal and non-standard for my tastes, sorry. It's not bad, just I have no patience for learning yet another non-standard syntax.

> Re toolchain:
> Generally, it seems to be the practice to have the toolchain similar to the
> one you mentioned. I don't know if there is some "standard" how to
> implement C compiler. There seem to be different implementations with some
> common points.

Yes, they all seem to (more or less) follow a common methodology.

I also wonder sometimes how much work it would be to port (T)ACK to DOS. Can't be that hard (famous last words). But it's weird (latest uses Lua build system, assumes GCC, doesn't support barely any targets anymore, would need a DOS libc). Even EM44 doesn't build anymore, meh. That's what you get for reviving something last touched in 1994. Yeah, old code sucks. But it's a nice compiler and has several interesting frontends.

P.S. This is all (pseudo) "academic" interest, and marcov will probably hate me for it, heh. I'm just vaguely interested in compilers in general, even if they are all heavily flawed.

I was writing a rather long reply, but my session expired. :( So just shortly...

The last change in DJGPP CVS is from 5y ago. It's good there are still ports. It keeps it alive. But without any activity in upstream... I don't know.

Re C99. You should know. :P I think the last 7za port in FreeDOS was yours. Btw, that build is case sensitive. Had troubles with it under DosBox. I guess it would work flawlessly on real DOS, but... I use DosBox for qicktesting to run dos apps directly from right click menu on Linux.

Re owatcom. Wcc(386) is not a big problem. Wlink is. I was thinkng on writing a small ld like wrapper around it but I doubt I'll have time for it.

I am aware of your mini OWatcom, but haven't played much with it. :) I was talking about upstream. ;) Btw, there is also this advice from Rod Pemberton:
http://newsgroups.derkeiler.com/Archive/Comp/comp.os.msdos.djgpp/2005-10/msg00030.html

Bcc and Desmet were only a sidenotes. They are usable, but not for heavy duty porting/development. Small C was another sidenote. Mainly to counter your add of microc to the list. :) I'm pretty sure Dave's MicroC is great, but haven't played with it and don't consider it a tool for heavy duty porting. :)

Re ACK. It's pretty much Unix(tm) specific. But might be possible. Ancient backends are pretty much non ANSI compliant or obsolete.

Re ELKS. It had it's own problems. They wanted it to be educational so a lot of complex ideas never got their try. And toolchain is base on Minix 8086/286 toolchain which had the same limits. It even uses minixfs (which is btw great for floppies). To make something out of it, they had to improve toolchain. But mainstream developement of bcc stoped. Even Minix went with gcc in 386 version. So bcc got hardly any developemnt beside what Robert de Bath was doing. Bcc also limits the size of kernel, which makes it tough to add enough device drivers. They did a sample implementation(s) of loadable module drivers but it collided with swap implementation. The other problem is limited support for 386+ and no pm support. DOS use extenders for this. One of ideas they were toying in the past was making kind of loadable drivers like in DOS. But nothing got out from this idea.

Offtopic I was playing with wcc and djgpp for a several days now (mostly Thomas Dickey's stuff, including a newer version of byacc then in Freedos). What is best way to put that stuff for test. A new topic? I am afraid it's nothing compared to the stuff you guys do, but it might be usefull to someone. Yes, I'm a lamer. :)

> I was writing a rather long reply, but my session expired. :( So just
> shortly...

Heh, I had to trim my previous ones because they were over 10000 chars.

> The last change in DJGPP CVS is from 5y ago. It's good there are still
> ports. It keeps it alive. But without any activity in upstream... I don't
> know.

Indeed, it has very very little upstream work being done, mostly just Juan. I'm surprised he's ported so much.

But actually, I'm fairly certain you're wrong. I've seen the posts and am subscribed (heh, why?) to djgpp-workers, so there definitely has been some minor patchwork in the past few months, let alone five years.

Grab djgpp.cvs.tar.gz, gunzip it, then do this: "tar tvf djgpp.cvs.tar.gz | grep 2012- | wc", and it should say 21 lines (aka, at least 21 files changed this year). For 2009, 2010, 2011: 16 lines, 10 lines, 321 lines respectively.

In particular, five days ago Juan posted a patch to djgpp-workers regarding "djgpp/src/libc/posix/sys/stat/xstat.c , which had a previous datestamp of 2001-12-01.

DJGPP is not dead (yet, barely, close but not quite).

> Re C99. You should know. :P I think the last 7za port in FreeDOS was yours.

I didn't write any new code, just got 4.65 to compile, which was a bit hairy. 9.13 was from Khusraw. Both have the same problem: trying to compile a POSIX (*nix) port atop DOS with DJGPP when the original had heavy Win32-isms in it. There are a lot of "#ifdef _WIN32" in there, which is why some of it doesn't work as well on DOS.

> Btw, that build is case sensitive. Had troubles with it under DosBox. I
> guess it would work flawlessly on real DOS, but... I use DosBox for
> quicktesting to run dos apps directly from right click menu on Linux.

No, it's far from flawless in DOS, it has a few quirks, but it "mostly" works. Or try 7ZA920.ZIP under HX.

> Re owatcom. Wcc(386) is not a big problem. Wlink is. I was thinkng on
> writing a small ld like wrapper around it but I doubt I'll have time for
> it.

The compiler driver (owcc) should mask any calls to that anyways. You normally don't need to call the linker directly. I've often seen makefiles with $(LD) point to "gcc" or "g++".

> I am aware of your mini OWatcom, but haven't played much with it. :) I was
> talking about upstream. ;) Btw, there is also this advice from Rod
> Pemberton:
> http://newsgroups.derkeiler.com/Archive/Comp/comp.os.msdos.djgpp/2005-10/msg00030.html

That depends heavily on target OS, cpu, and memory model. But it's not impossible, just impossible to perhaps please everybody.

The main problem isn't just ANSI C (1989) but everything since. You can easily have a small compiler if you only stick to strict ANSI, but it's all the extras (C99, POSIX, semi-standard DOS extensions) that add to it.

> Bcc and Desmet were only a sidenotes. They are usable, but not for heavy
> duty porting/development.

Depends on how hard you want to tweak them, how much you want to get your hands dirty, what you want to do, etc.

> Small C was another sidenote. Mainly to counter
> your add of microc to the list. :) I'm pretty sure Dave's MicroC is great,
> but haven't played with it and don't consider it a tool for heavy duty
> porting. :)

Well, it's just a bit quirky and non-standard. Otherwise it's fine. Honestly, unless you really need portability or heavily prefer it, an HLL has nothing over simple assembly. In fact, it might be overkill.

> Re ACK. It's pretty much Unix(tm) specific. But might be possible. Ancient
> backends are pretty much non ANSI compliant or obsolete.

ACK supports ANSI quite well. But yes, I looked again yesterday, the build process is fairly heinous. I wonder sometimes if the time saved using arcane build practices is really worth the pain in trying to make them not break. Sure, it takes longer to build from scratch, but at least you know it will build, unlike trying to configure everything otherwise, ugh. (But this is more of a *nix and C problem.)

> Re ELKS. It had it's own problems. They wanted it to be educational so a
> lot of complex ideas never got their try. And toolchain is base on Minix
> 8086/286 toolchain which had the same limits. It even uses minixfs (which
> is btw great for floppies). To make something out of it, they had to
> improve toolchain. But mainstream developement of bcc stoped. Even Minix
> went with gcc in 386 version.

ELKS is too hard to install and modify, IMHO. But are we really surprised? FreeDOS barely gets any work done, so how can we expect Linux users to care? Most of their code assumes 32-bit ints, they can't be bothered with 16-bit, even with (some) POSIX support. It's just not interesting to them, esp. with the advent of AMD64. It's a lost cause, almost. :-/

I don't know about latest Minix, haven't tried. 3.2.0 was just released. It probably still uses ACK (or at least used to). Presumably it "also" builds with GCC. This is also probably because of the BSD-ish license, but who knows. Yes, it seems 3.2.0 is borrowing heavily from NetBSD.

> So bcc got hardly any developemnt beside what
> Robert de Bath was doing. Bcc also limits the size of kernel, which makes
> it tough to add enough device drivers. They did a sample implementation(s)
> of loadable module drivers but it collided with swap implementation. The
> other problem is limited support for 386+ and no pm support. DOS use
> extenders for this. One of ideas they were toying in the past was making
> kind of loadable drivers like in DOS. But nothing got out from this idea.

The typical "solution" you'll hear to such problems is just ignore it. "Nobody" (they say) sells or makes or uses less than 386 / 32-bit anyways, so it's not worth doing.

Personally, I think that's a copout. But yeah, it's hard to talk to some people. It's kind of a weird pissing contest in some ways, everyone wants to show up someone else.

> Offtopic I was playing with wcc and djgpp for a several days now (mostly
> Thomas Dickey's stuff, including a newer version of byacc then in Freedos).
> What is best way to put that stuff for test. A new topic? I am afraid it's
> nothing compared to the stuff you guys do, but it might be usefull to
> someone. Yes, I'm a lamer. :)

There is a DJGPP port of BYacc, but I'm not heavily familiar with it (or "yacc" in general).

You're not a lamer, or at least no more than I am. I'm seriously wimpy in coding skills, just a lame hacker, doing lots of ad hoc stuff with little planning. It's hard to do something at all, much less well or portable or robust. Don't think everybody else is so super smart, they aren't. They're just heavy specialized. Nobody knows everything.

As for kicking the tires, dunno. The only things that I know of that might? be easy to build and need Yacc are GNU Bash (also needs m4) or Detlef's LCC/DJ. But to just play with DJGPP, you can choose anything. The TDE editor compiles very easily with it. And OpenWatcom has its own vi editor, even for DOS. Heck, Thomas Dickey's VILE compiles with DJGPP too. Unfortunately, OW has less support for (common Linux-y) POSIX code than DJGPP. Just find something you're interested in (hopefully with sane build process and requirements) and see what you can make of it. And ask questions (somewhere, anywhere) if needed.

> But actually, I'm fairly certain you're wrong. I've seen the posts and am
> subscribed (heh, why?) to djgpp-workers, so there definitely has been some
> minor patchwork in the past few months, let alone five years.
>

Ah ok. :) Do they have another CVS server? Or he's just not submitting the stuff upstream?

> Grab
> djgpp.cvs.tar.gz,
> gunzip it, then do this: "tar tvf djgpp.cvs.tar.gz | grep 2012- | wc", and
> it should say 21 lines (aka, at least 21 files changed this year). For
> 2009, 2010, 2011: 16 lines, 10 lines, 321 lines respectively.
>

Thanx. Will do.

> DJGPP is not dead (yet, barely, close but not quite).
>

Glad to hear that. :)

> I didn't write any new code, just got 4.65 to compile, which was a bit
> hairy. 9.13 was from Khusraw. Both have the same problem: trying to compile
> a POSIX (*nix) port atop DOS with DJGPP when the original had heavy
> Win32-isms in it. There are a lot of "#ifdef _WIN32" in there, which is why
> some of it doesn't work as well on DOS.
>

I know. What I meant is.. Lzma sdk based stuff uses a lot (?) of C99. But I don't know how good is 3.3.x support for C99. Had varied experiences. But it works ok. :)

> Depends on how hard you want to tweak them, how much you want to get your
> hands dirty, what you want to do, etc.
>

Indeed. :)

> ACK supports ANSI quite well. But yes, I looked again yesterday, the build
> process is fairly heinous. I wonder sometimes if the time saved using
> arcane build practices is really worth the pain in trying to make them not
> break. Sure, it takes longer to build from scratch, but at least you know
> it will build, unlike trying to configure everything otherwise, ugh. (But
> this is more of a *nix and C problem.)
>

You're talking about resurrected version? Classic ACK didn't have ANSI support.

> ELKS is too hard to install and modify, IMHO. But are we really surprised?
> FreeDOS barely gets any work done, so how can we expect Linux users to
> care? Most of their code assumes 32-bit ints, they can't be bothered with
> 16-bit, even with (some) POSIX support. It's just not interesting to them,
> esp. with the advent of AMD64. It's a lost cause, almost. :-/
>

Not only Linux. :)

> I don't know about latest Minix, haven't tried. 3.2.0 was just released. It
> probably still uses ACK (or at least used to). Presumably it "also" builds
> with GCC. This is also probably because of the BSD-ish license, but who
> knows. Yes, it seems 3.2.0 is borrowing heavily from NetBSD.
>

Well, Minix is quite modern right now. Minix 3 requires i586 or i686 and uses GCC. They switched a long time ago. They used the classic ACK in the beginning (after bcc?). Btw, their first 386 version in the mid ninties used GCC by default. Only 16-bit port (which died with version 3) used ACK. Minix 3 got announced in 2005.

> The typical "solution" you'll hear to such problems is just ignore it.
> "Nobody" (they say) sells or makes or uses less than 386 / 32-bit anyways,
> so it's not worth doing.
>

True.

> Personally, I think that's a copout. But yeah, it's hard to talk to some
> people. It's kind of a weird pissing contest in some ways, everyone wants
> to show up someone else.
>

Agreed.

> There is a DJGPP port of
> BYacc,
> but I'm not heavily familiar with it (or "yacc" in general).
>

I have 4 ports (and wrote a nice batch build system for it): 32-bit Watcom without LFN, 32-bit Watcom with 1.9 long names, 16-bit Watcom without LFN (not sure how well would it work with LFN compiled in, tests in qemu showed it to be buggy if LFN driver is not loaded), and a "classic" DJGPP build.

I tested with some software and it seems to work ok. All variants. :)

Well, I'm thinking of uploading stuff I was playing with to my site soon.

> As for kicking the tires, dunno. The only things that I know of that might?
> be easy to build and need Yacc are GNU Bash (also needs m4) or Detlef's
> LCC/DJ.

Bash is most likely to use Bison-isms, so I don't know how would it work with Berkley's Yacc (a classic favour). :)

> > Grab
> >
> djgpp.cvs.tar.gz,
> > gunzip it, then do this: "tar tvf djgpp.cvs.tar.gz | grep 2012- | wc",
> and
> > it should say 21 lines (aka, at least 21 files changed this year). For
> > 2009, 2010, 2011: 16 lines, 10 lines, 321 lines respectively.
> >
>
> Thanx. Will do.

That's the daily snapshot from Martin Stromberg, and it's certainly the easiest way to get it.

> > DJGPP is not dead (yet, barely, close but not quite).
>
> Glad to hear that. :)

Well, I wouldn't pin any huge hopes on it, but IMHO, it's too good to die.

> I know. What I meant is.. Lzma sdk based stuff uses a lot (?) of C99.

I don't know. But IIRC 7zdecode is pure ANSI C (C89).

> But I don't know how good is 3.3.x support for C99. Had varied
> experiences. But it works ok. :)

NASM 2.x series requires C99 (but has workarounds for incomplete OpenWatcom -za99 , see here). I just remember trying, and the oldest I could get working was 3.2.3 or such. I'm sure later versions have better C99 support, but remember that GCC has never fully implemented C99 (still! see here), although it's fairly close by now, hence why -std=gnu89 is still default instead of -std=gnu99. C11 makes some stuff optional, so maybe compliance will be easier. Though note that Clang is C99 by default.

> You're talking about resurrected version? Classic ACK didn't have ANSI
> support.

I'm pretty sure ACK has supported ANSI since a long time, at least since Minix 2.0.0 series. The last public "official" ACK from Vrije Universitat was 5.5 (see here).

> Well, Minix is quite modern right now. Minix 3 requires i586 or i686 and
> uses GCC. They switched a long time ago. They used the classic ACK in the
> beginning (after bcc?).

I don't know, haven't tried it much, mostly because I had trouble booting it, even in VMs or real hardware (IIRC). Haven't tried lately, latest may? require VT-X, which I have (but only on this cpu).

I thought? I had read somewhere that they were still defaulting to ACK and GCC was only optional. I can't imagine they'd switch entirely, but <sarcasm> those pesky (Linux) spies^H^H^H^H^H volunteers probably have their own preferences (sabotage!). </sarcasm>

> Btw, their first 386 version in the mid ninties
> used GCC by default. Only 16-bit port (which died with version 3) used ACK.
> Minix 3 got announced in 2005.

You mean Minix-vmd? That was unofficial, of course, just a fork. And it used a very hacked and old GCC (2.7.2.1), IIRC. But yeah, the 16-bit version was pretty obviously dying ever since 2.0.2. ACK did eventually support ANSI (long long ago), so the need for GCC was less pressing. Plus, IIRC, GCC assumed floating point, which (until very very recently) Minix didn't support (didn't save context upon task switching). Also it used more RAM (gotta love chmem), ran slower, was GPL (and Minix prefers BSD), etc.

> > There is a DJGPP port of
> >
> BYacc,
> > but I'm not heavily familiar with it (or "yacc" in general).
> >
>
> I have 4 ports (and wrote a nice batch build system for it): 32-bit Watcom
> without LFN, 32-bit Watcom with 1.9 long names,

Does 32-bit DOS output work with LFNs? In my limited testing, I didn't think so. Even the compiler itself isn't LFN-aware, so I wasn't very impressed. Sad, really, I guess there aren't enough volunteers, and I'm not convinced I could help very much.

> 16-bit Watcom without LFN
> (not sure how well would it work with LFN compiled in, tests in qemu showed
> it to be buggy if LFN driver is not loaded), and a "classic" DJGPP build.

16-bit seems to work with LFN okay, but I didn't heavily test. I guess it depends on what calls are used. You can disable LFN at runtime, I think, by "set LFN=n", IIRC.

> > As for kicking the tires, dunno. The only things that I know of that
> might?
> > be easy to build and need Yacc are GNU Bash (also needs m4) or Detlef's
> > LCC/DJ.
>
> Bash is most likely to use Bison-isms, so I don't know how would it work
> with Berkley's Yacc (a classic favour). :)

IIRC, building ACK on Linux didn't work with Bison, perhaps I had to install BYACC instead, funnily enough. But ACK is weird, prefers LLGEN. Honestly, it's such a weird beast to build that I'm not sure what it needs. Certainly it's a bit too *nix-y. Wirth compilers usually compile themselves and are simpler and cleaner. But ACK is written in C for *nix, so whatever, always seems to complicate everything. I guess it's really just a cultural difference, I'm not really complaining (but I definitely don't understand it enough to port it).

P.S. In particular, with Detlef's LCC/DJ build, he had a public DJGPP setup that he used, but it didn't include the Bison-generated output, so I had to install Bison + m4, and I tried telling him that BYACC (apparently) didn't need M4, so he could use / include that, but I don't think he ever "fixed" it. Oh well. But LCC is definitely easier to build than GCC, though of course it (at least 4.2) is C89 only and less optimizing, to say the least. (And he uses NASM as assembler, which LCC can build, but it still requires GNU ld.)

> I'm pretty sure ACK has supported ANSI since a long time, at least since
> Minix 2.0.0 series. The last public "official" ACK from Vrije Universitat
> was 5.5 (see here).
>

Sorry my bad. I just played with Minix a bit some time ago. You seem to be more informed then me. :)

Btw, I had success running the recent versions in qemu. That is without VT-X (sadly).

> I thought? I had read somewhere that they were still defaulting to ACK and
> GCC was only optional. I can't imagine they'd switch entirely, but
> <sarcasm> those pesky (Linux) spies^H^H^H^H^H volunteers probably have
> their own preferences (sabotage!). </sarcasm>
>

You have penguinofobia. :D

> Does 32-bit DOS output work with LFNs? In my limited testing, I didn't
> think so. Even the compiler itself isn't LFN-aware, so I wasn't very
> impressed. Sad, really, I guess there aren't enough volunteers, and I'm not
> convinced I could help very much.
>

It seems to work fine. At least with what I tested. What problems did you have? I'll test it more and let you know. I did a several quick tests. Nothing too thoroughly.

> 16-bit seems to work with LFN okay, but I didn't heavily test. I guess it
> depends on what calls are used. You can disable LFN at runtime, I think, by
> "set LFN=n", IIRC.
>

I don't know. Won't play with that soon. I can't seem to get word/bit/etc definitions for 16-bit right anyway... It seemed to work fine with a simple example. But with something other than that... Still have to test.

But yes. It seems to work fine when LFN driver is loaded. Otherwise it still tries to use LFN. But that that's my experience with only one package (small untar utility) so it may be generalization.

> IIRC, building ACK on Linux didn't work with Bison, perhaps I had to
> install BYACC instead, funnily enough. But ACK is weird, prefers LLGEN.
> Honestly, it's such a weird beast to build that I'm not sure what it needs.
> Certainly it's a bit too *nix-y. Wirth compilers usually compile themselves
> and are simpler and cleaner. But ACK is written in C for *nix, so whatever,
> always seems to complicate everything. I guess it's really just a cultural
> difference, I'm not really complaining (but I definitely don't understand
> it enough to port it).
>

I haven't look much into it. But it seems like a "no so easy task".

> P.S. In particular, with Detlef's
> LCC/DJ build, he had a public DJGPP setup that he used, but it didn't
> include the Bison-generated output, so I had to install Bison + m4, and I
> tried telling him that BYACC (apparently) didn't need M4, so he could use /
> include that, but I don't think he ever "fixed" it. Oh well. But LCC is
> definitely easier to build than GCC, though of course it (at least 4.2) is
> C89 only and less optimizing, to say the least. (And he uses NASM as
> assembler, which LCC can build, but it still requires GNU ld.)

Bookmarked. :) I'll check out his lcc. Good idea for a more detailed test.

What's wrong with ld? Can it be built with Deitmar's lcc build? Have you tried any other linker with COFF support (just brainstorming)?

I tried searching for linkers with DJGPP/COFF support

Club Dr.DOS wiki cites ALINK:
http://www.unet.univie.ac.at/~a0503736/php/drdoswiki/index.php?n=Main.DevelAsm#toc18

This little FAQ cites JLOC:
http://exec.h1.ru/docs/os-devel-faq/os-faq-linker.html

Anyway, maybe nasm output format can be tweaked for an another linker. It's able to generate different formats. Just the sort exerpt:
bin - flat-form binary files (e.g. DOS .COM, .SYS)
coff - COFF (i386) object files (e.g. DJGPP for DOS)
obj - MS-DOS 16-bit/32-bit OMF object files
ieee - IEEE-695 (LADsoft variant) object file format

Edit: props to Dietmar. :) The package is clean and easy to understand/hack on. I will play with it a bit.

> Sorry my bad. I just played with Minix a bit some time ago. You seem to be
> more informed then me. :)

Only very very barely.

> Btw, I had success running the recent versions in qemu. That is without
> VT-X (sadly).

QEMU is fairly hard to build on Win32, or at least pre-built binaries aren't as easy to come by anymore, apparently. But I usually just use VirtualBox, "good enough", these days.

> > I thought? I had read somewhere that they were still defaulting to ACK
> and
> > GCC was only optional. I can't imagine they'd switch entirely, but
> > <sarcasm> those pesky (Linux) spies^H^H^H^H^H volunteers probably have
> > their own preferences (sabotage!). </sarcasm>
>
> You have penguinofobia. :D

Nah, I run Linux a lot on that other machine (triple boot). It's just I hate POSIX-only code, it's so ugly. If I write DOS-only code, I'm an idiot, but they write Linux-only code and are geniuses, go figure.

> It seems [OW's LFN] to work fine. At least with what I tested. What problems did you
> have? I'll test it more and let you know. I did a several quick tests.
> Nothing too thoroughly.

Nothing big. Just the fact that the compiler itself isn't LFN aware after all this time can't be a good sign. (I guess we should be running Win32-hosted under HX?)

> Bookmarked. :) I'll check out his lcc. Good idea for a more detailed test.
>
> What's wrong with ld? Can it be built with Deitmar's lcc build? Have you
> tried any other linker with COFF support (just brainstorming)?

No, haven't tried, didn't seem worth the effort, maybe only for more independence or looser licensing or whatever. GNU ld may (in theory) build with LCC + POSIX libc (aka, DJGPP libc 2.01 he used), but I haven't tried.

P.S. (next post) You're right, ALINK supports some form of COFF, but I'm not sure if that's the DJGPP variant or (more likely) only Win32 PE/COFF, which differs in some incompatible ways (e.g. reloc handling). Actually, ALINK is old, buggy, and long abandoned, so I'm not sure how robust it is. (But better than nothing, I guess.) If you really just want a totally independent toolset, try CC386. At least that (supposedly) can build itself. OpenWatcom can too but not on DOS (AFAIR) though one guy halfway tried a few years ago.

> > Sorry my bad. I just played with Minix a bit some time ago. You seem to
> be
> > more informed then me. :)
>
> Only very very barely.
>
> > Btw, I had success running the recent versions in qemu. That is without
> > VT-X (sadly).
>
> QEMU is fairly hard to build on Win32, or at least pre-built binaries
> aren't as easy to come by anymore, apparently. But I usually just use
> VirtualBox, "good enough", these days.

They added glib as dependency which depends on gettext and libiconv in 1.0.
Not to mention the slirp networking is broken when they switched to glib. So lets stuck in 0.15.1.

> Edit: props to Dietmar. :) The package is clean and easy to understand/hack
> on. I will play with it a bit.

For no good reason, I downloaded LCC-DOS.ZIP again. Apparently he forgot to update the "last updated" date on his website, so it's actually the Aug. 28 version. Last I had was Aug. 20, from before I suggested he use "latest 0.98.39". So he upgraded to that (from 0.98.34) but downgraded the linker (2.16.1 to 2.8.1, I think), not that it matters. (I didn't know he'd updated it at all else I would've tried it earlier. Doh, so painful to find something breaks accidentally.)

The bigger problems are that: 1). he forgot something somewhere, so it erroneously fails with (default "bin") output format, and 2). lcc\src\lcc\dos.c has a hardcoded "c:/lcc" for the compiler driver, which is inconvenient if you move it anywhere.

The latter requires a simple edit and recompile. But you have to workaround the former issue first else manually piece together the compiler chain (cpp, rcc, asm, lnk) for dos.c and lcc.c. The simple "workaround" (until / if??? he updates his online .ZIP) is either "set NASMENV=-fcoff" or "lcc -Wa-fcoff" each time you use it. I'm surprised this didn't bite you already.

Oh well, nothing hugely major, just annoying.

> They added glib as dependency which depends on gettext and libiconv in
> 1.0.
> Not to mention the slirp networking is broken when they switched to glib.
> So lets stuck in 0.15.1.

I'm using a fairly older one. 0.11.1 (kqemu support). But it seems pretty sluggish on Athlon xp machine it is run on. I remember 0.9.1 being easier on resources.

> > Edit: props to Dietmar. :) The package is clean and easy to
> understand/hack
> > on. I will play with it a bit.
>
> For no good reason, I downloaded LCC-DOS.ZIP again. Apparently he forgot to
> update the "last updated" date on his website, so it's actually the Aug. 28
> version. Last I had was Aug. 20, from before I suggested he use "latest
> 0.98.39". So he upgraded to that (from 0.98.34) but downgraded the linker
> (2.16.1 to 2.8.1, I think), not that it matters. (I didn't know he'd
> updated it at all else I would've tried it earlier. Doh, so painful to find
> something breaks accidentally.)
>
> The bigger problems are that: 1). he forgot something somewhere, so it
> erroneously fails with (default "bin") output format, and 2).
> lcc\src\lcc\dos.c has a hardcoded "c:/lcc" for the compiler driver, which
> is inconvenient if you move it anywhere.
>
> The latter requires a simple edit and recompile. But you have to workaround
> the former issue first else manually piece together the compiler chain
> (cpp, rcc, asm, lnk) for dos.c and lcc.c. The simple "workaround" (until /
> if??? he updates his online .ZIP) is either "set NASMENV=-fcoff" or "lcc
> -Wa-fcoff" each time you use it. I'm surprised this didn't bite you
> already.
>
> Oh well, nothing hugely major, just annoying.

Well it certainly doesn't look finished or "production" quality. IE, he put together a simple batch files instead of CC. An there is the stuff you mentioned (and few others). But the code is clean and easy to hack on. Which is big plus on my side. It makes it easier for anyone to correct those mistakes. Maybe he was content just with that he made it work. :)

I'm just saying his code cleanup makes it easy to make something out of it. And it's easy to see what he did and change it. It's hackable and easy to understand source code. A good "base".

He actually spent a lot of time working on it, mostly due to his VESA gfx routines (with font support) and various examples and documentation (.tex). LCC by default doesn't come with a libc nor headers nor even assembler nor linker, so integrating all that also takes time and effort. I'm just saying, he's a hard worker!

It's clearly a lightweight alternative to GCC and easier to build since it relies less on POSIX. LCC is C89 only hence less cruft, so to speak. I know DJGPP's GCC is hard to build, but IIRC the only one semi-sane would be old 2.7.2.3, so I guess I would loosely compare it to that. However, I'm pretty sure he never built LCC-DOS totally with itself, due to some minor omissions, but it's certainly possible with a few tweaks, I assume.

BTW, I did email him, and he did say he'll eventually try to fix the issues mentioned if he can find the time.

> He actually spent a lot of time working on it, mostly due to his VESA gfx
> routines (with font support) and various examples and documentation (.tex).
> LCC by default doesn't come with a libc nor headers nor even assembler nor
> linker, so integrating all that also takes time and effort. I'm just
> saying, he's a hard worker!
>

I don't doubt he is. :)

I still haven't found the time to try it out. :(

> It's clearly a lightweight alternative to GCC and easier to build since it
> relies less on POSIX. LCC is C89 only hence less cruft, so to speak. I know
> DJGPP's GCC is hard to build, but IIRC the only one semi-sane would be old
> 2.7.2.3, so I guess I would loosely compare it to that. However, I'm pretty
> sure he never built LCC-DOS totally with itself, due to some minor
> omissions, but it's certainly possible with a few tweaks, I assume.
>

2.7.x didn't include optimization, didn't it? But I read it was fast. And I recently came across an optimizier from that era (Linux though).

I don't know about DOS, but 2.7 might be still buildable on modern Linux. I successfully built 2.8 and 2.9 recently. Although they don't like some of the recent glibc headers. But they work. C compiler... C++ doesn't. Although you need to build GCC 3.x first. GCC 4 won't work.

> BTW, I did email him, and he did say he'll eventually try to fix the issues
> mentioned if he can find the time.

He did great job with what he did by now. It just needs some tweaking and it might become an interesting alternative. :)

DJGPP is great though. But it doesn't hurt to have another freely available option. :)

I'm mostly a Linux guy, so I don't get much time to play with DOS stuff. But I do from time to time. I'm a bit of retro enthusiasist (that also includes old Linuces/Unices and also *dows). :)

I did setup a functional DosEMU setup with DJGPP and OWatcom this time, so I do get around more than before.

> 2.7.x didn't include optimization, didn't it? But I read it was fast. And I
> recently came across an optimizier from that era (Linux though).

2.7.2.3 only supported -m386 and -m486 optimizations, and the latter was just added padding / alignment. Yes, it was fast to run, -O2 was faster than 2.95.3's -O0 !! (Sad, really, heheh.) And it only went downhill from there.

> I don't know about DOS, but 2.7 might be still buildable on modern Linux. I
> successfully built 2.8 and 2.9 recently. Although they don't like some of
> the recent glibc headers. But they work. C compiler... C++ doesn't.
> Although you need to build GCC 3.x first. GCC 4 won't work.

I've built 2.7.2.3 in pure DOS a year or so back, it wasn't that hard. Allegedly, you can even build 2.95.3 with it. So I guess that's a fairly good bootstrap. But I guess it depends on what you want to do. (And BTW, DJGPP 2.03p2 libc was built with 2.8.1.)

I hate GCC-specific code, defeats the whole purpose (almost), too annoying when specific versions are needed (or must be avoided).

> He did great job with what he did by now. It just needs some tweaking and
> it might become an interesting alternative. :)
>
> DJGPP is great though. But it doesn't hurt to have another freely available
> option. :)

LCC is good but no optimizations. It's just cleaner to build and use, IMHO, that's all. But if you want more than just C89 support, I guess you're out of luck.

> I'm mostly a Linux guy, so I don't get much time to play with DOS stuff.
> But I do from time to time. I'm a bit of retro enthusiasist (that also
> includes old Linuces/Unices and also *dows). :)

Well, for me personally, DOS is just simpler, more comfortable, easier to use, mostly because I'm used to it. Everything else is such a struggle because of so many dependencies or binaries that don't exist or won't install or run anymore.

> I did setup a functional DosEMU setup with DJGPP and OWatcom this time, so
> I do get around more than before.

Don't forget that OpenWatcom runs natively on Linux too.

> Limited C subset
> ================
> Ron Cain's Small C 8086/8088 ports (original published in DDJ)
> * Project -fbin (diff. versions, req. nasm, modern)
> * Small C 2.1 - 2.2 (by James Hendrix, shareware, improved)
> * BYTE Small-C 1.0 (Rick Grehan, BYTE Mag., req ms link/masm)
> * Caproc Small-C (8088, req. ms link/masm)

Could you point out the versions of project-fbin CC you found?
Or even point out how to build one of them?
The documentation is close to useless for installing...
There is a libc that suffices to bootstrap, though.

Small C is subset-K&R, FWIW.

My point in mentioning the PCC-8086 compiler was:
1-it's a BSD-ish 16bit compiler (mentioned for cm's sake)
2-it might be helpful in porting the PCC "Ragge version" to target 16-bit DOS
(the latter does support segmented modes to some extent-the PDP11 is a 16-bit CPU with 6 extra bits for a 4MB total address space)

DJGPP et al. are exactly what this isn't about. They can't compile a kernel, are 32-bit and single-segment, and aren't nearly as liberally licensed.



I'm considering putting together a NASM + -fbin CC + *BASIC compiler floppy, that's a development environment in a few languages...might extend the libc a little in the process.

> > Limited C subset
> > ================
> > Ron Cain's Small C 8086/8088 ports (original published in DDJ)
> > * Project -fbin (diff. versions, req. nasm, modern)
> > * Small C 2.1 - 2.2 (by James Hendrix, shareware, improved)
> > * BYTE Small-C 1.0 (Rick Grehan, BYTE Mag., req ms link/masm)
> > * Caproc Small-C (8088, req. ms link/masm)
>
> Could you point out the versions of project-fbin CC you found?
> Or even point out how to build one of them?
> The documentation is close to useless for installing...
> There is a libc that suffices to bootstrap, though.

I assume you're not asking me, but a quick Google search found this (though I have not tried it):

http://www.project-fbin.hostoi.com/CCNA_HTM/RT_CCNA.HTML

> Small C is subset-K&R, FWIW.
>
> My point in mentioning the PCC-8086 compiler was:
> 1-it's a BSD-ish 16bit compiler (mentioned for cm's sake)

But is cm needing / wanting such a thing? All I knew of was him hacking at RxDOS in NASM, not expecting to use C for anything.

> 2-it might be helpful in porting the PCC "Ragge version" to target 16-bit
> DOS
> (the latter does support segmented modes to some extent-the PDP11 is a
> 16-bit CPU with 6 extra bits for a 4MB total address space)

The old 8086.zip one above from 1983? Or do you mean latest PCC 1.0 from a year or two ago? Unlikely to be ported either way, most people would just use OpenWatcom (whose license is still OSI approved, at least).

The 16-bit memory models aren't as popular these days, esp. since 32-bit and 64-bit modes have become the norm thanks to *nix and WinNT. If you have specific memory model requirements for something, it might be easier to just use assembly (if pre-existing C compilers like OpenWatcom don't fulfill your needs). At least there you have 100% control. If you want a bit of HLL flavor, some good HLL macros for NASM or FASM can somewhat ease the transition.

> DJGPP et al. are exactly what this isn't about. They can't compile a
> kernel, are 32-bit and single-segment, and aren't nearly as liberally
> licensed.

DJGPP can probably compile some kernels, but obviously not FreeDOS (compact model) without heavy tweaking. Is that what you wanted? What kernel did you want to build? Or are you writing from scratch?

> I'm considering putting together a NASM + -fbin CC + *BASIC compiler
> floppy, that's a development environment in a few languages...might extend
> the libc a little in the process.

If you're only wishing to hack a bit for fun, something like EiC or PicoC (both interpreters) would be better. But that's not as helpful if you really want to write low-level kernel code natively.

> > My point in mentioning the PCC-8086 compiler was:
> > 1-it's a BSD-ish 16bit compiler (mentioned for cm's sake)
>
> But is cm needing / wanting such a thing? All I knew of was him hacking at
> RxDOS in NASM, not expecting to use C for anything.

Comment made in private email: I asked about RxDOS because the fact that FreeDOS uses a "non-free" compiler to build means that dosemu is questionable for FSF-approved distros; he said it wasn't ready and probably would never be, and commented that a free compiler would be the best solution, then started pondering about whether there are any BSDish C compilers that could readily be ported to DOS or already target DOS.

> > 2-it might be helpful in porting the PCC "Ragge version" to target
> 16-bit
> > DOS
> > (the latter does support segmented modes to some extent-the PDP11 is a
> > 16-bit CPU with 6 extra bits for a 4MB total address space)
>
> The old 8086.zip one above from 1983? Or do you mean latest PCC 1.0 from a
> year or two ago? Unlikely to be ported either way, most people would just
> use OpenWatcom (whose license is still OSI approved, at least).
>
> The 16-bit memory models aren't as popular these days,
...
I mean, PCC 1.x still has support for cross-compiles to PDP11 (which is a segmented-mode 16-bit CPU). So you don't need to worry about whether 16-bit support is popular or feasible; it's already there even in the newer versions.
Perhaps the 8086.zip version could serve as a reference to retarget PCC 1.x for DOS/16; this might hypothetically allow a DOS/32 -> DOS/16 "cross-compiler".

> DJGPP can probably compile some kernels, but obviously not FreeDOS (compact
> model) without heavy tweaking. Is that what you wanted? What kernel did you
> want to build? Or are you writing from scratch?
A compiler that could build a 16-bit DOS kernel (ie, real mode + supports segmented modes). Freedos is an example of the type of kernel.


> If you're only wishing to hack a bit for fun, something like EiC or PicoC
> (both interpreters) would be better. But that's not as helpful if you
> really want to write low-level kernel code natively.
Just a toy project-- a C-ish compiler, an assembler, a BASIC compiler, etc.
The project could hypothetically run on an 8086, and provide an interesting setup for tinkering. I want compilers, though (and maybe also a BASIC interpreter).

> Comment made in private email: I asked about RxDOS because the fact that
> FreeDOS uses a "non-free" compiler to build means that dosemu is
> questionable for FSF-approved distros; he said it wasn't ready and probably
> would never be, and commented that a free compiler would be the best
> solution, then started pondering about whether there are any BSDish C
> compilers that could readily be ported to DOS or already target DOS.

If your goal is just to get DOSEMU accepted in a distro, it's unlikely to happen: DOSEMU is a second-class citizen to Linux as they prefer native binaries. It's still on like disk #8 (or whatever) of Debian, but you're unlikely to find it beyond that anywhere else. (And there are weird bugs and incompatibilities in other areas, e.g. SELinux under OpenSuSE, so most people don't bother.)

Yes, some people wrongly say DOSEMU is non-free, which is a lie, but they reject the OSI-approved Sybase v1 license, hence OpenWatcom, hence FreeDOS, hence DOSEMU as a whole. Also, RMS even considers x86 native BIOS (except Coreboot??) to be non-free, so he only uses a Leemote (sp?) cpu with gNewSense. So even native DOS (preferred environment) is non-free to him.

The path of least resistance would be to just keep using OW privately and/or create your own Linux distro. (99% of Linux distros are non-free anyways, e.g. binary blobs.)

The FreeDOS and Linux kernels have the same license, but by far Linux is heavily preferred, esp. by FSF/GNU, and that's unlikely to change, even with a "free-r" compiler, sadly. I.e., you're unlikely to ever see FreeDOS + DJGPP as a tier one target for GCC.

> I mean, PCC 1.x still has support for cross-compiles to PDP11 (which is a
> segmented-mode 16-bit CPU). So you don't need to worry about whether
> 16-bit support is popular or feasible; it's already there even in the newer
> versions.
> Perhaps the 8086.zip version could serve as a reference to retarget PCC 1.x
> for DOS/16; this might hypothetically allow a DOS/32 -> DOS/16
> "cross-compiler".

8086.zip seemed to only output .COM and not touch any segment registers, so that's only tiny model, which is available elsewhere (BCC/Dev86).

> A compiler that could build a 16-bit DOS kernel (ie, real mode + supports
> segmented modes). Freedos is an example of the type of kernel.

Probably easier "in theory" to just adapt it to use Dev86DOS + NASM for the tricky bits. So it would just mean migrating away from the compact model stuff and do it directly in (external) assembly.

> Just a toy project-- a C-ish compiler, an assembler, a BASIC compiler,
> etc.
> The project could hypothetically run on an 8086, and provide an interesting
> setup for tinkering. I want compilers, though (and maybe also a BASIC
> interpreter).

So then I would probably use Dev86DOS, NASM 0.98.39 (real mode version), and XPL0 (since I can't think of any 16-bit BASIC "compilers" offhand, e.g. BWBasic is only an interpreter). But there are probably others if you search hard enough.

> Probably easier "in theory" to just adapt it to use Dev86DOS + NASM for the
> tricky bits. So it would just mean migrating away from the compact model
> stuff and do it directly in (external) assembly.
IIRC that's what dosbox did (dev86 port of FreeDOS) --ought to check, though.
EDIT: Completely off. Wonder what I misread...

> So then I would probably use Dev86DOS, NASM 0.98.39 (real mode version),
> and XPL0 (since I can't think of any 16-bit BASIC "compilers" offhand, e.g.
> BWBasic is only an interpreter). But there are probably others if you
> search hard enough.
One of the unstated rules:
If it can't compile itself and is written in the language it implements, it's not good enough...
This pretty much kills dev86, since BCC-CC1.EXE is 120+ k. :(

DeSmet 3.03 will bootstrap itself, and runs small enough to fit on a floppy with some room free (600 k for the standard compiler, 450 k for the large one).
There's a bit of old code written for DeSmet, since it was the main shareware compiler (PCC).
I may poke and see if nasm 0.9x can build with this, so I have a full bootstrap environment.
DeSmet may be weird, but it still beats a K&R-ish small model compiler that supports DOS as an afterthought and can use unprotoize if you really need to try building ANSI. Allegedly, 3.1h supported ANSI C natively - I haven't verified this.

For BASIC, I'm looking at http://exmortis.narod.ru/src_compilers_eng.html (they have a near-QBASIC compatible compiler that outputs NASM code, and a GABASIC knockoff with IDE, written in GABASIC)

> One of the unstated rules:
> If it can't compile itself and is written in the language it implements,
> it's not good enough...

I don't like the difficulties in compilers that aren't able to (portably) bootstrap. It seems so senseless to me. In a way, I almost prefer interpreters or things that compile in ANSI C because it's so much simpler and portable. But the king of simple bootstrapping is Forth, so maybe I'm looking in the wrong place. It just bugs me that Wirth-family compilers are so hard to build (which is ironic considering how much Wirth himself keeps things simple, but nobody seems to take his advice ... reminds me that I need to study closer Oberon-0 or P4 or Pascal_s sometime).

> This pretty much kills dev86, since BCC-CC1.EXE is 120+ k. :(

While you're probably right, code size isn't always equivalent between compilers. So I don't think it's totally impossible that BCC could one day compile itself. Though it probably won't, it's mostly meant for cross-compiling from *nix. Most C libraries are notoriously bloated.

> DeSmet 3.03 will bootstrap itself, and runs small enough to fit on a floppy
> with some room free (600 k for the standard compiler, 450 k for the large
> one).
> There's a bit of old code written for DeSmet, since it was the main
> shareware compiler (PCC).
> I may poke and see if nasm 0.9x can build with this, so I have a full
> bootstrap environment.

I would be very very surprised if you could get NASM built with it. Actually, a fair number of assemblers are written in themselves (e.g. Octasm, FASM), so it'd be easier just to use one of those, though I admit those aren't 8086 friendly. (But check out Venksi's very tiny 8086 one here.)

Old NASM was indeed pure ANSI C89, though, so I guess it's possible, but Desmet doesn't have full ANSI libs / headers.

> DeSmet may be weird, but it still beats a K&R-ish small model compiler that
> supports DOS as an afterthought and can use unprotoize if you really need
> to try building ANSI. Allegedly, 3.1h supported ANSI C natively - I
> haven't verified this.

I haven't heavily used Desmet, but 3.1h does seem pretty good. Granted, I didn't test too much with it, and as mentioned I had to nop out any mention of stdlib.h and time.h, so you're going to be lacking things. But the syntax part and code generation seems to work (in at least one very unofficial test). Yes, it's surprisingly capable, but I wouldn't pin too high hopes on it (though it does support both small and, optionally, large model too).

> For BASIC, I'm looking at http://exmortis.narod.ru/src_compilers_eng.html
> (they have a near-QBASIC compatible compiler that outputs NASM code, and a
> GABASIC knockoff with IDE, written in GABASIC)

I'd be surprised if those were much use. Similarly it reminds me of old BASM286, but I don't think that's quite robust enough for you, but hey, it ain't too too bad, last I checked.

BTW, I know you want a real compiler, not an interpreter, but I must mention this: EiC (Detlef's port) is probably best for interpreting (and seems very very ANSI compatible). The advantage is, of course, that you don't need assembler, linker, libraries, hence no worries about calling conventions, object formats, etc. Of course, that will be slightly slower and makes it harder to share code. But for quick prototyping or simple demos, it's plenty good.

I really also wanted to mention PicoC. With DJGPP 2.03p2 and UPX, the NO_FP version is only 78k for me (with my silly patch to fix a few minor nits). Granted, it has some omissions, so it's not fully ANSI compatible, esp. the lack of (almost entire) CPP preprocessor capabilities. But if you workaround that (easy, use pre-existing external CPP.EXE), it works quite well and is small and self-contained, even slightly moreso than EiC even. So I find it interesting.

> Actually, a fair number of assemblers are written in themselves (e.g.
> Octasm, FASM), so it'd be easier just to use one of those, though I admit
> those aren't 8086 friendly. (But check out Venksi's very tiny 8086 one
> here.)

Also worth noting that Venksi's self-assembling assembler is preinstalled on JSLinux and runs happily via Fabrice Bellard's runcom:
[arjay@linuxbox asm]$ runcom asm.com hpigot.s
[arjay@linuxbox asm]$ ls -al hpigot.*
-rwxrwxr-x 1 arjay linux   77 2012-03-27 21:23 hpigot.com*
-rwxrwxr-x 1 arjay linux  378 2012-03-27 21:23 hpigot.lst*
-rw-rw-r-- 1 arjay linux 4043 2012-03-27 21:15 hpigot.s
[arjay@linuxbox asm]$ echo u | runcom debug.com hpigot.com
-u
1526:0100 BD1027        MOV     BP,2710
1526:0103 BB427F        MOV     BX,7F42
1526:0106 8BCB          MOV     CX,BX
1526:0108 B002          MOV     AL,02
1526:010A BF4D01        MOV     DI,014D
1526:010D F3AB          REP     STOSW
1526:010F 53            PUSH    BX
1526:0110 F7E3          MUL     BX
1526:0112 96            XCHG    AX,SI
1526:0113 8BFA          MOV     DI,DX
1526:0115 03DB          ADD     BX,BX
1526:0117 4B            DEC     BX
1526:0118 8B874C01      MOV     AX,[BX+014C]
1526:011C F7E5          MUL     BP
1526:011E 03C6          ADD     AX,SI
[arjay@linuxbox asm]$ runcom hpigot.com
000314159265358979323846264338327950288419716939937510582097494459230781640...
...2823608963208068222468012248

As per my comments on runcom thread, obviously not all programs compiled with asm.com will run under runcom (currently) due to limited interrupt support:

[arjay@linuxbox asm]$ ls
asm.com*  Changelog  display.s*  equ.s*   input.s*     lister.s*   output.s*    support.s*  symtab.i*
asm.s*    direct.s*  dos.i*      expr.s*  license.txt  message.s*  readme.txt*  symbols.s*  symtab.s*
[arjay@linuxbox asm]$ ls -al display.s
-rwxr-xr-x 1 arjay linux 2240 2009-04-21 18:25 display.s*
[arjay@linuxbox asm]$ runcom asm.com display.s
[arjay@linuxbox asm]$ ls -al display.com
-rwxrwxr-x 1 arjay linux 224 2012-03-27 20:19 display.com*
[arjay@linuxbox asm]$ runcom display.com
[arjay@ asm]$ debug display.com
-g

unhandled vm86 return code (0x1)
EAX=0001005c EBX=00020000 ECX=004000e2 EDX=bfe900ae
ESI=00000000 EDI=00000002 EBP=00000000 ESP=0000fff0
EIP=0000ffff EFL=000b0246
CS=1526 DS=1526 ES=1526 SS=1526 FS=0000 GS=0000
[arjay@linuxbox asm]$

However at least being able to compile DOS asm programs like this from the Linux command-line may be of interest/use to some people.