Given that today’s a public holiday and I have little else to do today, it’s a good chance to dive in to Clipper and see what can be done about some printing issues.

Starting again with Clipper

With the DataTech program it has issues when a Harbour-compiled version of it does printing. It’s use of IsPrinter() is nearly useless these days because it just checks LPT1, and doesn’t take in to account any spooling that windows uses on printers, so ft_print looks to be a suitable replacement for it from  the NanForum Toolkit which does a better job of things, and can handle lpt1 through to lpt3.

NanForum Toolkit

After an hour or so of digging around, eventually the source files nfsrc305.zip and the library files nflib305.zip are available from The Oasis library. A patch too is available, for which lib.exe is required to apply the patch, but that seems to be a part of an older version of visual basic. Some sites say lib.exe is available as a part of the Windows SDK, but after installing several versions of it there’s no trace of it, or even of link.exe which could be used instead. It seems that lib.exe only comes with older versions of software such as visual basic, and too much time has been spent already chasing down this rabbit hole. The patch doesn’t need to be applied at all for what we’re doing here so given that half the afternoon is already gone, it’s time to focus on more productive things.

32-bit virtual OS

I just have 64-bit operating systems on my desktop and laptop, and need a 32-bit one to run Clipper and the compiled version of the code. My reason for wanting to use Clipper instead of Harbour is that a print problem happens with the Harbour version of the code, so I want to use the Clipper version (which can’t run on 64-bit) to figure out what should be happening instead, and to also confirm that any changes to get the Harbour version working don’t result in breaking the Clipper version.

So setting up a virtual 32-bit development environment is the next thing to get sorted out. Eventually after installing a 32-bit version of vista (I won’t track down a 32-bit version of xp or 7 just yet), I work through a complicated series of steps to install clipper, harbour, sublime text, the printer, and configuring them all, so that I’m at last ready to compile and develop for Clipper. After setting up autoexec.nt and config.nt which apply when running dos-based programs and command.com, but not cmd – and it’s just gone 9pm.

One of the printing problems involves printing out to a text file. It seems that a problem occurs around a IsThisADir() function that comes from the DIRCHANGE() Function page, which I find to be due to using version 5.2 of Clipper when version 5,3 needs to be used instead. Okay – so upgrading to 5.3 is next to be done. It shouldn’t be that hard. I mean, hard can it be?

clarkson

Upgrading to 5.3?

Installing 5.3 wasn’t all that tricky, but setting up the environment variables certainly had its issues. There were ones pointing to locations in c:\clip\clipper5\lib\ and others pointing to places in c:\clip\clipper5.2\bin\ and we now have locations in c:\clip\clip53\ – and to make things worse, web-based examples use c:\clipper5\ instead. It’s time to get to work.

The computer environment variables for path, lib, and include all need to be changed, as well as the autoexec.nt file, and a few other batch files, so that all use a c:\clipper5\ folder. Moving Clipper 5.2 to that new location results in everything still working and compiling fine.

Replacing it with the 5.3 contents I find that I can’t link the code together anymore. RT-Link doesn’t come with 5.3, but instead there’s a different one called Blinker, so further time and learning occur as I figure out the syntax to use for it. Eventually I get things linking together, only to be told when running the program that we’re out of memory.  It seems that this early 1.0 version designed for Clipper 5.3 doesn’t have much in the way of extended memory assistance, and so Blinker is not likely to be a viable solution unless I can get a hold of a more recent version.

CauseWay linker

In the meantime I find out about an open-source linker called CauseWay does a better job than Blinker, so I install that and give it a try. CauseWay is in fact a much better linker and can replace RT-Link and Blinker, along with a wide range of other compilers. But, CauseWay doesn’t seem to want to work due to a “non-standard protected mode program already active” issue. Could this be due to Vista? I see elsewhere that CauseWay works fine in XP but no mention of vista exists.

What if I give CauseWay its own environment using DosBox? It runs there, but there are some issues with some parts of the DataTech codebase that it’s not happy with, and the time has gone well past 1am so further investigation must be held off for now.

I haven’t even started looking in to the issue that I was going to investigate at first, but when dealing with a 30-year-old programming language these are the challenges that are faced.

Advertisements