Getting Behold Running in Delphi XE8 - Mon, 6 Jul 2015
Last post, I updated my development tool and installed new versions of my three 3rd party applications. Now it was time to get Behold working again in the new Delphi XE8 environment.
Theoretically, if all updates made to an environment are backwards compatible, then old code would just run unchanged in the new environment. But they seldom are. Work needs to be done to convert.
To get started, I included the 3rd party packages without my customizations to see if what was left would still run. Then I compiled, and knowing that there was little likelihood of it working, I got:
2 Errors, 5 Warnings, 1 Hint
One error was an incompatible type between Integer and TRVTag. This was a change I remember reading that RichView had made a few years ago to use strings instead of integers for their tags. The second was the error aborting the compile because it couldn’t compile the unit. For now, I just changed the declarations to eliminate the error and proceed.
That doesn’t sound so bad for a first attempt, to have only 1 error. But I know how these compilers work. You fix one error and the compiler can then look at more code. Sure enough, after I fixed it, I now had:
16 Errors, 5 Warnings, 2 Hints
EurekaLog was now the culprit. The errors indicated major changes to that package, and indeed when I checked out their site, I found that Version 7 was almost completely rewritten.
I wasn’t trying to get EurekaLog to do much. It was passing information from unexpected errors to a special form I had set up for that purpose. I looked to see what changed, and it wasn’t simple. I always give myself a couple of hours to see if I can figure out any problem. I go through their documentation and try various things. If stumped I might check StackOverflow and maybe ask a question there about how to do it. But I could not make any headway on this, so I went to the next step and submitted a support ticket on the EurekaLog site with my problem and requested a method to fix it. I got a response quickly, within a couple of hours (on a Saturday!) and that answer led me to some good examples, but they weren’t quite enough to help me. So I added to my ticket and while waiting went back to fix the rest of what wasn’t working.
I commented out the offending EurekaLog statements and that allowed Behold to compile and run. It was nice to see Behold running from XE8. It ran fine, looked fine (except for a minor problem with the toolbar icons), and did not have any obvious problems.
There were still lots of warnings and hints to fix. These included fixing declarations, replacing a deprecated symbol or routine with another, and new messages about possibly uninitialized variables that the XE8 compiler was picking up that 2009 didn’t.
I worked my way through the most important compiler warnings and hints. In doing so, I must have recompiled the program 200 times over 2 days, finding and fixing things that worked under the old environment but not in the new one. I finally managed to get through them, leaving only a few hints about variables that are only valid on some operating systems.
With everything finally working with 32-bit processing, it was time to try 64-bit.
On my first 64-bit compile, I was quite surprised that there were new errors. The 64-bit compiler must have different checks in it. For example, one warning that came up was for code that I’ve had in place for as long as I can remember. It had never given me a message before. It was:
N := MaxN; { Execute the loop at least once }
while N = MaxN do begin
…
N := …;
…
end;
The warning message on the first assignment statement was that the value assigned to N was not being used. 32-bit compilation never gave me this. 64-bit must optimize differently. So to eliminate the warning, I changed this to:
repeat
…
N := …;
…
until N <> MaxN;
There were a bunch of little fixes like this I could make. But then I was getting errors again. The 64-bit compilation wanted me to address the RichView change of their tags from integer to string values. I was going to try to use a setting in RichView that allowed using the old style, but then I found the 64-bit compiler was not accessing those settings. I posted a query on the RichView forum. While waiting for a reply, I found that using the old style was not recommended, so I decided to go through the work and change it. It took me a few hours to update what was needed here. Once I did, Behold was able to compile and run in 64-bit.
The last thing to do was to add my customizations back into the RichView and ElPack routines. I had customized a 3 RichView units and 4 ElPack units to enhance them to provide some functionality I needed for Behold and to fix some bugs in them. There were changes to 7 different units. They represent dozens (maybe even hundreds) of hours of work I spent many years ago to isolate problems or limitations in these packages and figure out how to get them to work the way I needed.
I had delineated all my changes clearly with comments in my customized units, so they were easy to find. One of my typical changes looked like this:
{ LK - Jul 15, 2012 : Start of code to allow invisible text }
const
rvInvisible = 21; {= rvInvisible in _links.pas}
{ LK - Jul 15, 2012 : End of code to allow invisible text }
Now the question was, how much did these units change in 7 years? Fortunately, these were mostly low-level units with core functionality. The new version of these units did not change much from the old version, and I was able to simply slot my customized code back in, occasionally with minor modifications. I had the RichView units working in just 15 minutes.
But then it took me 2 hours to get the 64-bit version compiling. Some sort of strange dependency in the use of one unit by another was only revealing itself one unit at a time. And this was just in the 64-bit compile, not the 32-bit compile. It was very strange. I never did figure out what this was, but I thankfully reached the end of the loop after going through only 60 of the 200 units.
I stumbled a bit while updating the ElPack units with my custom code. In the ElIni unit, which handles reading and writing the Behold Organize file, the ElPack unit did not read ASCII files properly. I had the customized code to do this correctly. But it did not seem to be working. I installed, tested and removed that code 3 or 4 times. Behold was not reading any of the information from the customized Behold file at all. Then then it hit me. My code wasn’t what was wrong. The customized Behold file I was trying to read was empty. There just wasn’t anything to read. I kicked myself about this oversight. Only cost me 2 hours.
So that was it. Behold is now all updated and is now pretty well working under my new Delphi XE8 environment. I’m still waiting for the EurekaLog support message and I’ll get back to that later.
At this point, I couldn’t help myself. I just had to do run some comparisons of Delphi 2009 performance versus Delphi XE, and then of 32-bit performance versus 64-bit performance. The results were interesting:
Compared to the current Behold Version 1.1 release (which was compiled with Delphi 2009), the new 32-bit compilation under XE8 is about 30% faster and uses about the same memory.
Then I found that the 64-bit compilation is about 12% faster than Version 1.1, but is about 18% slower than 32-bit speed. And 64-bit uses almost 50% more memory.
This surprised me. My computer has a Windows 64-bit operating system. I would have thought 64-bit processing should have run faster than 32-bit processing on my machine, but I guess the manipulation of all that extra memory the 64-bit program takes also adds a time penalty.
Once I convert Behold’s in-memory data structures to a true disk-based database, that will eliminate much of its memory use. Then time will be more dependent on 32-bit versus 64-bit database access. Once that’s done, I’ll recheck these results and won’t be surprised if 64-bit happens to emerge as the winner.
Leave a Comment
and $$, do come and join me. 
Older Entries
RSS
Feedspot 100 Best Genealogy Blogs
Tamura Jones
