Re: AW: DCOM coming?

[Richard B. Johnson]

On Tue, 21 May 2002, Wessler, Siegfried wrote:

> Hello,
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Mark Hahn [mailto:[e-mail]]
> 
> > 
> > why would the kernel be involved?  seems perfectly userland to me.
> > 
> 
> What about TCP/IP or USB? Okay USB is not only a protocol, but a lot of
> hardware. But DCOM into the kernel would mean that a lot of people would
> take care about it. The sourceforge project freedce looks nice, but to me
> "as user" it's a bit tiny. 
> 
> If DCOM were wraped into the kernel, everyone could use it, as it would be a
> part of the os itself. That makes it more interesting for companies who make
> installations using DCOM to use Linux (also). And it would help us
> firmware/hardware oriented programmers to use Embedded Linux in
> infrastructures that are Microsoft dominated, because of MS propietaire
> protocols like DCOM.

The "Distributed Component Object Model" is a Microsoft extension of
"COM" which is in its death throes. It is just another proprietary
programming interface.

Linux/Unix has its own non-proprietary API. You can write user-mode
interface libraries to throw whatever layers onto that basic API
that you want. Of course it's a waste of programmer time and run-time
CPU cycles as well.

The "Distributed" part of COM, in theory, allows you to use the
RS-232C port on a M$ computer, over the network, on your M$
computer. If this is what you want, you can write Client/Server
stuff on both sides and stay away from license issues with embedded
systems.

COM and DCOM have no place in the kernel, if fact, they have
no place in Windows kernels either. They should not have been
molded into M$ kernels and they are not in Win-2000/Professional
or Win-NT.

On these machines, a separate task handles COM. If they are now putting
it into the kernel on other versions, it's broken by design.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.