Hi, On Mon, May 29, 2017 at 5:17 PM, Andreas K. Foerster <a...@akfoerster.de> wrote: > Am Samstag, dem 27. Mai 2017 schrieb Rugxulo: > >> >> > http://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. >> > I 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. >> >> > I 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.) > Note 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. > When 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.) > I 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. ;-) >> FreeDOS is open to accepting any Free (or OSI) software in its repos. >> It does welcome games now, so yes. >> >> > Well, 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 >> No, 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). > Actually 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.) > C 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. >> > Yes, 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. >> > And 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. ;-) > It 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). > On most systems gcc uses a different libc. I had weakly thought that most seemed to still use Glibc (outside of Alpine or whomever else). > And 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). > In 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). > The 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. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
