zack wrote:Do you mean I should create a 32 bit application (separate process) which used the SDK. And then I communicate with this process via... TCP?
You got it. As you mentioned you can't call a function in a 32bit DLL from within a 64bit process. But calling functions that can be dynanmically loaded into your application or process is the crux of Dlls. Remember that the abbreviation stands for (D)ynamically (L)oaded (L)ibrary. And a library in the early days of C, Unix and Windows was a set of bundled functions. It was created (and compiled) once and used from many applications that all needed to execute the same task.
In other words the strict borderline between 32bit and 64bit undermines the whole concept of a Dll. Nevertheless, as we live in a networked world the concept of calling functions or procedures in third party code (Dlls), that had to be installed on your computer was mirrored to cloud or remote computing. This means that the installation part was skipped and instead the interface for calling functions was made more capable and also more complicated.
Remote Procedure Calls were born. The complexity was under the hood in the lower layers. For the normal user and developer it was just like calling a function outside your own code.
But instead of executing code that was in a Dll installed on your computer the remote procedure call started a network connection, serialized your input parameters and sent them over the network to a remote computer, that deserialized the received data back into objects and did the requested processing on these objects. When done it serialized the result and sent it back to the initial computer where the result was de-serialized into a object again and was presented to the calling part.
For the initiating side the input parameters and the resulting object was conceptually the same as if it had called a function in a (local) Dll. Of course because network communication was involved in the remote procedure call it is more sensitive to errors and also slower by magnitudes.
Microsoft's DCOM or CORBA (or in newer times SOAP) are all some kind of implementaions of Remote Procedure Calls (RPC).
To make a long story short: Whereever you have a border either between a local and a remote computer or between a 32bit subsystem and a 64bit system, you have to implement some kind of serialisation for communication between them. Because the existing techniques for Remote Computing (DCOM, CORBA, sockets, ...) are well tested you do not re-invent the wheel but use these techniques for communicating between 64bit and 32bit.
The UNO library of OpenOffice was
notplanned for this kind of inter process communication and this means that you have to add this part. And it has to be done for each method or object of UNO that you want to use from your 64bit application. That is an awful lot coding that you would have to do. A team of 40 developers might complete it in 1 years time ... just to give you an estimation.
It is surely easier to check if the existing (D)COM interface of OpenOffice can serve this purpose. If yes, you will only have to code the part on the 64bit side of your application.
But I have heard that there are experimental projects that try to compile OpenOffice for a 64bit windows environment. In that case you could use 64bit Dlls of OpenOffice and all your problems were gone ... if the experimental compiled 64bit OpenOffice code is stable enough.
Frankly, I think I have just repeated what I have said in my last post ... maybe in other words. Hopefully it is now clearer for you.