DOS ain't dead

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

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


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

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

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