G
Guest
I am confused about Unmanaged Code, How .Net Framework treate that code,
What is the use of that.
Thanks in advance
Sandeep Chitode
What is the use of that.
Thanks in advance
Sandeep Chitode
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
K
Karl Seguin
I hope someone will correct me if I'm horribly wrong, but:
Managed code runs in the CLR (a virtual machine) which provides a number of
services: security, type safety, memory management just to name a few.
Unmanaged code doesn't run in the CL and is typically known as COM, COM+,
ActiveX, Win32 API.... However, the CLR does allow for interopability
between the two (which would be how the CLR treats it), basically shielding
from you the fact that code is unmanged.
If you are specifically interested in interopability, start by checking out:
http://msdn.microsoft.com/library/d...html/cpconInteroperatingWithUnmanagedCode.asp
Ideally, the "use" of unmanaged code would be something only there for
backwards compatibility. Everyone (ideally again) should be using Managed
Code...it lends itself to safer (which is I use broadly) and code which is
quicker to develop. Realistically, the CLR and .Net still aren't ideal for
all forms of development, such as real time development, graphically intense
development, firmware and the likes..
Karl
Managed code runs in the CLR (a virtual machine) which provides a number of
services: security, type safety, memory management just to name a few.
Unmanaged code doesn't run in the CL and is typically known as COM, COM+,
ActiveX, Win32 API.... However, the CLR does allow for interopability
between the two (which would be how the CLR treats it), basically shielding
from you the fact that code is unmanged.
If you are specifically interested in interopability, start by checking out:
http://msdn.microsoft.com/library/d...html/cpconInteroperatingWithUnmanagedCode.asp
Ideally, the "use" of unmanaged code would be something only there for
backwards compatibility. Everyone (ideally again) should be using Managed
Code...it lends itself to safer (which is I use broadly) and code which is
quicker to develop. Realistically, the CLR and .Net still aren't ideal for
all forms of development, such as real time development, graphically intense
development, firmware and the likes..
Karl
K
Kevin Spencer
Managed code runs in the CLR (a virtual machine) which provides a number
of
Excellent explanation.
I'm not sure what you mean by "Ideally," as that is a value judgment, almost
as if it is immoral to use unmanaged code. In fact, it is necessary to use
unmanaged code from time to time, if you are working on stuff that warrants
it. For example, I wrote some classes that "filter" images, applying
blurring, sharpness, contrast, and a number of other types of pixel-by-pixel
operations that become dreadfully slow if you use managed code only. I have
also written some classes that store tabular (Digital Elevation Model) data
in bitmaps for speed, and again, must loop through the pixels of the bitmap
to get the data. Using the GetPixel managed method to get to these pixels is
way too slow. Using a pointer is, of course, very fast. And note that
Microsoft has included fields and properties in managed classes to get a
pointer where necessary or useful.
The true advantage of managed code is that the developer doesn't have to
manage it. Specifically, you don't have to make sure that you have cleaned
up allocated memory, thus avoiding memory leaks. There is nothing immoral or
less-than-ideal about using unmanaged code from time to time. You just have
to manage it well for yourself.
--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
I get paid good money to
solve puzzles for a living
of
services: security, type safety, memory management just to name a few.
Unmanaged code doesn't run in the CL and is typically known as COM, COM+,
ActiveX, Win32 API.... However, the CLR does allow for interopability
between the two (which would be how the CLR treats it), basically shielding
from you the fact that code is unmanged.
Excellent explanation.
Ideally, the "use" of unmanaged code would be something only there for
backwards compatibility. Everyone (ideally again) should be using Managed
Code...it lends itself to safer (which is I use broadly) and code which is
quicker to develop. Realistically, the CLR and .Net still aren't ideal for
all forms of development, such as real time development, graphically intense
development, firmware and the likes..
I'm not sure what you mean by "Ideally," as that is a value judgment, almost
as if it is immoral to use unmanaged code. In fact, it is necessary to use
unmanaged code from time to time, if you are working on stuff that warrants
it. For example, I wrote some classes that "filter" images, applying
blurring, sharpness, contrast, and a number of other types of pixel-by-pixel
operations that become dreadfully slow if you use managed code only. I have
also written some classes that store tabular (Digital Elevation Model) data
in bitmaps for speed, and again, must loop through the pixels of the bitmap
to get the data. Using the GetPixel managed method to get to these pixels is
way too slow. Using a pointer is, of course, very fast. And note that
Microsoft has included fields and properties in managed classes to get a
pointer where necessary or useful.
The true advantage of managed code is that the developer doesn't have to
manage it. Specifically, you don't have to make sure that you have cleaned
up allocated memory, thus avoiding memory leaks. There is nothing immoral or
less-than-ideal about using unmanaged code from time to time. You just have
to manage it well for yourself.
--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
I get paid good money to
solve puzzles for a living