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 😉