Using SDK inside a 64 application (C++, Windows)

Java, C++, C#, Delphi, ??? - Using the UNO bridges

Using SDK inside a 64 application (C++, Windows)

Postby zack » Fri Jan 30, 2015 3:56 pm

There seems to be no official 64bit version of the SDK nor the application itself.
Is there a way to use the 32bit sdk in a 64 bit C++ application?
OpenOffice 4.1 on Windows
zack
 
Posts: 9
Joined: Fri Jan 30, 2015 3:50 pm

Re: Using SDK inside a 64 application (C++, Windows)

Postby rudolfo » Sun Feb 01, 2015 3:53 am

The general answer is NO as this MSDN article says. My experience is that executing 32bit code on a 64bit MS Windows system is very similar to running the 32bit code in a virtual machine on the 64bit host. Actually Microsoft calls it subsystem or Windows on Windows (WOW) and in fact the separation is not strict as in the virtual machine scenario. Nethertheless a 64bit process can't load 32bit dlls (like the OpenOffice library code) into its own process room. It can start a second process (which can be 32bit), but this means that you have two processes and you need to have Interprocess communication (IPC) methods in order to exchange data: Remote Procedure Calls, Sockets, Named Pipes, etc.

The OpenOffice Dlls are not equipped with such an interface and hence you have to build an wrapper layer for the OpenOffice library Dlls for the 32bit side of this interface and your application, that you program anyways has to implement the other side of the interface in 64bit code. Or in other words you have to do extra programming for each method call in the OpenOffice UNO API that you want to use. Surely not much fun!

There is a small chance that you can get the features easier. COM/DCOM is not that strictly bound to the separation between 64 and 32bit. See this blog post about how to start it. OpenOffice offers a COM interface on Windows, but as you know OOo is a multi-platform application and as COM can only used on one platform and not on all 4 or 5 it got less man power as the core parts of OpenOffice. Its COM support is limited compared to MS applications like MS Word and it might need additional work around beyond what is described in the blog post.
OpenOffice 3.1.1 (2.4.3 until October 2009) and LibreOffice 3.3.2 on Windows 2000, AOO 3.4.1 on Windows 7
There are several macro languages in OOo, but none of them is called Visual Basic or VB(A)! Please call it OOo Basic, Star Basic or simply Basic.
rudolfo
Volunteer
 
Posts: 1488
Joined: Wed Mar 19, 2008 11:34 am
Location: Germany

Re: Using SDK inside a 64 application (C++, Windows)

Postby zack » Tue Feb 03, 2015 7:17 pm

Thanks for your answer rudolfo.
What do you mean with wrapper? 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?
As far as I know, I cannot create a 64 bit DLL which uses the 32 bit DLL of the SDK?
OpenOffice 4.1 on Windows
zack
 
Posts: 9
Joined: Fri Jan 30, 2015 3:50 pm

Re: Using SDK inside a 64 application (C++, Windows)

Postby rudolfo » Wed Feb 04, 2015 1:21 am

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.
OpenOffice 3.1.1 (2.4.3 until October 2009) and LibreOffice 3.3.2 on Windows 2000, AOO 3.4.1 on Windows 7
There are several macro languages in OOo, but none of them is called Visual Basic or VB(A)! Please call it OOo Basic, Star Basic or simply Basic.
rudolfo
Volunteer
 
Posts: 1488
Joined: Wed Mar 19, 2008 11:34 am
Location: Germany

Re: Using SDK inside a 64 application (C++, Windows)

Postby zack » Wed Feb 04, 2015 4:28 pm

Ok I try to use the COM way. I was able to load a document in Writer.
Code: Select all   Expand viewCollapse view
CDispatchPtr serviceManager = new CDispatchPtr(L"com.sun.star.ServiceManager");
CDispatchPtr desktop = serviceManager.Invoke(L"createInstance", L"com.sun.star.frame.Desktop");
desktop.Invoke(L"loadComponentFromURL", QUrl::fromLocalFile(fileName).toString().utf16(), L"_blank", static_cast<long>(0), dummy_array);


My problem is now, where can I read about all the interfaces (properties, members etc..)? E.g. what arguments loadComponentFromURL need.
I found something here:
http://pn.org/wordpress/?p=18 But this is not officail...
Where is the official documentation of the COM interface. A colleague told me that there must be some kind of TBL file, where I can read about all interfaces.
Or maybe you know which person is responsible for this module.
OpenOffice 4.1 on Windows
zack
 
Posts: 9
Joined: Fri Jan 30, 2015 3:50 pm

Re: Using SDK inside a 64 application (C++, Windows)

Postby rudolfo » Thu Feb 05, 2015 2:35 pm

The OpenOffice COM Automation doesn't come with a type lib. It only supports late binding. No intellisense or any of the nice IDE features available. But this doesn't matter. Any of the available interfaces is simply a wrapper around the core UNO objects. Most of them have the phrase bridge in their name (Python-To-UNO-bridge, Automation-bridge-to-UNO, ...) to indicate this. In other words the official documentation of the COM Automation is the UNO API reference. You work with the UNO objects, set their properties and call their methods. That's the same in all programming language. The only difference is how you have to build structures like com.sun.star.beans.PropertyValue. That's a no brainer in StarBasic, more complicated in Python, Java or C# and very complicated in C++.

There is a COM automation tutorial on www.openoffice.org. As it is located on the official OpenOffice domain you might call it official. It explains a bit how to create such parameter structures in VB or VBA for COM.

Other useful resources are Programming OpenOffice.org with Visual Basic or anything that you find from Bernard Marcelly in the forum.
OpenOffice 3.1.1 (2.4.3 until October 2009) and LibreOffice 3.3.2 on Windows 2000, AOO 3.4.1 on Windows 7
There are several macro languages in OOo, but none of them is called Visual Basic or VB(A)! Please call it OOo Basic, Star Basic or simply Basic.
rudolfo
Volunteer
 
Posts: 1488
Joined: Wed Mar 19, 2008 11:34 am
Location: Germany


Return to External Programs

Who is online

Users browsing this forum: No registered users and 4 guests