DOS ain't dead

A release candidate for the next FPC version has been published (unfortunately this branch went into stabilization before Nikolay's many Graph fixes)

For Dos, atm there is no big zip, just separate zips:

ftp://ftp.freepascal.org/pub/fpc/beta/2.4.2-rc1/i386-go32v2/separate/

Enjoy

The Free Pascal Team

> A release candidate for the next FPC version has been published
> (unfortunately this branch went into stabilization before Nikolay's many
> Graph fixes)
>
> For Dos, atm there is no big zip, just separate zips:
>
> ftp://ftp.freepascal.org/pub/fpc/beta/2.4.2-rc1/i386-go32v2/separate/

I've been checking the front page occasionally every few days for a while now, so I'm surprised nothing was mentioned. Oh well.

Anyways, it seems a truly "minimal" install is this (actually, it's just what I grabbed, luckily it worked, couldn't find any more obvious install instructions):


aslddos.zip  1,031 KB   10/13/2010 12:50:00 PM
basedos.zip  4,960 KB   10/13/2010 12:50:00 PM
install.dat  25 KB      10/13/2010 12:51:00 PM
install.exe  367 KB     10/13/2010 12:51:00 PM


Works fine for my lame-o bef93.pas file. Of course, there's only one nitpick (aside from lack of install instructions ... I mean, I have fast internet but even I can't be bothered to download 1000 srcs for something I'll never recompile):

- old tools (AR, AS, LD, OBJDUMP, STRIP 2.17; CWSDPMI r5 2008)

Normally I wouldn't care, but I know I've mentioned this before (and edited the wiki). Heck, I've even recompiled BinUtils myself, so it's not like I couldn't do so again, but I guess FPC devs don't care. (Yes, these are the same broken-UPX'd binaries as before.) Worse is that AS probably isn't needed or used anymore (except in bootstrapping??), plus 2.19 should work now (didn't you guys already fix that?).

BTW, CWSDPMI r7 has been out since the beginning of the year, and I've mentioned it on several places too. CWS' standard site ("Clio", just tried yet again, still dead) has been down for a few months even, and I made sure to mention that too (in some places, even the Wikipedia article). So you can't even get anything from Clio even if you tried! The new (temporary??) site has been "Homer" for months now. r7 is even available (and offered by default now in Zip Picker) on every DJGPP mirror. It supports 4 GB and doesn't run out of base memory for page tables on > 512 MB machines, so you don't need weird workarounds like setting a swapping dir to a RAM drive.

http://homer.rice.edu/~sandmann/

ftp://ftp.delorie.com/pub/djgpp/current/v2misc/csdpmi7b.zip
ftp://ftp.delorie.com/pub/djgpp/current/v2misc/csdpmi7s.zip

http://djgpp.cybermirror.org/current/v2misc/csdpmi7b.zip
http://djgpp.cybermirror.org/current/v2misc/csdpmi7s.zip

> Anyways, it seems a truly "minimal" install is this (actually, it's just
> what I grabbed, luckily it worked, couldn't find any more obvious install
> instructions):

Instructions:
- download all
- run install.exe

> Works fine for my lame-o bef93.pas file. Of course, there's only one
> nitpick (aside from lack of install instructions ... I mean, I have fast
> internet but even I can't be bothered to download 1000 srcs for something
> I'll never recompile):

No problem. Don't expect us to support that kind of minimism though.

> - old tools (AR, AS, LD, OBJDUMP, STRIP 2.17; CWSDPMI r5 2008)
>
> Normally I wouldn't care, but I know I've mentioned this before (and edited
> the wiki). Heck, I've even recompiled BinUtils myself, so it's not like I
> couldn't do so again, but I guess FPC devs don't care. (Yes, these are the
> same broken-UPX'd binaries as before.) Worse is that AS probably isn't
> needed or used anymore (except in bootstrapping??), plus 2.19 should work
> now (didn't you guys already fix that?).

Well, afaik there were no reports of wide testing with the new tools, so I guess the mainteners stuck to known good versions.

> BTW, CWSDPMI r7 has been out since the beginning of the year,
[...]

Do you know who has extensively tested FPC with it ? (for more than a befunge interpreter?)

> Well, afaik there were no reports of wide testing with the new tools, so I
> guess the mainteners stuck to known good versions.

Wide testing??? Um, stable 2.4.0 didn't work with 2.19, so you can't test with that. So unless a ton of people tested the snapshots (obviously not), you won't bother?? Hooray!

EDIT: Well I thought you guys said you fixed it. Go figure, no it doesn't work (tested with AS and LD from DJGPP's 2.19). Gives a strange warning, still "compiles", but the .EXE is only 3 kb (obviously broken, normal is around 47 kb), and (obviously) doesn't run, causes an exception (XP Home SP3).

At the very least, as I've said before, you can't unpack these .EXEs, which means they will always run slower (2x ?) on XP's NTVDM than otherwise. There are other issues, but I can't remember offhand.

Note that I can (and will) rebuild BinUtils 2.17 (yet again) for you guys if you want, which should at least avoid any silly UPX problems. (BTW, since I didn't download the entire thing, you may wish to know that UPX 3.07 is latest. Haven't personally rebuilt that as UPX-UCL, only older 3.05, but since you never cared for using that instead anyways, I guess it's moot.)

> > BTW, CWSDPMI r7 has been out since the beginning of the year,
> [...]
>
> Do you know who has extensively tested FPC with it ? (for more than a
> befunge interpreter?)

Both CWS and I tested r7 with various things (non-FPC related) with DJGPP, and it works fine. (Rebuilt old DC:SS 0.5.x with it in pure FreeDOS on a 1 GB machine using 120 MB of RAM at compile time due to C++ optimizations.) It's pushed out by default by DJ himself on the Zip Picker in lieu of "old standard" r5. I'm not saying it potentially has no bugs, but since I've been using it exclusively on all my DOS setups for months, I haven't noticed anything obvious. I think CWS has declared it "stable". I mean, if you're really worried, include both r5 2008 and r7, they're small enough! (What's another 20 kb??)

r7 allows 4 GB (no, I've not tested that much yet, though I do have a 4 GB machine now, and PAQ8 will gladly oblige) without needing swapping for low page tables and is much faster due to 4 MB pages. But hey, why would you trust a DOS user about a DOS tool?

> At the very least, as I've said before, you can't unpack these .EXEs, which
> means they will always run slower (2x ?) on XP's NTVDM than otherwise.
> There are other issues, but I can't remember offhand.

IIRC, /beta/ (2.04) was 686+ only (and also UPX'd) while /current/ (2.03p2) was the one FPC currently uses (no pun intended). DJGPP never had 2.18 (nor 2.20 yet either).

> Note that I can (and will) rebuild BinUtils 2.17 (yet again) for you guys
> if you want, which should at least avoid any silly UPX problems.

Done. GCC 4.4.4, DJDEV 2.04, -mtune=i686 -O2 ... so it should be fast (in theory), esp. since no UPX/NTVDM slowdown.

P.S. I feel stupid mirroring source code that is already on a billion DJGPP mirrors, but for some oddball reason, the GPL thinks it should be hosted on the same server despite the fact that it's already "out there" in the wild. Worse since I didn't change anything, it's a completely stock build! Oh well.

http://rapidshare.com/files/425925780/fpc-bnu217-djgpp.tar.bz2 (.EXEs, 1 MB)
http://rapidshare.com/files/425926671/fpc-bnu217-src.tar.bz2 (srcs, 13 MB)

http://drop.io/fpc_bnu217_dos (has both)

> P.S. I feel stupid mirroring source code that is already on a billion DJGPP
> mirrors, but for some oddball reason, the GPL thinks it should be hosted on
> the same server despite the fact that it's already "out there" in the wild.
> Worse since I didn't change anything, it's a completely stock build! Oh
> well.

Ain't there GPL terms that allow you to delegate the hosting to someone else in such circumstances?

---
l

> Ain't there GPL terms that allow you to delegate the hosting to someone
> else in such circumstances?

Not that I know of.

> > Ain't there GPL terms that allow you to delegate the hosting to someone
> > else in such circumstances?
>
> Not that I know of.

Ah right. I read up on GPL stuff a bit. Then the only way for you to avoid distributing the source would be to not distribute binaries (only instructions on how to create them).

Or you could create a stripped-down version of the program which actually produces the same binaries, but strips anything from your source distribution that is superfluous to your build process for these binaries

---
l

> > > Ain't there GPL terms that allow you to delegate the hosting to
> someone
> > > else in such circumstances?
> >
> > Not that I know of.
>
> Ah right. I read up on GPL stuff a bit. Then the only way for you to avoid
> distributing the source would be to not distribute binaries (only
> instructions on how to create them).

It's not that I don't want to, but damn, Ubuntu's srcs is I forget how many gigabytes! I know it's 2010, but still, most free websites barely give you 100 MB (if even, and that's one thing I don't miss about dead Geocities, sheesh, talk about underpowered).

> Or you could create a stripped-down version of the program which actually
> produces the same binaries, but strips anything from your source
> distribution that is superfluous to your build process for these binaries
>

They don't allow obfuscation of sources. Never mind that most Bash/m4/C/C++/POSIX may as well be obfuscated for all most people know.

> It's not that I don't want to,

I hear you. It's kind of annoying that it requires you to mirror the exact same source, and isn't trivial as far as web hosting goes.

> They don't allow obfuscation of sources. Never mind that most
> Bash/m4/C/C++/POSIX may as well be obfuscated for all most people know.
>

Strip the documentation and other support files that ain't covered by GPL

---
l

> ... which should at least avoid any silly [older buggy] UPX problems.
> (BTW, since I didn't download the entire thing, you may wish to know that
> UPX 3.07 is latest. Haven't personally rebuilt that as UPX-UCL, only older
> 3.05, but since you never cared for using that instead anyways, I guess
> it's moot.)

Okay, yet another recompile for you guys to ignore. Best of all (sarcasm), it's free/libre (unlike traditional UPX since NRV is closed src). FSF approved, whee!

upx-uclx.zip
upx-ucls.zip

> > P.S. I feel stupid mirroring source code that is already on a billion
> DJGPP
> > mirrors, but for some oddball reason, the GPL thinks it should be hosted
> on
> > the same server despite the fact that it's already "out there" in the
> wild.
> > Worse since I didn't change anything, it's a completely stock build! Oh
> > well.
>
> Ain't there GPL terms that allow you to delegate the hosting to someone
> else in such circumstances?

The GPL says not at all to host. It says you must make available the source on request, against a nominal fee covering costs. Such nominal fee can be in the magnitude of $50. (since manhours count as cost and must also be covered)

So tarring the sources of the module that you changed (or diffs and the original archives) is enough.

So you put the diffs on your website and compy with the spirit. If some idiot knocks on your door and says "I don't want to apply the diffs etc, I want the orginals as required by GPL", you adhere to the letter of the GPL and burn a DVD with everything for $50. (not many will ask

>
> The GPL says not at all to host. It says you must make available the source
> on request, against a nominal fee covering costs. Such nominal fee can be
> in the magnitude of $50. (since manhours count as cost and must also be
> covered)

And speaking of licenses (not) ...

Did you know somebody ported the LZMA SDK to FPC? Yup. It's the old 4.42 version (LGPL), not newer public domain or anything, but that's no deal breaker, IMHO. From a quick glance, it seems to only be the actual stand-alone LZMA encoder/decoder tool (and related routines). Okay, I know I know, but still, in my perfect world, it could be used with FPC's installer, or even just in general.

But more importantly, here's the deal: comment out the requirement of the "windows" unit and comment out the benchmarking stuff too (since it relies on GetTickCount, which DOS doesn't have). Oh, and somebody (grumble grumble) hardcoded #10 for line ending (silly), change that to #13#10. It does compile and work with 2.4.0. However, it both compiles a lot faster (linking much??? wouldn't think so) and indeed runs a lot faster for the Win32 version of FPC here on XP/P4, dunno why. I'll be honest, I thought it (LZMAALONE.EXE) had hung, esp. for the DOS version. It doesn't print progress info, which is weird because I thought it should (with all the benchmarking bullcrap). I should really run it again and time it for you, but whatever. The point is that it does work! (Yes, I tried 2.4.2 first, but I'd really thought it had hung, kept trying, reverted to 2.4.0 to be safe, the program's just slow I guess. Worse is that I originally tried a much bigger file, heh, itself! Shame on me. Well, okay, not ready for prime time, but at least it functions correctly.)


REM ulzmabench.pas is 14 kb
lzmaalone e ulzmabench.pas tony.lzma
7za e tony.lzma
fc ulzmabench.pas tony /b
REM compares okay


EDIT: Compiles w/ 2.4.2 (DOS) in 9.5 secs, compression takes 3 min. 17 secs., comparison after unpacking still matches. (Note that this particular PC is very low on RAM, but that shouldn't? matter if default is 8 MB dictionary, right???) Oh, I used -XXs -CX -O3 -Oppentium4 (not that it helped, heh).

> EDIT: Compiles w/ 2.4.2 (DOS) in 9.5 secs, compression takes 3 min. 17
> secs., comparison after unpacking still matches. (Note that this particular
> PC is very low on RAM, but that shouldn't? matter if default is 8 MB
> dictionary, right???) Oh, I used -XXs -CX -O3 -Oppentium4 (not that it
> helped, heh).

No, something is definitely wrong with FPC for DOS. There is a serious regression somewhere (although it's in both 2.4.0 and 2.4.2rc1). It shouldn't be this much slower. The Win32 compiler can build and run lzmaalone.exe in less time than the DOS compiler can just (only) compile! My blind guess is that the RTL wasn't compiled with optimizations, but who knows. It's the same freakin' compiler version, it shouldn't behave this differently. (And yes, I compiled the exact same, slightly hacked, source code for each. And I tested on the same computer.) Heck, I even fiddled with the optimization options just in case that was affecting it, but no. Anyways, just FYI, this is not normal for a DOS compiler to be this much slower (if at all) than a Win32 one. Something has gone afoul. (BTW, I don't have older versions to test against. Ask Laaca, heh. Or maybe I'll grab 2.2.4 later, but somehow I doubt it would help. Oh well, just FYI, serious performance issue.)

And just for clarity, here's the (dumb) DOS-friendly patch:


diff -waur lzma442b.old/LZMAAlone.dpr LZMA.442b/LZMAAlone.dpr
--- lzma442b.old/LZMAAlone.dpr  2006-06-13 06:02:00 +0000
+++ LZMA.442b/LZMAAlone.dpr     2010-10-21 08:48:34 +0000
@@ -17,7 +17,7 @@
   URangeEncoder in 'compression\RangeCoder\URangeEncoder.pas',
   UBufferedFS in 'UBufferedFS.pas',
   ULZMAAlone in 'ULZMAAlone.pas',
-  ULZMABench in 'ULZMABench.pas',SysUtils;
+  {ULZMABench in 'ULZMABench.pas',}SysUtils;
 
 var lz:TLZMAAlone;
 
diff -waur lzma442b.old/ULZMAAlone.pas LZMA.442b/ULZMAAlone.pas
--- lzma442b.old/ULZMAAlone.pas 2006-06-13 06:04:58 +0000
+++ LZMA.442b/ULZMAAlone.pas    2010-10-21 08:49:16 +0000
@@ -6,7 +6,7 @@
 
 interface
 
-uses ULZMABench,ULZMAEncoder,ULZMADecoder,UBufferedFS,ULZMACommon,Classes;
+uses {ULZMABench,}ULZMAEncoder,ULZMADecoder,UBufferedFS,ULZMACommon,Classes;
 
 const kEncode=0;
       kDecode=1;
@@ -233,26 +233,26 @@
 procedure TLZMAAlone.PrintHelp;
 begin
 writeln(
-        #10'Usage:  LZMA <e|d> [<switches>...] inputFile outputFile'#10 +
-        '  e: encode file'#10 +
-        '  d: decode file'#10 +
-        '  b: Benchmark'#10 +
-        '<Switches>'#10 +
+        #13#10'Usage:  LZMA <e|d> [<switches>...] inputFile outputFile'#13#10 +
+        '  e: encode file'#13#10 +
+        '  d: decode file'#13#10 +
+        '  b: Benchmark'#13#10 +
+        '<Switches>'#13#10 +
         // '  -a{N}:  set compression mode - [0, 1], default: 1 (max)\n' +
-        '  -d{N}:  set dictionary - [0,28], default: 23 (8MB)'#10 +
-        '  -fb{N}: set number of fast bytes - [5, 273], default: 128'#10 +
-        '  -lc{N}: set number of literal context bits - [0, 8], default: 3'#10 +
-        '  -lp{N}: set number of literal pos bits - [0, 4], default: 0'#10 +
-        '  -pb{N}: set number of pos bits - [0, 4], default: 2'#10 +
-        '  -mf{MF_ID}: set Match Finder: [bt2, bt4], default: bt4'#10 +
-        '  -eos:   write End Of Stream marker'#10
+        '  -d{N}:  set dictionary - [0,28], default: 23 (8MB)'#13#10 +
+        '  -fb{N}: set number of fast bytes - [5, 273], default: 128'#13#10 +
+        '  -lc{N}: set number of literal context bits - [0, 8], default: 3'#13#10 +
+        '  -lp{N}: set number of literal pos bits - [0, 4], default: 0'#13#10 +
+        '  -pb{N}: set number of pos bits - [0, 4], default: 2'#13#10 +
+        '  -mf{MF_ID}: set Match Finder: [bt2, bt4], default: bt4'#13#10 +
+        '  -eos:   write End Of Stream marker'#13#10
         );
 end;
 
 procedure TLZMAAlone.Main;
 var params:TCommandLine;
     dictionary:integer;
-    lzmaBench:tlzmabench;
+//    lzmaBench:tlzmabench;
     inStream:TBufferedFS;
     outStream:TBufferedFS;
     eos:boolean;
@@ -265,14 +265,14 @@
     v:byte;
 const propertiessize=5;
 begin                         
-writeln(#10'LZMA (Pascal) 4.42 Copyright (c) 1999-2006 Igor Pavlov  2006-05-15'#10);
+writeln(#13#10'LZMA (Pascal) 4.42 Copyright (c) 1999-2006 Igor Pavlov  2006-05-15'#13#10);
 if paramcount<1 then begin
    PrintHelp;
    exit;
    end;
 params:=TCommandLine.Create;
 if not params.Parse then begin
-   writeln(#10'Incorrect command');
+   writeln(#13#10'Incorrect command');
    exit;
    end;
 if params.command=kBenchmark then begin
@@ -281,9 +281,9 @@
       dictionary:=params.DictionarySize;
    if params.MatchFinder>1 then
       raise Exception.Create('Unsupported match finder');
-   lzmaBench:=TLZMABench.Create;
-   lzmaBench.LzmaBenchmark(params.NumBenchMarkPasses,dictionary);
-   lzmaBench.Free;
+//   lzmaBench:=TLZMABench.Create;
+//   lzmaBench.LzmaBenchmark(params.NumBenchMarkPasses,dictionary);
+//   lzmaBench.Free;
    end
    else if (params.command=kEncode)or(params.command=kDecode) then begin
         inStream:=TBufferedFS.Create(params.InFile,fmOpenRead or fmsharedenynone);


> No, something is definitely wrong with FPC for DOS. There is a serious
> regression somewhere (although it's in both 2.4.0 and 2.4.2rc1). It
> shouldn't be this much slower. The Win32 compiler can build and run
> lzmaalone.exe in less time than the DOS compiler can just (only) compile!
> My blind guess is that the RTL wasn't compiled with optimizations, but who
> knows. It's the same freakin' compiler version, it shouldn't behave this
> differently.

I tried again, this time in native FreeDOS + HX, everything is fine, same (almost instantaneous) speed with each (DOS and Win32), even with copmressing the "bigger" .EXE itself. I have no idea what XP was doing wrong.

> I tried again, this time in native FreeDOS + HX, everything is fine



> I have no idea what XP was doing wrong.

Including NTVDM.EXE

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > I tried again, this time in native FreeDOS + HX, everything is fine
>
>

I knew you'd be thrilled.

> > I have no idea what XP was doing wrong.
>
> Including NTVDM.EXE

It's normally not this bad! It must just be my low-RAM computer (128 MB total, "designed for XP", ugh.) Since I don't have any other XP computers at the moment, I'll have to test at my aunts' soon (512 MB, whee!), so that should hopefully give better results.

> > Well, afaik there were no reports of wide testing with the new tools, so
> I
> > guess the mainteners stuck to known good versions.
>
> Wide testing??? Um, stable 2.4.0 didn't work with 2.19, so you can't test
> with that. So unless a ton of people tested the snapshots (obviously not),
> you won't bother?? Hooray!

I won't bother anyway. I'm not the dos platform maintainer (there isn't any, some people do fixes as they come by them, but that's it). Keep in mind that I'm here because of TUI interest, not dos in the strictest sense.

> EDIT: Well I thought you guys said you fixed it. Go figure, no it
> doesn't work (tested with AS and LD from DJGPP's 2.19). Gives a strange
> warning, still "compiles", but the .EXE is only 3 kb (obviously broken,
> normal is around 47 kb), and (obviously) doesn't run, causes an exception
> (XP Home SP3).

So the current ones work, the new ones are broken, and we received no fixes from interested Dos users. What could we do other than shipping the old ones?

> At the very least, as I've said before, you can't unpack these .EXEs, which
> means they will always run slower (2x ?) on XP's NTVDM than otherwise.
> There are other issues, but I can't remember offhand.

XP is not a target for the dos distribution. The Go32v2 target is meant for Dos and Win98. On NT systems, use the win32 or win64 distribution

> Note that I can (and will) rebuild BinUtils 2.17 (yet again) for you guys
> if you want, which should at least avoid any silly UPX problems.
> (BTW, since I didn't download the entire thing, you may wish to know that
> UPX 3.07 is latest. Haven't personally rebuilt that as UPX-UCL, only older
> 3.05, but since you never cared for using that instead anyways, I guess
> it's moot.)

Sure, if I have my way it disappears from the distro. Something everybody must decide for themselves, but I don't see a reason for FPC to package is (which sounds like a recommendation), and worse, to do version maintenance on it.

> > Do you know who has extensively tested FPC with it ? (for more than a
> > befunge interpreter?)
>
> Both CWS and I tested r7 with various things (

The trouble is that there is no group of heavy users for FPC/Go32v2 anymore that can validate any of such changes. And the current set IS validated by a set of users that used it every day.

> I won't bother anyway.

dumb

> I'm not the dos platform maintainer (there isn't any

wonder why

> some people do fixes as they come by them, but that's it).

not enough

> Keep in mind that I'm here because of TUI interest, not dos in
> the strictest sense.

good for you

> So the current ones work,

2.17, yes

> the new ones are broken,

2.19, yes ... or it could be FPC's fault, but I doubt it here

> and we received no fixes from interested Dos users

you don't NEED 2.19, just thought it would be better somehow, why slum it?

> What could we do other than shipping the old ones?

patch BinUtils or workaround it in FPC proper

> XP is not a target for the dos distribution. The Go32v2 target is meant for
> Dos and Win98. On NT systems, use the win32 or win64 distribution

dumb ... XP SP3 is still supported by MS, and NTVDM is dated 2008 ... and these UPX'd BinUtils have been proven to be 2x slower than unpacked (but you can't even unpack these particular ones!!)

> Sure, if I have my way it disappears from the distro. Something everybody
> must decide for themselves, but I don't see a reason for FPC to package is
> (which sounds like a recommendation), and worse, to do version maintenance
> on it.

Anybody who wants it probably already has it. I just thought that, as long as you had it, you might want latest / free-est, etc. Guess not. (dumb ... and it was handed to you on a silver platter, sheesh)

> > Both CWS and I tested r7 with various things (
>
> The trouble is that there is no group of heavy users for FPC/Go32v2 anymore
> that can validate any of such changes. And the current set IS validated by
> a set of users that used it every day.

obviously not ... and you are clearly not the person to tell ... if all the FPC developers are this stubborn, they deserve whatever scorn they get, it's just dumb to ignore clear improvements from the obvious target audience

And just for clarity, like I said, if you're that paranoid, include r5 AND r7 ... but if you think 2x slower speed and/or swapping due to low space for page tables on 1 GB RAM machines is rare, then you're lying to yourself. Do you want GO32V2 to die? Does it really offend you that much? Then surely you're at the wrong message board.

I was going to benchmark rebuilding the compiler for you, but it's far from obvious how to do that from a DOS-hosted FPC compiler. Maybe I did it wrong, but I suspect nobody tries (re)building with the DOS-hosted version.

> > So the current ones work,
>
> 2.17, yes
>
> > the new ones are broken,
>
> 2.19, yes ... or it could be FPC's fault, but I doubt it here

Or a mix.

> > and we received no fixes from interested Dos users
>
> you don't NEED 2.19, just thought it would be better somehow, why slum it?

I don't slum it. You were asking why the new release didn't have it, I told you why. Period.

> > What could we do other than shipping the old ones?
>
> patch BinUtils or workaround it in FPC proper

As said, nobody is working on Dos anymore.

> > XP is not a target for the dos distribution. The Go32v2 target is meant
> > Dos and Win98. On NT systems, use the win32 or win64 distribution
>
> dumb ... XP SP3 is still supported by MS, and NTVDM is dated 2008 ... and
> these UPX'd BinUtils have been proven to be 2x slower than unpacked (but
> you can't even unpack these particular ones!!)

We have never supported, not even win2000 or NT4. It is not a new policy.

> Anybody who wants it probably already has it. I just thought that, as long
> as you had it, you might want latest / free-est, etc. Guess not. (dumb ...
> and it was handed to you on a silver platter, sheesh)

...

> And just for clarity, like I said, if you're that paranoid, include r5
> AND r7 ... but if you think 2x slower speed and/or swapping due to
> low space for page tables on 1 GB RAM machines is rare, then you're lying
> to yourself. Do you want GO32V2 to die? Does it really offend you that
> much? Then surely you're at the wrong message board.

You want it, you got it. You have been just named Dos maintainer. Please have the final release ready by next week

Today I finally downloaded new FPC build. In first run it behaved extremely unstable. I don't know why but probably it was not related to FPC because after restart everything worked better.

The positive is that all demos finally work "from the box". There is no more needed setting for unit paths. It is good.

In GUI I found an annoying regression. If I go into "options" - "environment" - "preferences" and there change the screen resolution (f.e. 80x50) it fails with error message.
However if this videomode is specified in FP.CFG (or FP.INI, I am not sure) it starts normally.

And I think it is time to add the colorsel unit into FV to be possible to change colors in IDE (the default ones I don't like at all)

---
DOS-u-akbar!

> You want it, you got it. You have been just named Dos maintainer. Please
> have the final release ready by next week

No thanks. You don't want help, you don't get it. Just don't complain how nobody offers.

> You want it, you got it. You have been just named Dos maintainer. Please
> have the final release ready by next week


November 12th, 2010 A new release 2.4.2 is available from our sites. 2.4.2 is the first fixes release from the 2.4 series. Improvements, amongst others:

    * Delphi 2006 like for..in support
    * Support for sealed and abstract class modifiers,
    * new targets
          o 64-bit FreeBSD (x86_64)
    * Many improvements and fixes to the XML, database and CHM packages
    * Long term bug in OS/2 implementation of unit Video finally fixed which among others allows inclusion of the text-mode IDE (without debugger) for this platform as part of the distribution again.
    * Many compiler bugfixes and more than half an year of library updates (since 2.4.0)

Downloads are available from the download page (mirrors should follow soon).
A list of changes that may require changes to existing code is available here.


> > > Do you know who has extensively tested FPC with it ? (for more than a
> > > befunge interpreter?)
> >
> > Both CWS and I tested r7 with various things (
>
> The trouble is that there is no group of heavy users for FPC/Go32v2 anymore
> that can validate any of such changes. And the current set IS validated by
> a set of users that used it every day.

Please be aware that this is NOT obvious to people who don't use DOS! It will bite someone who is unaware, hence it is NOT something to be ignored or else the innocent end user will suffer (or complain or walk away). It doesn't matter that there is no DOS maintainer, I'm telling you point blank about this for your users' benefit.

r5 is good but cannot work as well on high-RAM machines as r7. It only handles max. 2 GB real RAM and 2 GB swap, but it's 2x slower. Plus, you have to swap somewhere for > 512 MB machines or else it won't work at all (4 kb pages instead of 4 MB, and it uses low RAM used to hold page tables or whatever). I'd consider that "solution" a hack and inconvenient. (Hmmm, maybe I should've swapped to RAM disk with r5 just to prove to you how much slower it is.) It wasn't a problem when nobody had that much RAM, but nowadays all computers come with much more.

For example, since this is apparently too arcane for you, here's my new 4 GB Dell laptop booted via USB floppy drive with FreeDOS. The only active DOS drives are A:\ (floppy) and G:\ (RAM disk). In other words, the default C:\ drive doesn't exist (or isn't FAT, so DOS can't read it, in this case), so it can't swap there. By default I bound r7 to the actual .EXE so that nobody would have to accidentally use an older copy (r5).


[ FreeDOS ] G:\>cwsdpmi5        (load for a single program execution)

[ FreeDOS ] G:\>paq8o8z -7 doydoy7a *.cpp
Warning: cannot open swap file c:\cwsdpmi.swp

paq8o8z compiled Jan 13 2010 by DJGPP 2.04 / G++ 4.4.2 for FreeDOS (i686-tuned)

2134831104 bytes DPMI available

CPUID? yes, MMX or SSE2? yes yes, using SSE2

Creating archive doydoy7a.paq8o8z via level 7 with 1 file(s)...
paq8o8z.cpp 153786 -> No swap space!

[ FreeDOS ] G:\>paq8o8z -7 doydoy7b *.cpp    (use CWSDPMI r7)
Warning: cannot open swap file c:\cwsdpmi.swp

paq8o8z compiled Jan 13 2010 by DJGPP 2.04 / G++ 4.4.2 for FreeDOS (i686-tuned)

CPUID? yes, MMX or SSE2? yes yes, using SSE2

Creating archive doydoy7b.paq8o8z via level 7 with 1 file(s)...
paq8o8z.cpp 153786 -> 32884
153786 -> 32918
Time 13.74 sec, used 803156196 bytes of memory

[ FreeDOS ] G:\>paq8o8z -8 doydoy8 *.cpp  (use > 1 GB of RAM)
Warning: cannot open swap file c:\cwsdpmi.swp

paq8o8z compiled Jan 13 2010 by DJGPP 2.04 / G++ 4.4.2 for FreeDOS (i686-tuned)

CPUID? yes, MMX or SSE2? yes yes, using SSE2

Creating archive doydoy8.paq8o8z via level 8 with 1 file(s)...
paq8o8z.cpp 153786 -> 32883
153786 -> 32917
Time 14.07 sec, used 1574908133 bytes of memory


P.S. To anybody who cares, I'm 99% sure that -9 doesn't work at all anyways, but that's a bug in the original PAQ, possibly fixed for paq8px (Jan Ondrus?) or some other similar variant, but I forget exactly. To do a proper benchmark, I'd have to test against enwik8 or enwik9, but I don't have a FAT partition available (yet). Well, I guess I could make a liveCD image, but I don't think most people would be interested, even Matt (he's moved on to zpaq, which, for lack of any real reason, I haven't messed with yet).

> > The trouble is that there is no group of heavy users for FPC/Go32v2
> anymore
> > that can validate any of such changes. And the current set IS validated
> by
> > a set of users that used it every day.
>
> Please be aware that this is NOT obvious to people who don't use DOS! It
> will bite someone who is unaware, hence it is NOT something to be ignored
> or else the innocent end user will suffer (or complain or walk away). It
> doesn't matter that there is no DOS maintainer, I'm telling you point blank
> about this for your users' benefit.

IMHO it is useless bitching, since as said there is nobody to pass this on to.

There are a couple of loose end leads like you provide, but nobody that uses it in day to day usage (building up some experience), who is to integrate these.

> be
> > in the magnitude of $50. (since manhours count as cost and must also be
> > covered)
>
> And speaking of licenses (not) ...
>
> Did you know somebody ported the
> LZMA SDK to
> FPC? Yup. It's the old 4.42 version (LGPL), not newer public domain or
> anything, but that's no deal breaker, IMHO. From a quick glance, it seems
> to only be the actual stand-alone LZMA encoder/decoder tool (and related
> routines). Okay, I know I know, but still, in my perfect world, it could be
> used with FPC's installer, or even just in general.

As you already noticed, there are more pressing concerns than vary compression of the release ad infinitum to squeeze out some more bytes.

In last few months I more work on machine with 512MB RAM and FreeDOS installed and I have to confirm the lost of performance in Freepascal IDE after few compilation. (after few compilations is another compilation very slow and hard disk is still accessed).
Firstly I thought that problem is in my disk cache but it helped when I swithed from cwsdpmi r5 into cwsdpmi r7.
(however best speed is with some nonswapping DPMI server - but it can't be generaly recomended at all - some swapping is sometimes necessary)

So - I vote for switching into cwsdpmi r7 in official distributions.

---
DOS-u-akbar!

> In last few months I more work on machine with 512MB RAM and FreeDOS
> installed and I have to confirm the lost of performance in Freepascal IDE
> after few compilation. (after few compilations is another compilation very
> slow and hard disk is still accessed).
> Firstly I thought that problem is in my disk cache but it helped when I
> swithed from cwsdpmi r5 into cwsdpmi r7.
> (however best speed is with some nonswapping DPMI server - but it can't be
> generaly recomended at all - some swapping is sometimes necessary)
>
> So - I vote for switching into cwsdpmi r7 in official distributions.

In fairness, marcov is not the DOS maintainer, doesn't use DOS, and he has enough to do (work, FreeBSD, updating FPC mirrors).

But it does seem silly. It's like me saying "8.3 is good enough" (which it is), but nobody wants to use that when LFNs are available, certainly not marcov. But I guess it's easy to marginalize DOS when there are very few "GO32v2" users. Perhaps some of us need to benchmark build times with r5 vs. r7 (or even vs. HDPMI32). As for swapping, you can disable it (-s- or permanently via CWSPARAM or just use CWSDPR0).

> > Did you know somebody ported the
> > LZMA SDK
> > to FPC? Yup. It's the old 4.42 version
>
> As you already noticed, there are more pressing concerns than vary
> compression of the release ad infinitum to squeeze out some more bytes.

Well, you were the one saying the blocker for upgrading the installation process was that "nobody had done the work, and it needs to be written in Pascal". Besides, guess what? Even your friends use it.


> FreeBSD 8.1-RELEASE Release Notes
> =================================
> The liblzma library for LZMA2 lossless data compression algorithm
> and the userland utilities xz(1), xzdec(1), lzma(1), and lzmainfo(1).
> has been imported.

> >
> > So - I vote for switching into cwsdpmi r7 in official distributions.
>
> In fairness, marcov is not the DOS maintainer, doesn't use DOS, and he has
> enough to do (work, FreeBSD, updating FPC mirrors).
>
> But it does seem silly. It's like me saying "8.3 is good enough" (which it
> is),

(not for me)

> but nobody wants to use that when LFNs are available, certainly not
> marcov.

I don't care about SFN, as long as such problems of the dosport don't effectively limit other platforms. And it is the problem of the dosport maintainers to find solutions to do so.
(just like amiga volume support is a problem of the Amiga people, and symlinks for Unix people. (well, Vista+ has symlinks, but that hasn't really sunk in yet)

> But I guess it's easy to marginalize DOS when there are
> very few "GO32v2" users.

There is no marginalization. The point is and was that the Dos platform currently doesn't hold up its own belt. Be it with testers, developers or release maintainers. Other people (specially Tomas and Pierre) do some charity work now and then, and that's it.

> Perhaps some of us need to benchmark build times
> with r5 vs. r7 (or even vs. HDPMI32). As for swapping, you can disable it
> (-s- or permanently via CWSPARAM or just use CWSDPR0).

I think the main question would be to test if cwsdpmi is stable and compatible and if a default install works with all places where dos binaries can be run. Speed is secundary only, since people that need the extreme can always downgrade to R7.

The textmode IDE is probably one of the most demanding apps.

> I think the main question would be to test if cwsdpmi is stable

No, I do not consider any CWSDPMI release stable.

> and
> compatible and if a default install works with all places where dos
> binaries can be run.

Yes, because CWSDPMI is used by everyone and their DJGPP.

> Speed is secundary only, since people that need the
> extreme can always downgrade to R7.

Downgrade? I suddenly think I don't understand what (both of) you are talking about. (What DPMI server/release is shipped by default if CWSDPMI r7 is a downgrade?)

> > I think the main question would be to test if cwsdpmi is stable
>
> No, I do not consider any CWSDPMI release stable.

Hahaha, relative to the current r5 distro, and relative to the number of bugs posted about it in FPC bugtracker now (read: zero)

> > and
> > compatible and if a default install works with all places where dos
> > binaries can be run.
>
> Yes, because CWSDPMI is used by everyone and their DJGPP.

That is inconclusive. FPC is independant of DJGPP, and might use a different subset.

> > Speed is secundary only, since people that need the
> > extreme can always downgrade to R7.

> Downgrade? I suddenly think I don't understand what (both of) you are
> talking about. (What DPMI server/release is shipped by default if CWSDPMI
> r7 is a downgrade?)

Downgrade to r5, my mistake.

Anyway, I'll make a remark to the OS/2 maintainer who cobbles up the Dos releases if nobody else does, and then it is his call.

> > > Did you know somebody ported the
> > > LZMA SDK
> > > to FPC? Yup. It's the old 4.42 version
> >
> > As you already noticed, there are more pressing concerns than vary
> > compression of the release ad infinitum to squeeze out some more bytes.
>
> Well, you were the one saying the blocker for upgrading the installation
> process was that "nobody had done the work, and it needs to be written in
> Pascal".

That is true. So where is the tested LZMA installer?

> Besides, guess what? Even your friends use it.

Probably somebody submitted it to them then :)

> Hahaha, relative to the current r5 distro, and relative to the number of
> bugs posted about it in FPC bugtracker now (read: zero)

Why would I spam CWSDPMI bugs in your tracker?

I know (and reported) some of its shortcomings/bugs, though most of them are related to DOS process stuff. More importantly, some DPMI things are done so poorly that it might stab you (FPC) in the back if you (FPC) deviate(s) from DJGPP's DPMI subset. (I am not aware of any issues new to r7 though. Edit: None of my bugs were addressed by r7, either. In fact, I reported them recently when r7 was already out. There's no upcoming release either. Might have sounded like that.)

> That is inconclusive. FPC is independant of DJGPP,
> and might use a different subset.

True; I meant to say you use their loader and DPMI host. Therefore I assume that the subset currently used by FPC is similar to DJGPP's.

> Downgrade to r5, my mistake.

Okay. But (asking Rugxulo here) what was the disadvantage of r7 again? I can only find this document, which indicates you can (pre)configure r7 not to use 4 MiB pages to avoid the issues.

---
l

> Okay. But (asking Rugxulo here) what was the disadvantage of r7 again? I
> can only find
> this
> document, which indicates you can (pre)configure r7 not to use 4 MiB
> pages to avoid the issues.

4 MB pages (?? Pentium circa 1993) didn't exist in either DPMI spec (0.9, 1.0), and VCPI (EMM386), slightly older, also was unaware of it. So some apps might break. But CWS has admitted to being very careful not to break complying apps. Badly-written ones? That's a different story, but he doesn't want to accidentally break things in reasonable places. But honestly I don't know how much he utilizes 4 MB by default, it might only be for certain amounts of RAM or certain situations, so honestly I'm not sure it's the default all the time.

> That is true. So where is the tested LZMA installer?

First things first. And obviously I can't promise I'll write one (though at least somebody else could fairly easily, in theory). But you wanted Pascal-written compression, not C-based stuff, if at all possible (since the current installer's unzip has Pascal equivalents). Besides, LZMA is a huge improvement over ZIP, so it's far better than "squeezing out some more bytes."

> > Besides, guess what? Even your friends use it.
>
> Probably somebody submitted it to them then :)

We have those exact same xz utils ported to DJGPP recently, but as mentioned, you won't use them because they aren't integrated (but instead separate tools) plus not written in Pascal. Feel free to change your mind, but I know better than to expect that.

> * Delphi 2006 like for..in support

Okay, I pretty much guessed what this was for. I assume this is similar to OORexx's [do] "over". Of course, here's what I really found funny, which even marcov must be aware of:


[ WinXP ] Tue 11/23/2010> type hello.pas
program hello;
var c: char;
begin
for c in ['a','e','i','o','u'] do writeln(c)
end.

[ WinXP ] Tue 11/23/2010> fpc hello.pas
Free Pascal Compiler version 2.4.2 [2010/11/09] for i386
Copyright (c) 1993-2010 by Florian Klaempfl
Target OS: GO32 V2 DOS extender
Compiling hello.pas
Linking hello.exe
5 lines compiled, 1.3 sec

[ WinXP ] Tue 11/23/2010> hello
a
e
i
o
u

[ WinXP ] Tue 11/23/2010> for %c in (a e i o u) do @echo %c
a
e
i
o
u


DOS lives!

EDIT: Barely surprising that someone else had almost the same lame test code as me. And surely there are better uses for this feature, heh.

> > That is true. So where is the tested LZMA installer?
>
> First things first. And obviously I can't promise I'll write one (though at
> least somebody else could fairly easily, in theory). But you wanted
> Pascal-written compression, not C-based stuff, if at all possible

It is always possible. C and Pascal map 1:1. Conversions are not always trivial though, and maintenance is a bitch.

But we are a pascal compiler, and we manage an all Pascal codebase (with only gdb linked into any core binary as non Pascal/Asm source in core binaries). To avoid maintainers to _mandatorily_ have to know 10 different languages and their linking habits, we require all pascal code. Basta.

A different, easier solution might be .tgz. While gzip doesn't compress that well, the "solid" aspect with the combination with tar might actually outperform zip in this case, without the need for a massive translation.


> Besides, LZMA is a
> huge improvement over ZIP, so it's far better than "squeezing out some more
> bytes."

For most users it only squeezes out out some more bytes, since they download a compiler because of the functionality, not because of its size.

The same amount of effort invested in the dosport itself would do much more for the dosport than say 40% reduction in size.

Of course also the difference in extracter size (unzip vs p7zip or whatever) must be factored in, snce that util is also provided in the distro

> > > Besides, guess what? Even your friends use it.
> >
> > Probably somebody submitted it to them then :)
>
> We have those exact same xz utils ported
> to DJGPP recently, but as mentioned, you won't use them because they aren't
> integrated (but instead separate tools) plus not written in Pascal.

Correct.

> Feel free to change your mind, but I know better than to expect that.

This policy has been kept for 17 years, and is not going to change to reduce the size of the dos distro from say 30MB to 20MB. Nothing is set in stone, but to upset such long standing policies (specially ones with big consequences like this) the reasons must be very,very severe.

GDB is such severe case, since you don't build a multiplatform debugger from scratch that easily

> For most users it only squeezes out out some more bytes, since they
> download a compiler because of the functionality, not because of its size.

Well, I wasn't going to mention it, but since I'm already mentioning other stuff, you may? wish to know that AdvanceZip actually shaved 2 MB off the "full" DOS 2.4.2 .ZIP download. Unless you know that such info was needed (heavily doubt it, extra fields, .ZIP comments) or that worse compression was used on purpose (impossible, it's 100% compatible, just uses 7-Zip's improved Deflate) .... But hey, it's not like you can fit anything useful in 2 MB anyways.


-r--r--r--    1 Owner    dos        966489 May  2  1989 tp55.zip


BTW, I rechecked FreeBASIC, forgot that CoderJeff (I think) had recompiled as.exe and ld.exe (2.17) himself, hence they use by default non-UPX'd versions. So if you're so paranoid that changing it would break something, use theirs verbatim. Anybody using FreeBASIC is almost definitely using the included BinUtils, so it should've been fairly well tested by now (though I still don't know why my stock recompile of the exact same version would worry you).


-rwxr-xr-x    1 Owner    dos        585728 Mar 15  2007 as.exe
-rwxr-xr-x    1 Owner    dos        559616 Mar 15  2007 ld.exe


BTW, since you love Delphi and seem to be interested in Delphi code, you may be interested in CMT Solitaire (supports 40 games):

http://web.archive.org/web/20050206051117/www.encompass.net/~ctyson/cmtsolit.htm

It's a Windows program, Delphi 3.0 source code available. Years ago I installed in all my computers, forgot about it, remembered it recently for dumb reasons. No, it doesn't compile "out of the box" with FPC, but that's just a minor nit. (Bristol was always my favorite solitaire though Freecell is okay too if you don't like Klondike's quite crappy odds. I thought I used to be good at Yukon too, but now I can't remember my strategy.)


-rw-r--r--    1 Owner    dos        207796 Dec 25 05:26 cmtsol13.zip
-rw-r--r--    1 Owner    dos         34795 Dec 25 05:26 solsrc13.zip


EDIT: MERRY CHRISTMAS!

> [ WinXP ] Tue 11/23/2010> for %c in (a e i o u) do @echo %c
> DOS lives!

Where ???

> > For most users it only squeezes out out some more bytes, since they
> > download a compiler because of the functionality, not because of its bloat

> actually shaved 2 MB off the "full" DOS 2.4.2 .ZIP download

Yeah ... haven't we (or was it just me ?) already found out that the FPC BLOAT could be reduced by factor 3 at least by:

- Removing garbage or unnecessary stuff (Linux examples, ...)
- Avoiding UPX
- Switching to solid LZMA compression

See also: IDE (not retested yet)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > For most users it only squeezes out out some more bytes, since they
> > download a compiler because of the functionality, not because of its
> size.
>
> Well, I wasn't going to mention it, but since I'm already mentioning other
> stuff, you may? wish to know that
> AdvanceZip
> actually shaved 2 MB off the "full" DOS 2.4.2 .ZIP download. Unless you
> know that such info was needed (heavily doubt it, extra fields, .ZIP
> comments) or that worse compression was used on purpose (impossible, it's
> 100% compatible, just uses 7-Zip's improved Deflate) .... But hey, it's not
> like you can fit anything useful in 2 MB anyways.

Well, you would have to subtract the lzma decompressor from that.

>
> -r--r--r--    1 Owner    dos        966489 May  2  1989 tp55.zip
>

Great, grouped together with the date it was last useful

> something, use theirs verbatim. Anybody using FreeBASIC is almost
> definitely using the included BinUtils, so it should've been fairly well
> tested by now (though I still don't know why my stock recompile of the
> exact same version would worry you).

So why don't you simply use it?

> BTW, since you love Delphi and seem to be interested in Delphi code, you
> may be interested in CMT Solitaire (supports 40 games):

> http://web.archive.org/web/20050206051117/www.encompass.net/~ctyson/cmtsolit.htm

Always fun.


P.s. Why don't you become FPC/dos release manager? Then you can package whatever you like, and compress it with 25 different archives. As long as you deliver on type, and do the support

> AdvanceZip
> > actually shaved 2 MB off the "full" DOS 2.4.2 .ZIP download.
>
> Well, you would have to subtract the lzma decompressor from that.

No, I'm talking about ZIP. "advzip -z4" optimized (recompressed) the .ZIP (via 7-Zip's improved Deflate) to save 2 MB without losing any compatibility. I only mentioned extra fields or comments in case somebody (???) needed those here (doubt it).

> > something, use theirs verbatim. Anybody using FreeBASIC is almost
> > definitely using the included BinUtils, so it should've been fairly well
> > tested by now (though I still don't know why my stock recompile of the
> > exact same version would worry you).
>
> So why don't you simply use it?

The point is that I consider the UPX'd-but-can't-unpack binaries "broken", so that's bad. But whatever, just wanted you to know that you're not stuck. FreeBASIC considers their own "stable" and has been tested, so you could always use those as default.

> P.s. Why don't you become FPC/dos release manager? Then you can package
> whatever you like, and compress it with 25 different archives. As long as
> you deliver on type, and do the support

If someone on the dev team really cares and wants to discuss it (doubt it), let them e-mail me.

I never built the DOS compiler (failed) nor IDE (never tried) nor know anything about DPMI exceptions, plus my new-found Pascal skills are low. I thought you implied that these were deal breakers?? Or (better) you only need help with testing and formal releases? Color me skeptical.

> I never built the DOS compiler (failed) nor IDE (never tried) nor know
> anything about DPMI exceptions, plus my new-found Pascal skills are low. I
> thought you implied that these were deal breakers?? Or (better) you only
> need help with testing and formal releases? Color me skeptical.

Well, this is the whole point about the current dos releases. Everybody wants to help or give expert advice, and nobody wants to be responsible. (either lacking motivation or skill)

Slowly, win9x is getting in the same category. There is currently some discussion going on about killing off win9x. Or more precisely, just work if it is NT only, and see if win9x+MSLU will eat it.

The amount of unicode usage is greatly increasing (driven by Lazarus' decision to consider every string utf-8), and the constant win9x hacks are getting annoying.

> Well, this is the whole point about the current dos releases. Everybody
> wants to help or give expert advice, and nobody wants to be responsible.
> (either lacking motivation or skill)

It's not that I don't WANT to help, I'm vaguely willing, but I don't know (and doubt) whether FPC devs give a crap about DOS or are even willing to cooperate with me. Repackaging newer tools is an easy job, but I'm not sure anybody will go for it. I've done it before for other projects and still been ignored. So I wonder whether it's worth it or even possible at all.

(freepascal.org's "Contact" doesn't even list Tomas' email, and I'd bet some of those are outdated anyways. Should I try to email Pierre? I seriously doubt he cares what I think, esp. if even you don't.)

> Slowly, win9x is getting in the same category. There is currently some
> discussion going on about killing off win9x. Or more precisely, just work
> if it is NT only, and see if win9x+MSLU will eat it.

RAR 4.x has already killed off Win9x (and also DOS) for the same reason. But last I heard MSLU was a crappy license (thanks for nothing, MS) and Mozilla's (?) reimplementation was only half-baked at best. Anyways, I don't have any Win9x machines to test (and dunno where that one of my brother's is).

> The amount of unicode usage is greatly increasing (driven by Lazarus'
> decision to consider every string utf-8), and the constant win9x hacks are
> getting annoying.

It's a losing battle. It's easier to drop support, deprecate, delete than keep afloat. And like I said, RAR dropped DOS too (though still sells "old" version 3.93, for now), so I hope FPC doesn't do the same. (RAR apparently now supports Win32, Win64, Linux32, Linux64, Mac OS X, FreeBSD.) All anybody cares about is Windows and/or POSIX (read: usually Linux only) at most!, very sad. If we can't all get along, what good are we? (Obviously not very.)

The useful and relatively easy job is to report bugs around DOS version of FPC. It seems it can motivate FPC developers to work even for DOS target.

Now they is one important issue examined (look here)

You can help if you test some development version (called snapshot) and try
to compile and run this source:
Procedure Confuse;
begin

end;


Procedure TestBug(chr:word);
begin
Confuse; {if you comment it, everything is fine even in Level 2}
Mem[$B800:0]:=byte(chr);
end;

begin
writeln(#13#10#13#10);
TestBug(42); {should print '*'}
readln;
end.

It should print asterix ("*") in left upper corner.
Try to set the compilation parameters in IDE and set "Optimalization level 2"
Then should be provoced a bug - nothing is displayed.

I need a confmitation by somebody about this bug.

---
DOS-u-akbar!

> The useful and relatively easy job is to report bugs around DOS version of
> FPC. It seems it can motivate FPC developers to work even for DOS target.
>
> Now they is one important issue examined (look
> here)

I already have been monitoring this, I already merged Jonas' previous fix to 2.4.3 even.

But due to holidays, I haven't been behind my 32-bit machines. (I do have 32-bit 2.4.2, but no devel version setup on this machine, only 64bit) Will test it somewhere this week.

> It's not that I don't WANT to help, I'm vaguely willing,
....

> (and doubt) whether FPC devs give a crap about DOS or are even willing to
> cooperate with me.

The whole point is that they don't HAVE to care. They rather get rid of the responsibility and park it with somebody who wants the job. Of course that one must then also look into problems himself.

(and actually they do care, but their agenda's are already full enough, and like me they know if they try to salvage Dos, they'll have to drop something else)

> (freepascal.org's "Contact" doesn't even list Tomas' email, and I'd bet
> some of those are outdated anyways. Should I try to email Pierre? I
> seriously doubt he cares what I think, esp. if even you don't.)

Get on the fpc-devel list.

> > Slowly, win9x is getting in the same category. There is currently some
> > discussion going on about killing off win9x. Or more precisely, just
> work
> > if it is NT only, and see if win9x+MSLU will eat it.
>
> RAR 4.x has already killed off Win9x (and also DOS) for the same reason.

The problem is that win9x has gotten a free ride for say the last 5 years, where users hardly contribute, but lift on the win32 port for NT.

That is also where the same problem as with Dos lies. Without maintainers, almost nothing is doable. E.g. one could simply split the win32 target into a NT and win9x target, if a serious user(or -group) would start working on that win9x target.

That way the NT people wouldn't be bothered with win9x compatibility, and at the same time win9x could continue. But that isn't happening, because people only complain about win9x not working, and only want a quick fix to let it last just another xxx months longer. Same as with Dos, where since 2003 not much more as the bare minimum has been done (and actually not even that, since dos has been broken in many releases)

> But last I heard MSLU was a crappy license (thanks for nothing, MS) and
> Mozilla's (?) reimplementation was only half-baked at best. Anyways, I
> don't have any Win9x machines to test (and dunno where that one of my
> brother's is).

Possible. But it is the only solution to not split the win32 target (requiring reponsibility to be carried by Win9x people, something I don't see happening, they only want to use their old machine somewhat longer, not work for it), and at the same time getting rid of the uneasy marriage that is happening now, and starting to crack (win9x+winNT in one target)

> > The amount of unicode usage is greatly increasing (driven by Lazarus'
> > decision to consider every string utf-8), and the constant win9x hacks
> are
> > getting annoying.
>
> It's a losing battle. It's easier to drop support, deprecate, delete than
> keep afloat.

The problem is not that it is a losing battle. The problem is more that it is not a battle at all. People are only complaining on the "losing" side, nobody is actually fighting (working) to keep it afloat.

Of course it is easy to blame core (since they are always to blame per definition in the minds of users), but the reality is that nobody is interested in Win9x or Dos, except if there are problems. (and they then try to get away with the most minimal fixes possible, or drop the burden on core).

For Dos this situation already exists since 2003, and I don't think this is going to happen for win9x, unless it gets its own target (no NT marriage anymore) and own maintainers.

And it takes only one person, like I kept the FreeBSD port afloat for all these years with only one or two regular bugreporters.

> And like I said, RAR dropped DOS too (though still sells "old"
> version 3.93, for now), so I hope FPC doesn't do the same. (RAR apparently
> now supports Win32, Win64, Linux32, Linux64, Mac OS X, FreeBSD.)

While the dos and win9x are both orphans maintainerwise, the situation is different in that dos at least is its own platform.

So Dos doesn't require people not interested in X working on X compatibility. (well it does of course, for general features, but on a much smaller scale) IOW if you are interested in Windows NT, can't test anymore on win9x, it is very hard to consider win9x in anything you do, every @&^%$@ day. That nerves people.

If this isolation (and the modest but important work of Giulio, Tomas and Pierre) wouldn't have been there for Dos, and Dos would have coexisted within a target with another OS, Dos would have been killed off ages ago.

> All anybody cares about is Windows and/or POSIX (read: usually Linux only) > at most!, very sad. If we can't all get along, what good are we? (Obviously
> not very.)

Well, I think Mac OS X actually gets more contributions than Windows.

But caring is not enough. Work needs to be done, and experience needs to be built, and that needs a dedicated maintainer. And that's where the dos and win9x problems lie.

Actually Windows (and then I mean say XP+)has gigantic problems too. The user/development ratio is very high (many users, in proportion only a very little amount of devels). In fact Windows has no dedicated maintainer, and the windows specific work is done by patches from users mostly, and bits and pieces by core.

If for some reason Windows NT as a platform stumbles, the same fate as Dos and win9x awaits for the same reasons. (as soon as it is legacy, nobody seems to want to work on these platforms anymore, contrary to e.g. OS X and Linux/FreeBSD)

Currently these problems are hidden by the fact that mainly commercial Lazarus users pick up the tab by heavily debugging the windows platform and providing patches. But if this activity stops, Windows as a platform will hurt badly too.

http://www.arcamax.com/newspics/14/1477/147711.gif

> Firstly I thought that problem is in my disk
> cache but it helped when I swithed from
> cwsdpmi r5 into cwsdpmi r7.
> (however best speed is with some nonswapping DPMI server

Right

> can't be generaly recomended at all - some
> swapping is sometimes necessary)

Wrong. You (or FP) have a BUG in memory management. Memory hogging can always fail. One must be always prepared to handle this case. Outsourcing a memory leak into a huge swapfile is a very bad idea (Windaube does this too)

> So - I vote for switching into cwsdpmi r7 in official distributions.

Or kick it

> No, I do not consider any CWSDPMI release stable.

I deprecate CWSDPMI (and actually DPMI at all). BTW, FPC has patched r5 from 2008 - just kick it

> I need a confmitation by somebody about this bug.

Done!!! ( as again nobody else bothers, as usual in this "community" )

Got:

FPC251.ZIP 17'750'934
B07F'165F'1394'3036'1086'CF7D'6DD1'B626

"fp.exe" 1'872'132 2011-03-07 16:41

Result:



Doesn't compile because LD.EXE is missing ... "switching to external linking" is nonsense, because LD.EXE is the external linker ... but where is the internal one ???

Got further 20 MiB of bloat (containing LD.EXE) :

BUG.EXE (sort of "Hello World" program) brewn (240 KiB )



The BUG is still in even in "opti" 1 (but not if I comment out the "Confuse").

More problems:

### "install2.png" is bloated

INSTALL2.PNG 7'176

INSTALL3.PNG 5'545 Saving factor 1.3 and __LOSSLESS__ !!!





### UPX is still included, and binaries are still UPX'ed, with UPX 1.20

Solution: completely kick UPX from FPC

### CHM reader doesn't work, neither with FPC internal, nor with external files:



> > It's a losing battle. It's easier to drop support, deprecate, delete
> > than keep afloat.

YES. For DOS, it's better to have OSama/2 and Windaube (NE, ME, maybe also XP in future) deprecated and dead. I deprecate them all

> The problem is not that it is a losing battle.
> The problem is more that it is not a battle at all.

Wrong. There is a battle. But the problem is, that the soldiers failed to find the front

> People are only complaining on the "losing" side,
> nobody is actually fighting (working) to keep it afloat.

??? WtF ??? How many people bothered to test this one ???

> RAR 4.x has already killed off Win9x

Good

> And like I said, RAR dropped DOS too

No problem at all

> (though still sells "old"
> version 3.93, for now), so I hope FPC doesn't do the same.

So please whine less about dead Windaube ME

> While the dos and win9x are both orphans maintainerwise,
> the situation is different in that dos at least is its own platform.

Good attitude Future of DOS may NOT depend from Macro$oft

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > Firstly I thought that problem is in my disk
> > cache but it helped when I swithed from
> > cwsdpmi r5 into cwsdpmi r7.
> > (however best speed is with some nonswapping DPMI server
>
> Right

Test r5 against r7 for anything significant, latest (w/ 4 MB pages) should be 2x faster.

Besides, CWSDPMI only creates a zero-byte swapping file at startup, doesn't actually expand/use it unless needed/accessed.

> > can't be generaly recomended at all - some
> > swapping is sometimes necessary)
>
> Wrong. You (or FP) have a BUG in memory management. Memory hogging can
> always fail. One must be always prepared to handle this case. Outsourcing a
> memory leak into a huge swapfile is a very bad idea (Windaube does this
> too)

IIRC, you can limit the size of the swap file via CWSPARAM.

> > So - I vote for switching into cwsdpmi r7 in official distributions.
>
> Or kick it

FPC/DOS won't work without DPMI. Unless you want to resurrect the EMX (raw or VCPI) port or roll your own extender.

> > No, I do not consider any CWSDPMI release stable.
>
> I deprecate CWSDPMI (and actually DPMI at all). BTW, FPC has patched r5
> from 2008 - just kick it

I know it has r5 2008, that's good (SSE works now), but r7 is even better. Kick it? Like I said, FPC/DOS won't work without it.

> > I need a confmitation by somebody about this bug.
>
> Done!!! ( as again nobody else bothers, as usual in this "community"
> )

I thought it was already fixed?!?

> Got:
>
> FPC251.ZIP 17'750'934
> B07F'165F'1394'3036'1086'CF7D'6DD1'B626

From here?

ftp://ftp.freepascal.org/pub/fpc/snapshot/v25/i386-go32v2/

> "fp.exe" 1'872'132 2011-03-07 16:41
>
> Result:
>
> Doesn't compile because LD.EXE is missing ... "switching to external
> linking" is nonsense, because LD.EXE is the external linker ... but
> where is the internal one ???

I don't know, I'm not in the loop, but I just always assumed the internal linker was MS COFF (Win32) only. At least, I never heard that it fully worked with DOS (nor was ever barely tested there, if at all).

> Got further 20 MiB of bloat (containing LD.EXE) :
>
> BUG.EXE (sort of "Hello World" program) brewn (240 KiB )

-XXs -Os

> The BUG is still in even in "opti" 1 (but not if I comment out
> the "Confuse").

So don't write empty procedures. Or perhaps {$ifdef} makes that harder to avoid?

> More problems:
>
> ### "install2.png" is bloated
>
> INSTALL2.PNG 7'176
>
> INSTALL3.PNG 5'545 Saving factor 1.3 and __LOSSLESS__ !!!

Okay, good point, but surely you don't expect any sympathy there, do you?

> ### UPX is still included, and binaries are still UPX'ed, with UPX
> 1.20
>
> Solution: completely kick UPX from FPC

It's up to the (non-existent) DOS maintainer to decide, not us DOS users.

> ### CHM reader doesn't work, neither with FPC internal, nor with external
> files:

Who reads docs anyways?

> > While the dos and win9x are both orphans maintainerwise,
> > the situation is different in that dos at least is its own platform.

If DOS/DPMI stuff fully worked like it did in Win9x days, even on XP / Vista / 7, we wouldn't be having such a shortage of users. Useless whining but true nonetheless. Nobody targets a non-existent (or broken) subsystem, and MS knows this. They want to avoid what happened to OS/2 ("too compatible" for its own good). Unfortunately, being totally INcompatible is bad for users. "DOS at least is its own platform", yes, but DPMI was invented by and for Windows. That will never change, no matter how hard anybody wants to say otherwise.

> Done!!! ( as again nobody else bothers, as usual in this "community"
> )

I'm sorry, but - I don't use FP, so I (falsely?) assumed that I was probably not very helpful here.

> Wrong. There is a battle. But the problem is, that the soldiers failed to
> find the front

Sounds like a problem of logistics. However, fixing such problems is not the task of simple soldiers - that's a failure of the General officer.

---
MS-DOS forever!