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-RPC
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 mad
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 s
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
> >mor
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
gues
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)?
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
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 r
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
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 <[EMAIL PROTECTED]> wrote:
> maman yonatan wrote:
>
> >my question is there any way to write a client on
> the
> >native (Linux)
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 ha
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 M
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, al
13 matches
Mail list logo
