Assistance needed with old Turbo/Borland Pascal 7 project

[Dilan Rona]

Hi

As stated in my title, I have an old library from 1993, by Paul Coxwell. That I need assistance to get working with Free Pacal. If it was just the pascal aspect, I would probably manage. but the assembly portion is completely beyond me.

TURBO PASCAL LIBRARY
Version 2.1, June 1993

I have the complete archive, with all the supporting source code for example programs, the units, the assembly files thats needed. And what I need the most is the ENHCON unit. Will provide it once there is some interest in trying to revive and modernise it. Will also upload screenshots of what ENHCON can do once I get a vm with MSDOS 6.22 up and running with Borland Pascal 7.

[SilverWarior]

If it was just the pascal aspect, I would probably manage. but the assembly portion is completely beyond me.

If the assembly code was written with 32 bit architecture in mind then FreePascal could easily compile it to your application. But if it was perhaps written for 16 bit architecture or relies on working around CPU protected mode such code would probably fail to execute on modern CPU's.

Will also upload screenshots of what ENHCON can do once I get a vm with MSDOS 6.22 up and running with Borland Pascal 7.

Instead of MS DOS 6.22 you may want to try FreeDOS https://www.freedos.org/
Sometimes FreeDOS tends to work more reliably in VM's compared to the original MS DOS. So you may want to check it out especially if you don't have original MS DOS installation floppies handy.

Unfortunately I don't know enough assembly to be much of a hand. But I do have some experience setting up DOS environments on modern computers so I can play some old DOS games.

PS: Perhaps you could even manage to make your old application work in DOS emulators like:

• DOSBox https://www.dosbox.com/ or
• DOSBox-X https://dosbox-x.com/

[Dilan Rona]

FreeDos could do I suppose. But the hope was to get this to work on Linux systems via FreePascal as well.

[Dilan Rona]

Screenshot_20250908_023209.jpgScreenshot_20250908_023309.jpgScreenshot_20250908_023333.jpgScreenshot_20250908_023409.jpg

Some of the screenshots of the ENHCON library. Granted, it can be made easily with FreePascal. But I was hoping to get that old gem working on FreePascal.

Screenshots are all from VirtualBox running MSDOS 6.22, with Borland Pascal 7 installed (with the RTL library fixes added in).

[SilverWarior]

While I'm not sure I would be able to help you I would still like to see the code of this unit. Mostly I'm wondering why would someone need to use assembly code just for creating these text based windows.
I'm guessing one might use assembly code to intercept keyboard or perhaps mouse interrupts on hardware level. As far as I know these are not supported by CRT.pas unit that would otherwise be used for creating and managing text windows.

[Dilan Rona]

http://annex.retroarchive.org/cdrom/...AL/TPLIB21.ZIP

That is the project in its whole. The exe file in the archive is a self extracting zip, and you need to run it with MSDOS 6.22, or another 16 bit dos operating system. I got it extracted on my end allready. And provided archives for TPLib v 2.0, and 2.1 as well (see zip file attached for decompressed code).

Best I could maybe do is make a recreation of ENHCON (but it will be a poor recreation. Especially if it looses the speed that the original had for its time). But in my opinion, it would make for a great addition to FreePascal.

Thanks for being interested in this gem as well

Dilan

[SilverWarior]

The exe file in the archive is a self extracting zip, and you need to run it with MSDOS 6.22, or another 16 bit dos operating system.

Since the executable files are Self-Extracting ZIP archives all you need is a good Compression application like WinZIP, WinRAR or 7zip and you can extract the archived files from that executable with ease. No need to be running ancient OS

Best I could maybe do is make a recreation of ENHCON (but it will be a poor recreation. Especially if it looses the speed that the original had for its time).

I have just looked at the enhcon.pas and the two Assembly files that it directly depends on.
The CRTKB.ASM is just used to retrieve the status of NumLock, CapsLock, ScrollLock, and status if InsertLock (whether writing on keyboard will insert or overwrite characters on screen) and procedure to Flush Keyboard buffer.
The CRTVDU.ASM most complex function is GAcheck which checks the type of the graphics adapter that computer uses. It does so by using BIOS display code service. Now unless you want to compile application to run on some ancient hardware with MDA, EGA or CGA graphics card you could easily assume that VGA is supported. It does also contain routines which seems to write directly into display text buffer. I would be seriously surprised if FreePascal does't have equivalent or similar routines as part of its dos based units.

But in my opinion, it would make for a great addition to FreePascal.

Based on what I have seen in the source doe I might disagree with that. Don't get me wrong. For that time this was pretty awesome code.
But for nowadays. Well. Those ASM files rely on the fact that the application will be ran on an IBM/PC compatible device. Running it on any device that no longer supports direct access to the graphical interface though BIOS and the application will fail miserably and probably freeze your computer entirely.
Also when I was looking though ENHCON.PAS I can see that the entire code is written for working with ANSI strings and using British codepage. So forget about showing any special characters from other languages. This means that such code could only be used in English speaking world. Heck I doubt it would be even able to handle the German ä ö ü or ß characters. And German is amongst top most popular languages in computing.

I'm however impressed with the code logic that handles text windows and their layering. It seems quite clever approach to store the contents of each separate text window into heap so you can access contents of each one without the need for constantly accessing graphical interface memory. Back in the days graphical memory was pretty slow and if I'm remembering correctly when writing you had to write the entire screen buffer at once. It was not possible to update only part of the buffer. I never did any programming for dos so I may be wrong about this.

This project also contains some string handling units but they are limited to old non referenced strings while FreePascal already has built in string handling routines that are far more capable than these.

Any way if you manage to rewrite enhcon.pas unit so it no longer relies on the assembly code that is limited to specific hardware and so that it can handle Unicode strings while maintaining the overall logic of text windows I'm sure many people might get interested in it especially from Linux world where many applications are stil text based. And if you enhance the code so that you can define the size of the text buffer (instead of relying on predetermined sized from EGAC, CGA, VGA graphics cards) to match the actual size of the text display this could become useful for those that use FreePascal for developing applications for embedded computers.

PS: While writing this answer I stumbled on a very old question about porting and old DOS application that is writing directly to Video buffer so that it can be compatible with newer systems: https://fpc-pascal.freepascal.narkiv...console-buffer
If you decide to attempt rewriting this code so that is compatible with FreePascal it might help you get started.

Also i suggest you go and check every file event the ASM files. The author of this library has commented his code very well. Yes even assembly code is well documented.

[Dilan Rona]

I havent touched pascal properly for years tbh, and have never learned assembly. hence me coming here to ask for assistance. besides, the ENHCON unit also uses the supplied strings unit. so its not just 2 assembly files it relies on, but an additional 6. Besides, if I do recode this to a more modern FreePascal unit, I dont want to loose the speed the library has. Which is why I recommend you try it with 86box and one of its emulated pc's. You get close to the native speeds of the hardware back in the 1993 days. And you can get a feel for how fast the code is then.

Also I do agree with you that this would be a huge asset to the linux communities who do make text based programs. Hence me posting that gem here. It may be of use to someone here.

Since the executable files are Self-Extracting ZIP archives all you need is a good Compression application like WinZIP, WinRAR or 7zip and you can extract the archived files from that executable with ease. No need to be running ancient OS

I'm a bit old school, and like to do it the hard way ;-)

[SilverWarior]

I havent touched pascal properly for years tbh, and have never learned assembly. hence me coming here to ask for assistance. besides, the ENHCON unit also uses the supplied strings unit. so its not just 2 assembly files it relies on, but an additional 6.

Yes I have seen those string handling routines but as I have said I doubt they could outperform the modern way of string handling that is now built into the core of FreePascal language. And most importantly the modern string handling is not limited to non referenced based ANSI strings that these units are.

Speaking of performance you might want to check the next video.


While the video is not directly focused on Pascal language it does talk quite a lot on how modern CPU's increase performance in general. It also shows an example of how modern compiler can sometimes significantly improve performance by actually replacing part of the code that developer wrote with a different code that wold return the same results but in a different more performant way.

What I'm trying to teach you here is that having old assembly code doesn't necessary mean it will outperform modern code.
I mean this library is from 1993 for Turbo pascal 2 that was released in 1984. Meaning that even at a time this was library for a very old Turbo Pascal version especially if you take into account that Turbo Pascal 7 released in 1992.
Do you think that in all these years the Pascal language hasn't got any optimisations and improvements. You would be gravely mistaken.