molly,
I am sure that the loadlibrary works, because it returns a valid handle, although, it returns a non-zero handle, which it does not if it cannot find the library. There is also no reason to doubt it could not load the library. It is a valid library, like many others, and it is well tested (see my C-program I published yesterday in this discussion). I think we can trust that step.
So the problem is in the getProcAddress and the parameters it gets. I used to be quite good in pointers to pointers, and so, but not anymore. For over fifteen or twenty years, I have worked with programming environments which hide these kind of things. So I lost my talent to solve these kinds of things. And I am not sad about that.
That is why I am writing here. I was hoping that this kind of question would be a piece of cake. I was hoping that there were tons of example-programs which load unix-libraries, from which we can learn. But it seems to turn out that I have bad luck.
You say that the code I pointed to was wacky, checking if a pointer is nil? I think the writers are used to OO thinking, where not initialized objects are nil? But their code works on Windows. Maybe Windows is more permissive?
The JNI layer would be very useful to me. It would give me the opportunity to have really fine JVM-libraries available for FPC. This could be very useful, also for the FPC/Lazarus community. Not for using every micro-second., it would be too slow, but for transferring complete jobs/algorithms to the "other" side.
Why would one want to do that?
For Java (and other JVM languages) have lots of academic use, there is so much knowledge available and for free, while FPC has it strong points too. It is fast, and easy to use as a RAD environment and it hides platform dependencies in code. Both are a strong pair, which give lots of opportunities.
The academic knowledge which is available in JVM languages, one can always rewrite that in FPC. But that feels like reinventing the wheel, but then in an uneasy way.
There are other ways too to connect to a Java-environment, for example, a small internal REST mechanism. The boilerplate to do that can be generated, also from the Pascal side. I think that can work too. But I kind of hate that solution a bit. It feels too much as not being connected, and modules living apart on a network connection. But it also has advantages in context of scalability.
So, I still hope, someone is able to solve this problem, which I cannot solve, and if not, I am already preparing plan B. I have to. My product needs it.
Recent
