Microsoft, Native Code, and Security One of the core tenets of the entire .NET architecture (compared to the native Win32 world) was security. Now with COM bindings for Silverlight and the end of Code Access Security, the picture has been changed significantly. One of the core tenets of the entire .NET architecture (compared to the native Win32 world) was security. At the very beginning, it was often claimed you could mathematically prove that a managed application was types safe, you could use Code Access Security to determine if an application had specific permission to execute any code deemed potentially unsafe. Also the goal (4 or 5 years ago) was to rapidly phase out COM (declared an obsolete legacy technology right after .NET was launched) and native code in favor of an all managed ecosystem. Fast forward to the last few weeks. First, one of the most heralded new features of Silverlight 4 is its COM binding capability. This goes against the security mantra (even if this will be possible only for applications installed locally), the entire idea of portability (how could a Mono app on Linux talk via COM to Office is a mystery), and the notion that COM is obsolete. One of the core issues is Microsoft Office interaction. If Microsoft cannot push Office as an element of its development ecosystem. Second, one of the cornerstones of .NET security, Code Access Security, is "retired" as Tim Anderson clearly tells in his blog. Even if powerful, the model was too complex for most programmers to comply with and system administrators to enable. This certainly doesn't compromise the security of .NET applications in any way, as I doubt it was really used. Now if we put these two unrelated announcements together, the morale is quite obvious (at least to me and many other die-heats native Win32 developers): Native COM and Win32 code is here to stay and using it properly doesn't compromise security. This is not surprising, given the amount of new native (COM and Win32) features in Windows Vista and (even more) Windows 7. There is nothing new in recent operating systems you cannot use in a native application. Connecting the dots, however, I'm tempted to push this a little forward. Contrary to what Microsoft envisioned or hoped or simply told us, the Windows ecosystem is not moving towards a .NET centric solution, but .NET is only a powerful and sophisticated execution and development environment on top of Windows . Which is what Delphi and the VCL are, even if at a much smaller extened due to the highly different R&D budget behind it. I know this is debatable, happy to hear about your point of view.

22 Comments

Microsoft, Native Code, and Security Couldn't agree more with your moral: Win32 will never go away and the fact Windows 7 includes new native and COM code illustrates the point that Microsoft thought they could change the face of software development on Windows. Did they really think that 15 years of prior native-code development would all go eventually? The, otherwise exceptional, Lino Tadros, at a Delphi Developer's Conference in reading in about 2002/3, said "it isn't a case of IF you move to .NET, but WHEN". I didn't believe him at the time and I'd be interested to hear his comments on that quote now.

Microsoft, Native Code, and Security .net is a nightmare. the same nightmare as java. Buggy and slow. Native code rocks always and forever.

Microsoft, Native Code, and Security That's good, but Delphi VCL does very little to exploit Windows security - look at Datasnoop 2010. Right now we still have mostly a Win9x development tool update to support Unicode and some new GUI features. Behind that, there's almost nothing built upon the NT line capabilities. COM/DCOM support was never really improved, and still has limits due to Win9x didn't had full capabilities, although Win9x is no longer supported. BTW: "the entire idea of portability" at Redmond just means how to port users to Windows and Office. What Mono on Linux does I guess is the last of their worries - and mine <g>.

Microsoft, Native Code, and Security For me, .NET is just a huge and easy to use library, where most features are free (as in beer, compared to Delphi). Another goodie is Mono, which really seems to be coming of age.

Microsoft, Native Code, and Security "The Windows ecosystem is not moving towards a .NET centric solution" Hmmm. Microsoft "Midori"? http://en.wikipedia.org/wiki/Midori_(operating_system) It will be the first Microsoft managed operation system. They are working on it. Perhaps, Windows will run within Midori for keeping compatibility...

Microsoft, Native Code, and Security There will never be a .net OS. .net will be what it is: a niche product as java for special tasks, but no main stream technology. Security and .net??? LOL!!! Everybody can see your code via disassembler. The life becomes easier for the Chinese Service.

Microsoft, Native Code, and Security Found a comment to this blog post at http://wupingxin.blogspot.com/2010/01/com-is-still- alive.html

Microsoft, Native Code, and Security Frankly, I don't know what MS wants, but it is for sure that they have to do some new thing because Windows becomes unsaleable. In my opinion, the .NET would be a great possibility for creating a full managed/OOP Windows API. An extra abstraction layer is always better for supporting higher level solutions (programming languages, OOP API, security & isolation, etc.). Of course, there are also performance problems, but a "manged" layer is several advantages you don't able to do in native code. It is fact.

Microsoft, Native Code, and Security Daywalker, seven years are not enough to develop an OS using MS resources? And did you ever hear about JavaOS and its siblings? MS needed such project to push developer to embrace .NET which started with zero developers available. My take: 128 bit processor will become mainstream before we see a .NET/Java OS.

Microsoft, Native Code, and Security I am glad that I didn’t invest so much on .Net, my conclusion now is much the same as it was 9 years ago which I posted in borland.public.delphi.non- technical: http://groups.google.com/group/ borland.public.delphi.non-technical/browse_thread/ thread/432e8fd36f5220ee

Microsoft, Native Code, and Security Luigi, in my opinion, it makes no sense. Again, I like the .NET and the native code world too. I can imagine a full managed operation system on my dual core (x64) machine. Anyway, there are several advantages of the .NET. See parallel framework, entity framework v2.0, improved language features, an OOP class library (no visual "LEGO" components), Workflow Foundation 4.0!!! and Windows Communication Foundation 4.0 (improved MSMQ support)!!! These are good things and no enemies. If the Windows API would be so unified like the .NET, then...

Microsoft, Native Code, and Security This is a continuing conversation, trying to find problems with another framework/platform to legitimize one's affection to a certain platform. Java folks do this with .net, .net folks with Java, windows folks with Linux, and apple with everybody else. Even without code access security and with optional COM interop with silverlight, there is enough layers of abstraction and access to OS security features from .net that makes it much easier to develop secure applications. The argument that one can create secure application with win32 (or assembly or any other) is rather self defeating. Now, when it comes to VCL, though i do not have enough exposure to Vcl2010, the previous versions were quite buggy (even after discounting the bloached .net effort), which in itself is a security threat. With the ever shrinking ecosystem of ancilliary tools (code analysis, testing, agile, components) Delphi is fast becoming the preferred tool of a few die hard fans. Delphi is still contemplating 64bit, while most of the new computers come with 64bit OS. If you look at the history of large scale changes in VCL/IDE, I personally dont have a lot of trust in the first or even second version of a 64bit releast. The same goes for parallel computing (which Oxygene/Prism already supports at a language level). The lesson? Finding fault with others wont automatically improve your standing.

Microsoft, Native Code, and Security Thanks for this blog. I really opened my eyes to three facts (from my view point): 1. Delphi is here to stay but unfortunately its IDE is still dependent on bloated and slow to execute .NET framework. This itself show that even a Native Code compiler developer has to use and depend on .NET. Very BAD! 2. VB will not die out that soon. That is just great. I have a fleet of ActiveX (around 200) most of which are just not getting imported properly in Delphi 2006 but they seem work seamlessly in VB6. So I can and should develop in VB6 also instead of ignoring it. That is what I have been doing since last 2 years. 3. Any programming language be it Delphi or VB or what ever is incomplete if it does not support ActiveX/COM natively as this technology is the back bone of Windows. So I think for Delphi to be really usable and have greater appeal in the programming world it should be able to host ActiveX as easily as VB6 without any unwanted work around. In short Delphi should support VCL as well as ActiveX out of the box and there should be some way by which one can add a VCL or an Activex/COM to a project directly like one would add a code module to a project.

Microsoft, Native Code, and Security Daywalker, I never said .NET/Java are useless environments. But they are - and IMHO will be for a long time - environments atop a native operating system, and I wonder when - and if - we will see a fully managed OS - or even an OS with only a managed interface.

Microsoft, Native Code, and Security Luigi, I hope that this is the near future. (2020??? :D) I'm waiting for this.

Microsoft, Native Code, and Security Write in C: http://www.youtube.com/watch?v=J5LNTTGDKYo

Microsoft, Native Code, and Security I guess WWSAPI is interesting too: http://code.msdn.microsoft.com/wwsapi

Microsoft, Native Code, and Security I think the post is not totally accurate. Let's start by the security model. It is true that CAS is going to be retired, but it is also true that a new model is taking place, named security transparency (http://blogs.msdn.com/shawnfa/archive/2009/11/03/tran sparency-101-basic-transparency-rules.aspx). Actually this is not really new because it has been used by Silverlight runtime since long time ago and we could say with good success. Then COM. It is very true that COM is very hard to remove and it was probably a dream to think about removing it in few years. When MS proposed to remove VBA from Office they got busted by the customers. Back to the case of Silverlight, COM can be called only for out of the browser instances, which makes Silverlight more like a standard Windows application. As far as I know Silverlight got only one security vulenarability discovered (it was Silverlight 2.0) and this proves, somehow, that the security model adopted is not so bad. Isn't it?

Microsoft, Native Code, and Security I reported the Windows Web Services API support yesterday. http://qc.embarcadero.com/wc/qcmain.aspx? d=81498.

Microsoft, Native Code, and Security The (so to say) Delphi killer app to me (actually my company) was ASP.NET. The web development makes the difference. Compare intraweb with asp.net; see the work a firm like DevExpress is doing; they still work with Delphi (great components too) but, for web development, build very sophisticated libraries asp.net based....

Microsoft, Native Code, and Security This is a blog dated back to 2004, but I feel it mentions one fact, which is more relevant today. The real power of Microsoft was in their API (Win32 API) and if they loose it, they will loose the everything and ultimately the 'war' also. http://www.joelonsoftware.com/articles/APIWar.html

VC++ in its 'swan song'? - Microsoft, Native Code, and Security Just thought of adding the following, as it relates to this discussion about 'native' world. Though MS can't do away with the native platform, I feel, it is now clear that like their old VB, even VC++ will eventually be dumped. (Even now it is just a second class 'citizen' in MS DotNET world) If not convinced, please read the following, which is "Straight from the horse's mouth" http://connect.microsoft.com/VisualStudio/feedback/details/382151/what-is-the-future-of-c-cli "Investing in C++/CLI will be mainly in the native-managed interop areas." and VC++ won't play a major role in DotNET. See these http://www.tech-archive.net/Archive/DotNet/microsoft.public.dotnet.languages.vc/2007-12/msg00254.html http://msmvps.com/blogs/peterritchie/archive/2008/01/29/is-c-cli-a-second-class-language-with-microsoft.aspx Also, this http://www.pcreview.co.uk/forums/thread-3683834.php





Post Your Comment

Click here for posting your feedback to this blog.

There are currently 0 pending (unapproved) messages.