From owner-freebsd-hackers  Thu Feb 20 17:08:55 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id RAA22853
          for hackers-outgoing; Thu, 20 Feb 1997 17:08:55 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id RAA22848
          for <hackers@freebsd.org>; Thu, 20 Feb 1997 17:08:53 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA00698; Thu, 20 Feb 1997 18:07:49 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199702210107.SAA00698@phaeton.artisoft.com>
Subject: Re: Windows95: what you don't know, you must reinvent
To: ponds!rivers@dg-rtp.dg.com (Thomas David Rivers)
Date: Thu, 20 Feb 1997 18:07:48 -0700 (MST)
Cc: hackers@freebsd.org
In-Reply-To: <199702202155.QAA02124@lakes.water.net> from "Thomas David Rivers" at Feb 20, 97 04:55:41 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > 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.