proxy/stub woes

I have some vague uncertainties about getting things to work between
apartments when there are interfaces that are not IDispatch-derived.

Are there any good simple examples out there showing servers/clients in
separate build trees working together with interfaces derived from
IUnknown, and Good Practices for sharing the interface pointer type
definitions? (e.g. use #import?)

Here's my case:

(some information below abbreviated -- I am trying to include the
relevant info)
I have Server SPROC which is an .exe server.
I have Server SLOCAL which is a .dll server.
SLOCAL implements interface Ibatch using coclass Cbatch.
SPROC implements interface Ibatch_generator using coclass
Cbatch_generator.

Ibatch_generator has a get/put property called "data" which accepts an
interface pointer to Ibatch. If you call put_data(), it stores away the
(marshalled) interface pointer in a smart-pointer. If you call
get_data(), it retrieves the interface pointer, and if it's NULL, it
attempts to CoCreate() an Ibatch locally. This gives me the choice
whether to have the Cbatch residing within the apartment on the server
SLOCAL running within SPROC, or the server SLOCAL running within a
client (or through someone else's implementation of Ibatch, but forget
about that one).

Both Ibatch and Ibatch_generator are derived from IUnknown and are
defined in a base .idl file for which I am creating a proxy/stub .dll .

I have client C1 which instantiates the Ibatch_generator *, and based
on a command-line switch, it either calls get_data() to obtain the
Ibatch *, or it creates a Ibatch * itself and then calls put_data() to
share that with the Ibatch_generator. This way I can control in which
apartment the Ibatch resides.

Case 1: Ibatch_generator creates Ibatch *.
If Ibatch * resides within SLOCAL running within SPROC, everything
works great (as far as I can tell).
Case 2: C1 creates Ibatch *.
If Ibatch * resides within SLOCAL running within C1, I'm not so sure...
C1 calls methods of Ibatch_generator (running within SPROC) which then
call methods Ibatch::setup() (running within SLOCAL running in C1) and
I'm still debugging one method call (found an insidious problem where I
was using BSTR b = L"something" in a method call, and the proxy/stub
marshalling code didn't appear to like BSTRs which aren't properly
prefixed with their length, but there's something else wrong...)

In the IDL file, if I have Ibatch declared as "oleautomation" things
work OK, but if I leave that out, then I get some errors (still trying
to debug that), and I don't understand why.

.

Relevant Pages

  • Re: proxy/stub woes
    ... I have Server SPROC which is an .exe server. ... SLOCAL implements interface Ibatch using coclass Cbatch. ... SLOCAL running within SPROC, or the server SLOCAL running within a ...
    (microsoft.public.vc.atl)
  • Re: What doesnt lend itself to OO?
    ... The whole idea that a subsystem is just ... > The first line exists in the server. ... objects between client and server i.e. as far as the client code is ... > external interface is the traditional input interface whose ...
    (comp.object)
  • Re: Brian Kernighan, maybe Im not worthy, maybe Im scum
    ... If you think I'm giving a verbose pseud write access to my server, ... interface appears in C Sharp as consisting of sbyte arrays. ... failed to see that a for loop is not just a while loop because a while ... chilling effect on freedom of speech. ...
    (comp.programming)
  • Re: Cannot get NAT to route in RRAS
    ... The basic problem is that you are using an ADSL modem on the server. ... I would suggest that you set up a demand-dial interface to act as the ... Static Route wizard, create a default route using this interface (ie put ...
    (microsoft.public.win2000.ras_routing)
  • Re: Cannot get NAT to route in RRAS
    ... ADSL Link was set as the Public interface in NAT, ... The static route also adds in fine using the ADSL Link interface, ... separate DNS server handles client’s requests, ... > Internet connection. ...
    (microsoft.public.win2000.ras_routing)