The DLL support for Harbour is also ready, and in the same way we are used to, and not in the way Harbour imposes.

Until now, the DLLs made with Xailer and xHarbour were sustained on the VM and RTL of the executable, so the DLL was extremely small (no VM and RTL inside), and they perfectly integrate with our programs. A good example of this are the IDE and xEdit plugins and third party components that can be used inside the IDE.

Unfortunately, Harbour does not let you do it that way. Harbour only supports two types of pCode DLLs: with the complete VM & RTL inside of it, or depending on a external Harbour.dll.

On the first case, the DLL will be too big, since it includes all the Harbour libraries, besides all the problems due the fact that the code is running on a second VM, so in a different context of the main executable. This kind of DLLs are normally designed to be used with executables done with other programming languages or programming tools. And for that reason is the need to include everything on them so they can run by their self without any collaboration from the executable.

On the second case, although they are designed to be executed by a Harbour program, they have the big inconvenience that we must distribute Harbour.dll, that normally is larger than what we really need (All Harbour is inside of it), besides the fact that we must also create our executable using that Harbour.dll (on contrary we would use two VM at the same time). On our case is even worst, because we should also include a Xailer.dll with the complete Xailer RTL inside, so its accessible by any DLL and the main executable, that of course, should also be distributed with your programs.

Well, to be honest, Harbour also supports PCode DDLs that use the VM inside the executable, but only if the DLL contains PCode and doing some little hacks. But, in the moment the DLL includes any Harbour API function, they become completely useless. And I’m afraid this happens almost every time. As soon you create a C routine you are dead 🙁 since you surely will use hb_par*() or hb_ret*() functions. So, this option is not good for us, since in the practice it offers the same and with same limitations than .HRB files. For example, it will not serve to create IDE third party controls, since normally there is some (or a lot) of C code.

Fortunately, in Xailer, we have achieve what we really need: Small DLLs, sustained on the executable VM and RTL, what we already had running for years in xHarbour and exactly with the same facility: just need to check the ‘DLL’ option on the project properties and that’s all.

Now, the next step is the debugger, besides of course, of the complete code debugging of Xailer for Harbour libraries. As you can see, there is a little time to get everything done 😉

XAILER FOR HARBOUR IS READY!

Well, to be honest, almost ready. A few details besides the complete debug are missing. But the 90% of Xailer is working nicely. Both the Xailer kernel and the OOP extensions have been ported with complete success, the complete Xailer run-time library, with all its controls, data source, and so on. The only things missing are the DLL creation support and the debugger, but we are already working on that. Also the IDE has been modified to be able to compile any project with xHarbour or Harbour (3.0).

For now all is done with BCC++. We have some code passed to MinGW, but on this first stage we want to make it work with BCC++, and when all is tested and we are sure everything works as expected, then we will make the jump to MinGW.

All our tests we have done so far are satisfactory, and we have check that the programs run a little bit quicker, consume less memory and the executable is a little bit smaller. Is not easy to give any statics, since it depends on how you do the test; some times you will gain more speed and less in others. However on a Ad-hoc test, we have achieved a speed increment of 75% against tje actual Xailer with xHarbour, which is not bad. This does not mean that your programs will run a 75% faster, since on any program there are many factors that can affect the performance, and only the operations that affect the OOP engine will be 75% faster. On the other hand and in general, Harbour is faster than xHarbour, so the improvement is guarantee.

On the jump to Harbour, we have try to minimize the possible differences between both compilers, so they do not affect to much on your actual Xailer programs. But I’m afraid some problems have been impossible to overcome, and every programmer must check all its programs to adapt them. In any case the changes are few and easy to fix. Here (in Spanish) you have a list will all the differences found from ourselves on the migration process. And here it is the official difference between both compilers: xhb-diff.txt.

Finally, although we have said on some occasions that Xailer 3.0 will work only with Harbour & MinGW, we are considering the possibility to publish a new version of Xailer 2.7 that will support xHarbour & Harbour through BCC++. The main objective is to debug Xailer & Harbour ASAP and your help can be great for that. If, in addition it serves to users that would like to recompile their programs taking the advantage of the best Harbour performance. If you want, you can use the comments to give us your opinion.