#375 Free Pascal package of FreeDOS isn't installed properly

[Oliver]

When installing Free Pascal via FDIMPLES.EXE from the FreeDOS 1.3 Bonus CD, then Free Pascal
isn't installed properly.

The problems are especially related to the FPC.EXE and FP.EXE IDE of the Free Pascal package

1. The UNIT files to compile Pascal source code isn't configured in the FP.EXE IDE.
2. Trying to configure them in the Options -> Directories MENU manually fails because the / key character can't be entered in the IDE.
3. In the FP.EXE editor window it's not possible to enter characters like [, ], and \. But these are needed to program Pascal code. It seems to be that it also doesn't help to change the loaded keyboard layout.
4. The input of the above characters does work if FreeDOS is bootet in emergy mode without drivers. But in this mode the cursor keys and numpad keys are the same in the FP.EXE IDE. This means, if i enter cursor key down, then a 2 is printed in the editor window.
5. There is no default FP.CFG file for the FP.EXE IDE in the Free Pascal folder.
6. The FP IDE doesn't work properly when the FDAPM power saving modes are turned on. It is required to set FDAPM to ADV:REG

For the errors 1 and 2 i added an output file of

fpc -vut sndtest.pas > output.txt

as an attachment to this bug report.
See the file OUTPUT.TXT

[Anthony Williams]

If FPC.EXE can't find CRT.O (and .PPU), then FPC.CFG is wrong or some other installation error. Try grabbing the release .ZIP from upstream and installing manually (e.g. DOS322.ZIP).

Also, traditionally, Pascal allowed "(." for "[" and ".)" for "]".

[Tomas Hajny]

First of all - the missing unit Crt is clearly due to wrong packaging of FPC provided on the Bonus CD of FD.
Despite the workaround for bugs 3 and 4, I still believe that the primary source is outside of FP IDE. The developers of FP IDE cannot check much because they don't use FreeDOS. However, you might check it yourself what happens if compiling a test program available on https://gitlab.com/freepascal.org/fpc/source/-/blob/main/packages/rtl-console/tests/kbd1.pp and checking the output of that program when running from the FreeDOS command line (without / before running FP.EXE) and from within FP.EXE (without running your workaround program first and after running it). If there's any difference, check also whether running the test from the command line after your workaround program gives a different result. In general, the returned keyboard key codes should be always the same (and obviously compatible to those returned when under a different DOS or a DosBox, etc., with the same keyboard layout). BTW, information about the keyboard layout and codepage used/configured in FreeDOS is missing in the report.

[Tomas Hajny]

First of all - if I understand it correctly, you basically say that you're too lazy to read the Gitlab terms and conditions and that's the reason why you're not willing to create a bug report in the FPC bug repository. I could understand if you found some specific condition in the contract which you were not willing to accept, but that doesn't seem to be the case here (you didn't name any particular problem there). You reported the bug here, which is absolutely OK considering that at least part of the reported problems are strictly confined to the FreeDOS distribution rather than FPC. However, asking somebody else to report it in the FPC repository instead of you is not OK unless the other person can reproduce the problem and respond to raised questions as appropriate. Thus I'll close the ticket in the FPC bug repository. Note that there are still other ways for your communication with FPC community even without accepting Gitlab conditions like subscribing to one of FPC mailing lists or using the WWW based community forum.

Second - it isn't clear to me what prevents you to use VFAT (i.e. LFN extensions to FAT16), or FAT32, if you work in a virtual environment anyway. I could understand that in case of HW installation having specific compatibility concerns, but again, this isn't the case here.

Third - as already mentioned in my response above, the FreeDOS packaging of FPC is broken / incomplete. Please, install FPC using an official release as available on the FPC site. Even though the installer warns you if trying to install on a FAT16 partition without LFN support, it still allows you to proceed. Some directory names will be truncated (like rtl-console becoming rtl-cons), but that makes no difference by itself. On top of that, certain units having conflicting names after truncation to 8.3 won't be usable (most notably, this is certainly the case for packages rtl-generics, rtl-unicode and fcl-image, but also chm, fcl-passrc, fcl-res, fcl-sdo and possibly others) - well, that's indeed a limitation. There are possible workarounds for those cases, but that isn't directly related to this bug report. Once you perform the FPC installation, you should be able to compile the test program.

Fourth - the fact that cursor keys behave differently when not using the German keyboard suggests a potential conflict between configuration of keyboard layout in your host Linux environment and the QEmu configuration. I have no knowledge of QEmu whatsoever, nor sufficiently deep knowledge of keyboard layout configuration options in Linux / X11, but I'd start by making sure that your Linux host environment is configured for the en-us keyboard before starting the FreeDOS image, because multiple keyboard translations running on top of each other could easily result in behaviour described by you.

[Jim Hall]

That was quite a long rant. Please do not use the FreeDOS tracker to attack other people. Many parts of your post go against the community guidelines, not to mention general netiquette. That behavior is not welcome here and will not be tolerated.

[Tomas Hajny]

Thanks to Jim. We talk about open source projects here and about people spending their free time to support them. Anybody is welcome to use the projects outcomes and people willing to help are welcome even more. People demanding a specific service and considering it their right are not.
As an additional off-topic side comment (before moving to the more important stuff) - FPC forum moderators have specific rights in a particular area and cannot move topics from one area to another (unlike the administrator of the forum server). That doesn't mean that Bi0T1N might not have done a better job, just for clarification.
Now to the merits - no, FPC project is and will not be driven by limitations of MS-DOS, because FPC supports more than a dozen HW architectures and over 3 dozens of target operating systems / environments. Nevertheless, FPC still provides high level of support for users who have to live with those limitations and want to use FPC for compiling their projects. However, vast majority of FPC users are not limited this way nowadays, and FPC allows compiling code targetting DOS e.g. under Linux without such filesystem limitations. More importantly, most FPC users don't use DOS at all and their code uses operating environment features not available under DOS out of the box (multitasking, multithreading, network communication, interprocess communication, etc.).
Since the original reporter stated that his primary focus was providing feedback to allow improving FPC (rather than solving his real problem), I'll use relevant parts of the last response exactly for that purpose. In particular - yes, adding specific notes related to installation of FPC in 8.3 limited environment is worth adding to the readme.txt file. That includes one part which I forgot to mention in my previous post - namely the fact, that packages containing longer file names are by default not selected in the installer and need to be selected explicitly if users want to use them. Admittedly, it's a bit unfortunate that this includes the basic package containing the compiler and basic RTL units nowadays, but that's how it is. And, BTW, yes, Unicode may be used in DOS with FPC to deal with text in various character sets.
While adding information to readme.txt, I'll also add the part clarifying the difference between the dos322.zip and dos322full.zip - people downloading the packages from the FPC WWW server and its mirror (links to Hungary and Canada below the Sourceforge link) have this information already available, but this is not visible on Sourceforge.
I'll also update the section related to documentation in that file by explicitly mentioning the section More information on our WWW server (as already referenced at the bottom of the Documentation page on the same server) - among others, there is a link to a general Pascal tutorial (although most people would rather use Google or some other search engine to find quite a few tutorials nowadays).
Finally, regarding the keyboard issues - unfortunately, there are too many moving parts in the configuration used by the reporter (Linux and its keyboard layout+QEmu+FreeDOS+FreeDOS keyboard layout changing program). Nevertheless, I noticed that there are indeed some issues which may be observed by users trying to use the Alt-Gr combinations for accessing certain keys with non-US keyboard layouts (rather than switching to the US keyboard providing them) and this part is easily reproducible even on other platforms, i.e. I'll see how to make sure this gets fixed (either by me, or by some other member of the FPC team).

[Jim Hall]

Oliver,

I deleted your post because it was entirely abusive. Note that the codes of conduct for our email lists applies to bug reports, too:

1. No hate speech or bullying (your post was exactly that)
2. No promotions or spam
3. Be kind and courteous (your post was not)

We will not tolerate this behavior.

[Jim Hall]

Third - as already mentioned in my response above, the FreeDOS packaging of FPC is broken / incomplete. Please, install FPC using an official release as available on the FPC site.

Also, it would be nice for the OP to test this with the updated FreeDOS package. We create an updated "test release" of the FreeDOS distribution every month for exactly this kind of debugging - if there's a problem with a package in the main distribution, we fix it in the test release so it stays fixed in the next distribution. T2404 ("test .. year 2024 .. month 04") is the latest version right now. T2404 has a slightly different package, fpc.zip package. Comparing the two files from FreeDOS 1.3 and T2404 with MD5 shows different content:

70758ec8c829796acad7eee0a474f237 FD13-BONUS0/packages/devel/fpc.zip
e8ee3c5f3e70aa8b5bbc0f85d4a4437d T2404-BONUS0/packages/devel/fpc.zip

According to the changes.log file, the fpc package was already updated, although I don't know if it fixes the issue OP reported:

2022-07-20 10:59:52 fpc (shidel): NLS: Package and Description Update

[Tomas Hajny]

@jhall1: I believe that I can respond to this part, at least to some extent. I wasn't aware of the optional 'lfnfiles.zip' component of your packaging when writing the above statement about broken/incomplete FPC package - the missing pieces seem to be there (in lfnfiles.zip), i.e. it might be complete from this point of view, although not necessarily consistent (see below for more details). I don't know whether your installer allows installing the content of lfnfiles.zip even under 8.3 restricted filesystem by truncating the unpacked file and directory names to 8.3. If it does, it may be used to provide the missing pieces. If not, then installing using the official FPC installer might be a better option (actually, there may be other good reasons for that as well, but I understand that you wanted to increase convenience for FreeDOS users by providing them with everything possibly needed at once and in a common way).

Regarding inconsistence of your package - the trouble is that there are dependencies among the provided units and your mechanical sorting of non-LFN and LFN files results e.g. in including the FPC package FreeVision (units/go32v2/fv/), but excluding package rtl-console (units/go32v2/rtl-console in lfnfiles.zip). Unfortunately, the FreeVision units cannot be used without those in rtl-console. I understand that this situation is somewhat tricky and there's no simple solution, but including everything (and ignoring conflicts after truncation to 8.3 names) might be a better option in this particular case than excluding everything stored in a directory with a longer name.

[Shidel]

As you noted, the FreePascal package is not "broken" it contains files require Long File Name support inside a LFNFILES.ZIP archve. This was also the case with the package provided with FreeDOS 1.3. This is also the case for any other package that contains LFN files.

Some packages work fine without extracting the LFNFILES.ZIP. While others dont work.

FDIMPLES does a great deal of complex data processing to generate a browsable package list of the installed, available and upgradable packages. It pulls data from up to appoximately 12 different data sets. It combines and correlates that data into an easy to understand interface for adding and removing packages. However like many programs in the Linux/Unix world, it does not perform the actual installation or removal of packages on its own. That task is deligated to a command line package manager. Unfortunately, that program will not automatically extract the LFNFILES.ZIP when LFN support is present.

During the creation of a FreeDOS Release (or interim test build), the RBE (Release build environment) scans all packages for files that require LFN support. It compress those into the LFNFILES.ZIP archive(s) automatically and updates fields in the related package metadata files. Those metadata files (among other things) are used by FDIMPLES to generate some of the information regarding packages in FDIMPLES.

Future versions of FDIMPLES may use the metadata notice regarding LFNs in a package and warn that the package requires support before installing. Possibly at some point, it may simply extract the LFN files when support is already present.

[Anthony Williams]

Thank you again, Tomas, for all your years spent working on such a wonderful project. (FYI, I believe he is the OS/2 maintainer who also sometimes helps Go32v2/DOS target since it's unmaintained.)

You can use LFNs in FreeDOS (e.g. DOSLFN), and it's not that problematic on FAT(12/16/32), esp. under VM. If you insist on being like Turbo Pascal exactly and thus "more" DOS compatible, just use freeware TP 5.5 (or one of many other Pascal compilers). For casual usage questions like that or programming advice, freedos-user and BTTR's forum are a friendly place.

"it would make sense if you wrote an online textbook on Free Pascal so that you can attract young programmers."

I can try to post a list of Pascal tutorials for you later this week. (But keep in mind that "Pascal" is a family of languages, so ISO 7185 vs. Extended vs. TP 7 vs. classic Mac vs. Delphi, so there are a LOT of changes! You may be unaware that {$mode tp} is not the default!)

"Free Pascal and the installer is broken on none LFN DOS systems."

"packages containing longer file names are by default not selected in the installer and need to be selected explicitly if users want to use them"

Yes, the installer notices if a .ZIP has an LFN inside and will not automatically select it if no LFN services are available. This is a known quirk and quite unfortunate when it's an unimportant file like a simple readme.

"If I ever write something for FreeDOS, I'll use C."

OpenWatcom and NASM are recommended for FreeDOS. I like C, but I find Pascal safer and easier (and FPC is more robust). FreeBASIC is also quite nice, but the core Pascal language is better designed, IMHO. Jerome is also a big Pascal fiend (and I believe FDIMPLES is written in TP 7).

[Anthony Williams]

Here are a few links to Pascal tutorials and related sites.

Tao Yue's Basic Pascal tutorial
Wikibooks' Pascal Programming
Standard Pascal FAQ and Rules
Modern Object Pascal
FreePascal From Square One

You may also wish to check some example programs included with FPC (e.g. fpctris and samegame).

[Jim Hall]

FYI: This user had become abusive and made accusations of censorship after I deleted several offensive comments. He then edited other comments in this bug, effectively creating spam. He has been banned from the bug tracker.