Saturday, January 23, 2021

Porting an application to Windows 10/Delphi 10.2 (part 3)

I thought that I was long done with this activity, but I was overly optimistic. The OP bought a new computer that will function as their server; as this is running Windows 10, I had to ensure that my new unicode program would work properly on this computer. Obviously it doesn't, as otherwise I wouldn't be writing this.

Every attempt to run the program on the OP's computer would bring up the error message 'Unable to load dbxfb.dll (error code 193). It may be missing from the system path'.  First of all, I had to find the dbxfb file; I looked high and low before I found it on my mobile computer in one of the many directories that Delphi had installed. I then copied the file to the OP's computer but this made no difference. 'System path'? I found where Windows maintains its environment variables (a hold over from DOS) and updated the 'path' variable to point to directories where I had copied the file. Still no luck. I considered this issue for some time and came to a tentative conclusion that installing Delphi on the target computer would help; I did this but with no change.

This left me with no option but to turn the question over to Stack Exchange. The first answer had me bewildered: it said that I was using a 64 bit dll with a 32 bit program or vice versa. After digging around a bit more, I discovered that indeed there were two different versions of dbxfb.dll in the Delphi directories: one in a directory called bin64 and one in a directory called bin. Either by design or mistake, I had copied the 64 bit version; replacing this with the 32 bit version improved matters slightly: the original error message had disappeared. But now there was a different error message!

A comment to the SE question suggested that I look at the SQL connection component; there I found the reference to dbxfb. But now, running the program on my own computer would bring up gibberish in the a certain place. I added a definition 'utf8' to the 'server charset' parameter of the connection's params array and redefined the strings that appear in the affected grid: finally the strings appear in Hebrew. I quickly copied this version of the program to the target computer - and it worked!

Unfortunately I didn't manage today's work in a scientific manner so I'm not sure exactly what the magical invocation was that made everything work. My tasks now are to complete redefining the strings displayed on the grid (the 'utf8' definition seems to have caused changes), copy the program to the target computer and check everything there. 

No comments: