Re: .NET and ActiveX

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Jerry Pisk (jerryiii_at_hotmail.com)
Date: 07/03/04 

Date: Fri, 2 Jul 2004 21:47:11 -0700

Scott, give it up, you're the one who's not understanding. You say .Net COM
objects are not COM inside - NO COM objects are. You're actually
acknowledging that yourself ("COM is not a language") but then you go on
saying that "real" COM objects are in COM, while .Net COM objects are in
.Net. C++ COM objects are C++ inside (running under C++/MFC/ATL/whatever
framework internally), VB COM objects are VB inside (running under the VB
runtime) and the same way .Net COM objects are .Net inside, running under
the .Net framework. COM doesn't define what the objects are or are not
internally, all it does is define an interface (NOT a language interface) on
how COM objects are exposed and communicate with each other. The actual
implementation internally can be anything.

Oh and if you think there were not managed languages when COM was created
then take the time and learn something about the history of programming
languages.

Jerry

"Scott M." <s-mar@nospam.nospam> wrote in message
news:eWAXIgKYEHA.644@tk2msftngp13.phx.gbl...
>> Well, that was precisely the definition for a COM object in the COM
>> specification, you know?
>
> You are reading a definition of COM that was written before there was such
> a
> thing as .NET and trying to make it applicable to a technology that didn't
> exist when COM was created. Because the may look the same from the
> outside,
> does not make them the same on the inside. And, it is that point exactly
> (what architecture is the component written to run in) that determines if
> it
> is a COM object or a .NET component. If it is written to be run natively
> by
> the CLR, then it is a .NET component, can run outside of traditional COM
> layers, is not reliant upon COM, doesn't need the Windows Registry and not
> part of Windows DNA. Get it yet?! Probably not.
>
>> Of course!
>> But exactly the *same* applies to virtually any language: Native C++
> classes
>> do not interface each other using COM. Neither do native Ada classes;
> Heck,
>> K&R C doesn't even have classes, and still you can create "real" COM
> objects
>> in it. So what's your point? What makes .NET COM objects "special" in
>> your
>> mind?
>
> You are confusing languages, class definitions and runtime architectures
> and
> somehow trying to blur them all into the same thing. COM is not a
> language.
> COM is not a class. COM is an architecture. Do you understand what an
> architecture is? An architecure is not the object or language, it is the
> rules about the underlying runtime for that class, developed in whatever
> language. ANY object that is a native .NET object uses a completely
> different archtecture/runtime when it processes than COM objects do...This
> is the point and what you are failing to understand. You can dress up a
> COM
> object and make it look like it is a .NET component via a Runtime Callable
> Wrapper, but that COM object better be registered in the Windows Registry
> (a
> requirement of COM based components) before you try to use it in .NET.
> Why?
> Because it still is a COM object and the underlying architecture that is
> processing its code is COM, not .NET. The CLR is just passing messages
> to/from the COM architecture in this case.
>
>>
>> > You believe that is takes a COM object and turns it into a .NET object
> or
>> > that it takes a .NET object and turns it into a COM object and that is
>> just
>> > not the case.
>>
>> Slow, slow, slow.
>> You probably agree that C++/MFC can create "true" COM objects, wouldn't
> you?
>> So - we're talking about pure old C++ at the moment - imagine you have a
> C++
>> object of a C++ class derived from some MFC base class. The object
> contains
>> special "interface implementation objects", one for each interface (MFC
>> implements interfaces this way). The member functions of these "interface
>> members" do nothing more but adjusting a few globals and calling the
>> "parent" object.
>> That's an MFC COM object.
>>
>> Now, how does "COM simulation" in .NET look like?
>> You have an object, derived from "System.Object". It creates a new
>> object,
>> the callable wrapper. The member functions of the callable wrapper "call
>> through" to the "parent" object's members.
>>
>> So, the only difference is in the "object behind" the interface. But the
>> whole point about COM *is* that it hides that object behind an interface.
>> The point of COM *is* that this object behind the scenes could be
> anything -
>> a C struct, a Java class, a bunch of JScript code or even a remote
>> object.
>> It doesn't make any sense to say that a COM interface is "simulated".
>
> You are speaking in theoretical and philosophical terms. Just because the
> CLR performs tasks that the COM architecture performs, doesn't mean that
> .NET = COM. You are again confusing languages, classes and architectures.
> The simplest analogy would be that if a car has a Buick engine, then it is
> a
> Buick - - no matter what the body type is. COM objects are driven by the
> underlying architecture that they were built for and that architecture is
> what drives them, no matter what they may look like to .NET. The CLR does
> not provide the processing for COM objects, other than the wrapper class.
>
> I don't know of any way to spell it out any clearer than I already have
> for
> you and quite frankly, I'm exhausted from trying. I wish you well and
> suggest you pick up some reading material on architecture and specifically
> the .NET Framework and CAR.
>
>
>
>

Relevant Pages

  • Re: What would motivate conversion to a new concurrent model akin to that of the transputer?
    ... >So a new language in the transputer spirit has to add good concurrency ... >architecture, and the non-success of Itanium, show that compilers can ... >the CPU over external memory access stalls. ... Synchronous Objects and Asynchronous Objects. ...
    (comp.sys.transputer)
  • Re: A website or wiki on language design
    ... well, at this point I am a little more interested in matters of VM design than of language design per-se, as at this point much of language design boils down to "how can I make something absurd and push it off as a good idea". ... to some extent, C is a micro-spec, since enough freedom is left in the "C architecture" to basically use it for damn near any task one sees fit. ... people just can't see these things as components which could be used freely, but only in terms of the "platforms", and any implementation of a feature is seen as an attempt to emulate said platform. ...
    (comp.lang.misc)
  • Re: .NET and ActiveX
    ... the CLR, then it is a .NET component, can run outside of traditional COM ... COM is an architecture. ... An architecure is not the object or language, ... The member functions of the callable wrapper "call ...
    (microsoft.public.dotnet.framework)
  • Re: TASM revisited
    ... overhead" do you mean the overhead of the associated system calls that ... Neumann architecture, system calls could be coded in assembly language ... system could help your HLA students learn assembly even better, ...
    (alt.lang.asm)
  • Re: How Many Processor Cores Are Enough?
    ... Let's say the language is strictly Assembly, ... If a particular architecture does not have the correct barrier for this kind ... that architecture very much at all; RCU performance would tank with explicit ...
    (comp.arch)