DOS ain't dead

Hello fellow DOS lovers!

I'm not sure whether this fits best the Announce category or the Misc one, (moderator(s), feel free to correct).

I've come across this thread, Old 8086 version of pcc spotted (cross-compiles to DOS), and I'd like to share with you my recent work in the field.

For the past year I've been working in my spare time on a C compiler that could potentially target DOS. And, in fact, it already can. :)

Meet Smaller C!

Smaller C in not too many words (more on github):

- is much like the original Small C by Cain/Hendrix/etc and Micro-C by Dunfield, but with normal ANSI/C89 syntax and behavior (=no foul play in expressions as in Micro-C), work is underway to support more of C89

- generates NASM-agreeable 16- or 32-bit i80386 assembly code, and should be fairly easily adaptable to other assemblers if needed (I've been told, it takes an hour to adapt it to NBASM)

- -seg16t,-seg16,-flat16 options are for the 16-bit tiny/small memory models (ints and pointers are 16-bit, pointers are near)

- -seg32,-flat32 options are for 32-bit code (ints and pointers are 32-bit, pointers are near)

- -huge option is for a memory model similar to the huge memory model found in Borland/Turbo C/C++ compilers (ints and pointers are 32-bit, pointers are physical addresses, transparently converted into segments and offsets, no need to mess with far, MK_FP(), FP_SEG(), FP_OFF() and the like, you can pretend you're in 32-bit mode!; this should help with porting code to DOS or even writing new code for DOS)

- is trivially compilable with any C89+ compiler (Turbo/Borland C/C++, Open Watcom C/C++, djgpp, gcc, you name it) and can run in DOS

- (re)compiles itself (you can already make a DOS .EXE of Smaller C using only Smaller C (compiled with another compiler or itself) and NASM (2.03 or better), no linker needed)

- doesn't yet provide libc, though it should be easy to implement a basic library for DOS (the compiler itself needs only a handful of ctype/string/stdlib/stdio functions to operate and those are already available for bootstrapping for DOS)

- BSD licensed


More details (live document) can be found here, in the Wiki.

In the near future I'm going to add support for struct, short and long.

You're most welcome to play with Smaller C, report bugs and discuss it (and contribute:).

Alex
P.S. Robert, indeed, I'm the author of the Frounze Commander. :) Thanks for my new account on the forum!

Basic support for struct/union has just been submitted.

You can do everything with struct and union, except:
- bit-fields, flexible array members
- tight packing (members are naturally aligned)
- passing/returning to/from functions by value; pass/return by reference instead
- initializing at definition time via = { initializer(s) }

Assignment, ?:, ->, ., (unsigned)&((struct someTag*)0)->someMember are OK.

Enjoy. Please report bugs.

Just a quick test, there's one waring with gcc 4.8.x:

smlrc.c: In function 'exprval':
smlrc.c:3906:33: warning: 'ofs' may be used uninitialized in this function [-Wma
ybe-uninitialized]
stack[i][1] = uint2int(stack[i][1] + 0u + ofs); // TBD!!! need extra
truncation?
^

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

> smlrc.c: In function 'exprval':
> smlrc.c:3906:33: warning: 'ofs' may be used uninitialized in this function
> stack[i][1] = uint2int(stack[i][1] + 0u + ofs);

That is a reasonable warning for a condition, whose impossibility the compiler fails to deduce (see, there's still a long road ahead of us in terms of i(nv|mplem)enting AI ). ofs can be initialized to 0 explicitly (in its declaration) to suppress this warning.

There are a few other warnings needing cleanup. I should modify my build scripts to catch warnings early (I've changed them and lost the various -Wall's and -Wextra's in the process).

P.S. Thanks for noticing!
P.P.S. And thanks for trying out!

> Basic support for struct/union has just been submitted.
>
> You can do everything with struct and union, except:
> - bit-fields, flexible array members

Does this mean you allow this funky bit of C structs?

struct Parent
{
char* str;
}

struct Child
{
struct Parent;
int length;
}

struct Child c;
c.str = "Hello World!";
c.length = strlen( c.str );

> Does this mean you allow this funky bit of C structs?
> ...

You could try, right? :)

This does compile:


int main(void)
{
  struct Parent
  {
    char* str;
  }; // note the semicolon

  struct Child
  {
    struct Parent p; // note the member name p
    int length;
  }; // note the semicolon

  struct Child c;
  c.p.str = "Hello World!"; // note the p
  c.length = strlen( c.p.str ); // note the p

  return 0;
}


New things:
- short
- long (32-bit and huge mode(l)s only)
- improved extern (now extern directives are generated for NASM automatically as needed, not based on whether or not you use extern in C)
- one bug fixed

New things:
- typedef
- __func__
- bugfixes

New things:
- enum
- #pragma pack()
- bugfix

Improvements/New things:
- bugfixes
- support initialization of multidimensional arrays
- support initialization of structures
- support initialization of structures and arrays inside functions
- support static inside functions

The compiler should now be much more usable.

I've uploaded binaries for DOS and most of the standard library.

Note: a few things are still missing from the library, most notably: <time.h> functionality, *scanf() functions.

Everyone's welcome to play with the compiler and report bugs.

How to install the .zip file downloaded from GitHub:

1. Create C:\SMLRC (any hard disk or name will do, but make the full path as short as possible) and copy into it the following subdirectories of the .zip file:
BIND
INCLUDE
LIB
TESTS

2. Include C:\SMLRC\BIND in the environment variable PATH

3. Don't forget to have NASM (2.10 is good) installed and also available via PATH

You should now be able to compile the following example from TESTS\hw.c:

/*
How to compile for DOS (all mode(l)s: tiny/.COM, small/.EXE, huge/.EXE):
smlrcc -dost hw.c -o hwdt.com
smlrcc -doss hw.c -o hwds.exe
smlrcc -dosh hw.c -o hwdh.exe
*/
#include <stdio.h>

int main(void)
{
puts("Hello, World!");
return 0;
}

I suggest to stick to the huge memory mode(l) as it supports 32-bit types such as long the functions that consume or return these types. In this mode(l) you can allocate all the available conventional memory via malloc() and you're not limited to objects smaller than 64KB.

The huge memory mode(l) is selected with the "-dosh" option, but you don't need to specify it explicitly when using a DOS version of smlrcc.

What else to know?

smlrcc can consume one or more of .c, .asm, .o or .a files and make an executable out of them.

If the command line is too long (over some 120 characters), you can put it into a file, say, mycmd.txt, and invoke smlrcc with @mycmd.txt (note the @ prefix) and it will extract the command line parameters from the file mycmd.txt. The linker (smlrl) supports this as well.

smlrcc supports the following useful options:
-c (compile only, don't link)
-S (compile to assembly only)
-v (verbose; show executed commands)
-map <mapfile> (produce the map file together with the binary)

You can compile your .c/.asm/.o files directly to a .a library file if you invoke smlrcc like so:
smlrcc [options] <file(s)> -c -o mylib.a

There's more but the documentation hasn't been updated for a while and so here I'm giving the most basic info only.

Enjoy.

I've just added support for Windows as both a host and a target platform.

This means that there are now executables and libraries for both DOS and Windows and you can develop on either platform for either platform.

The standard C library is practically complete (up to what the compiler supports in terms of the C language) and should be usable.

There have been some other changes and improvements in the meantime.

I've updated the documentation (smlrcc.exe, smlrl.exe, standard library):
https://github.com/alexfru/SmallerC/wiki

I've added Linux support (library and binaries).

So, finally, all 3 platforms (DOS, Windows and Linux) are the host and the target platforms.

I've added an option (-ppg) to smlrcc to invoke gcc as a preprocessor and included the va_* macros in stdarg.h.
This should help until there's a decent preprocessor in Smaller C.

It looks like DJGPP's gcc.exe works as well.

Alex

> Hello fellow DOS lovers!
>
> I'm not sure whether this fits best the Announce category or the Misc
> one, (moderator(s), feel free to correct).
>
> I've come across this thread,
> Old 8086
> version of pcc spotted (cross-compiles to DOS), and I'd like to
> share with you my recent work in the field.
>
> For the past year I've been working in my spare time on a C compiler that
> could potentially target DOS. And, in fact, it already can. :)
>
> You're most welcome to play with Smaller C, report bugs and discuss it (and
> contribute:).
>
> Alex
> P.S. Robert, indeed, I'm the author of the Frounze Commander. :) Thanks for
> my new account on the forum!

I read some discussions in IRC somewhere and there is a question raised: Why writing a custom parser when there is standard parser (bison/yacc) exists?

> I read some discussions in IRC somewhere and there is a question raised:
> Why writing a custom parser when there is standard parser (bison/yacc)
> exists?

Multiple reasons:
- bison/yacc/etc don't help much and it's not all that hard to implement all this manually (I must've done a full lexer/parser at least once in my life myself!: ) One could also reasonably ask why writing yet another C compiler? Many already exist and are available. And who cares about it being able to target realmode DOS? :)
- I don't want too many dependencies on other tools
- If I'd used those other tools, I wouldn't have been able to make the compiler self-compilable for a long time (long = until it could compile those other tools), but I wanted it to compile itself and selfhost as early as possible

Alex

> Multiple reasons:
> - bison/yacc/etc don't help much and it's not all that hard to implement
> all this manually (I must've done a full lexer/parser at least once in my
> life myself!: ) One could also reasonably ask why writing yet another C
> compiler? Many already exist and are available. And who cares about it
> being able to target realmode DOS? :)
> - I don't want too many dependencies on other tools
> - If I'd used those other tools, I wouldn't have been able to make the
> compiler self-compilable for a long time (long = until it could compile
> those other tools), but I wanted it to compile itself and selfhost as early
> as possible
>

hmm, what about win16 (NE output) support?

> hmm, what about win16 (NE output) support?

I'm not familiar with NE (at all) or Win16 APIs (I had very little 16-bit programming experience with Windows). So, I don't know the exact problems that may need to be overcome other than just supporting a different kind of executable and rewriting pieces of the standard library. Windows 3.xx support was not and is not planned. Even Windows 9x/Me/2k isn't supported because the standard library links to a few functions that appear only in Windows XP (this can be worked around, though).

There's one potential problem in that Smaller C doesn't have good support for segmentation and far pointers. If Win16 is happy with an app having just 2 segments (code and combined data/stack) and there are no far pointers to things outside these 2 segments, then it might be doable. Otherwise some hacks are needed and they will cause performance degradation (e.g. the huge model support in DOS).

Why are you asking? Is this related to ReactOS? (they have linked to Smaller C recently).

For those interested, it's now possible to pass and return structures by value.

A few important bugfixes are uploaded.

I never read nor frequented news://alt.os.development before,
but I somehow stumbled upon an old post from last October:

> Another thing that could help with testing under DOS is some
> simple tooling and scripting to build the compiler, write it
> and a bunch of tests and batch files to a floppy image, run
> stuff from it in a VM, then get back the log from the floppy
> image. I haven't researched automation with DOSBox, VirtualBox
> and the like. I imagine, not everyone of them provides
> programmatic interface to create/update/start/stop a VM.

I'm far from an expert. Plus most people indeed don't have
the interest to attempt things like this (at least not for DOS).

BTW, in an effort to be brief, I'll just post a few relevant
links here:

1). http://en.wikipedia.org/wiki/Mtools (also, 7-Zip 7z can extract)
2). ftp://ftp.winimage.com/extrac21.zip
3). http://www.freedos.org/software/?prog=vmsmount
4). http://www.freedos.org/wiki/index.php/VirtualBox_-_Chapter_6
5). http://en.wikibooks.org/wiki/QEMU/Devices/Storage
6). http://www.dosemu.org/docs/README/1.4/x724.html
7). http://rufus.akeo.ie/
8). http://qemu.weilnetz.de/

I've still been working on my single-floppy .img (FreeDOS) MetaDOS
distribution (0.2, still unreleased). The original version was
ultra minimal and somewhat useless (and broken). This one, while
still somewhat weak, is heavily improved. It uses packet drivers
to enable networking (mTCP's FTP, Watt-32 built Wget or Links2),
at least under VBox or QEMU.

My point is that I (privately, manually) run naive tests occasionally
just to make sure some things (still) work, e.g. rebuilding old NASM,
rebuilding the kernel, some random other silly things. E.g. my TP-ish
Befunge-93 interpreter, which I sometimes use (snapshot from FTP)
FreePascal's ppcross8086 (Win32-hosted cross-compiler) under HX (since
there still isn't a self-hosted DOS version!). BTW, they don't even
use NASM (nor WLIB) by default anymore, only internal bin writer.

I did see that you said you'd filed bugs against OpenWatcom. I still
haven't tried the 2.0-pre releases, although Jiri did update his
unofficial snapshot last month. I keep meaning to try to rebuild
NASM with it (which is, AFAIK, totally broken and unsupported
for that compiler due to bugs), but it's not important enough.
I don't even remember when it last built correctly (with OW),
probably 2.09-ish. Not sure about DJGPP, haven't tried natively.
I think they only cross-compile (for DOS via DJGPP) from Linux
, which might make things harder (./configure never works well
anywhere else).

http://sourceforge.net/projects/openwatcom/files/current-build/

Did I mention that I'm using a RAM driver (now unmaintained) by
Jason Hood that won't assemble in newer NASMs (due to his very
weird nasm.mac macros)? Yeah, fun fun fun. Oh, and the FreeDOS
kernel also requires NASM to rebuild.

Did any of this help? I feel like I just mostly rambled (again, sigh).

> I never read nor frequented news://alt.os.development before,
> but I somehow stumbled upon an old post from last October:
>
> > Another thing that could help with testing under DOS is some
> > simple tooling and scripting to build the compiler, write it
> > and a bunch of tests and batch files to a floppy image, run
> > stuff from it in a VM, then get back the log from the floppy
> > image. I haven't researched automation with DOSBox, VirtualBox
> > and the like. I imagine, not everyone of them provides
> > programmatic interface to create/update/start/stop a VM.
>
> I'm far from an expert. Plus most people indeed don't have
> the interest to attempt things like this (at least not for DOS).
>
> BTW, in an effort to be brief, I'll just post a few relevant
> links here:
>
> 1). http://en.wikipedia.org/wiki/Mtools (also, 7-Zip 7z can extract)
> 2). ftp://ftp.winimage.com/extrac21.zip
> 3). http://www.freedos.org/software/?prog=vmsmount
> 4). http://www.freedos.org/wiki/index.php/VirtualBox_-_Chapter_6
> 5). http://en.wikibooks.org/wiki/QEMU/Devices/Storage
> 6). http://www.dosemu.org/docs/README/1.4/x724.html
> 7). http://rufus.akeo.ie/
> 8). http://qemu.weilnetz.de/

I do have my own tools to create a FAT12-formatted floppy and populate
it with files. But the idea of writing DOS batch files for this is
putting me off. :)

> I've still been working on my single-floppy .img (FreeDOS) MetaDOS
> distribution (0.2, still unreleased). The original version was
> ultra minimal and somewhat useless (and broken). This one, while
> still somewhat weak, is heavily improved. It uses packet drivers
> to enable networking (mTCP's FTP, Watt-32 built Wget or Links2),
> at least under VBox or QEMU.

Is it just FreeDOS kernel w/ network support?

> My point is that I (privately, manually) run naive tests occasionally
> just to make sure some things (still) work, e.g. rebuilding old NASM,
> rebuilding the kernel, some random other silly things. E.g. my TP-ish
> Befunge-93 interpreter, which I sometimes use (snapshot from FTP)
> FreePascal's ppcross8086 (Win32-hosted cross-compiler) under HX (since
> there still isn't a self-hosted DOS version!). BTW, they don't even
> use NASM (nor WLIB) by default anymore, only internal bin writer.
>
> I did see that you said you'd filed bugs against OpenWatcom. I still
> haven't tried the 2.0-pre releases, although Jiri did update his
> unofficial snapshot last month. I keep meaning to try to rebuild
> NASM with it (which is, AFAIK, totally broken and unsupported
> for that compiler due to bugs), but it's not important enough.

Is the last commercial version of Watcom (10.x/11.x?) less buggy,
do you know? After all, it was Watcom with which a bunch of popular
games for DOS (e.g. Doom, Descent, etc) were compiled.

> I don't even remember when it last built correctly (with OW),
> probably 2.09-ish. Not sure about DJGPP, haven't tried natively.
> I think they only cross-compile (for DOS via DJGPP) from Linux
> , which might make things harder (./configure never works well
> anywhere else).
>
> http://sourceforge.net/projects/openwatcom/files/current-build/
>
> Did I mention that I'm using a RAM driver (now unmaintained) by
> Jason Hood that won't assemble in newer NASMs (due to his very
> weird nasm.mac macros)? Yeah, fun fun fun. Oh, and the FreeDOS
> kernel also requires NASM to rebuild.
>
> Did any of this help? I feel like I just mostly rambled (again, sigh).

Not really/not yet. :)

Btw, I'm working on implementing BSS section support in Smaller C,
so the binaries are going to shrink somewhat (~40KB for a set of
smlrc.exe, smlrl.exe, smlrcc.exe). Of course, something like
PKLITE could be used to make them even smaller and the library
files can have their local symbols stripped off, but even now
my compiler fits onto a 1.44MB floppy together with NASM without
using compression. :)

One day I was pondering the idea of making a tiny DOS that would
only support the functions used by the compiler. :) The problem
is NASM, which uses lots of DOS functions. OTOH, there's FASM,
but it isn't compatible enough with NASM/Smaller C. A development
system on a floppy is kinda cool. :)

> I do have my own tools to create a FAT12-formatted floppy and populate
> it with files. But the idea of writing DOS batch files for this is
> putting me off. :)

What's the problem with .BATs? Too tedious? Anyways, I'm starting to wonder if makefiles (e.g. 16-bit port of Dmake) would be better (for testing).

> > I've still been working on my single-floppy .img (FreeDOS) MetaDOS
> > distribution (0.2, still unreleased).
>
> Is it just FreeDOS kernel w/ network support?

Yes, of course. I didn't write any major code, just simplified things and made it easier (at least for me). Unfortunately, some things still trip me up (e.g. different QEMU versions or iBiblio quirks), but it mostly works well.

> Is the last commercial version of Watcom (10.x/11.x?) less buggy,
> do you know? After all, it was Watcom with which a bunch of popular
> games for DOS (e.g. Doom, Descent, etc) were compiled.

I'm no expert, but I think those ancient versions are even worse. Even OW 1.4 (or 1.8) added and fixed lots of stuff. If anything, newer versions are probably regression-tested better than ever.

I haven't followed them closely in recent years. Not sure why they are so slow to have a newer release. Probably too ambitious (adding AMD64, among other things). Probably should've just done a bugfix-only release or two. Also the buyout of Sybase by SAP probably didn't help.

> > Did any of this help? I feel like I just mostly rambled (again, sigh).
>
> Not really/not yet. :)

I honestly don't know what you're trying to do here.

> Btw, I'm working on implementing BSS section support in Smaller C,
> so the binaries are going to shrink somewhat (~40KB for a set of
> smlrc.exe, smlrl.exe, smlrcc.exe). Of course, something like
> PKLITE could be used to make them even smaller and the library
> files can have their local symbols stripped off, but even now
> my compiler fits onto a 1.44MB floppy together with NASM without
> using compression. :)

Sounds good. Though I'm not sure what advantages PKLITE has over UPX.

> One day I was pondering the idea of making a tiny DOS that would
> only support the functions used by the compiler. :) The problem
> is NASM, which uses lots of DOS functions. OTOH, there's FASM,
> but it isn't compatible enough with NASM/Smaller C. A development
> system on a floppy is kinda cool. :)

RxDOS was GPL, written in assembly, but quite buggy. Not sure if that would help you here. IIRC, originally MASM, but there was also an A86 port. Not sure if that one guy ever finished his conversion to NASM.

The problem with FASM (for 16-bit DOS target) is lack of OMF/OBJ support. And the problem with FreeDOS' kernel is reliance on quasi-standard 16-bit DOS-isms and (now) compact model.

> And the problem with FreeDOS' kernel is reliance on quasi-standard 16-bit
> DOS-isms and (now) compact model.

Please explain what kind of problems this is causing

> > And the problem with FreeDOS' kernel is reliance on quasi-standard
> > 16-bit DOS-isms and (now) compact model.
>
> Please explain what kind of problems this is causing

Tom, I wasn't trying to yet again whine about ye olde OpenWatcom license wars. I was actually referring to his idea of "making a tiny DOS that would only support the functions used by the compiler". So unless Smaller C eventually implements those 16-bit DOS extensions and compact model, it's probably not (easily) going to support rebuilding the FreeDOS kernel. Didn't DOS-C formerly use small model?

> > I do have my own tools to create a FAT12-formatted floppy and populate
> > it with files. But the idea of writing DOS batch files for this is
> > putting me off. :)
>
> What's the problem with .BATs? Too tedious? Anyways, I'm starting to wonder
> if makefiles (e.g. 16-bit port of Dmake) would be better (for testing).

.BATs are a bit too primitive to my taste and insufficiently standardized/
widespread. I wouldn't be able to use them under Linux, for example.
They'd have to be confined to DOS/Windows environment. Makefiles aren't
the best either. There are different makes and Windows doesn't provide
make out of the box.

> > Is the last commercial version of Watcom (10.x/11.x?) less buggy,
> > do you know? After all, it was Watcom with which a bunch of popular
> > games for DOS (e.g. Doom, Descent, etc) were compiled.
>
> I'm no expert, but I think those ancient versions are even worse. Even OW
> 1.4 (or 1.8) added and fixed lots of stuff. If anything, newer versions are
> probably regression-tested better than ever.

The kinds of bugs I've found in OW (and heard others stumble upon)
suggest that testing in OW is rather poor if existent at all. The OW's
very own website says that 3rd party commercial tests were lost in
transition of the project to open source. They couldn't be open sourced.

> > > Did any of this help? I feel like I just mostly rambled (again, sigh).
> >
> > Not really/not yet. :)
>
> I honestly don't know what you're trying to do here.

What do you mean by that?

> Sounds good. Though I'm not sure what advantages PKLITE has over UPX.

Probably none. Think of it as a recognizable brand name rather than
a specific .exe compressor.

> The problem with FASM (for 16-bit DOS target) is lack of OMF/OBJ support.

It is a problem to a degree. OMF/OBJ itself is a huge problem. It's an
overly complicated format that pretty much nobody implemented properly.
We may talk about conspiracy theories behind different OMF/OBJ tools
being incompatible with one another, but it's a too big and too quirky
thing to deal with.

My compiler's linker consumes ELF32 object files, no matter if it's 32-bit
code for Linux or for Windows or 16-bit code for DOS. NASM supports
16-bit relocations in ELF32 and that's all that's really needed.
Segments can be organized around that, if needed.

> And the problem with FreeDOS' kernel is reliance on quasi-standard 16-bit
> DOS-isms and (now) compact model.

Yeah, far pointers and such peering out of every corner. :)

> > What's the problem with .BATs? Too tedious? Anyways, I'm starting
> > to wonder if makefiles (e.g. 16-bit port of Dmake) would be better
> > (for testing).
>
> .BATs are a bit too primitive to my taste and insufficiently standardized/
> widespread. I wouldn't be able to use them under Linux, for example.
> They'd have to be confined to DOS/Windows environment. Makefiles aren't
> the best either. There are different makes and Windows doesn't provide
> make out of the box.

Then use pre-existing portable tools like GNU Make or OpenWatcom Wmake(r) or Dmake.

> The kinds of bugs I've found in OW (and heard others stumble upon)
> suggest that testing in OW is rather poor if existent at all. The OW's
> very own website says that 3rd party commercial tests were lost in
> transition of the project to open source. They couldn't be open sourced.

Maybe so, I don't know. I'd be surprised if they didn't glean a lot from other sources, esp. GCC. Dunno what tests they use currently. But be sure to try again with the latest unofficial build from a month ago.

> > > > Did any of this help? I feel like I just mostly rambled (again,
> sigh).
> > >
> > > Not really/not yet. :)
> >
> > I honestly don't know what you're trying to do here.
>
> What do you mean by that?

I thought you wanted help with running tests under emulators and extracting files from images. I don't know what else would apply here.

> > The problem with FASM (for 16-bit DOS target) is lack of OMF/OBJ
> support.
>
> It is a problem to a degree. OMF/OBJ itself is a huge problem. It's an
> overly complicated format that pretty much nobody implemented properly.
> We may talk about conspiracy theories behind different OMF/OBJ tools
> being incompatible with one another, but it's a too big and too quirky
> thing to deal with.

A few years ago, I already experienced a lot of that trying to use ancient Oberon-M 1.2 for DOS. We had a long thread about it here. That (freeware) compiler is very old (1991), back when DOS still came with LINK. Obviously various vendor extensions and adding 32-bit support threw a lot of wrenches into everything. I had to do a tiny hack myself to the resulting (main) .OBJ just to get it to work. Japheth did kindly patch JWlink for me. I tested a bunch of linkers: some worked, some didn't. It's definitely complicated. So I don't really blame you for using something else entirely.

Improvements:
- .bss section (smaller binaries)
- lifted limitations on string literal length (hooray!)
- better concatenation of adjacent string literals
(even across preprocessor directives)
- type specifiers may occur in any order
(e.g. "unsigned short int" and "int short unsigned")

> > .BATs are a bit too primitive to my taste and insufficiently
> standardized/
> > widespread. I wouldn't be able to use them under Linux, for example.
> > They'd have to be confined to DOS/Windows environment. Makefiles aren't
> > the best either. There are different makes and Windows doesn't provide
> > make out of the box.
>
> Then use pre-existing portable tools like GNU Make or OpenWatcom Wmake(r)
> or Dmake.

Well, I don't mean makefiles are perfect. Admittedly, I've only done semi-trivial ones, and the host OS shell is the main problem. Some makefiles rely way too heavily on host features, and it's admittedly not easy to avoid that.

Just for example, P5 Pascal 1.1 (bytecode compiler): he used many (DOS-unfriendly) .BAT and .SH files separately for his compilation and tests. Presumably that's the kind of duplication of effort which you're trying to avoid. I did myself write a simple GNUmakefile (only to use GPC, not IP) that did a subset of that. Hence I was able to build and test on DOS, Linux, and Windows (with a few macro substitutions). IIRC, I used DJGPP GNU Make 3.79.1, Lucid Puppy Linux's GNU Make 3.81, and FreePascal's GNU Make 3.80. (Yes, even FPC relies on makefiles sometimes.) EDIT: DJGPP /beta/v2gnu/ has mak40b.zip and mak41b.zip nowadays.

OpenWatcom's Wmake is also portable, and Wmaker (real mode) should work anywhere with any extender (in theory). Same with old 16-bit DOS build of Dmake. I've not really tested Dmake on Windows or Linux, but a quick search the other day did show that prebuilt binaries exist, at least for Windows, e.g. some old Perl version, even Apache OpenOffice (though I have no idea if they still actively use or maintain such build scripts).

A lot of people these days (besides ignoring DOS entirely) prefer more robust tools, almost scripting languages, like Cmake or Scons. Obviously GNU relies (too) heavily on Bash + POSIX utilities + AutoTools + GNU Make.

http://www.gnu.org/prep/standards/standards.html#Utilities-in-Makefiles

I guess there's not much else to say. You probably knew most of this. I just don't know what else to tell you. Nothing's perfect.

P.S. I was also (barely) going to suggest you look at Louis Santillan's picotap, but apparently he removed DOS support ("May revisit that later")! Dunno why. Maybe it was too kludgy. You'd have to email him. I still have his old .ZIP but never really used it. https://github.com/lpsantil/picotap

What's new in the compiler?
- DPMI support and DPMI binaries of the compiler itself
- linker bugfixes
- support for a.out (OMAGIC) executable format with relocation records
https://github.com/alexfru/SmallerC

Btw, if you're using NASM with Smaller C or alone, you may want to check out YASM. It's noticeably faster on large files than NASM (and you can just rename it to nasm.exe in order to use with Smaller C).

Alex

(BTW, sorry for procrastinating and not testing this sooner. You've done very good work!)

> I've added an option (-ppg) to smlrcc to invoke gcc as a preprocessor and
> included the va_* macros in stdarg.h.
> This should help until there's a decent preprocessor in Smaller C.
>
> It looks like DJGPP's gcc.exe works as well.

It looks like you're using "-nostdinc -isystem". Why not just use "-I" instead since it prepends your dir before searching the other typical standard system header places. (GCC online manuals): -I, -isystem

Also, you should probably also use "-U__GNUC__" since some macros may depend on it. (For instance, I was optionally using case ranges #if defined _GNUC__ || defined __TINYC__ , e.g. "case 'a' ... case 'z':".) In other words, if you don't do this and use GCC as preprocessor, SmallerC will choke on faulty code.

> (BTW, sorry for procrastinating and not testing this sooner. You've done
> very good work!)

Thanks! Nice to hear someone's at least trying it out. :)

> > I've added an option (-ppg) to smlrcc to invoke gcc as a preprocessor
> and
> > included the va_* macros in stdarg.h.
> > This should help until there's a decent preprocessor in Smaller C.
> >
> > It looks like DJGPP's gcc.exe works as well.
>
> It looks like you're using "-nostdinc -isystem". Why not just use "-I"
> instead since it prepends your dir before searching the other typical
> standard system header places. (GCC online manuals):
> -I,
> -isystem

Smaller C does not support all of the C language (that applies to the library as well) and the compiler proper uses a fixed amount of memory to keep track of declarations and symbols. It is unlikely that some random stuff pulled in from, say, DJGPP include directories (by mistake or intentionally) will do much good. So, the location of system headers is overridden to prevent mixing and matching system headers, especially while having these limitations.

> Also, you should probably also use "-U__GNUC__" since some macros may
> depend on it. (For instance, I was optionally using case ranges #if defined
> _GNUC__ || defined __TINYC__ , e.g. "case 'a' ... case 'z':".) In other
> words, if you don't do this and use GCC as preprocessor, SmallerC will
> choke on faulty code.

Maybe. Right now you can depend on __SMALLER_C__ for stuff that's intended for Smaller C and when it's not defined do something else for gcc or another compiler. Given the above limitations, you still pretty much have to write specialized code for Smaller C, in which case checking first for __SMALLER_C__ isn't that much different from checking for __GNUC__ and the like.

Thanks!

> Smaller C does not support all of the C language (that applies to the
> library as well) and the compiler proper uses a fixed amount of memory to
> keep track of declarations and symbols. It is unlikely that some random
> stuff pulled in from, say, DJGPP include directories (by mistake or
> intentionally) will do much good. So, the location of system headers is
> overridden to prevent mixing and matching system headers, especially while
> having these limitations.

Okay, makes sense, I had forgotten about that possibility.

> > Also, you should probably also use "-U__GNUC__" since some macros may
> > depend on it. If you don't do this and use GCC as preprocessor,
> > SmallerC will choke on faulty code.
>
> Maybe. Right now you can depend on __SMALLER_C__ for stuff that's intended
> for Smaller C and when it's not defined do something else for gcc or
> another compiler. Given the above limitations, you still pretty much have
> to write specialized code for Smaller C, in which case checking first for
> __SMALLER_C__ isn't that much different from checking for __GNUC__ and the
> like.

Well, I'm not sure why I ever (even optionally) used case ranges. It's trivial syntactic sugar, not very useful, the object code isn't any different/better, so I've removed it.

However, my trivial code doesn't need additional checks, everything so far works fine (since you've implemented most stuff already).

Anyways, FYI, I think -undef is more appropriate: "Do not predefine any system-specific or GCC-specific macros. The standard predefined macros remain defined."

> > Smaller C does not support all of the C language (that applies to the
> > library as well) and the compiler proper uses a fixed amount of memory
> to
> > keep track of declarations and symbols. It is unlikely that some random
> > stuff pulled in from, say, DJGPP include directories (by mistake or
> > intentionally) will do much good. So, the location of system headers is
> > overridden to prevent mixing and matching system headers, especially
> while
> > having these limitations.
>
> Okay, makes sense, I had forgotten about that possibility.
>
> > > Also, you should probably also use "-U__GNUC__" since some macros may
> > > depend on it. If you don't do this and use GCC as preprocessor,
> > > SmallerC will choke on faulty code.
> >
> > Maybe. Right now you can depend on __SMALLER_C__ for stuff that's
> intended
> > for Smaller C and when it's not defined do something else for gcc or
> > another compiler. Given the above limitations, you still pretty much
> have
> > to write specialized code for Smaller C, in which case checking first
> for
> > __SMALLER_C__ isn't that much different from checking for __GNUC__ and
> the
> > like.
>
> Well, I'm not sure why I ever (even optionally) used case ranges. It's
> trivial syntactic sugar, not very useful, the object code isn't any
> different/better, so I've removed it.
>
> However, my trivial code doesn't need additional checks, everything so far
> works fine (since you've implemented most stuff already).

I try not to use any compiler-specific extensions unless absolutely needed in the project.

> Anyways, FYI, I think
> -undef
> is more appropriate: "Do not predefine any system-specific or GCC-specific
> macros. The standard predefined macros remain defined."

I must've missed that option. I should've used it from the beginning. Thanks for mentioning it, I'll add it in one of the future versions.

What's new in the compiler?
- it can use FASM instead of NASM when compiling 32-bit protected
mode code (DOS/DPMI32, Windows, Linux)

There's now a wrapper around FASM, n2f.c, which if compiled into
nasm[.exe] will transparently convert the assembly code generated
by smlrc to the syntax and layout that FASM understands and invoke
FASM on it. A kind of NASM replacement/substitution. This tool
isn't general purpose, it converts only a very restricted subset of
assembly code from NASM syntax to FASM syntax and layout.

What does this mean? Well, for one thing, FASM is faster and
smaller than NASM, so you can make a floppy with the compiler
and the assembler and, say, DOS/DPMI32 library and you'll still
have about a half of the space free on the floppy. And you can
run this even in DOSBox without fearing that NASM would take
forever to assemble code with many jump instructions and without
having to give many many more CPU cycles to DOSBox.

Another thing is that this makes Smaller C fully and easily
portable to any x86 OS running apps in 32-bit protected mode.
Smaller C can fully recompile its libraries and itself if
there's NASM or YASM in your system. If porting NASM or YASM
is somehow problematic or undesirable, there's now another
option, FASM. FASM is written in 80386 assembly and can
recompile itself without needing any other tools. So, you
only need to teach FASM to use your OS syscalls and do the
same with the Smaller C library.

Alex

> Anyways, FYI, I think
> -undef
> is more appropriate: "Do not predefine any system-specific or GCC-specific
> macros. The standard predefined macros remain defined."

Works with MinGW gcc 4.8.2.

Doesn't work with DJGPP gcc 3.3.4 (no error, but __GNUC__ remains defined). Odd.

> > Anyways, FYI, I think -undef is more appropriate
>
> Works with MinGW gcc 4.8.2. Doesn't work with DJGPP gcc 3.3.4 (no error,
> but __GNUC__ remains defined). Odd.

DJGPP GCCs 3.4.6 and 4.9.1 worked fine for me. I don't know which versions would be wise to suggest that users rely upon anymore. Maybe 4.7.3 or 5.2.0 since those are latest for 2.03p2 and 2.04 (until 2.05 becomes /current/, which might honestly be any day now, dunno!).

> > > Anyways, FYI, I think
> -undef
> is more appropriate
> >
> > Works with MinGW gcc 4.8.2. Doesn't work with DJGPP gcc 3.3.4 (no error,
> > but __GNUC__ remains defined). Odd.
>
> DJGPP GCCs 3.4.6 and 4.9.1 worked fine for me. I don't know which versions
> would be wise to suggest that users rely upon anymore. Maybe 4.7.3 or 5.2.0
> since those are latest for 2.03p2 and 2.04 (until 2.05 becomes /current/,
> which might honestly be any day now, dunno!).

Yeah, I haven't updated mine for a long time (10 years?). I'm not doing much DOS programming these days. Anyway, I've included -undef in smlrcc.exe.

> > DJGPP GCCs 3.4.6 and 4.9.1 worked fine for me. I don't know which
> versions
> > would be wise to suggest that users rely upon anymore. Maybe 4.7.3 or
> 5.2.0
> > since those are latest for 2.03p2 and 2.04 (until 2.05 becomes
> /current/,
> > which might honestly be any day now, dunno!).

DJGPP 2.05 has indeed been officially released into /current/ (replacing both 2.03p2 and /beta/ 2.04), and latest GCC is 5.2.0 (but additionally a few others were also rebuilt: 4.9.3, 4.8.5, 4.7.4, 3.4.6).

> Yeah, I haven't updated mine for a long time (10 years?). I'm not doing
> much DOS programming these days. Anyway, I've included -undef in
> smlrcc.exe.

10 years ago is roughly when the 3.x series ended. I think it's fair to say that even 4.9.3 is barely maintained and will probably be soon dropped (once 4.9.4 and/or 6.0 are released).

Why am I wasting your time with this? Dunno!

P.S. For a laugh, check this out: movfuscator ("The single instruction C compiler")

> > > DJGPP GCCs 3.4.6 and 4.9.1 worked fine for me. I don't know which
> > versions
> > > would be wise to suggest that users rely upon anymore. Maybe 4.7.3 or
> > 5.2.0
> > > since those are latest for 2.03p2 and 2.04 (until 2.05 becomes
> > /current/,
> > > which might honestly be any day now, dunno!).
>
> DJGPP 2.05 has indeed been officially released into /current/ (replacing
> both 2.03p2 and /beta/ 2.04), and latest GCC is 5.2.0 (but additionally a
> few others were also rebuilt: 4.9.3, 4.8.5, 4.7.4, 3.4.6).
>
> > Yeah, I haven't updated mine for a long time (10 years?). I'm not doing
> > much DOS programming these days. Anyway, I've included -undef in
> > smlrcc.exe.
>
> 10 years ago is roughly when the 3.x series ended. I think it's fair to say
> that even 4.9.3 is barely maintained and will probably be soon dropped
> (once 4.9.4 and/or 6.0 are released).
>
> Why am I wasting your time with this? Dunno!
>
> P.S. For a laugh, check this out:
> movfuscator ("The
> single instruction C compiler")

FYI, gcc 4.8.4 is the current compiler in ubuntu 14.04.3. 4.8.x will likely be a compiler to support for 3 more years (2019/04) as 14.04 was an LTS release, enjoying 5 years total of support by Canonical. In reality, most people will move have moved to 16.04 or 18.04 by 2019.

> > 10 years ago is roughly when the 3.x series ended. I think it's fair to say
> > that even 4.9.3 is barely maintained and will probably be soon dropped
> > (once 4.9.4 and/or 6.0 are released).
>
> FYI, gcc 4.8.4 is the current compiler in ubuntu 14.04.3. 4.8.x will likely
> be a compiler to support for 3 more years (2019/04) as 14.04 was an LTS
> release, enjoying 5 years total of support by Canonical. In reality, most
> people will move have moved to 16.04 or 18.04 by 2019.

https://gcc.gnu.org/ml/gcc/2015-12/msg00054.html

"Yes, there will be another 4.9 release as well. Usually we close the 4.9
branch with a last release somewhen after GCC 6 is released."

That was my point, that 4.9.x is basically dead. It's not that some distros won't still use it, but that's not quite what I meant by "supported". There seems to be a mad rush to move to 5.x (and 5.3 was released today, although of course Debian presumably still hasn't migrated everything to 5.x yet).

It seems that MS Visual C is starting to use a new, improved optimizer.

https://blogs.msdn.microsoft.com/vcblog/2016/05/04/new-code-optimizer/

I mention this only because they mention fuzz testing with tools like Csmith, C-Reduce, Opt-fuzz, etc.

So maybe those tools could help you, too?

> It seems that MS Visual C is starting to use a new, improved optimizer.
>
> https://blogs.msdn.microsoft.com/vcblog/2016/05/04/new-code-optimizer/

It's probably time. OTOH, they write that they too are now abusing undefined behavior, e.g. signed integer overflows. Seems like they want to be as pseudo-effective as gcc and clang. I wonder how many teams are affected by that and how many have simply decided to disable the "helpful" feature instead of fixing the code. And some code has changed little since Windows 3.xx. Fun! :)

> I mention this only because they mention fuzz testing with tools like
> Csmith, C-Reduce, Opt-fuzz, etc.
>
> So maybe those tools could help you, too?

I know of the first two and it looks like the last one doesn't generate C code. Anyhow, I know most of the issues and I do have a bunch of tests (written by myself, borrowed or generated somewhat similarly to Csmith). The project has accumulated six issues on github in the past three years, of which only one was a bug (in the linker) and the rest were either questions or known/documented issues. There's one build issue on MacOS, the only open issue today. So, either nobody's using the project, or there aren't that many problems in it if people aren't reporting them. So, it looks like I should be OK w.r.t. bugs.

What I really (still!) need is a preprocessor. I like a lot the one from Plan9/LCC because it's complete, proven, small and even compiles as-is (the LCC variant) with Smaller C. I do not like its license, however. Others are either big or bad (rather incomplete, buggy, using functions that aren't in the C standard).

Btw, did I tell you that Smaller C has basic floating point support now?
In short:
- float and double are both 32-bit single precision
- ++, --, +=, -=, *=, /= aren't yet supported with floats
- floats not supported in *scanf() and there's no strtod(), atof() (but *printf() should just work with floats)
- most of ANSI C's <math.h> is in with some extras from C99

(I shouldn't probably mention on this forum that it can also make Windows GUI apps (there's a small clock demo for SDL2.dll))

Alex

> > I mention this only because they mention fuzz testing with tools like
> > Csmith, C-Reduce, Opt-fuzz, etc.
> >
> > So maybe those tools could help you, too?
>
> I know most of the issues and I do have a bunch of tests ...
> So, either nobody's using the project,

Sadly, some people have no imagination, certainly regarding DOS.

> or there aren't that many problems in it if people aren't reporting them.

Right, I didn't see any obvious errors. But my usage was far from expert anyways. Still, I've seen much worse compilers.

> So, it looks like I should be OK w.r.t. bugs.

Yes, I think you've already ironed out most obvious bugs. I just felt like mentioning it in the off chance that it would help iron out some more hidden cases (since no software is ever totally bug-free).

> What I really (still!) need is a preprocessor. I like a lot the one from
> Plan9/LCC because it's complete, proven, small and even compiles as-is (the
> LCC variant) with Smaller C. I do not like its license, however. Others are
> either big or bad (rather incomplete, buggy, using functions that aren't in
> the C standard).

Isn't ancient GCC 2.7's CPP fairly small? I imagine that would be (relatively) easy to port.

As for Plan9 license, what is wrong with it? AFAIK, it has changed several times, so it should be okay. Heck, I think they even dual-licensed to GPL recently.

Wikipedia says this:

> Starting with the release of Fourth edition on April 2002,
> the full source code of Plan 9 from Bell Labs was freely
> available under Lucent Public License 1.02, which is considered
> to be open source license by the Open Source Initiative (OSI),
> free software license by the Free Software Foundation, and it
> passes the Debian Free Software Guidelines.
>
> In February 2014, the University of California, Berkeley, has
> been authorized by the current Plan 9 copyright holder ?
> Alcatel-Lucent ? to release all Plan 9 software previously
> governed by the Lucent Public License, Version 1.02 under the
> GNU General Public License, Version 2.

You mention Plan9/LCC, but isn't LCC different? Plan9 has its own compiler. Though LCC does allegedly use dmr's CPP (or so I thought). Yeah, LCC license sucks.

I would even suggest (T)ACK, but I don't see a separate CPP binary there.
But it's BSD-ish and relatively simple. Maybe (BSD-ish) PCC? Theirs seems fairly small. Or even BCC/Dev86? Meh, dunno.

> > > I mention this only because they mention fuzz testing with tools like
> > > Csmith, C-Reduce, Opt-fuzz, etc.
> > >
> > > So maybe those tools could help you, too?
> >
> > I know most of the issues and I do have a bunch of tests ...
> > So, either nobody's using the project,
>
> Sadly, some people have no imagination, certainly regarding DOS.

My compiler targets Windows, Linux and RetroBSD as well, so, it's either the compiler or all four OSes. :)

> > or there aren't that many problems in it if people aren't reporting
> them.
>
> Right, I didn't see any obvious errors. But my usage was far from expert
> anyways. Still, I've seen much worse compilers.
>
> > So, it looks like I should be OK w.r.t. bugs.
>
> Yes, I think you've already ironed out most obvious bugs. I just felt like
> mentioning it in the off chance that it would help iron out some more
> hidden cases (since no software is ever totally bug-free).
>
> > What I really (still!) need is a preprocessor. I like a lot the one from
> > Plan9/LCC because it's complete, proven, small and even compiles as-is
> (the
> > LCC variant) with Smaller C. I do not like its license, however. Others
> are
> > either big or bad (rather incomplete, buggy, using functions that aren't
> in
> > the C standard).
>
> Isn't ancient GCC 2.7's CPP fairly small? I imagine that would be
> (relatively) easy to port.

I haven't seen it, but I have doubts.

> As for Plan9 license, what is wrong with it? AFAIK, it has changed several
> times, so it should be okay. Heck, I think they even dual-licensed to GPL
> recently.
>
> Wikipedia says this:
>
> > Starting with the release of Fourth edition on April 2002,
> > the full source code of Plan 9 from Bell Labs was freely
> > available under Lucent Public License 1.02, which is considered
> > to be open source license by the Open Source Initiative (OSI),
> > free software license by the Free Software Foundation, and it
> > passes the Debian Free Software Guidelines.
> >
> > In February 2014, the University of California, Berkeley, has
> > been authorized by the current Plan 9 copyright holder ?
> > Alcatel-Lucent ? to release all Plan 9 software previously
> > governed by the Lucent Public License, Version 1.02 under the
> > GNU General Public License, Version 2.

I didn't know about that. I have plan9.iso.bz2 downloaded in January 2015 from Lucent. It contains some files dated May 2014 (May > February!) and its only mention of GPL is with respect to printer fonts. Most of the thing is under Lucent Public License, Version 1.02 in there.

> You mention Plan9/LCC, but isn't LCC different? Plan9 has its own compiler.

The compiler proper is different. But the LCC authors borrowed the preprocessor from Plan9 and made a few relatively small changes (mostly cleaned it up and made ANSI C). In their LCC book they don't even describe the preprocessor, only mention its existence.

> Though LCC does allegedly use dmr's CPP (or so I thought). Yeah, LCC
> license sucks.

I wonder if the LCC guys would agree to explicitly license their version of the preprocessor as GPL as well (they don't have to, but it would be nice = less work for me or for someone else adapting the code again).

> I would even suggest (T)ACK, but I don't see a separate CPP binary there.

There was something I didn't like about ACK.

> But it's BSD-ish and relatively simple. Maybe (BSD-ish) PCC? Theirs seems
> fairly small.

It is. We use it in RetroBSD, but it has a few odd problems w.r.t. memory management / memory use. It also makes use of lex/yacc/whatever, which I'm not happy about either.

> Or even BCC/Dev86? Meh, dunno.

I wouldn't go there.

> > > What I really (still!) need is a preprocessor.
>
> > You mention Plan9/LCC, but isn't LCC different? Plan9 has its own
> compiler.
>
> The compiler proper is different. But the LCC authors borrowed the
> preprocessor from Plan9

Ah, I had forgotten (since I've never used Plan9) that they were a bit different. So yeah, perhaps by default they didn't need (or want) a "full" preprocessor, hence the POSIX environment add-on.

> > Though LCC does allegedly use dmr's CPP (or so I thought). Yeah, LCC
> > license sucks.
>
> I wonder if the LCC guys would agree to explicitly license their version of
> the preprocessor as GPL as well (they don't have to, but it would be nice =
> less work for me or for someone else adapting the code again).

Like I said, Plan9 is dual-licensed these days, so maybe it already is okay. But maybe not. Hopefully so, but then again, if LCC itself still (!) isn't OSI or FSF friendly, then it's unlikely they'll ever care.

Besides, if dmr had copyright on his cpp (and not AT&T or whomever), then you might be out of luck (since he died and copyright is notoriously broken regarding re-licensing after-the-fact).

> > I would even suggest (T)ACK, but I don't see a separate CPP binary
> there.
>
> There was something I didn't like about ACK.

Well, if the cpp isn't a separate utility, it's probably useless for your needs. But that one guy did finally make a new pre-release a week or so ago. The big change now is using ordinary makefiles (instead of Prime Mover [Lua]), maybe that's what you meant??

AFAIK, cpp evolved from m4, m3, and Kernighan's "macro" (Software Tools??). Though somehow I doubt any of those would help you much either. It can't be THAT hard (famous last words)!

> > > > What I really (still!) need is a preprocessor.
> >
> > > You mention Plan9/LCC, but isn't LCC different? Plan9 has its own
> > compiler.
> >
> > The compiler proper is different. But the LCC authors borrowed the
> > preprocessor from Plan9
>
> Ah, I had forgotten (since I've never used Plan9) that they were a bit
> different. So yeah, perhaps by default they didn't need (or want) a "full"
> preprocessor, hence the POSIX environment add-on.

I'm not sure what you're talking about. There's not much of POSIX in the preprocessor, just file handles and open()/read()/etc instead of FILE* and fopen()/fgetc()/etc, which is the easiest thing to clean up and standardize w.r.t. ANSI C. In terms of functionality there's almost no difference as far as I can tell by looking at the diff (most notably, wide chars, Unicode and variadic macros (..., __VA_ARGS__) have been removed). But it looks like they've done some valuable cleanup as well.

> > > Though LCC does allegedly use dmr's CPP (or so I thought). Yeah, LCC
> > > license sucks.
> >
> > I wonder if the LCC guys would agree to explicitly license their version
> of
> > the preprocessor as GPL as well (they don't have to, but it would be nice
> =
> > less work for me or for someone else adapting the code again).
>
> Like I said, Plan9 is dual-licensed these days, so maybe it already is
> okay. But maybe not. Hopefully so, but then again, if LCC itself still (!)
> isn't OSI or FSF friendly, then it's unlikely they'll ever care.

I don't think licenses can travel backwards and then forward again in time. The diff between LCC and Plan9 is not GPL'd.

> > > I would even suggest (T)ACK, but I don't see a separate CPP binary
> > there.
> >
> > There was something I didn't like about ACK.
>
> Well, if the cpp isn't a separate utility, it's probably useless for your
> needs. But that one guy did finally make a new pre-release a week or so
> ago. The big change now is using ordinary makefiles (instead of Prime Mover
> [Lua]), maybe that's what you meant??

Nopes. Just looked at it again. It needs additional tools to compile besides the C compiler.

Alex

> > Sadly, some people have no imagination, certainly regarding DOS.
>
> My compiler targets Windows, Linux and RetroBSD as well, so, it's either
> the compiler or all four OSes. :)

You've done a very impressive job, so if your compiler isn't being significantly tested by outside developers, then I blame them, not you. That's what I meant. Developers can be narrow-minded, stuck in their ways ("all the world's a VAX").

Plus I think a lot of projects are too non-portable (or at least haven't well isolated the system-specific stuff). That probably doesn't help.

> > Isn't ancient GCC 2.7's CPP fairly small? I imagine that would be
> > (relatively) easy to port.
>
> I haven't seen it, but I have doubts.

It's fairly small, but it too is probably very POSIX heavy (or maybe relies on other weird stuff, alloca??). Dunno, maybe a bad suggestion, I too haven't looked closely.

> I didn't know about that. I have plan9.iso.bz2 downloaded in January 2015
> from Lucent.

http://akaros.cs.berkeley.edu/files/Plan9License says this:

"The University of California, Berkeley, has been authorised by
Alcatel-Lucent to release all Plan 9 software previously governed by
the Lucent Public License, Version 1.02 under the GNU General
Public License, Version 2."

So if you're worried about licensing, use that version. It can't be much worse than LCC's fork, can it?

> > Ah, I had forgotten (since I've never used Plan9) that they were a bit
> > different. So yeah, perhaps by default they didn't need (or want) a
> > "full" preprocessor, hence the POSIX environment add-on.
>
> I'm not sure what you're talking about.

http://man.cat-v.org/plan_9/1/cpp

"The standard Plan 9 C compilers do not use cpp; they contain their own simple but adequate preprocessor, so cpp is usually superfluous."

http://plan9.bell-labs.com/sys/doc/comp.html

"The compilers include an integrated preprocessor that accepts the familiar #include, #define for macros both with and without arguments, #undef, #line, #ifdef, #ifndef, and #endif. It supports neither #if nor ##, although it does honor a few #pragmas. The #if directive was omitted because it greatly complicates the preprocessor, is never necessary, and is usually abused. Conditional compilation in general makes code hard to understand; the Plan 9 source uses it sparingly. Also, because the compilers remove dead code, regular if statements with constant conditions are more readable equivalents to many #ifs. To compile imported code ineluctably fouled by #if there is a separate command, /bin/cpp, that implements the complete ANSI C preprocessor specification."

> I don't think licenses can travel backwards and then forward again in time.
> The diff between LCC and Plan9 is not GPL'd.

How big a difference (and advantage) is it? Surely you can handle the original (worse code but better license).