DOS ain't dead

> > Probably a dumb question, but should I join some FPC mailing list
>
> Not much point in it, unless you really build the IDE etc with it, and
> test it.

Er ... unlikely.

BTW, did you know RHIDE had an unstable Cygwin build? Old, though, 2003, probably not too useful.

> > Or are you forwarding the relevant info to them.
> > (E.g. GDB 6.8 builds with 2.04 only, 7.0-pre builds fine with 2.03p2.
>
> 7.0 final is out for ages?

Oops! Haven't heard anything from Eli. Guess he never finished or is just working on 7.1 now. I never heard from you either whether you had success about GDB or even contacted Eli or Andris. (Not that I'm anybody, just saying I'm out of the loop.)

> Btw, how does djgpp handle with the python and decimal support
> of 7.0? This optional stuff lead to problems on Linux
> with 7.0, since some enable it, and some not.

Dunno, haven't tried it. You'd have to ask Eli. IIRC, (I thought??) he implied it all worked okay for him at one time.

> > IIRC, FP.EXE uses GDB 6.2? Easier to build??)
>
> Those 6.2 libs are handpatched by a GDB coremember over several releases.
> The said GDB coremember used to be FPC coremember. IOW they are a
> stability island, but now with the move to dwarf we will have to move on
> sooner or later.

It's not that I care for old GDB in the IDE itself, but having 6.1.1 separately seems senseless when that's an easy "drop in" upgrade. But I guess you guys don't "need" it right now. (Andris' 6.8 supports --tui , though, which might be useful when used standalone.)

> > I was unable to build Watcom RTL, probably bitrotted a bit.
>
> No. It was only buildable by knowledgable people to begin with.

Such as who? It doesn't look like it works at all now.

> > Also -TWDOSX
> > never seemed to work, and I'm unable to figure out quickly how to
> enable
> > it.
>
> WDOSX is a bit HX like. A modification for the win32 target so that it is
> runnable on Dos, not a mod of the dos target.

I tried both DOS and Win32 versions of 2.4.0, and -Twdosx didn't work on either. Like I said, the Win32 output by default doesn't use relocs, and WDOSX always needs those for PE files.

> > Building the GO32V2 RTL
> > had various warnings (including the infamous "lcall indirect * blah"
> > crapola attributed to newer BinUtils). So I'm halfway guessing it could
> be
> > old code that expects older BinUtils.
>
> Hmm, that should be checked out.

Especially if it might be the causes of some of the regressions! (Same warnings in Quake, BTW, which is also pretty old code.)

> Since not used they are ancient, created with ancient procedures etc. Hope
> to upgrade some before 2.4.2.

But LD.EXE is indeed used in DOS 2.4.0, AS.EXE not. Hard to imagine somebody doesn't intend to make the internal linker support DOS too.

> > P.P.S. My comment about fpctris being bigger is wrong, I didn't use -Os
> > -CX -Oppentium -XXs. So it's about 65k, IIRC, before UPX (27k
> > afterwards??). However, since 1.0.10 is verboten, any size comparison
> is
> > moot anyways!
>
> Good. Don't forget to look at the author of that program

I did, but it still doesn't work (you can't actually play if lines don't disappear). Try it yourself if you don't believe me. (Install DOSBox if needed.) Or should I post a screenshot??

> > > The docs shrink to 6-10 MBish in CHM form.
> >
> > That would definitely be nice.
>
> I'll see if I can upload them (even if slightly corrupted) next weekend

Eheheh, corrupted? Wha?

> >(I guess you guys don't want to use
> > 7zdecode since it's not Pascal, only C. But AS and LD and GDB are C
> also,
> > so you aren't that stubborn.)
>
> I don't see what 7zdecode would be good for in this context. As far as I
> know 7zdecode is a decompressor for a solid archivetype, not a helpfile
> system.

Okay, obviously this has been mentioned before. 7-Zip compresses better than .ZIP. The INSTALL.EXE of FPC has built-in unzip, apparently. 7zdecode is ANSI C, easy to build with various compilers (I've done so). You could definitely write a FPC program using the C part as interface to 7Z/LZMA/LZMA2 files. And .7z files can indeed be semi-solid. Never mind, it's just a crazy idea to not have such big downloads. But I guess since separate files are (usually) provided for DOS anyways, it's no biggie. Just seems silly (to me) to use .ZIP when something else works better and is also portable.

Okay, obviously you don't care about this, I'm sorry I brought it up again.

> Yes. But now you managed to find a release that I even hate more than
> 1.0.10 (or well, actually I hate every older than 1.0.10 more than 1.0.10,
> but I hate 0.99.5 in particular
>
> > But I can't find that anywhere either.
>
> Keep it that way.

Uh ... if it works, even if slightly buggy, it's better than nothing. (And BTW Simtel still has fpc100.zip, ugh.) People still use BP7 / TASM / Vista / etc. despite outstanding bugs.

> No it is not that. In general the 1.0 and 2.0 are 5 years apart in one
> single blow, without any significant inbetween versions. There are 15000
> CVS commits inbetween, and heaps of stuff is changed. And most of it for
> the good, and with reason.
>
> If 2.4 is too big for some strange fruit kind of idiotic passtime, cut
> down 2.4 sources. Don't mess with older releases. Period.

I already figured that, but I kinda wanted to know what was expected, what worked before. Sometimes it's actually useful having old code to diff against to find bugs. I'm not saying 2.4.0 is hugely buggy, but ....

> > Well, AT2's examples were very heavily assembly-oriented, and ignoring
> the
> > useless MemAvail, the main problem was something like @POINTER[].
>
> That might not be a bug. It might be selecting the wrong compiler dialect
> mode.

Nope, changed that, didn't help.

> Modes TP and Delphi follow the borland way, the default(fpc) and
> objfpc modes require an extra disambiguating @ here and there.

Still annoying when old code breaks. (Apparently GPC 4.1.2 isn't against that either.) I understand it's often unavoidable, but it's still painful. I guess it's partly (mostly?) the AT2 guy's fault.

> > It was
> > geared only towards TMT (long gone)
>
> No still exists. Last release in 2007 or so, as "framework pascal". Even
> though there were releases after 2000, not much interesting happened
> though, afaik.

Latest TMT for DOS seems only available for "educational use", which means you can't sell or even redistribute anything made with it. And it's not free (no lite version either). They do seem to sell a Win32 and DOS combined version of "Framework", but the OS/2 and Linux ones are nowhere to be found. Similarly with Irie Pascal, the DOS version is gone (and price tripled, too).

> > IIRC, Quad (DOS) didn't work even in DOSBox, Mandel (Win32) stayed
> active
> > even when quit, had to be manually killed. So some of the examples need
> > revisiting.
>
> Definitely. They are not used much, since most people don't even bother
> with console or old-school graphic libs.

You do realize that having buggy examples is bad P.R., at the very least. I'm really not picking on you, but if they don't work, why include them???

> > Couldn't they borrow parts from GNU Pascal??
>
> GNU Pascal is general in worse state than FPC, and has much less
> code (the whole compiler is essentially a patch on gcc), so even if there
> were missing parts in FPC, you couldn't get much from GPC.

I meant mainly the Borland-compatible units they rewrote. Or is even that not compatible somehow?