From: james AT wgold DOT demon DOT co DOT uk (James Mansion) Subject: Re: linking with MSVC++ 17 Oct 1996 18:43:50 -0700 Sender: daemon AT cygnus DOT com Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <3266A50A.9BB.cygnus.gnu-win32@wgold.demon.co.uk> References: <2 DOT 2 DOT 32 DOT 19961017165633 DOT 00699150 AT doctord DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b6Gold (WinNT; I) Original-To: gnu-win32 AT cygnus DOT com X-Info: Evaluation version at wgold.demon.co.uk X-Info: Westongold Ltd: +44 1992 620025 Original-Sender: owner-gnu-win32 AT cygnus DOT com 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 > "gnu-win32-request AT cygnus DOT com" with one line of text: "help". James - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".