how to connect to com object "outside" from wine?
Hi (I'm new in that group and don't know much about wine, so I'm sorry in advance if my question is in-proper) Here is my problem: I wrote in windows com object, and registered it in wine using regsv32 utility. I also wrote a com client application. When I executed the client code using Wine, all was just OK, and the client successfully make a reference to the server and activated It. :-) my question is there any way to write a client on the native (Linux) using g++ and activation the com object? does it make a difference if the com object id a dll, exe, or ocx ? 10x Yonatan __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools
maman yonatan wrote:
my question is there any way to write a client on the native (Linux) using g++ and activation the com object?
Currently only a Winelib-App can do that look at http://winehq.org/site/docs/winelib-user/index for what that is. How ever if you're client is written in ATL or MFC than that is a different problem and it will be harder to do.
does it make a difference if the com object id a dll, exe, or ocx ?
ocx is Just a special case of dll. exe is what is called an out-of-processs server. It is heavier and slower but has the advantage of being able to be single-tone (all clients call on one server). Both types are supported under wine. Free Life Boaz
so if I understand you properly, you say that there is no way doing from _outside_ of wine (no matter what kind of com object I have), is that correct? --- Boaz Harrosh <boaz(a)hishome.net> wrote:
maman yonatan wrote:
my question is there any way to write a client on the native (Linux) using g++ and activation the com object?
Currently only a Winelib-App can do that look at http://winehq.org/site/docs/winelib-user/index for what that is.
How ever if you're client is written in ATL or MFC than that is a different problem and it will be harder to do.
does it make a difference if the com object id a dll, exe, or ocx ?
ocx is Just a special case of dll. exe is what is called an out-of-processs server. It is heavier and slower but has the advantage of being able to be single-tone (all clients call on one server). Both types are supported under wine.
Free Life Boaz
__________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools
maman yonatan wrote:
so if I understand you properly, you say that there is no way doing from _outside_ of wine (no matter what kind of com object I have), is that correct?
Of course there is a way: you could make your own remote procedure call mechanism. Might be a very cool project, actually, to make an interface to call objects living a wine, that makes COM accessible from unix! However, it will be quite some work. You probably need a server kind of application that lives in Wine, and a client application that lives in Linux. Then, you got to make sure that the linux app can connect with the server, and issue procedure calls to the wine server. Finally, the wine server should forward actual calls into COM, and return the result value back to the linux client. Thus something like this: 1. [COM object(Wine)] <-> 2. [Custom build COM-server(Wine)] <-> 3. [Client application using the COM object(Linux)] Where layer 2 is something needs probably to be implemeted from scratch. I don't know how much is known about COM by the wine-people, but I guess it that when they succeeded in replicating the COM API, it should also be doable to make a Linux frontend to that... (??) Grtz, Robert
On Sunday 22 February 2004 03:49 pm, Robert van Herk wrote:
maman yonatan wrote:
so if I understand you properly, you say that there is no way doing from _outside_ of wine (no matter what kind of com object I have), is that correct?
Of course there is a way: you could make your own remote procedure call mechanism. Might be a very cool project, actually, to make an interface to call objects living a wine, that makes COM accessible from unix!
However, it will be quite some work. You probably need a server kind of application that lives in Wine, and a client application that lives in Linux. Then, you got to make sure that the linux app can connect with the server, and issue procedure calls to the wine server. Finally, the wine server should forward actual calls into COM, and return the result value back to the linux client.
Thus something like this:
1. [COM object(Wine)] <-> 2. [Custom build COM-server(Wine)] <-> 3. [Client application using the COM object(Linux)]
Where layer 2 is something needs probably to be implemeted from scratch.
I don't know how much is known about COM by the wine-people, but I guess it that when they succeeded in replicating the COM API, it should also be doable to make a Linux frontend to that... (??)
This is a pretty good idea. It would definitely take some doing, but one could imagine cutting and pasting lots of code from rpcrt4 and the wineserver to achieve it via unix domain sockets... this would definitely be a big boon to projects like mplayer and mono which want some way to kick wine around from a normal linux ABI environment (seems like a pretty common problem actually, I see it mentioned on this list quite frequently). Although I've contemplated inventing something like this in the past, ATM I am /not/ volunteering. If you give me a few months (or pay me ;)) I will probably take a crack at it, but right now I am hopelessly busy :(. -- gmt "We lay it down as a fundamental, that laws, to be just, must give a reciprocation of right; that, without this, they are mere arbitrary rules of conduct, founded in force, and not in conscience." --Thomas Jefferson
søn, 22.02.2004 kl. 22.49 skrev Robert van Herk:
maman yonatan wrote:
so if I understand you properly, you say that there is no way doing from _outside_ of wine (no matter what kind of com object I have), is that correct?
Of course there is a way: you could make your own remote procedure call mechanism. Might be a very cool project, actually, to make an interface to call objects living a wine, that makes COM accessible from unix!
However, it will be quite some work. You probably need a server kind of application that lives in Wine, and a client application that lives in Linux. Then, you got to make sure that the linux app can connect with the server, and issue procedure calls to the wine server. Finally, the wine server should forward actual calls into COM, and return the result value back to the linux client.
I still think it would be better to use the Samba RPC client libraries to interact with Wine's RPC implementation (rpcrt4). You wouldn't need to implement a custom server to achieve that, it would just work, and be more efficient.
Ove Kaaven wrote:
I still think it would be better to use the Samba RPC client libraries to interact with Wine's RPC implementation (rpcrt4). You wouldn't need to implement a custom server to achieve that, it would just work, and be more efficient.
What are these (Samba RPC client libraries)? Do they belong to the Samba project or the Wine project (and where)? Is there any kind Winelib or "Native" test that exercises these, that one can examine and dissect? Do we need to use the Wine implementation of OLE than. or are we able to use native OLE as well. If the former than I am afraid it is a little broken still. If you point me to the right place I think I'll have a crack at it. I like this approach. I'm thinking of a way to use widl with some extra scripts to make that process automatic. But we need the technology first. By the way: Is widl able to process regular RPC calls as well, or Just COM object? What I mean is: An IDL prototype to C function prototype. without a COM scope. (That was the original use of it in MS, no? Just an RPC compiler)
On Mon, 23 Feb 2004 10:26:27 +0200, Boaz Harrosh wrote:
Do we need to use the Wine implementation of OLE than. or are we able to use native OLE as well. If the former than I am afraid it is a little broken still.
Wines current RPC runtime is not wire compatible with native ORPC, so I'm guessing you would need to use native dcom.
man, 23.02.2004 kl. 09.26 skrev Boaz Harrosh:
Ove Kaaven wrote:
I still think it would be better to use the Samba RPC client libraries to interact with Wine's RPC implementation (rpcrt4). You wouldn't need to implement a custom server to achieve that, it would just work, and be more efficient.
What are these (Samba RPC client libraries)? Do they belong to the Samba project or the Wine project (and where)?
The Samba project is about communicating with Windows clients and servers, using the Windows protocols. For many services (authentication, printing, directory services, etc), modern Windows versions use RPC, not SMB. So the Samba folks have been forced to write a RPC protocol stack. This RPC stack should be available as a library (libsmbclient probably) to native Linux apps. I think they have a utility to generate marshalling code for any RPC interface, which could enable native Linux apps to access Windows RPC services through libsmbclient. This could prove useful because DCOM is built on top of RPC, though I don't know if they have any native DCOM support yet.
Is there any kind Winelib or "Native" test that exercises these, that one can examine and dissect?
I only know of the Samba source code itself.
Do we need to use the Wine implementation of OLE than. or are we able to use native OLE as well. If the former than I am afraid it is a little broken still.
Communication happens on the RPC level, not the COM/OLE level. Builtin or native OLE shouldn't matter for this (though native OLE probably doesn't work with Wine's RPCRT4 for unrelated reasons). But currently Wine's RPCRT4 is not wire-compatible with anything but itself. There are many alignment issues that we currently don't take into account, for example. To use Wine's RPCRT4 for this, it'd have to be made wire-compatible with DCE RPC, or at least enough so to communicate with Samba. On the other hand, the native RPCRT4 would also take a fair bit of work to get to work under Wine. I imagine this Samba<->Wine RPC communication to happen over named pipes (once Wine supports remote named pipes), but other transport protocols could probably be used if easier to implement. Now all of this may sound like a fair amount of work, and it probably is, but it's work that would really have to be done anyway sooner or later, so if you're looking for a general solution, it'd be more useful time spent for Wine to work on these things, rather than writing a dedicated server app.
If you point me to the right place I think I'll have a crack at it. I like this approach. I'm thinking of a way to use widl with some extra scripts to make that process automatic. But we need the technology first.
By the way: Is widl able to process regular RPC calls as well, or Just COM object?
Well, yes, to the same degree it can process DCOM interfaces - i.e. it can still only really generate .h files, not interprocess proxies/stubs. That would also have to be "fixed"... and I probably won't have time for that kind of task myself anytime soon (unless I get paid or something).
What I mean is: An IDL prototype to C function prototype. without a COM scope. (That was the original use of it in MS, no? Just an RPC compiler)
Pretty much... a regular RPC interface definition looks just like a DCOM interface, but without the [object] attribute in the interface attributes. Without [object], the generated prototypes will look like regular functions, without the This parameter. But the functions still have to be defined inside an interface definition. This is obviously so that the UUID of the interface the function belongs to can uniquely identify the requested procedure call, even when many similar interfaces with similar function names (but different semantics) exist.
Ove Kaaven wrote:
The Samba project is about communicating with Windows clients and servers, using the Windows protocols. For many services (authentication, printing, directory services, etc), modern Windows versions use RPC, not SMB. So the Samba folks have been forced to write a RPC protocol stack. This RPC stack should be available as a library (libsmbclient probably) to native Linux apps. I think they have a utility to generate marshalling code for any RPC interface, which could enable native Linux apps to access Windows RPC services through libsmbclient. This could prove useful because DCOM is built on top of RPC, though I don't know if they have any native DCOM support yet.
Communication happens on the RPC level, not the COM/OLE level. Builtin or native OLE shouldn't matter for this (though native OLE probably doesn't work with Wine's RPCRT4 for unrelated reasons).
But currently Wine's RPCRT4 is not wire-compatible with anything but itself. There are many alignment issues that we currently don't take into account, for example. To use Wine's RPCRT4 for this, it'd have to be made wire-compatible with DCE RPC, or at least enough so to communicate with Samba. On the other hand, the native RPCRT4 would also take a fair bit of work to get to work under Wine.
If I may summarize what I understood. There are 2 options: 1) It would be best to take Samba-project implementation of RPC and implement wine's RPCRT4 over that. This way we are both wire-compatible with DCE RPC and also we can use a ready made "libsmbclient" to send COM-RPC calls the wine way. (Remote or local) from Linux-Land. In this case in theory both native and builtin OLE implementations can be used. 2) Make a Linux-Land lib that is wire-compatible with wine-RPCRT4 and send COM-calls over that. Currently this approach can only use builtin OLE implementation, but that could be fixed. Did I understand correctly? If so which way would you take?
I imagine this Samba<->Wine RPC communication to happen over named pipes (once Wine supports remote named pipes), but other transport protocols could probably be used if easier to implement.
What is Samba-RPC using, do you know?
Now all of this may sound like a fair amount of work, and it probably is, but it's work that would really have to be done anyway sooner or later, so if you're looking for a general solution, it'd be more useful time spent for Wine to work on these things, rather than writing a dedicated server app.
I'm with you 100% on that. This single fixture can be what makes Wine main-stream Linux just like samba is? Juan, can you see the light at the end of the...?
Pretty much... a regular RPC interface definition looks just like a DCOM interface, but without the [object] attribute in the interface
Good I'll give it a go.
man, 23.02.2004 kl. 15.26 skrev Boaz Harrosh:
If I may summarize what I understood. There are 2 options: 1) It would be best to take Samba-project implementation of RPC and implement wine's RPCRT4 over that. This way we are both wire-compatible with DCE RPC and also we can use a ready made "libsmbclient" to send COM-RPC calls the wine way. (Remote or local) from Linux-Land. In this case in theory both native and builtin OLE implementations can be used.
2) Make a Linux-Land lib that is wire-compatible with wine-RPCRT4 and send COM-calls over that. Currently this approach can only use builtin OLE implementation, but that could be fixed.
Did I understand correctly? If so which way would you take?
Neither of those options look much like what I meant. Let's see... 1) No, you can't take Samba-project implementation and put it into Wine. Not possible. Wine's RPCRT4 must conform to Microsoft's low-level RPC API *and* the DCE RPC wire protocol, but Samba's implementation *only* care about the wire protocol; its design, implementation, and API is completely different from what RPCRT4 needs. Wine's RPCRT4 has no other choice than being an independent implementation of MS-RPC, without possibility to nab any significant amount of code from elsewhere (like FreeDCE or Samba). The point of using Samba for its RPC client capabilities is that it's a Linux native library, so you don't need to be a Winelib app to use it, but you'd still be able to communicate with Wine and its RPCRT4 implementation using it (provided we make RPCRT4's wire protocol compatible with DCE RPC and hence Samba, and implement remote named pipes or other transport). 2) I don't get what you're referring to with "Linux-Land lib". The idea was that Samba could be that Linux-Land RPC lib, wasn't it?
What is Samba-RPC using, do you know?
I'm pretty sure they use named pipes. A named pipe is a multiplexed TCP stream on a particular port. The alternative would probably be to implement RPC in all its UDP glory, and you can probably imagine how fun *that* would be... Just consider that you can use attributes such as [maybe] or [idempotent] on functions and methods in RPC, and you may get some idea. If I remember right, if a function is marked [maybe], it means that it's okay if RPC packets for calls of that function are lost. (Could be useful for progress bars, since if a packet is lost, a new call will come in later with updated info anyway.) If a function is marked [idempotent], it means that it's okay if the function gets called more than once due to duplicate packets (due to retransmission or routing issues). Now tell me you'd still want to do the full UDP implementation instead of a named-pipe TCP connection... Well, it's possible to run RPC over plain TCP, without named pipes, but I don't think that's a widely used feature under Windows, so it probably wasn't a good alternative for Samba. Of course, Microsoft also had to invent RPC over HTTP, to get some DCOM stuff (ActiveX?) through corporate firewalls...
Ove Kaaven wrote:
Neither of those options look much like what I meant. Let's see...
I'm pretty sure they use named pipes.
OK I think I understand you better now. What you are saying is that we need to study Samba and FreeDCE code to see what DCE-RPC wire protocol is. Than fix Wine-RPCRT4 to be compatible with that. Now one can use Samba-RPC or FreeDCE on the Linux side, and the Wine side is pretty much ready. only we have to fix it so Wine-RPC can work with Native OLE or fix Builtin OLE implementation. I'll try and dig in and collect clients and servers of different platforms. Than see when combinations start to work. If any one has some RPC code lying around please send them in. (Also URLs. If it is bigger than 40k send it directly to me). we need the most simple do nothing no extra code of: Samba/FreeDCE client and server. Win32 PE client and server that runs on windows. Win32 PE/ELF client and server that runs on wine (same machine) Than with a couple of debuggers and Samba/FreeDCE source code we can make it work. Free Life Boaz
søn, 22.02.2004 kl. 14.43 skrev maman yonatan:
my question is there any way to write a client on the native (Linux) using g++ and activation the com object?
Perhaps it'd be possible to hack the Samba RPC client into doing that with a little work... of course the Wine RPC server would also have to be fixed quite a bit.
does it make a difference if the com object id a dll, exe, or ocx ?
COM has a feature called "DLL surrogates", where a dedicated exe file (dllhost.exe or something like that) can load dlls when out-of-process activation of them is desired. It may be possible to use that somehow to activate dlls and ocxs inside wine when the client wishes to be outside wine.
participants (6)
-
Boaz Harrosh -
Gregory M. Turner -
maman yonatan -
Mike Hearn -
Ove Kaaven -
Robert van Herk