R
Richard Grimes
Scott said:
Did you look at WinFS critically (I did... do a Google search for my
name and WinFS)? It was extremely slow, partly because it was over
engineered (there were too many layers and they were trying to solve too
many problems). But the main problem was that it used too much memory.
In that build the WinFS service was the major consumer of memory. So
although I agree with the 'reliably' part of your comment I do not agree
with the 'securely' part.
It is the 'securely' aspect that is the reason why .NET must be used
more in operating system code. And yes, there is a *must* in that last
sentence. Native code will never fully get rid of exploits like buffer
overruns; with C++ 8 you have the option of using the 'secure' string
functions, but it is an *option*, and it will not affect code that has
been compiled with the older static CRT libraries. And anyway the
'secure' memory methods in the CRT in VS2005 will not prevent your own
pointer code from writing past the end of a buffer. There is a solution
that will detect buffer overruns in code that you have not written and
shutdown the process, but it involves kernel drivers that detect memory
usage. It is a third part product, it is expensive, and it is used by
the military and companies that have the money and require a more secure
system. In .NET a buffer overrun is impossible! You simply cannot do it.
The problem has gone away and the solution is free. If a developer had
the choice of writing new code she would be extremely stupid not to use
..NET!
This is just one example as to why .NET is more secure, and there are
many more, so many, in fact, that it is incontrovertable that .NET is
inherently more secure than native code. Since security is the *most*
important part of an operating system, it mandates that .NET is used as
much as possible in Windows.
However, as I have pointed out elsewhere, the security of a process is
only strong as its weakest link. That is invariably native code, so
Microsoft's current policy (in Vista) of providing mixed code (where the
main stuff is existing Win32 code and there is a veneer of .NET applied
on top) does not give any more security. They may as well not do it.
Huh? This fits in exactly with what I am saying. The example I gave is
*not* reuse, it is totally new rewriting (ie it is Giant Software's
*algorithms* that they are using in their Defender product), which means
that they can use *any* technology they choose. You cannot reuse VB
source code in C++: they had to throw away the VB code they bought from
Giant. So, they had a great opportunity to show the world how good .NET
is, they could have shown how the RAD aspect of VS.NET meant that they
produced it under schedule and under budget (these are the things they
are telling us about VS.NET, right?), but instead they decided to use
unmanaged C++. For goodness sake, all that this stuff does is monitor
the registry and file system and pattern matches with know exploits, if
VB can do it then a .NET language (any one, all of them are more
powerful than unmanaged VB) plus the framework library can do it better.
What does it say about Microsoft's attitude to .NET? (Hint: it says that
there are other reasons why they didn't want to use .NET. They are not
telling us what those reasons are, or what they are doing about those
problems.) It may not be .NET that is the problem, it may be that the
person in charge is a native code bigot, or that the team used for the
development were incapable of learning .NET, but even so, if we are not
told *why* .NET was not used there will always be a question mark over
the framework.
No, Microsoft Defender will be on Vista, so .NET v2.0 will be
distributed as part of the operating system.
Richard
ldSyntax on