Sam,
From the perspective of a .NET developer, managed code does in fact equal
..NET code, and unmanaged code is all code that does not run under the CLR.
However, Java bytecode is often referred to as "managed code" as well. By
this more generic definition, managed code is any code that is run in a
managed environment that controls security access and access to resources.
That managed environment might be .NET's Common Language Runtime, Java's
bytecode interpreter, or something else. It is not enough for the code to
require a supporting runtime; VB6 or FoxPro executables, for example, are
not "managed" in this sense. A support library full of routines is
passively called by such code; but unlike a suport library, a manged
environment may refuse application an request if it violates security
protection levels or accesses forbidden resources. In order to be able to
determine whether or not to honor requests, the application code must be
self-describing; hence the other requirement to call an execution
environment "managed."
So, generically, managed code (1) contains some kind of meta-data to
describe itself to its runtime environment with (2) actively grants or
denies application requests based on the defined security configurations for
the application, and the machine and network the application is interacting
with.
--Bob
From the perspective of a .NET developer, managed code does in fact equal
..NET code, and unmanaged code is all code that does not run under the CLR.
However, Java bytecode is often referred to as "managed code" as well. By
this more generic definition, managed code is any code that is run in a
managed environment that controls security access and access to resources.
That managed environment might be .NET's Common Language Runtime, Java's
bytecode interpreter, or something else. It is not enough for the code to
require a supporting runtime; VB6 or FoxPro executables, for example, are
not "managed" in this sense. A support library full of routines is
passively called by such code; but unlike a suport library, a manged
environment may refuse application an request if it violates security
protection levels or accesses forbidden resources. In order to be able to
determine whether or not to honor requests, the application code must be
self-describing; hence the other requirement to call an execution
environment "managed."
So, generically, managed code (1) contains some kind of meta-data to
describe itself to its runtime environment with (2) actively grants or
denies application requests based on the defined security configurations for
the application, and the machine and network the application is interacting
with.
--Bob
Sam Gentile [MVP - C#/.NET] November 15th, 2005 11:13 PM
Guest - n/a Posts
#4: Re: What is Marshaling?
> Thanks. So is recreating the structs into C#-readable structs (class or[color=blue]
> struct) marshalling?[/color]
Yes, it's one form of marshaling. As people said, marshaling is serializing
or transforming types over the wire or some boundary. COM had marshaling
when you went out of one apartment into a non-compatible apartment or across
the wire to another machine. When dealing with COM Interop, .NET uses
Interop Marshaling between COM data types and .NET CLR types.
> struct) marshalling?[/color]
Yes, it's one form of marshaling. As people said, marshaling is serializing
or transforming types over the wire or some boundary. COM had marshaling
when you went out of one apartment into a non-compatible apartment or across
the wire to another machine. When dealing with COM Interop, .NET uses
Interop Marshaling between COM data types and .NET CLR types.
>> And what's unmanaged code? I've heard that code with pointers is
>> unmanaged
> code, or C code is unmanaged code. But why is a class managed code (if
> that statement is true) hile other code is unmanaged?
Unmanaged code is simply all code pre .NET. It is all code NOT compiled to
operate under .NET's runtime, the CLR. Unmanaged code is code compiled and
linked natively and has no knowledge of the CLR. Unmanaged code can be
native C++ with pointers, or C, or VB 6, or Delphi, etc. It is everything
not managed by the CLR. In the CLR, code is compiled into IL + metadata into
assemblies and then those assemblies are JITed into assembly language
instructions while called. It is the metadata throughout that allows managed
code to be managed, managed by the CLR. The CLR can control the type
definitions and boundaries (enforce CTS type definitions), control memory
through automatic management of data via the garbage collector, and provide
CAS security among other benefits. So a class is managed code IF compiled
with a .NET compiler and controlled by the CLR whereas "other code is
unmanaged" because it is compiled without a .NET compiler and uses the
unmanaged heap for memory and knows nothing of the CLR.
This is the answer to your question but I can go deeper if you want.
Essentially, both systems produce a Windows PE format file in the form of a
DLL or EXE. The huge difference is that in .NET, that PE file is called an
assembly and has different header. It also contains IL + metadata. All .NET
compilers are REQUIRED to emit IL + metadata. The metadata fully describes
all types in terms of CTS types. The metadata allows managed code to be
called "self-describing." When that assembly is loaded, and the types used,
the CLR JIT's the IL for the called method and replaces that section of IL
with the native assembly language. The IL is *never* interpreted but
provides a common platform-independent, language-independent standard form.
Because of all this, the CLR can manage the types and provide it's services.
-----
Sam Gentile
Microsoft MVP - C#/.NET
..NET Blog http://samgentile.com/blog/
>> unmanaged
> code, or C code is unmanaged code. But why is a class managed code (if
> that statement is true) hile other code is unmanaged?
Unmanaged code is simply all code pre .NET. It is all code NOT compiled to
operate under .NET's runtime, the CLR. Unmanaged code is code compiled and
linked natively and has no knowledge of the CLR. Unmanaged code can be
native C++ with pointers, or C, or VB 6, or Delphi, etc. It is everything
not managed by the CLR. In the CLR, code is compiled into IL + metadata into
assemblies and then those assemblies are JITed into assembly language
instructions while called. It is the metadata throughout that allows managed
code to be managed, managed by the CLR. The CLR can control the type
definitions and boundaries (enforce CTS type definitions), control memory
through automatic management of data via the garbage collector, and provide
CAS security among other benefits. So a class is managed code IF compiled
with a .NET compiler and controlled by the CLR whereas "other code is
unmanaged" because it is compiled without a .NET compiler and uses the
unmanaged heap for memory and knows nothing of the CLR.
This is the answer to your question but I can go deeper if you want.
Essentially, both systems produce a Windows PE format file in the form of a
DLL or EXE. The huge difference is that in .NET, that PE file is called an
assembly and has different header. It also contains IL + metadata. All .NET
compilers are REQUIRED to emit IL + metadata. The metadata fully describes
all types in terms of CTS types. The metadata allows managed code to be
called "self-describing." When that assembly is loaded, and the types used,
the CLR JIT's the IL for the called method and replaces that section of IL
with the native assembly language. The IL is *never* interpreted but
provides a common platform-independent, language-independent standard form.
Because of all this, the CLR can manage the types and provide it's services.
-----
Sam Gentile
Microsoft MVP - C#/.NET
..NET Blog http://samgentile.com/blog/
Nicholas Paldino [.NET/C# MVP] November 15th, 2005 11:07 PM
Guest - n/a Posts
#2: Re: What is Marshaling?
Marshaling is the act of taking data from the environment you are in and
exporting it to another environment. In the context of .NET, marhsaling
refers to moving data outside of the app-domain you are in, somewhere else.
When you work with unmanaged code, you are marshaling data from your
managed app-domain to the unmanaged realm. Also, when transferring data
between app-domains (to another application, on the same or another
machine), you are also marshaling data from your app-domain, to another
app-domain.
exporting it to another environment. In the context of .NET, marhsaling
refers to moving data outside of the app-domain you are in, somewhere else.
When you work with unmanaged code, you are marshaling data from your
managed app-domain to the unmanaged realm. Also, when transferring data
between app-domains (to another application, on the same or another
machine), you are also marshaling data from your app-domain, to another
app-domain.
Posts
No comments:
Post a Comment