I should feel more relaxed now that I demonstrated that the program builds, can run and, best of all, can print. But I’m not.

The original program had 16 executables. One is the main menu that I already compiled (but not fully tested), one is the Utility menu, that was merged into the main menu, but only for a couple of operations.

Now I think I face the biggest problem: one by one merging all the other executables source code. Now that the basic functions are working I think that it is better to work on the biggest external program, the one the accountant spend the most part of their day: the form to load data in the db.

This form is composed of several sub-windows, each with its own way of work, several function keys always active, tons of lookup tables, popup windows… it is a real pleasure look at the lady loading data typing on the keyboard at light speed, TABs, cursor keys, function keys: she knows the exact sequence to type.

I decided to split the job in two parts. In the first I will compile the program as is, like an external program, just to see if it compiles and, expecially, links. The second is to merge the code into the main one.

As done before, I hand converted the blinker style .lnk file to Harbour .hbp file. I then added the libraries and tried to compile. There was one error in compiling, a RETURN statement nested in a BEGIN SEQUENCE that I remmed just for testing, and several missing functions. I counted 7 missing functions and looking at how they were used, some of them looked complex. Time to decompile again. I was able to recover all of them and I added it to the applib.hbp file. I alse recovered a couple of functions I had to rewrite from the main menu executable.

I had to iterate the process twice since the recovered functions called other functions I hadn’t recovered yet. Finally both main executable and this new one compiled and linked without errors.

Testing the new executable is very easy: it just needs to be run with its current directory set to the client/year subdirectory. Simple. The program started with no problem and it seems to work: I can input data, lookup table appears, all that strange popup just keep popping up but I don’t know what to write in there. Just one note: it seems that some popups doesn’t restore the underlying screen when they close. I know that some windows related functions are just stubs, empty functions with no code. I will check that later.

One more thing to note is the RETURN inside a BEGIN SEQUENCE. I don’t know why it was allowed in Clipper 87 and it is no more. What makes me feel a bit worried is that BEGIN SEQUENCE is on line 300, the RETURN statement on line 604, the END SEQUENCE on line 1568! With a nested BEGIN/END SEQUENCE and several BREAKs. It will be a long night the one I will work on this.

Terminated succesfully the first part, I started the second, merging the code. Well, actually I added the new hbp files to the old. And compiled forcing a full rebuild.

I got 51 (FIFTYONE) duplicate functions! Until now I was fighting for missing functions. Now I need to fight with duplicate functions!

I don’t know why there is this situation in the code. But as I already said, the application library is without sources, and it is the only lib. Probably the programmer didn’t know how to create a lib. Or had some other obscure need to duplicate them.

These errors messages are like an alarm ringing in my head: why so much duplicates ? Are I really sure these are real duplicates?

Let’s check.

The first duplicated function reported is lockok(). I open the 2 source files and discover immediatle that no, they are not equal. Worst, a grep reveals that this function is defined in THREE different source files, and used in 7!

The second duplicated function is a callback function of a browse. Each one is defined and used in the same source code, so I could simply add a STATIC in front of them. In no other source file there is their name.

But for the first one, what to do? The only “easy” solution is to change the functions name with a prefix of the executable they were from, info that I need to extract from the .lnk files. As I said the function is defined in 3 files and this means there are 3 executables involved. So, it is easy to change the name of the functions defined and used in the same source, but I have to search for the other 4, which executable they are linked in.

This is the most important program and I have to solve 51 duplicates. In the process I need to solve more, like the first one that I saw is present in 3 files. But what will I find next, working on the other executables? Will I find dozens more duplicates?

Should I keep the executables distinct and find a way to set the working directory? It can be as easy as adding a memowrit() to save the working subdirectory and a memoread() to read it back…

I have to think about it.