On Wed, May 24, 2017 at 4:18 PM, Andreas K. Foerster <a...@akfoerster.de> wrote:
> 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?

As long as it isn't broken or cheating, then it's fine.
(Of course you could always add an Easy mode, if you think it'll
become too difficult.)

>> > 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 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?)

> 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.)

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.

No, there are others (of varying quality). In particular, Free Pascal
(since v3) has supported i8086-msdos cross-target.
(Although I'll admit I'm not familiar with the Graph unit or other

>> > 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.

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.

> 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).

> And people too easily link to many libs. Dynamic linking hides
> all the big code away, but it's still all there and loaded...

Linux is obsessed with that, yes. Ironically I think static binaries
are a good thing (most times). Obviously they disagree.

>> 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.

It's not much (if any) speed increase. And alignment can indeed waste
far too much, more than just a few kb. You have to be very very

>> (UPX, FTW!)
> Well, UPX made sense when we still used floppy disks...

Well, if you already have terabytes free and extremely fast Internet
speeds, then it doesn't matter as much. Otherwise, it's still good to
have (for various other reasons too).

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

Reply via email to