Does a solution written for Microsoft .NET have to be 100% .NET? Scott Hanselman looks at how hybrid managed-unmanaged solutions are really the norm.
The Myth of .NET Purity, Reloaded
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Why people care about “pure .NET”? It’s simple. They want to run it not only on MS CLR, but on Rotor, on Mono, on Portable.NET, etc. Of course that was not MS’s intention, but so what.
Except most people in the business world want to leverage the code they already have and don’t really care about crossplatform.
Also, just because you have your managed code calling some unmanaged code doesn’t mean it can’t be crossplatform. If the C code is crossplatform then just recompile it for whatever platform your targetting.
And that leads me to the WORA speel that Sun has been peddling all these years. Nobody really gives a damn about WORA. They care much more about WOCA(Write Once Compile Anywhere). Heck, most major client-side apps already have native installers anyway.
The cool thing about .NET/Mono/Pnet is that it’s absolutely trivial to call native code compared to Java.
I’ll be sticking with Java/SWT/Jface for my current project just because I can compile it with GCJ for windows and linux and don’t need a runtime(well, I need libjit, but not a full JRE).
Sun makes too many assumptions (or tries to tell people) what they really want, when they are just plain wrong. WORA, Swing common look-n-feel, the Java language itself.
From what I understand, none of the security features of .Net are applicable to non-managed code.
This means that in the Longhorn generation there might be just as many hooks from managed code into underlying native systems as there is from Outlook.
Basically there could be a continuation of the current swiss cheese security policies.
The switch to all managed code was the reasoning someone gave to me why Longhorn would be secure and safe from script kiddies.
I didn’t read the document, but it seems more like incentive to start migrating existing applications without needing a complete rewrite.
How is .Net any less Run Anywhere?
I thought the whole point of mono was to use CLI and just use a virtual machine on the binaries.
Surely the output from MS compilers is the same as from Mono’s compiler?
If you want cross platform compiling you can use C/C++ and QT? or wxWindows.
btw I agree that Swing is currently braindead, but it was less so when it first appeared.
I thought the whole point of mono was to use CLI and just use a virtual machine on the binaries.
Surely the output from MS compilers is the same as from Mono’s compiler?
It is, but the point of the article was about leveraging native code. It’s pretty stupid to re-write everything just for the sake of being managed. Of course, if you are starting fresh, and do care about cross-platform, then either (a) don’t do interop with platform specific code, or (b) make sure that library call you’re going to do is available on the platform you care about.
Yer, I saw this article directly on MSDN. This article was written because are sh*t scared of people porting .Net apps elsewhere and they’re scared of people talking about pure .Net applications. Notice the excessive use of P/Invoke and other Windows specific hooks.
Quite funny.
It would be funny if it were entirely true. The fact is though that there are many things that it is currently impossible to do in purely managed .net code. Sometimes, you have to fall back on the lower system APIs, which is why p/invoke exists.
This is largely irrelevant except for porting to Mono/Portable.NET. Remember how Sun used to push “100% Pure Java” certification, and then quietly let it disappear?
You can’t build on platform X and then deploy on platform Y without doing _testing_ on platform Y. “Write once, run anywhere” only buys you as much as traditional cross-compiling… you still need to double your QA/testing if you double your supported platforms. And developers are going to need access to all the platforms anyway for bug fixing.
The .NET Framework is missing a few interesting bits still; for example, to write a Windows screen saver, you need to dip into the unmanaged Win32 APIs to handle the preview display. Also, there’s no way to draw a single pixel on-screen… the “best” work-around is to create a 1×1 bitmap of the desired colour and blit it.
Note how both of those are trivial shortcomings and probably don’t apply to most .NET developers. 😉 I was porting some xscreensaver modules.
– chrish
It is not possible to do 100% .Net. Its not done yet. Half of the tools needed won’t be available for several years. The only thing .Net really solves right now is bad COM programmers.
I wish some CTO’s at my work would read that, but forwarding it will make me the boogie man again that’s always critical about their hypes
“From what I understand, none of the security features of .Net are applicable to non-managed code.”
Not really true, calling unmanaged code from .NET require some rights. At worst (if the unmanaged call is a simple DllImport or COM use) you’ll get exactly what you have right now: unmanaged code can do just anything. The diff is that you run .NET app and you’ll be warned that some unmanaged code are being in use… (sounds to me like the classic warning about downloading files… you can’t do anything against stupid users…). With “correct” unmanaged call you’ll be able to get something more fine grained…
Imho, what’s interresting about this article is that it clearly explain the purpose of .NET: it’s not to build cross-platform applications, it’s not to virtualize the machine… it’s simply to provide a clean and easier to use API for developers (and that’s great Win32 API often sucks).
Another strange thing about managed environment is that people use the “pure” expression… when does it become unpure? I mean any kind of managed environment need to hook the native environment… you won’t put anything to disk or on the screen (or anywhere) without asking the OS to do it… imho the frontier between what’s pure and what’s not is really fuzzy… Sun put it somewhere, Microsoft elsewhere… is one of them wrong?
Absolutely correct. Take a look at this line from the article:
“the Common Language Runtime still at some point needs to work with the Windows internal APIs. As the saying goes, no matter what you’re working on, eventually someone has to call LoadLibrary().
“If Microsoft were to truly virtualize the machine, they would have marginalized their investment in the Windows platform.”
There. He said it right there. Is there still question as to Microsoft’s intents?