> > -----Ursprüngliche Nachricht-----
> > Von: Mark Hahn [mailto:email@example.com]
> > 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
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
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
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.
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/