[SOLVED] StringUtils in MSDOS

[chobani]

Okay, I think I'm following everyone as best as I can. In my fcl-base directory I do see both base64.o and base64.ppu in my units directory for i386-win32. I do not have that in MSDOS unit directly and this is a fresh install where I haven't made any modifications other than to install the latest version of FPC along with the MSDOS cross compiler.

I see sysutils and strutils both in my MSDOS directory for all memory sizes. There is no FCL-BASE in any of the MSDOS unit directories though. Does this mean no one uses strutils out of the box for MSDOS target? That seems like it might be the case because it starts with the BASE64 include, but I don't know why that wouldn't be one of the next things you would want to have.

So I think you all have shown me the exact issue. I have no idea what to do about that though. I'm guessing I have to do some sort of compile that might be beyond me, hopefully not. Or maybe it's possible someone has already done this? I can't tell you how much I appreciate everyone helping, I'm just trying to help someone else who wants a 16 bit application version of something I wrote for a hobby. I really thought I might be able to just target MSDOS and call it a day hah, so thanks!

[MarkMLl]

This is basically an installation or installation instructions issue. Let's start off by trying to work out what you've got.

On my system I can see- for example-

/usr/local/lib/fpc/3.2.2/units/i386-linux/fcl-base/base64.ppu

If I step back a couple of directory levels to /usr/local/lib/fpc/3.2.2/units/i386-linux I can see


...
fcl-base
...
rtl
rtl-console
rtl-extra
rtl-generics
rtl-objpas
rtl-unicode
...


What do you have in the corresponding place in your MSDOS tree? I think it would be worthwhile C&Ping the entire list so that we can see the scale of the damage.

In any event, it might be that one of the maintainers can point out more detailed instructions that you should have been using (in which case why haven't the out of date ones been removed?) but at present I don't think it's any mistake on your part.

MarkMLl

[Thaddy]

maybe you are on the wrong foot about fcl-base and base64. fcl base does or should not contain a base64 at all.
Read fcl-base as fcl-basics (minimal required). Base 64 is an encoding to save - which  it does not do very good - space and work around non-printable characters. They are not related.
See https://en.wikipedia.org/wiki/Base64

If you need base64, You might want to shoot a bear - guns not allowed, just spear or bow and arrow - and cut down a tree for warmth.

[chobani]

I do have a Linux VM I'll kick up and can test that install to see if it works. This is what the MSDOS directory looks like as you can see no fcl-base and this is true for all the memory module directories -

Directory of C:\lazarus\fpc\3.2.2\units\msdos\80286-tiny

11/25/2022  12:14 PM    <DIR>          .
11/25/2022  12:14 PM    <DIR>          ..
11/25/2022  12:14 PM    <DIR>          fcl-stl
11/25/2022  12:14 PM    <DIR>          fv
11/25/2022  12:14 PM    <DIR>          graph
11/25/2022  12:14 PM    <DIR>          hash
11/25/2022  12:14 PM    <DIR>          libtar
11/25/2022  12:14 PM    <DIR>          regexpr
11/25/2022  12:14 PM    <DIR>          rtl
11/25/2022  12:14 PM    <DIR>          rtl-console
11/25/2022  12:14 PM    <DIR>          rtl-extra
11/25/2022  12:14 PM    <DIR>          rtl-generics
11/25/2022  12:14 PM    <DIR>          rtl-objpas

[Thaddy]

read my reply above, posts crossed.

[chobani]

read my reply above, posts crossed.

Ah yes! Even closer now.  Appreciate it, I see that I've added some confusion by mistake here. It's actually StringUtils a sub library that's getting imported, not strUtils which I've been using interchangeably and are obviously not the same thing (sincere apologies, was just kind of staring at it). The code for StringUtils (my version) starts with uses BASE64 and that's where the hang up is. I went through everything and it doesn't seem to have any other issues other than not being able to find it in the MSDOS install. I don't think I can work around not importing BASE64 here without significant pain though...  is this a feasible thing?

 

[PascalDragon]

maybe you are on the wrong foot about fcl-base and base64. fcl base does or should not contain a base64 at all.
Read fcl-base as fcl-basics (minimal required). Base 64 is an encoding to save - which  it does not do very good - space and work around non-printable characters. They are not related.

The Base64 unit is part of the FCL-Base package. The FCL-Base package is however not enabled for the MSDOS target (and some other more restricted targets).

@chobani: I have not tested it with target i8086-msdos, but you should probably be able to simply take the source file of the Base64 unit and copy it to your project.

[chobani]

Just simply saving as BASE642 and renaming the Unit BASE642 worked. I should have tried that. Thank you!

[MarkMLl]

The Base64 unit is part of the FCL-Base package. The FCL-Base package is however not enabled for the MSDOS target (and some other more restricted targets).

So where is that controlled: in fcl-base/fpmake.pp where it says

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

1.     P.SourcePath.Add('src/unix',AllUnixOSes);
2.     P.SourcePath.Add('src/win',AllWindowsOSes);
3.  

and so on? I admit to having trouble understanding how things hang together these days: the manual talks about compiling the compiler etc. manually and talks about either doing it manually or using a Makefile, and it also documents fpcmake... but doesn't say whether this is the ultimate starting point.

MarkMLl

[PascalDragon]

So where is that controlled: in fcl-base/fpmake.pp where it says

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

1.     P.SourcePath.Add('src/unix',AllUnixOSes);
2.     P.SourcePath.Add('src/win',AllWindowsOSes);
3.  

It's controller a few lines further up:

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

1.     P.OSes:=AllOSes-[embedded,msdos,win16,macosclassic,palmos,zxspectrum,msxdos,amstradcpc,sinclairql];
2.     if Defaults.CPU=jvm then
3.       P.OSes := P.OSes - [java,android];
4.  

I admit to having trouble understanding how things hang together these days: the manual talks about compiling the compiler etc. manually and talks about either doing it manually or using a Makefile, and it also documents fpcmake... but doesn't say whether this is the ultimate starting point.

The overall building is controlled by the Makefiles which is also used for the compiler and the core RTL. The building of the packages themselves (and the utils) is controlled in the corresponding fpmake.pp files which is essentially a Pascal code building system. fpcmake (in contrast to fpmake) is used to convert Makefile templates (Makefile.fpc) to Makefiles.

[MarkMLl]

Thanks for that, so I was on the right track.

I've obviously used the makefiles, and continue to use them in other contexts. Apart from anything else I think it's good practice to have a working makefile for any published project... at least for stuff which is console-only.

I was vaguely aware of the fpmake/fpcmake "metalayer" and have tinkered with it minimally in the past- I think that was while fpmake was dominant. A summary like the one you've just given could usefully appear in the docs at some point.

MarkMLl

[PascalDragon]

I was vaguely aware of the fpmake/fpcmake "metalayer" and have tinkered with it minimally in the past- I think that was while fpmake was dominant. A summary like the one you've just given could usefully appear in the docs at some point.

fpmake is younger than fpcmake and is also what powers fppkg.

[MarkMLl]

fpmake is younger than fpcmake and is also what powers fppkg.

Ah. I clearly need to plough through whatever documentation is available... fppkg I'm chiefly aware of because of the insoluble question when trying to start a new instance of Lazarus.

MarkMLl