four in a row

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

four in a row

Andreas K. Foerster
Hello,

I have written a small "four in a row" game.
Some may know this game under the name "connect four",
however that name is trademarked.

It's small and not very exciting, but maybe you DOS-people
find it usefull.

http://akfoerster.de/dl/akf-software/row4.zip

Background:

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. 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!
https://archive.org/download/Commodore_C64_1984_Commodore_GB/Commodore_C64_1984_Commodore_GB.mp4
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.
In fact in the beginnig this program was actually larger with less
functionality, until I started to optimize it.

--
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: four in a row

Rugxulo
Hi,

(I'm late to reply to this, sorry!!)

On Fri, May 5, 2017 at 12:33 PM, Andreas K. Foerster <[hidden email]> 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.   :-)

> http://akfoerster.de/dl/akf-software/row4.zip
>
> Background:
>
> 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.

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

> 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. (UPX, FTW!)

> In fact in the beginnig this program was actually larger with less
> functionality, until I started to optimize it.

I don't know Forth, but I think it's the king of small code. There are
some insanely talented Forth developers, but indeed a lot of it is
very arcane and hard to use. Still, they seem to know all the tricks
in the book. They excel at cramming everything into one small
"kernel".

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: four in a row

Andreas K. Foerster
Am Montag, dem 22. Mai 2017 schrieb Rugxulo:

> On Fri, May 5, 2017 at 12:33 PM, Andreas K. Foerster <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: four in a row

Rugxulo
Hi,

On Wed, May 24, 2017 at 4:18 PM, Andreas K. Foerster <[hidden email]> wrote:

> Am Montag, dem 22. Mai 2017 schrieb Rugxulo:
>
>> On Fri, May 5, 2017 at 12:33 PM, Andreas K. Foerster <[hidden email]> 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
alternatives.)

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

>> (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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: four in a row

Andreas K. Foerster
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...
> >
> > 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.

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.

When someone wants to integrate that with bcc, I'd be willing to
rerelease those parts under GPLv2+ and help ith the integration...

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

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

Pascal is a different language.
Actually I like Pascal, but I don't want to rewrite everything.
C is much more widely supported.

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

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

> > 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. It is not about the compiler, but
about the glibc. The glibc is not a part of gcc. On most systems
gcc uses a different libc. And also for Linux there are other
libc's you can use with gcc. In fact gcc is pretty good in
optimizing (djgpp is a different matter).

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/

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

I am. ;-)

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

But it's not the kind of small that I mean.

When you compress with UPX the code has to be uncompressed each and
every time the program is started. So the code that needs to be
executed gets larger rather than smaller. That's how I see it.

Disk space is not so rare these days. You can get small USB-keys
or SD cards that have megabytes or even gigabytes of space.

In fact I often don't even strip the symbol table anymore. That
is not executable code and I don't know about other systems, but
on GNU/Linux it's not even loaded into RAM. It's just additional
information, and that's good. Those who are really low on disk
space can still strip it easily.

And most people don't understand the importance of distributing
source code. They are socialized on systems that don't do it.
So the source code can easily get lost. And then the symbol table
could be useful to those who want to analyze the program then.

Maybe UPX has a place in the world of IoT...?


Did you say Internet? When I put software on the Internet I compress
it with zip or gzip. You don't want to execute code directly over
the Internet, wouldn't you?

--
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: four in a row

Rugxulo
Hi,

On Mon, May 29, 2017 at 5:17 PM, Andreas K. Foerster <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: four in a row

Rugxulo
Hi again,

On Tue, May 30, 2017 at 12:18 PM, Rugxulo <[hidden email]> wrote:

>
> On Mon, May 29, 2017 at 5:17 PM, Andreas K. Foerster <[hidden email]> wrote:
>>
>>> > 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.

Here's what I had tested:

[ FreeDOS ] G:\TONY>sed -e "/LITE/,$!d" BCCDEV86.OUT
LITE     EXE         3,320  07-23-16 11:09p
PRINTF   EXE         4,332  07-23-16 11:09p
SCANF    EXE         4,868  07-23-16 11:09p
BOTH     EXE         5,880  07-23-16 11:09p

So roughly 2 kb isn't much savings (compared to 8 kb or 28 kb for others).

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: four in a row

Andreas K. Foerster
In reply to this post by Rugxulo
Am Dienstag, dem 30. 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.

Sorry for the late answer. But I worked on it further...

Now it is actually compilable with the version of bcc that comes
with FreeDOS. It has even more limitations, but nothing I
couldn't work around. However, no optimizations at all anymore.

Now it also has mouse support on almost all platforms.
For FreeDOS you must have ctmouse installed.

I've also separated the low level stuff for bcc into a separate
file and have put that under GPLv2 or later. So it can be
used for bcc or other projects.

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

The license of OpenWatcom is not accepted by the FSF.
That is important for me.

In that case I also think that maybe they are a little too pickey,
but I do respect their judgement.

> (Apparently Mateusz's Sudoku86 uses Turbo C. Also a fun game with
> graphics. Paku Paku used Turbo Pascal with lots of inline asm.)

And you included it in FreeDOS without recompiling it with a free
compiler? That's why you won't be accepted as a free distribution
for a long time. (I read some of that discussion in the archive.)

I'm not a part of that group, but I know how they're thinking.
And I agree with them most of the time.

Free software is not only about licenses. To be free you have to
be able to actually exercise the freedom. The freedom to make
changes to the source code is worth nothing without a compiler.
And it has to be a free compiler, otherwise you would again
give up your freedom... The system should be "self-hosting".
And it should not recommend unfree software (like compilers).

https://www.gnu.org/distros/free-system-distribution-guidelines

> 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

Thanks.
Maybe I'll contact them later.

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

Well, the programming language is largely a matter of taste.
And C++ is definetly something I don't like!
C is small and simple and you can do everything with it.
That's what I like about it.
In the end you cannot do more with C++, It's all just abstractions.

| It seems that perfection is attained not when there is nothing more to
| add, but when there is nothing more to remove.

    Antoine de Saint ExupĂ©ry, Ch. III: L'Avion, p. 60.

However I do admit that C is really dirty.

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

Well, it's not much, but it's noticable.
Floats are deactivated by default in bcc.
It's more with diet libc.

Sorry for deleting so much, but I don't want to go deeper into
those discussions...

--
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: four in a row

Rugxulo
Hi,

On Sun, Jun 4, 2017 at 5:02 PM, Andreas K. Foerster <[hidden email]> wrote:
> Am Dienstag, dem 30. 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...
>>
> Sorry for the late answer. But I worked on it further...

Added mouse, combined .de and .en, but you didn't use UPX-UCL! (Tsk tsk.)

> Now it is actually compilable with the version of bcc that comes
> with FreeDOS. It has even more limitations, but nothing I
> couldn't work around. However, no optimizations at all anymore.

"copt"[.exe] was missing (upstream) for the 16-bit DOS-hosted version.
Honestly, I doubt it improves much.

>> 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.
>
> The license of OpenWatcom is not accepted by the FSF.
> That is important for me.

Seriously, if you want good 16-bit support and have an irrational
hatred of OpenWatcom (OSI), then use Free Pascal's i8086-msdos
cross-target (all memory models except Huge, but see trunk). Hey, it's
way better than GCC anyways!    ;-)

>> 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
>
> Thanks.
> Maybe I'll contact them later.

Ask them to (Canadian?) cross-compile it for DJGPP:

https://github.com/andrewwutw/build-djgpp

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: four in a row

Rugxulo
In reply to this post by Andreas K. Foerster
Hi,

On Wed, May 24, 2017 at 4:18 PM, Andreas K. Foerster <[hidden email]> wrote:
> Am Montag, dem 22. 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 that you just updated again it two days ago! (Although I
haven't replayed it just yet.)

> Would you include it with FreeDOS?

As mentioned, if you want us to make a FDNPKG-compatible package for
the 1.2 repo, then we can do so. (Or did you have something else in
mind?)

But I don't know if you consider it "finished" or "stable" yet.

Just checking back with you because I don't want it to slip through
the cracks (as it always feels like we miss things).

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Loading...