January 21, 2010

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.



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.
Comment by Jason Sweby [http://delphidisciple.blogspot.com] on January 21, 11:43

Microsoft, Native Code, and Security 

.net is a nightmare. the same nightmare as java. 
Buggy and slow. Native code rocks always and forever. 
Comment by Bill on January 21, 12:30

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>.
Comment by Luigi D. Sandon on January 21, 14:11

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.
Comment by arni on January 21, 15:22

Microsoft, Native Code, and Security 

"The Windows ecosystem is not moving towards a .NET 
centric solution"

Hmmm. Microsoft "Midori"?

It will be the first Microsoft managed operation system.   
They are working on it. Perhaps, Windows will run within 
Midori for keeping compatibility...
Comment by daywalker [http://janosjanka.spaces.live.com] on January 21, 16:42

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.
Comment by Peter on January 21, 20:09

Microsoft, Native Code, and Security 

Found a comment to this blog post at 
Comment by Marco Cantu [http://www.marcocantu.com] on January 21, 20:12

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.
Comment by daywalker [http://janosjanka.spaces.live.com] on January 21, 21:19

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.
Comment by Luigi D. Sandon on January 21, 23:02

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-
Comment by Khaled Shagrouni [http://www.shagrouni.com] on January 21, 23:37

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...
Comment by daywalker [http://janosjanka.spaces.live.com] on January 22, 03:23

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 

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.
Comment by salim on January 22, 04:05

Microsoft, Native Code, and Security 

Thanks for this blog.

I really opened my eyes to three facts (from my view

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

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.

Comment by Yogi Yang on January 22, 09:50

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 
Comment by Luigi D. Sandon on January 22, 14:33

Microsoft, Native Code, and Security 

Luigi, I hope that this is the near future. (2020??? :D) 
I'm waiting for this.
Comment by daywalker [http://janosjanka.spaces.live.com] on January 23, 14:30

Microsoft, Native Code, and Security 

Write in C:

Comment by C Master [http://www.youtube.com/watch?v=J5LNTTGDKYo] on January 23, 18:28

Microsoft, Native Code, and Security 

I guess WWSAPI is interesting too:

Comment by Luigi D. Sandon on January 26, 10:25

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 
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?
Comment by Pierre on January 26, 17:57

Microsoft, Native Code, and Security 

I reported the Windows Web Services API support 
yesterday. http://qc.embarcadero.com/wc/qcmain.aspx?
Comment by daywalker [http://janosjanka.spaces.live.com] on January 26, 23:05

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....
Comment by Nicola Farina on January 27, 13:17

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.

Comment by Surendran Krishnapuram [] on February 1, 14:55

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" 


"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


Also, this
Comment by Surendran Krishnapuram on February 3, 15:34

Post Your Comment

Click here for posting your feedback to this blog.

There are currently 0 pending (unapproved) messages.