Subject: Re: linking with MSVC++
From: [email-masked] (James Mansion)

17 Oct 1996 18:43:50 -0700
Sender: [email-masked]
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.0b6Gold (WinNT; I)
Original-To: [email-masked]
X-Info: Evaluation version at wgold.demon.co.uk
X-Info: Westongold Ltd: +44 1992 620025
Original-Sender: [email-masked]

That was an awfully long post, perhaps trying to be helpful but
succeeding in showing only ignorance.

Jeff Bronte wrote:
> If I had to solve your problem of tacking a GUI onto GNU I would
> use RPC's (Remote Procedure Calls). If you are not familiar with
> network programming using this powerful tool (many of the internal services

Why?  The DLL interface style is so much more efficient, and it
does not rely on network services that the user may have elected
not to install.  Its enormously faster.

> VC++ GUI. There isn't really an 'interface' definition since
> clients and servers communicate with each other using function calls.

Uhh, so the .x file isn't an interface definition?  How does it
differ from the IDL files that are used for:
 - DCE RPC
 - OLE
 - Corba?

(Apart from the syntax!)

> Rather than going through a link to execute the call, the parms
> are converted to a machine independent form, sent through sockets
> to the server who executes the call and returns the return values.
> >From the programmer's perspective it is a just another call.

Actually its rather more than just another call, since you have
to care about whether the connection was lost, and whether you are
going to retain a connection to work over.  And then there's the
'small' issue of managing the memory that the xdr layer allocated
for you.

> 
> In the UNIX world of network programming this is often how it
> is done. (I know you see a lot about sockets, but that is a dying
> method because of tracking addresses and hosts, RPC's offload
> you from this through a binding process, which becomes more important
> when you have several hosts and dozens of servers). Also, there is
> a util called RPCGEN which greatly simplifies this type of development.
> 
> I'm not sure how any of this plays on Win95. Also, NT added RPC's

If you're so clearly in the dark, why post?

> because the industry demanded it, not because MS had any interest
> in provided the service (which allow UNIX and NT machines to
> talk easily with each other, sockets are primitive). The MS
> version of RPC's (ONC compliant?) are supported in MFC on NT's,

Uh, wrong, I think you'll find.  The RPC that Microsoft use is a
derivative of the DCE style RPC.  Its compatible on the wire but
has a different API (largely 1:1 mapping) and different name
services and security.  There IS an O'Reilly on mixing and
matching.

If you want ONC on Win95 and NT, there's a port of the sources
that Sun released at http://set.gmd.de/~mfg/oncrpc.html

The main driver for MS implementing RPC is the communications
between NT components under the hood.  MS implement high-
efficiency 'local RPC' or 'LRPC' to talk between subsystems.

They also use the marshalling technology in OLE2.

> I have colleague's doing it now, but as with most MFC development,
> they are having difficulties getting it to work as well as the

Sounds like your colleagues have a problem then.  Believe me, the
MS RPC technology is the core of a lot of stuff that they are
delivering, and it does work.

It *is* more complex than ONC RPC, though no more so than DCE.

There is an O'Reilly book on MS RPC as well as on ONC RPC, btw.

> mature UNIX RPC's. Also, MS doesn't provide the powerful RPCGEN util,
> you have to do some lower level stuff.

Huh?  Its called MIDL.  It has the same functionality coverage, more
or less.

> 
> If you are doing professional development, you'll find this a very
> powerful way to modularize and distribute applications, even if
> on the same host. I am hoping that as GNU Win32 matures and more

Its a dumb way to do it on a Win32 host though.  Using MS RPC
requires you to have a resolution service which doesn't come
with Win95.  Using ONC RPC would require you to compile up
and run portmapper et al (see reference above) and would require
the machines to have TCP/IP loaded.

Either way you cut it, as a solution there are major problems.

If you must use RPCGEN then the best way to do it is to use
the generated stubs to marshal to xdr memory streams and then
use a Win32 IPC to blat them around in the box, though this
is expensive since everything will undergo network byte order
transformations that are completely unnecessary.

Why on earth not use a DLL interface directly?  You do have
to be careful not to pass responsibility for freeing data between
runtimes (unless its directly allocated from the operating system)
but its MUCH simpler than trying an RPC solution.

And if you really want to do RPC like this, then just go
for an in-proc OLE server.  (But forget about writing it with
gcc for the time being)  Yup, you guessed it, the interface
file is compiled with MIDL, the Microsoft RPC interface compiler.

> people want to play with the Win32 API, that this solution is
> supported if not already.
> 
> Good Luck,
> 
> Jeff
> 
> p.s. all of which I spoke of, at least in the UNIX environment, is
> all public domain. (The ONLY thing that scares MS$ !!)
> 
> -
> For help on using this list, send a message to
> "[email-masked]" with one line of text: "help".

James
-
For help on using this list, send a message to
"[email-masked]" with one line of text: "help".