Problems when cross-compiling for 16-bit DOS

[thelastpsion]

Hi!

I'm pretty new to Free Pascal. I used Delphi briefly about 20 years ago and I remember really enjoying it. I was recently looking for a language/compiler that could target modern OSes and DOS, but I didn't want to use C/C++. Object Pascal and Free Pascal felt like the perfect choice.

I'm writing a replacement for a preprocessor that forms part of an old Psion SDK. I want it to be a drop-in replacement for the original, but also run on modern Linux/Windows/macOS/etc. The source for the project is here: https://github.com/PocketNerdIO/ctran

However, after adding uses Classes; to get TStringList, it stopped compiling for DOS. I get one or more errors when linking, complaining that various code segments are too large for a 64K block. It doesn't matter which memory model I use, I always get errors.

Small Memory Model:

Code: Text  [Select][+][-]

1. Error: Code segment "_TEXT" too large (exceeds 64k by 79732 bytes)

Medium Memory Model:

Code: Text  [Select][+][-]

1. Error: Code segment "CLASSES_TEXT" too large (exceeds 64k by 8976 bytes)

Large Memory Model:

Code: Text  [Select][+][-]

1. Error: Code segment "CLASSES_TEXT" too large (exceeds 64k by 36388 bytes)
2. Error: Code segment "SYSTEM_TEXT" too large (exceeds 64k by 207 bytes)

Compact Memory Model:

Code: Text  [Select][+][-]

1. Error: Code segment "_TEXT" too large (exceeds 64k by 135480 bytes)

I've also attached a screenshot of the terminal output.

It compiles fine with ppcx64.

Am I doing something wrong? Do I need to add some more switches to ppcross8086 to get it to work?

Just so you know, I'm not using Lazarus for this - it's all command line, with NeoVim and an (incomplete) LSP.

Hope someone can point me in the right direction!

Alex

[louis]

Have you tried this switch?

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

1. {$HUGECODE on}

See:
https://wiki.freepascal.org/DOS#Supported_memory_models

[thelastpsion]

Thanks for the quick reply!

I hadn't tried that. I've just added it to the code, both in the main app and the unit. I get exactly the same errors. With -WmSmall, ppcross8086 also says that it's ignoring the switch.

Also tried the huge memory model, just in case:

Code: Text  [Select][+][-]

1. Error: Code segment "CLASSES_TEXT" too large (exceeds 64k by 39635 bytes)
2. Error: Code segment "SYSTEM_TEXT" too large (exceeds 64k by 2669 bytes)

[Thaddy]

I think using classes - or sysutils for that matter, but maybe there is a stripped down version for DOS - do not fit in 64k.
Alternative is using objects, not classes, and FreeVision (FV) as framework.
(also comes with lists etc, but with a different syntax.)

That also reflects the DOS days a bit better   

[thelastpsion]

That's what I was worried about. That's a shame.

I'm planning on removing the need for TStringList anyway, so I might be able to get away without Classes for now. I'll do some experimentation.

I haven't played with objects yet, and I hadn't looked at Free Vision. I'll look at both of those.

Would it be worth trying the 32-bit DOS compiler? I think it's very unlikely that this project will ever run on anything but DOSBox.

[Bart]

For what functionality do you need a TStringList?

Bart

[thelastpsion]

I'm using it with LoadFromFile() to quickly load a text file into an array. I was thinking of changing to parsing the file character by character (better for memory usage), or writing my own equivalent. TStringList.LoadFromFile() just got the job done quickly.

[Bart]

Well if you want to load it as an arry of strings, then readln(afile, astring) and an array is all you need.
TStringList is a nice class, but it can be overkill.
You can create your own TStringList that just does what you need and nothing more.

Bart

[Thaddy]

As  I wrote: the Fv framework contains a stringlist and works similar and is much lighter.
It is practically the same as the TurboVision frame work from the 80's and works perfectly OK under DOS. And it is supported. And is in the standard distribution. And comes with examples.

[marcov]

Enabling a memory model with $hugecode is not enough I think, everything would have to be compiled with -wmhuge, including FPC's only units.

[TRon]

Enabling a memory model with $hugecode is not enough I think, everything would have to be compiled with -wmhuge, including FPC's only units.

Besides that wasn't the hugecode directive not just recently added to trunk (or fixes, can't remember) ?

edit: ah, ic. fixes added hugecode directive for sysutils and classes.

[thelastpsion]

As  I wrote: the Fv framework contains a stringlist and works similar and is much lighter.
It is practically the same as the TurboVision frame work from the 80's and works perfectly OK under DOS. And it is supported. And is in the standard distribution. And comes with examples.

Out of interest, has there been any progress on AnsiString in Free Vision? Just looking at the comments here: https://wiki.freepascal.org/Textmode_IDE_development#ansistringification

[marcov]

Afaik Nikolay put a non legacy TV next to it in trunk, all units have an "u" prefix, which I assume is for "unicode". I haven't played with it yet.

[thelastpsion]

Thanks to everyone for helping me out with this.

I went on a sidequest and ended up building the GO32V2 cross-compiler for Linux. This has worked perfectly with my existing code. I'd like to put something on the wiki about the process, so I'll look into getting an account. In short: build binutils for GO32V2, rename the generated assembler and linker, put them somewhere in your path, grab fpc source archive, build the compiler with the right switches, make crossinstall. Binaries generated by ppcross386 just need a copy of CWSDPMI.EXE to be available.

I am still really intrigued by Free Vision. I've seen that there is FV tutorial on GitHub in German - my German is a little rusty, but I think I know enough to give it a go. I've been gathering links on old TurboVision code that has been tested with Free Pascal. It looks like a great way to build cross-platform text-based interfaces, something that could be really handy for future projects.

[marcov]

The textual ide ("fp") is the best demonstration.