Hi,
Post by Andreas K. FoersterPost by RugxuloPost by Andreas K. FoersterPost by Andreas K. Foersterhttp://akfoerster.de/dl/akf-software/row4.zip
Please look for updates. I'm still working on it.
Though most work is for ports to other systems...
Yes, I see.
Post by Andreas K. FoersterPost by RugxuloPost by Andreas K. FoersterI always wanted to make it as portable as I could. So I started
with the most limited environment I could find.
I agree that portability is nice.
Post by Andreas K. FoersterI also plan to maybe make graphical versions.
Doing graphics with bcc could be very hard. There is no lib, yet.
Then use a different compiler for the (separate) graphical version.
OpenWatcom or DJGPP would be fine. (GRX? Allegro?)
No, that wouldn't be fun. ;-)
I still want to explore what is possible with those 64kB.
OpenWatcom (OSI) supports tiny model and has conio.h. You can always
support both compilers, if desired. And it does cross-compile from
many host OSes, including Windows or Linux.
(Apparently Mateusz's Sudoku86 uses Turbo C. Also a fun game with
graphics. Paku Paku used Turbo Pascal with lots of inline asm.)
Post by Andreas K. FoersterNote that bcc also had no code to support screen oriented programs.
I had to do that in assembly already. Meanwhile it can also do colors.
That's what I meant when I said, it could be usefull for others...
Look at the source code.
Yes, it's an interesting demo.
Post by Andreas K. FoersterWhen someone wants to integrate that with bcc, I'd be willing to
rerelease those parts under GPLv2+ and help ith the integration...
Dev86 isn't really actively maintained, certainly not for the DOS
target (nor the DOS-hosted versions). I did barely update the FDNPKG
package recently, but I didn't recompile anything (and mostly doubt
it'd work anyways). It's still a good compiler overall, but it's not
nearly perfect either.
AFAICT, the last release is 0.16.21 from 2014, updated by some other
dude (not by Robert de Bath anymore):
https://github.com/lkundrak/dev86/releases
I don't see any obvious releases for DOS. Heck, the 16-bit hosted
version available elsewhere is from 2002. (The 32-bit DJGPP versions
hosted on iBiblio were independently done by me and another dude circa
2012, and I didn't know what I was doing because it wasn't really
Canadian-cross friendly or whatever. You're on your own because nobody
else cared.)
Post by Andreas K. FoersterI think graphics should not be much harder. But I wouldn't want to
do it, if I have the impression, that no one will use it then...
I don't think many people use Dev86 at all, outside of that one dude
(Pelle) who reported a bug to us (mistakenly thinking that we maintain
it or know how). Even then, it was only because we had a package for
it.
It's still fairly good, but I don't actively recommend it over other
compilers unless bored, desperate, etc. ;-)
Post by Andreas K. FoersterPost by RugxuloFreeDOS is open to accepting any Free (or OSI) software in its repos.
It does welcome games now, so yes.
Post by Andreas K. FoersterWell, that compiler has many limitations and quirks.
I used it mainly to gain experience.
And it is, as far as I know, the only 16 bit compiler for x86 that is
free software.
Debatable. There are various toolsets out there. I'm not sure I can
even remember them all (much less tried them extensively, much less
know what I'm doing half the time).
Take a look at this, too, but don't get your hopes up too too high:
http://www.desmet-c.com/
SmallerC is also very good but 386+ only (despite huge model "-dosh",
among others):
https://github.com/alexfru/SmallerC
Post by Andreas K. FoersterPost by RugxuloNo, there are others (of varying quality). In particular, Free Pascal
(since v3) has supported i8086-msdos cross-target.
Pascal is a different language.
Yes, obviously, but it's still semantically similar (or better, even).
Post by Andreas K. FoersterActually I like Pascal, but I don't want to rewrite everything.
It's not that hard. And yes, I saw you had some Pascal experience.
http://akfquiz.akfoerster.de/akfquiz.en.html#pascal
(BWK was only half right about classic Pascal. And 90% of that was
already solved by Modula-2, even back in 1981. Of course Extended and
Turbo Pascals fixed most of it, too. And Knuth's TeX is a good example
of a non-trivial program that was very successful. I don't want to go
off on a tangent, but there's plenty to say about Pascal and
derivatives here.)
Post by Andreas K. FoersterC is much more widely supported.
Than FPC? Maybe in obscure hardware, yes, but FPC supports quite a lot
of cpus and OSes too.
I fully believe that using FPC is "better" than C. (Yeah right, that's
what they all say.) However, I'm not familiar enough with C++ to say,
but I think it's halfway equivalent, so it's not a bad choice over
that either.
Post by Andreas K. FoersterPost by RugxuloPost by Andreas K. FoersterYes, note that I took great pains to avoid stdio completely.
I don't think printf is the main problem here. But for other compilers
(OW or DJGPP), definitely yes. Still, if you don't need it, don't
require it.
Well, when you mentioned printf I thought you understood...
Actually not using it made the binaries with bcc several kilobytes
smaller. It's not, that it wasn't required. I had to write my own
function to print integers. And it's still several kilobytes
smaller. ;-)
I don't remember the size difference with Dev86. It was much more
noticeable with DJGPP and OpenWatcom than with, say, Turbo C. I've
written my own printf("%ld",blah) replacement, too.
And another guy wrote his own TinyStdio (not directly for DOS, but anyways):
https://github.com/DarkWishMaster/TinyStdio
Many FreeDOS utils also use prf.c to lighten the load.
Post by Andreas K. FoersterPost by RugxuloPost by Andreas K. FoersterAnd it's not dumb linkers, but dumb libraries, that use printf
and everything else internally. If everything depends on everything,
the linker can do nothing. Worst case: see glibc. Static linking with
glibc? Forget it. It always drags in nearly everything. And most
of it is never used.
There are other compilers that compile statically (e.g. (T)ACK or
OpenWatcom or FPC).
I think you are confused here.
Always. ;-)
Post by Andreas K. FoersterIt is not about the compiler, but about the glibc. The glibc is not a part of gcc.
Maybe not, but the "G" in "Glibc" stands for GNU, so they are
intrinsically connected. I know there are other clibs, but it's tricky
to support them all. Most distros assume Glibc by default (although
Musl has gained niche popularity in recent years).
Post by Andreas K. FoersterOn most systems gcc uses a different libc.
I had weakly thought that most seemed to still use Glibc (outside of
Alpine or whomever else).
Post by Andreas K. FoersterAnd also for Linux there are other libc's you can use with gcc.
But it's rarely by default, most use Glibc and can't change it (easily).
Post by Andreas K. FoersterIn fact gcc is pretty good in optimizing (djgpp is a different matter).
There is experimental COFF support for the --gc-sections, but that
won't (necessarily??) help with large library routines that weren't
well-designed for small size. (I tried to submit a patch for ctime.o
but got ignored. Yes, doprnt.o is very large these days.)
UPX is your friend with DJGPP (although checking the map file can help
identify problem areas, too).
Post by Andreas K. FoersterThe binaries for GNU/Linux in the package row4.zip are statically
linked with the diet libc. That is a libc that is optimized for
size to the extreme! It even warns you, when you use printf or
stdio. That's where I learned that trick.
https://www.fefe.de/dietlibc/
Yes I saw that, and yes I've heard of it, though I've never used it.
But I meant that, while unpopular, there are compilers for Linux that
support static linking (e.g. TACK, OW, FPC) with their own bundled
system libs. But static linking is not nearly as popular in Linux
circles as it is in DOS. Personally, I think that's a shame, some
utils are better static. Ten bazillion incompatible binaries isn't
wise, IMHO.