Basic Units (CRT) missing in full download package for DOS ?

[MrCC]

I downloaded dos304full.zip from https://www.freepascal.org/down/i386/go32v2-hungary.var because i wanted to compile some old DOS pascal code under DosBox that accesses a sound card via Ports. The sample code

Code: Pascal  [Select][+][-]

1. USES crt;

but compilation via fp and fpc fails because the unit crt cannot be found.

After looking inside basedos.zip path \units\go32v2\rtl\ of the installation files, it appears that indeed the file is not there (crt.a, crt.o and crt.ppu are all absent)

I checked an older download of version 2.64 and the aforementioned files were in there  (these files, however, cannot be used with 3.04 due to "version mismatch").
Has the unit CRT (and possibly other units) been axed starting with FP 3.x ? Or is that archive file incomplete?

[marcov]

No, with 3.0.0+, the RTL has been cleaned up, and units have been moved to various packages/rtl- packages.

The reason for this is that RTL is built 3 times in single core mode, while packages can be built in multi-core mode.

So either there is something wrong in your configuration (only scanning RTL/ dir) or you didn't install the relevant package.

[MrCC]

Okay,
thanks for the pointer.

After fiddling around a little, and for future reference for people facing the same "basic <unit> not found" problem, it seems that the default installer under DOS (DOSBox in my case) is a little overzealous when pre-selecting (or deselecting, rather) options of a default installation - I will explain why in a moment, but first a solution for people who specifically have the "CRT missing" issue (so, for people searching by topic name). The missing CRT.PPU / CRT.O is in the file urtlcdos.zip under units/go32v2/rtl-console/. That file also contains keyboard, mouse, vesamode and video units, so if you're looking for those, you might be in luck. Simply copy the files to one of your "UNITS" folders of your Free Pascal directory that is also in the units search path (I picked <FP-Installation-DIR>\UNITS\GO32V2\RTL ).
Btw, the compiled executable will need the "cwsdpmi.exe" file (it's comes included in dos304full.zip and is also available as separate download, see the download location of my first post) under DOSBox. If you get a (misleading) error message "Load error: no DPMI - Get csdpmi*b.zip" when running your compiled executable, simply copy that file to where your executable is.

As to the WHY, and to the reason I believe this should be considered a bug rather than anything else (e.g. "by design"):
The DOS installer under DosBox gives you a warning about your OS not supporting long file names (see attached images). I've also attached a 2nd image of the resulting default pre-selections after the message. (@marcov: I'm assuming the installer selection "RTL-console abstraction" corresponds with the contents of urtlcdos.zip I mentioned above and is preselected by default in the case that LFN support is available, correct me if I'm wrong). You can see many options deselected by default, each entry marked by "(requires LFN support)". So in other words, a default installation will leave you with many missing basic libraries.

So the question is, "Why does a library like CRT require LFN support?" and the answer is "It doesn't.". What does require LFN support is the path one of the project maintainers deemed sensible for the location of the library: In the CRT case, the culprit is the "rtl-console" part of "units/go32v2/rtl-console/" - this is the sole reason for the LFN requirement.

I believe this needs either to be documented somewhere (preferably at the download page for the DOS installer files), or the installer fixed in such a manner that it would provide a sensible default installation (another option would be to shorten the path-segments to the standard "8.3 format" under DOS).

[marcov]

I believe this needs either to be documented somewhere (preferably at the download page for the DOS installer files), or the installer fixed in such a manner that it would provide a sensible default installation (another option would be to shorten the path-segments to the standard "8.3 format" under DOS).

The problem is that both the number of developers and testers for odd-ball scenarios is too low.  Patches are welcome.

Afaik most people that still use dos releases use win9x, which has LFN. The non lfn group is yet another magnitude smaller.

Too much work on dos is centered on releases, when the changes that cause the problems are already old. Dos could use some users that actively track trunk.