DOS ain't dead

Hello!
After quite a long time is a new FPC version available.
For us is important mainly the improving DOS realmode target.
The Dos-32 (GO32V2) packages are here:
ftp://ftp.freepascal.org/pub/fpc/beta/3.2.0-rc1/i386-go32v2/

---
DOS-u-akbar!

> After quite a long time is a new FPC version available.

Well, it is a RC

> For us is important mainly the improving DOS realmode target.
> The Dos-32 (GO32V2) packages are here:
> ftp://ftp.freepascal.org/pub/fpc/beta/3.2.0-rc1/i386-go32v2/

Unfortunately there were problems getting the textmode IDE to link to the debugger, so afaik that release has no debugger in the IDE.

> ftp://ftp.freepascal.org/pub/fpc/beta/3.2.0-rc1/i386-go32v2/

1). IDEDOS.ZIP seems corrupted (no CDS found in .ZIP).
Is this a duplicate (or newer?) version of UIDEDOS.ZIP?
But INSTALL.DAT only mentions IDEDOS.ZIP.

2). INSTALL.DAT still uses ~G~ twice (General, Go32v2 packages 2nd part)
workaround: load mouse driver (Ctrl-Tab doesn't work??)

3). BASEDOS.ZIP ("basic system") says it needs LFNs
("required", but deselected by default when DOSLFN not loaded).

>unzip -l basedos.zip | awk "$2~/2020$/{sub(\".*/\",\"\",$4);\
if(length($4)>12)print $4}"


    character.ppu       cp8859_10.ppu cp8859_11.ppu   cp8859_13.ppu
    cp8859_14.ppu       cp8859_15.ppu cp8859_16.ppu   fpwidestring.o
    fpwidestring.ppu    unicodedata.o unicodedata.ppu unicodenumtable.o
    unicodenumtable.ppu


Some of these will resolve to the same filename. DOSCHK (see DJGPP
mirrors) is your friend. (Or are we requiring LFNs now? Or only
required for "full" installs?)

So, after install, apparently \FPC\UNITS\GO32V2\RTL\cp8859_1.o
(according to its CRC32) is actually CP8859_16.O ! So it's
overwriting the original file (CRC32 = 0x8ED94CDF). This may
not be the end of the world, but it's still wrong.

4). INSTALL.EXE seems to hang after a few (incomplete) runs
(needing Ctrl-C to abort).
(IIRC, it had this problem once before. I forget the workaround
to restart it successfully.)


So I just kept defaults and installed everything (but manually
selected BASEDOS.ZIP since SFNs only, for now).


5). Trying to run "gdb --version" crashes (Page fault, reg dump).
No idea why.

6). Compiling some simple programs does still work, and they run okay.

OK, tried this release and my impressions are rather positive. (I will speak about GO32V2 version only)

+ Installer (INSTALL.EXE) works
+ For most packages it needs LFN driver. In the beginning of the instalation it warns about it. Some packages is anyway possible to properly install even without LFNs and even those where they are supposed to be really required is possible to force manualy the installer to install.
It is fair behaviour.

- Unfortunately the LFNs are reported as requierred even for the very basic packages like basic GNU tools or the Turbo pascal compatible units.
It would be much better to be SFN compatible for this minimal DOS set.
But OK, I understand that FPC in targeted primary for the modern platforms and to keep such level of DOS compatibility would be difficult.
Anyway - for us, DOS entusiasists is still possible the create a more DOS friendly package of FPC.

- Even other complication with the LFN requirement is the location of the RTL units. They are in the LFN directories.
I recommend to manulaly edit the FPC.CFG and FP.CFG files and replace the LFN paths to their SFN equivalents. After this correction will the compiler again work even in the non-LFN environment.

- As Rugxulo mentioned, the IDEDOS.ZIP package is corrupted. But surprisingly it can be cured by tool PKZIPFIX. I did it and uploaded the fixed version here:
http://laaca.sweb.cz/idedos.zip

+ Huge pleasant surprise is the perfectly working IDE (the FP.EXE file) hidden in the above mentioned IDEDOS.ZIP file.
After many years and after many releases it finally works out of the box even with fully working integrated debugger. (but yes, here is still the bug with not working output screen saving in VESA modes)
And the debugger is based on the very new GDB 7.7.1

- I can confirm the crash with the bundled external GDB.EXE file. It is not the duty of the FPC team because it is a external utility. Maybe people from the DJGPP group could help there.
Or you can use this slightly older GDB 7.2
http://laaca.sweb.cz/gdb.exe

---
DOS-u-akbar!

> - As Rugxulo mentioned, the IDEDOS.ZIP package is corrupted. But
> surprisingly it can be cured by tool PKZIPFIX. I did it and uploaded the
> fixed version here:
> http://laaca.sweb.cz/idedos.zip

Even the fixed zip reports problem - error in fp.exe.
Winzip didn't extract the corrupted file but 7zip extracted fp.exe as 60MB instead of 72MB and it surprisingly started without a crash but it doesn't mean it's OK, releaser should uploat it again, was it reported to them?

---
DOS gives me freedom to unlimited HW access.

> OK, tried this release and my impressions are rather positive. (I will
> speak about GO32V2 version only)
>
> + Installer (INSTALL.EXE) works
> + For most packages it needs LFN driver. In the beginning of the
> instalation it warns about it. Some packages is anyway possible to properly
> install even without LFNs and even those where they are supposed to be
> really required is possible to force manualy the installer to install.
> It is fair behaviour.

Tomas was looking into workarounds.

> - Unfortunately the LFNs are reported as requierred even for the very basic
> packages like basic GNU tools or the Turbo pascal compatible units.
> It would be much better to be SFN compatible for this minimal DOS set.
> But OK, I understand that FPC in targeted primary for the modern platforms
> and to keep such level of DOS compatibility would be difficult.
> Anyway - for us, DOS entusiasists is still possible the create a more DOS
> friendly package of FPC.

Yes, the relevant units are lfn and in the base libraries. The best you can do is delete them from a LFN machine.

> - Even other complication with the LFN requirement is the location of the
> RTL units. They are in the LFN directories.
> I recommend to manulaly edit the FPC.CFG and FP.CFG files and replace the
> LFN paths to their SFN equivalents. After this correction will the compiler
> again work even in the non-LFN environment.

This is new for me. Does it create i386-go32v2 paths somewhere instead of "go32v2"?

> - As Rugxulo mentioned, the IDEDOS.ZIP package is corrupted. But
> surprisingly it can be cured by tool PKZIPFIX. I did it and uploaded the
> fixed version here:
> http://laaca.sweb.cz/idedos.zip

It is intact on FTP. unzip -t yields no errors.

I put it on http://www.stack.nl/~marcov/idedos.zip (215MB), and tested it again with *nix infozip, and it tests ok, also after transfer.

> + Huge pleasant surprise is the perfectly working IDE (the FP.EXE file)
> hidden in the above mentioned IDEDOS.ZIP file.

The big one? I assume, not the uidedos one?

> After many years and after many releases it finally works out of the box
> even with fully working integrated debugger. (but yes, here is still the
> bug with not working output screen saving in VESA modes)
> And the debugger is based on the very new GDB 7.7.1

I have been misinformed by the maintainer then. He said it contained no gdb in the IDE.

> - I can confirm the crash with the bundled external GDB.EXE file. It is not
> the duty of the FPC team because it is a external utility.

It this case, maybe. Because the dos packager also is a GDB committer (though afaik not for dos related issues and not for packaging/releasing)

> Maybe people
> from the
> DJGPP
> group could help there.
> Or you can use this slightly older GDB 7.2
> http://laaca.sweb.cz/gdb.exe

Afaik the dos/gdb guy is still working on it.

I see that you refreshed the RC1 downloads on April 8th. Fixed INSTALL.DAT and IDEDOS.ZIP, but GDB still crashes. Haven't looked much beyond that (again) yet.

> I see that you refreshed the RC1 downloads on April 8th. Fixed INSTALL.DAT
> and IDEDOS.ZIP, but GDB still crashes. Haven't looked much beyond that
> (again) yet.

Fortunately we can still download the GDB.EXE from the DJGPP archives which works fine
I doubt that the version budled with FPC have some diferencies from the "official: version. Except the crashes, of course

---
DOS-u-akbar!

Hm, f*ck. I've found a regression between FPC 3.0.4 and FPC 3.2.0
If the debugging informations is turned on I still get in the end of the program a detailed info about unfreed memory block.

So - the program normally ends but it does not silently go back into DOS but on the screen appears a detailed list of all unfreed memory blocks.
It may be a nice feature in some circumstancies, but hey, how can I switch it off?

I know that I don't free all memory blocks - it is OK for me.
I have not discovered any combination of switches which allows me to debug the program (in IDE) but don't bother me with this "info".

It seems that switch combination...
-g
-gh-
-gl-
...does not help.

It look like FPC is always loading the Heaptrc unit.

The normal behaving program compiled with FPC 3.0.4 (debug info on) is here: http://laaca.sweb.cz/barev304.exe
and the same source compiled with same settings with FPC 3.2.0 is here:
http://laaca.sweb.cz/barev320.exe

It is a demo application for me units - a simple color selector for HiColor modes.

---
DOS-u-akbar!

> Hm, f*ck. I've found a regression between FPC 3.0.4 and FPC 3.2.0
> If the debugging informations is turned on I still get in the end of the
> program a detailed info about unfreed memory block.

Make sure that heaptrc isn't referenced in the sources anywhere.

I don't see an option for it in the IDE, does the command compiler do it too?

You might also search the fp.cfg/fp.ini for -gh info and remove it. They are textfiles.

Not to be off-topic or waste your time, but ....

Our discussion of CMOVcc (686+) made me wonder about some things. But I still don't have any reliably good benchmarks for that, so I dunno. I'm pessimistic.

Anyways, I vaguely remember rebuilding AdvanceComp (advzip, advdef) years ago (since he only cross-compiled with an old compiler) for noticeable speedup. Latest DOS releases (at least 2.1 from 2018), IIRC, have the dreaded CMOV, which I doubt helps overall speed at all. It can still be quite slow, especially for lots of files (and still needs DOSLFN loaded due to tmpfile, doh). It should be mostly cpu bound, though.

I know that doesn't tell you much, but I did run "advzip -z4" on 3.2.0 RC1's .ZIPs to save a little over 3 MB. (Size matters! Well, not really.) Just bored and curious, I suppose. (N.B. it recompresses with an improved Deflate, and it removes EOS markers, but I don't think that breaks any obvious decompressors.) This is just one minor size optimization that I've mentioned (in vain) before.

So maybe I should cross-compile ADVZIP.EXE both with and without CMOV (-march=i686), and see the speed difference.

Interresting.
I've tracked the problem and the code with caused this behaviour was in my include file DEFINES.INC which is called from all my units.
And there is this line: {$IFDEF DEBUG}{$CHECKPOINTER ON}{$ENDIF}

But I've never selected the option "-gh"

The Freepascal help for the {$CHECKPOINTER} says this:

"The {$CHECKPOINTER} directive turns heap pointer checking on (value ON) or off (value OFF). If heap pointer checking is on and the code is compiled with the -gh (heaptrace) option on, then a check is inserted when dereferencing a pointer. The check will verify that the pointer contains a valid value, i.e. points to a location that is reachable by the program: the stack or a location in the heap. If not, a run-time error 216 or 204 is raised.

If the code is compiled without -gh switch, then this directive has no effect. Note that this considerably slows down the code."


1) From the text above does not follow that the tracking of the unfreed memory blocks should be on. (especially when no "-gh" switch is set)

2) The FPC 3.2.0 behaviour is different from FPC 3.0.4 so the first or the latter does it wrong.

---
DOS-u-akbar!

> 2) The FPC 3.2.0 behaviour is different from FPC 3.0.4 so the first or the
> latter does it wrong.

I tried to reproduce it with other 3.2.0rc1 editions, but couldn't. Nevertheless, I'll pass it on.

I think I've found another bug.
It seems that the file streams from unit Objects do something wrong with relative paths.
Look at this simple source:

program teststrm;
uses objects;
var s:TDosStream;
begin
s.Init('.\SUBDIR\FILE.TXT',stOpenRead);
writeln(s.status);
writeln(s.errorinfo);
s.Done;
end.

If you have existing .\SUBDIR\ and file "FILE.TXT" inside it should print 0 and 0.
But it prints -2 and 3 which means "Invalid file path."

Compiled with FPC 1.0.10 it works as expected.

edit: I've created a bugreport in the Freepascal mantis system.
edit2: It seems that the root of the bug are in the functions FExpand and GetDir in the unit DOS.

---
DOS-u-akbar!

Hm, bad...
This bug occur only from IDE.
If I leave the IDE and run the generated EXE everything is OK.
It will be hard to debug...

---
DOS-u-akbar!

Strange...
I am not able to replicate the bug today.
Maybe I somehow curred the FPC when I run it in pure DOS without any LFN driver? Maybe I had somehow defect the FP.DSK file?
Anyway, now everything works in pure DOS without LFN and even in Win98 with LFN.
What will happen in next days?....

Edit:
Maybe it is a consequence of the fact that I mixed using the FPC304 and FPC320 and kept the FP.* files in my working directory...

---
DOS-u-akbar!

> Strange...
> I am not able to replicate the bug today.
> Maybe I somehow curred the FPC when I run it in pure DOS without any LFN
> driver? Maybe I had somehow defect the FP.DSK file?

I think your directory inside the IDE was somehow messed up. Next time this occurs, try explicitely changing to the project directory using file->"change dir"