Date: Thu, 20 Feb 1997 18:07:48 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: ponds!rivers@dg-rtp.dg.com (Thomas David Rivers) Cc: hackers@freebsd.org Subject: Re: Windows95: what you don't know, you must reinvent Message-ID: <199702210107.SAA00698@phaeton.artisoft.com> In-Reply-To: <199702202155.QAA02124@lakes.water.net> from "Thomas David Rivers" at Feb 20, 97 04:55:41 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > I'm willing to write the COM model support code for FreeBSD. I might > > even be willing to write a Registry (or LDAP directory) for class > > identification, agregation, and configuration. > > I'd like to see that - as I have a developer who's trying to > convince us to change the VTABLE format in our C++ compiler. > He claims we should use Microsoft's; or else we won't be able > to compile/run-with COM... > > opinions? He's right, at least insofar as you want binary interoperability with COM components produced by commercial vendors for Microsoft platforms to run on your platform. The following is an exceprtf from "The Component Object Model: Techincal Overvied" ( http://www.microsoft.com/oledev/olecom/Com_modl.htm ): ] Binary Standard ] ] For any given platform (hardware and operating system combination), ] COM defines a standard way to lay out virtual function tables ] (vtables) in memory, and a standard way to call functions through ] the vtables. Thus, any language that can call functions via ] pointers (C, C++, Smalltalk, Ada, and even BASIC) all can be used ] to write components that can interoperate with other components ] written to the same binary standard. Indirection (the client holds ] a pointer to a vtable) allows for vtable sharing among multiple ] instances of the same object class. On a system with hundreds of ] object instances, vtable sharing can reduce memory requirements ] considerably, because additional vtables pointing to the same ] component instance consume much less memory than multiple ] instances of the same component. ] ] COM Component ] Client ,---------------------. ] Variable --|---> VTBL pointer ---|-------> VTBL ] | | ,---------------------. ] | Provate object data | | pointer to function | ] `---------------------' | pointer to function | ] | pointer to function | ] `---------|-----------' ] | ] | ] ,---------v---------------------. ] | function1(pObj,arg1,arg2,...) | ] | { | ] | ... | ] | } | ] `-------------------------------' [ ... ] ] Basic Interoperability and Performance ] ] These are provided by COM's use of vtables to define a binary ] interface standard for method calling between components. Calls ] between COM components in the same process are only a handful ] of processor instructions slower than a standard direct ] function call and no slower than a compile-time bound C++ ] object invocation. In effect, if you don't do it, then you might be able to use third party COM components in your framework, but third party containers ("applications built from components") won't be able to use code compiled by your compiler... at least for inprocess servers; I suppose you *could* write a glue .exe that would marshal your interfaces into a vtable exported by the glue .exe ...at the cost of having to marshal all your data and function call arguments using RPC, which you would not have to do with an in process COM server, and at the cost of not being able to engage in "free threading" in consumers of the objects you provide. An RPC call, even for IPC, won't migrate threads into the address space of the implementation object. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702210107.SAA00698>