Am Montag, dem 22. Mai 2017 schrieb Rugxulo: > On Fri, May 5, 2017 at 12:33 PM, Andreas K. Foerster <a...@akfoerster.de> > wrote: > > > > I have written a small "four in a row" game. > > Some may know this game under the name "connect four", > > > > It's small and not very exciting, but maybe you DOS-people > > find it usefull. > > Useful? No. Entertaining? Yes. :-)
Thanks. Should I try to make it harder, or would it be too hard then? > > 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... I always wanted to make it as portable as I could. So I started with the most limited environment I could find. I also plan to maybe make graphical versions. Doing graphics with bcc could be very hard. There is no lib, yet. Would it be worth to try? Would you include it with FreeDOS? (I don't know if I can do it, I don't promise anything.) > > I'm always fascinated with small programs, small as can be. > > Then I came across Bruce's C compiler. I read it could cross-compile > > for DOS, but only up to 64kB. > > I think it's "small" memory model (64 kb code + 64 kb data/stack) but > indeed limited to 64 kb .COM output. Yes, but with the option -i you get the "tiny" model, where anything has to fit in that segment. I'm using that. 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. By the way, I haven't tried it on DOS yet, I use it as cross-compiler. > > My first thought was that this is very > > small... But then I thought, wait a minute... my very first computer > > only had 16kB of RAM. At that time 64kB wasn't considered small at all! > > 64 kb is indeed a lot of code ... but only in assembly. HLLs tend to > bloat up a lot more (esp. due to "dumb" linkers or big and complicated > functions like printf). Yes, note that I took great pains to avoid stdio completely. 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. And people too easily link to many libs. Dynamic linking hides all the big code away, but it's still all there and loaded... For example for writing screen oriented programs like mine, most people would use something like pdcurses or ncurses. Those libs alone are much larger than my programs are without them. Okay, if I needed really fancy stuff, I would use them too. They have their place, but not everything needs them. > > So, I started a journey to explore, what I could do with such an > > "enormous memory"... > > > > You should never judge a program by the size of the binary. > > Alignment also wastes a ton these days. People will tolerate huge > binaries in the vain hope of more speed. Alignment isn't much. And I think trading size for speed is legitimate. That's no waste. > (UPX, FTW!) Well, UPX made sense when we still used floppy disks... -- AKFoerster <https://AKFoerster.de/> ------------------------------------------------------------------------------ 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
