DOS ain't dead

I did a very rough, preliminary cross-compile (using Ozkan's GCC 3.4.6 Linux to DJGPP cross-compiler build) of Dev86 0.16.18, and it appears to work (though a few utils didn't build and I didn't bother investigating as they weren't directly needed for compiling, e.g. nm86, size86, dis86). I haven't barely tested it, but it should work okay, or at least as good (or better??) than the older 16-bit DOS-hosted version of 0.16.2 on iBiblio. In particular, hopefully this one fixes some bugs and adds some stuff (e.g. unproto.exe and copt.exe without weird bugs), but I would appreciate anybody kicking the tires a bit more.

The main problem is that it's clearly very Linux-oriented build process, which I hate, but I've not had the patience to try to distill it to something more DOS-friendly just yet. So for now, hopefully this works okay, at least as good or better than the older DOS build.

A quick test shows it may not allow Linux-8086 target from DOS host (ld86 "-r" not supported?), but I don't know why. DOSELKS.COM (already on iBiblio) does mostly work, but I don't have any good examples for it. I thought I could build BWBasic, but that (even with 255-byte strings to fit in small data model) seems? to rely heavily on float FPU stuff, which Dev86 apparently lacks, so that's a bust. (And I don't think my silly B93 interpreter counts as interesting, oh well. I'm open to suggestions here.)

EDIT: Forgot to mention, for silly reasons, you can only unzip it to the root of the drive, e.g. "/dev86dj/", then you just put d:\dev86dj\bin in your %PATH% or whatever, and "bcc -v -O -ansi myfile.c -o myfile.com" should work okay.

You did not mention what you plan to do with DEV86-BCC-ELKS. I just want to mention that Nano-X had been ported to ELKS so FLTK and its applications could possibly work with ELKS.

> You did not mention what you plan to do with DEV86-BCC-ELKS. I just want to
> mention that Nano-X had been ported to ELKS so FLTK and its applications
> could possibly work with ELKS.

I don't know. I just know I had halfway built it with DJGPP before but never was confident enough in such configuration (and still am not, honestly). Having COPT and UNPROTO is an improvement over previous DOS version (plus bugfixes, allegedly better CPP, etc). Even a quick email (re: DJGPP build issues) to the maintainer years ago went unanswered (sigh). I just wanted a decent DOS-hosted build, though I know few use (or want) it on DOS when better alternatives exist (e.g. OpenWatcom). But, unless I'm mistaken, it only outputs .COM, so I don't know if that can (easily) even support small model (64k+64k) there, unless that for some reason means via the heap and not the executable image itself (hopefully).

The main point was DOS-hosted and DOS-targeted, but I was not opposed to supporting Linux/ELKS 16-bit output either. However, there must be some hardcoded stuff in the sources as it chooses which target based upon how you bootstrapped it (ugh). Hence by default on Linux it targets ELKS (for use with "elksemu") but on "MSDOS" it targets DOS. So "-Ms" doesn't quite do what I want on DOS/DJGPP host. I must be misunderstanding the man page (bcc.1) because "-Ms" is not vanilla ELKS output but "alters the arguments for all passes and selects C-library to produce standalone Linux-86 executables". In other words, -D__STANDALONE__ without any mention of __ELKS__ and chooses "-lc_s" instead of normal libc.a, so it whines about "undefined symbol: __mkargv". I don't know if this is for freehosting crapola or what. (This stuff really gets confusing fast, ugh.)

Long story short: you can apparently mostly build Linux/ELKS 16-bit a.out target from the DJGPP version, but I'm not sure of the "proper" way, so here's what I did semi-successfully:

bcc -s -O -ansi -Ms -v newbef93.c -U__STANDALONE__ -D__ELKS__ -D__unix__ /dev86dj/lib/bcc/libc.a -o b
(ignore spurious warnings about libc clashes, stupid "-lc_s" vs. "-lc")
doselks.com b guesswho.bef
(verbose but works)

P.S. There is also apparently the "-f" option to add float support, but I haven't tried rebuilding BWBasic again yet, and I'm not sure how well (if at all) floating point is supporting in the ELKS libc. Though I guess I could build something simpler like Chipmunk Basic (original from p2c) or such. Though it's moot, nobody but me cares, just curious to find good example of (potential, barely) real-world use.

> P.S. There is also apparently the "-f" option to add float support, but I
> haven't tried rebuilding BWBasic again yet

No, apparently it can't find libc+f.a [sic], which I'm not sure fully exists (or maybe only 386 target??? No, that's libfp.a, apparently, and isn't available in default builds). *shrug* Can't find any obvious mention of it otherwise.

Anyways, what I discovered is ...

"-Md" is for DOS .COM, which indeed is limited to 65000 byte size but BSS and stack can allegedly grow in RAM up to 64k beyond that.

"-Mn" is native 16-bit ELKS Linux a.out output for elksemu, doselks, etc.

"-Ml -N -3" seems to (except on DOS host) correctly produce a runnable 386 Linux binary, though trying to use it with -O clashes because it gets confused (rules.i386 [sic] not found). Also, at compile time, #ifdef MSDOS is used and thus it doesn't quite work cross-compiling from DOS/DJGPP because ld86 is always stripping the header. This seems to be due to weird understanding of -N ("native") and -d ("headerless output") where "native" means different things to different OSes (see ld/ld.c and ld/writex86.c). Honestly, it would've just been easier to my eyes to just name everything according to target OS, similar to OpenWatcom's -bt=dos or -bt=linux with -l=dos or whatever.

EDIT: "-Mn -3" doesn't strip the a.out header but instead gives it "Minix-386" properties, so it won't run in Linux. Argh.

"-Ms" is indeed "standalone" outputting a.out using BIOS calls only, and adding "-d" makes it headerless.

I've never rebuilt nor used bootblocks (nor used either as86 or ld86 elsewhere), so perhaps that's why I didn't understand the terminology used here.

And I'm still unsure of this stuff and my own understanding here, so I don't know, but at least it's something (I hope).

My understanding is that bcc uses no operating system calls but BIOS calls instead. Therefore it can be used to write operating systems in C, i.e. ELKS. This may explain the lacking libc.

I have to correct my last post: ELKS seems to support just bcc as a compiler for application development. So FLTK cannot be used since it and its applications are based on C++.

Georg

> My understanding is that bcc uses no operating system calls but BIOS calls
> instead. Therefore it can be used to write operating systems in C, i.e.
> ELKS. This may explain the lacking libc.
>
> I have to correct my last post: ELKS seems to support just bcc as a
> compiler for application development. So FLTK cannot be used since it and
> its applications are based on C++.
>
> Georg

You might think about Cfront for limied C++ support.

I doubt a bit that FLTK will compile with cfront.

Instead of bcc one could probably use TASK: TASK C compiler

But that is not C++.

Georg

> I doubt a bit that FLTK will compile with cfront.
>
> Instead of bcc one could probably use TASK:
> TASK C compiler

The compilers discussed here produce poorly optimized code. This must be pointed out. If someone needs a real "optimizing" compiler, they are not a choice.

---
Glory to God for all things

> > I doubt a bit that FLTK will compile with cfront.
> >
> > Instead of bcc one could probably use TASK:
> > TASK C compiler
>
> The compilers discussed here produce poorly optimized code. This must be
> pointed out. If someone needs a real "optimizing" compiler, they are not a
> choice.

I seriously doubt anything converted by Cfront would fit into a 64k .COM file, much less if combined with FLTK. Besides, Cfront 3.0 is pre-standard and lacks exceptions, apparently. But just for the record, you can find Cfront sources here. You'd probably have better luck porting to OpenWatcom, but DJGPP is good enough, so there isn't much need.

BTW, I think you meant (T)ACK, the Amsterdam Compiler Kit, and that was never ported to DOS host or target, that I know of anyways. I know Pat Villani ported it to Cygwin "host", but I never tested it. But yeah, that's a nice compiler, still very *nix specific, so it wouldn't be easy to bootstrap for DOS (at least without lots of tweaking, even with DJGPP). You'd have to do similar to what the Linux port did, add some stub functionality in the library and a quick converter to native DOS executable format. Either that or revive em44 intermediate code interpreter.

Re: optimizing compilers, BCC/Dev86 barely does anything, only simple peephole optimizations. Obviously it hasn't been updated much over the years, but at least it works somewhat well for what little it does. Better than nothing.

> BTW, I think you meant (T)ACK, the Amsterdam Compiler Kit, and that was
> never ported to DOS host or target, that I know of anyways. I know Pat
> Villani ported it to Cygwin "host", but I never tested it. But yeah, that's
> a nice compiler, still very *nix specific, so it wouldn't be easy to
> bootstrap for DOS (at least without lots of tweaking, even with DJGPP).
> You'd have to do similar to what the Linux port did, add some stub
> functionality in the library and a quick converter to native DOS executable
> format. Either that or revive em44 intermediate code interpreter.

Over the recent years, there's been some work on a new version 6.0 (it is licensed under the 3-clause BSD license), which as of yet allows creation of (Real 86 Mode, naturally) 8086 code or (only(?) 32-bit Protected Mode, I assume) 386 code out of the box, as far as I understand it. However, the former's only targeted platform is "pc86 (bootable floppy disk images)" (probably uses BIOS services?) and the latter's only one is "linux386 (ELF Linux executables)". The names of those formats are specified here: http://tack.sourceforge.net/about.html

It probably wouldn't require great amounts of effort to add a simple "dos86" platform sharing the i86 code generator; at first, this would minimally only have to create programs that are loadable as DOS executables*, which consider what resources (memory etc) they are provided by DOS, and which terminate the DOS process when they exit. It should also (allow) switch(ing) to DOS's I/O functions instead of the BIOS's (which as I noted I think it currently uses; it is a while ago that I skimmed the source), though that is not strictly necessary of course.

* Of course this could potentially be programmed to create .COM (flat) executables if the output is small enough, but .EXE (MZ header) executables are the more general case and additionally (seen strictly) require less run-time stack space validation if the header fields are correctly used to make DOS take care of insuring that enough stack space is available.

---
l

> Over the recent years, there's been some work on a new version 6.0 (it is
> licensed under the 3-clause BSD license), which as of yet allows creation
> of (Real 86 Mode, naturally) 8086 code or (only(?) 32-bit Protected Mode, I
> assume) 386 code out of the box, as far as I understand it. However, the
> former's only targeted platform is "pc86 (bootable floppy disk images)"
> (probably uses BIOS services?) and the latter's only one is "linux386 (ELF
> Linux executables)". The names of those formats are specified here:
> http://tack.sourceforge.net/about.html

Right, I think one guy (only?), David Given, had hacked on it for a few years to produce a slimmed 6.0 version that supported only like two or three targets and actually builds on modern *nix machines without weird kludges (though he now in 6.x uses a Lua builder, wha??). N.B. to Arjay, it also supports CP/M 8080, apparently.

But I think he barely has time for it anymore, and he kinda gave up (esp. his PPC port) as register-based is too clunky and bad for modern machines. So I dunno how much work is going in to it anymore (though he did, vaguely, update it once or twice in recent years. But the mailing list is a ghost town.)

I've vaguely used it atop PuppyLinux (and also in DOS-Minix), and it's a nice compiler with a few interesting frontends. I actually appreciate the pc and m2 compilers, but I suspect you only are interested in cc (and its libs). Well, we are mostly talking about 16-bit C for x86 FreeDOS here, so that's valid. But still, pc and m2 are good too. (There are other frontends supported too but much less tested and useful overall.)

> It probably wouldn't require great amounts of effort to add a simple
> "dos86" platform sharing the i86 code generator; at first, this would
> minimally only have to create programs that are loadable as DOS
> executables*, which consider what resources (memory etc) they are provided
> by DOS, and which terminate the DOS process when they exit.

The easiest thing would be to resurrect the em44 interpreter via DJGPP or such, but I've not tried. The next easiest would be to add a few stub functions to the library and allow cross-compiling for DOS. Of course, part of the problem is translating its quirky a.out variant to native DOS format(s). Or maybe BCC/Dev86's linker would (also) support it already? Dunno. (Minix used to use BCC.)

> It should also
> (allow) switch(ing) to DOS's I/O functions instead of the BIOS's (which as
> I noted I think it currently uses; it is a while ago that I skimmed the
> source), though that is not strictly necessary of course.

pc86 seems useless to me almost. If you can't even do file access, what can you do? Just bare computation? I know people complain that DOS is a glorified boot loader, but at least it (and BIOS) ease things tremendously over having to do it all from scratch. Besides, it's not like DOS is totally undocumented or obscure or anything (API -> RBIL), so it shouldn't (in theory) be hard to port (famous last words!!).

> * Of course this could potentially be programmed to create .COM (flat)
> executables if the output is small enough

I think its 16-bit output is separate I&D, i.e. tiny or small model only. In 16-bit Minix it actually shared code pages between background instances in order to save RAM. So I'm not sure how hugely useful the 16-bit compiler is unless you can live with that limitation. (Though 386 code has no such problems, assumedly.)

> , but .EXE (MZ header) executables
> are the more general case and additionally (seen strictly) require less
> run-time stack space validation if the header fields are correctly used to
> make DOS take care of insuring that enough stack space is available.

Yes, .EXE is probably more comfortable, though I don't think the binaries will be very big as it seems pretty efficient and the runtimes are pretty small too (smallest to largest output seem to be pc, cc, m2; see here for a few notes about ACK overall, mostly m2 related).

Just for fun, I built with DJGPP the new 0.16.19 version of Dev86. You may download the package from http://ompldr.org/vZmhveA. Comparing to Rugxulo's previous build, it is friendlier re: paths, and it correctly supports the "-Ml" and "-Mg" switches. The compiler defaults to "-Md". The source code for the package is available at http://ompldr.org/vZml3Ng.

---
Glory to God for all things

> Just for fun, I built with DJGPP the new 0.16.19 version of Dev86. You may
> download the package from http://ompldr.org/vZmhveA. Comparing to Rugxulo's
> previous build, it is friendlier re: paths, and it correctly supports the
> "-Ml" and "-Mg" switches. The compiler defaults to "-Md". The source code
> for the package is available at http://ompldr.org/vZml3Ng.

It does work better, yes, so thanks. (Better CPP, defines __STDC__ when "-ansi", also now supports ## token concatenation.)

But I don't have any great tests or anything. I doubt something like Lua (very strict ANSI!) will build with it. But it does work on my silly Befunge interpreter.

EDIT: I would really like to upload this to iBiblio for everyone (esp. FreeDOS), if you think it's stable enough.

> EDIT: I would really like to upload this to iBiblio for everyone (esp.
> FreeDOS), if you think it's stable enough.

I've had not too much time for testing, but it seems it does the job it was intended for. With apologies, personally I consider the DOS "community" to be one of the worst from such "communities".

---
Glory to God for all things

Hello ecm,

> It probably wouldn't require great amounts of effort to add a simple
> "dos86" platform sharing the i86 code generator; at first, this would
> minimally only have to create programs that are loadable as DOS
> executables*, which consider what resources (memory etc) they are provided
> by DOS, and which terminate the DOS process when they exit. It should also
> (allow) switch(ing) to DOS's I/O functions instead of the BIOS's (which as
> I noted I think it currently uses; it is a while ago that I skimmed the
> source), though that is not strictly necessary of course.

In case you would like to know: I have been trying to add an "msdos86" target for ACK --- with some success: https://github.com/davidgiven/ack/compare/default...tkchia:tkchia/msdos86 .

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> In case you would like to know: I have been trying to add an "msdos86"
> target for ACK --- with some success:
> https://github.com/davidgiven/ack/compare/default...tkchia:tkchia/msdos86
> .
>
> Thank you!

Interesting, thanks for the link!

---
l