I have 2 versions of .NET, which is being used

[Richard Grimes]

Much of the promised file system features were eliminated because of
the difficulty level in making it work reliably and securely. Since
the OS is not managed itself, there shouldn't be any reason that MS
*must* stuff .NET into it.

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.

But this isn't what I'm talking about at all. I'm talking about
brand new applications *written* from the ground up. Purchasing a 3rd
party product and re-writing it as unmanaged code just fits into what
I've been saying in the first place - - today MS can't guarantee that

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.

all Windows OS's out there have .NET on them, so most code is
unmanaged. It won't be until the .NET Framework is standard on most
machines out there for you to see apps. written in .NET hit the
mainstream.

No, Microsoft Defender will be on Vista, so .NET v2.0 will be
distributed as part of the operating system.

Richard

 

[Willy Denoyette [MVP]]

John, can you provide more detail on this? To my knowledge, once the
initial JIT happens, the IL assembly is compiled down to native code,
which is then stored (ASP.NET) in the
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files
folder and remains there until/unless the IL assembly is modified, at
which time a new JIT assembly is created. So, once the assembly is
JIT-ted, it will not be re-JIT-ted unless the IL assembly changes.

This is not true, the temp asp.net files folder do contain the compiled CS
or VB files (IL code files), JIT-ted code is never saved nor loaded to/from
disk in asp.net scenarios.
The only way to load native image files code is from the GAC, these files
must have been ngen'd however.

Willy.

 

[Richard Grimes]

Did you also notice that a number of "SQL assemblies" are now
authored using C++/CLI? Is this just "dog-fooding" or is there
something else going on?

I noticed that there were serveral that had clearly been written in
managed C++, I also did an analysis of the 2.0 framework library, and
there are several assemblies there written in C++. In particular, I
noticed that there were quite a few uses of IJW (ie not platform invoke,
but calls that were through embedded native code) which I thought was
very odd.

I don't know the reason, I can speculate that perhaps there are too many
C++ developers in Microsoft that won't move to .NET. For example,
Microsoft.SqlServer.Replication.dll contains ATL code that has been
compiled as managed C++ (I suspect simply by using /clrldSyntax on
some unmanaged C++ source code). Why is that? It does not make much
sense to me.

Richard

 

[Richard Grimes]

They're JITed only the first time they run, correct?

Yes, on a method by method basis, but as Scott points out, the
assemblies can me pre-jitted with ngen, and all of the framework
libraries are prejitted.

Richard

 

[Willy Denoyette [MVP]]

I noticed that there were serveral that had clearly been written in
managed C++, I also did an analysis of the 2.0 framework library, and
there are several assemblies there written in C++. In particular, I
noticed that there were quite a few uses of IJW (ie not platform invoke,
but calls that were through embedded native code) which I thought was very
odd.

I don't know the reason, I can speculate that perhaps there are too many
C++ developers in Microsoft that won't move to .NET. For example,
Microsoft.SqlServer.Replication.dll contains ATL code that has been
compiled as managed C++ (I suspect simply by using /clrldSyntax on some
unmanaged C++ source code). Why is that? It does not make much sense to
me.

Richard

Richard,

You don't need the 'oldsyntax' to compile C++/CLI that contains ATL code,
IMO Replication.dll uses ATL for easy COM interop with the DTS core and
relication package.
In my opinion there are teams in MS that won't move to C#, why should they,
C++/CLI is considered the system level language in .NET, right?

Willy.

 

[Scott M.]

Well, I could reply I have 8 year of experience (including 4 years .NET)
and I'm not impressed.

When I mentioned 4+ years of experience, I was referring to my .NET
experience. In other words, I've been working with .NET since before it's
public release. I tell you this to try to impress upon you that I might
just have clue as to what I'm talking about. I'm not trying to start a
pissing contest.

To pleases you I decided to argument a bit more here, to gives you an
opportunity to convince me as, I feel, you boil to do.
3 facts:
- in 2001 I clearly remember it tooks about 1 second to launch an empty
WinForm whereas Notepad was already instantaneous. Since then it has
improved. Truth to tell it has been a while I didn't experience slow
startup, but I'm not yet convince 100%.

But is this really a good benchmark of a test? First of all, are you
referring to an un-JIT-ted .NET application that took longer than Notepad to
open? Next, comparing "about 1 second" to "instintaneous" doesn't really
sound like a technical comparison.

- I read once in some MS newsgroup a complaint from an ASP develop which
has server with 3GB of memory and was previously able (through some
extension API I can't remember of) to use most of it in plain C program.
In .NET he was somehow limited to much less (maybe 1.3Gb) and it was some
problem due to .NET.

The size of the managed heap is directly proportional to the amount of
memory on the system. What you've stated above is too vauge to be able to
respond to with any specfics.

 

[Scott M.]

No Willy, that's not true at all.

In ASP.NET applications, the IL assembly is saved in the project/bin folder.
At first run, that assembly is JIT-ted and a new native assembly is created
and placed in the "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary
ASP.NET Files" folder. It is this assembly that is actually used during
application execution. This assembly will stay in this folder and continue
to be used until such time as the original IL assembly (the one in the
project/bin folder) is changed or the contents of the project/bin folder
changes.

-Scott

 

[Scott M.]

Microsoft has made no bones about saying that Office will not be re-written
as a managed application. It just doesn't make any sense to spend millions
and millions of dollars and hog the resources of many developers to re-write
what already works.

It has nothing to do with .NET capabilities, it was purely a business
decision ($$$).

 

[Lau Lei Cheong]

I'll place amendment here - Afterall, they did attempt to rewrite the
"visual part of" OS with as much managed code as possible...

 

[Jon Skeet [C# MVP]]

But is this really a good benchmark of a test? First of all, are you
referring to an un-JIT-ted .NET application that took longer than Notepad to
open? Next, comparing "about 1 second" to "instintaneous" doesn't really
sound like a technical comparison.

It's a good benchmark of your statement that:

<quote>
..NET apps. do not/are not slower in start up, period.
</quote>

That's not a statement which says you have to pre-JIT a .NET
application to make it as fast to start up as native apps. It just
talks about ".NET apps."

Now, if a trivial application with no functionality beyond showing a
window is slower to start up than one *with* functionality, that seems
to me to disprove your statement. 1 second *is* slower than
"instantaneous", however untechnical the comparison is. If you showed
users (technical or not) two things, one of which started up in 1
millisecond and one of which started up in 1 second, do you not think
they'd all say that the 1 second app was "slower in start up"?

If you want to revise your statement to only include ngen'd
applications, that's fine, but I don't think it's reasonable to claim
that your statement as originally made *only* includes ngen'd
applications.

 

[Damien]

No Willy, that's not true at all.

In ASP.NET applications, the IL assembly is saved in the project/bin folder.
At first run, that assembly is JIT-ted and a new native assembly is created
and placed in the "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary
ASP.NET Files" folder. It is this assembly that is actually used during
application execution. This assembly will stay in this folder and continue
to be used until such time as the original IL assembly (the one in the
project/bin folder) is changed or the contents of the project/bin folder
changes.

-Scott

Seems to me that all of the DLLs stored under that folder are openable
with ildasm, and still seem to have IL inside them. I know that ASP.NET
taks a copy of all DLLs in the bin folder (and creates DLLs for the
aspx pages) so that the DLLs in the bin folder are not locked, but
can't find any reference to them being pre-JITted or the like, except
for your own statements in this thread?

Damien

 

[Willy Denoyette [MVP]]

If you mean "Avalon" or WPF, you are right this is a managed API, but this
is an API it's not part of the OS, it's optional. Vista runs without it no
problem. If you mean everything that sits under avalon (the rendering
engines for avalon, DirectX, GDI) well, this is still unmanaged code which
sits in top of USER and win32k.sys (longhorn kernel version).

Willy.

 

[Willy Denoyette [MVP]]

Scott, this is not true, certainly not in v1.1 neither in v2.0. Note also
that what's stored in the Temporary directory are the shadow copy files or
work files from VS.
The files (the DLL's) in Temporary ASP.NET Files are IL files, try to run
ildasm on them and watch.
All other files are simple administrative templates (XML files, compiler
scripts, etc..) used by VS (when run on the same box) to manage/compile the
assemblies, none of them a unmanaged PE files.
If you need JIT-ted images to be loaded from asp.net you will have to ngen
them and automatically they'll end in the GAC where fusion will pick the up.

Willy.

 

[Lau Lei Cheong]

Oh really? I thought DirectX is going to be "managed" as well... :O

 

[Scott M.]

It's a good benchmark of your statement that:

<quote>
.NET apps. do not/are not slower in start up, period.
</quote>

That's not a statement which says you have to pre-JIT a .NET
application to make it as fast to start up as native apps. It just
talks about ".NET apps."

Now, if a trivial application with no functionality beyond showing a
window is slower to start up than one *with* functionality, that seems
to me to disprove your statement. 1 second *is* slower than
"instantaneous", however untechnical the comparison is. If you showed
users (technical or not) two things, one of which started up in 1
millisecond and one of which started up in 1 second, do you not think
they'd all say that the 1 second app was "slower in start up"?

If you want to revise your statement to only include ngen'd
applications, that's fine, but I don't think it's reasonable to claim
that your statement as originally made *only* includes ngen'd
applications.

 

[Scott M.]

.NET apps. do not/are not slower in start up, period.
</quote>

That's not a statement which says you have to pre-JIT a .NET
application to make it as fast to start up as native apps. It just
talks about ".NET apps."

I had already discussed NGEN earlier in this thread and the fact that once
NGEN happens, it is no longer an issue is what that statement is referring
to. The IL to Native code compilation delay is not a reasonable reason to
make the statement that ".NET applications start slower than un-managed
apps." because it is easily overcome by NGEN as well as the fact that
ASP.NET apps. only suffer the hit on the first call to the application, not
every call. So since the IL to Native compilation is just something that
you can easily fix, it is perfectly reasonable to say ".NET apps. do
not/are not slower in start up, period."

Now, if a trivial application with no functionality beyond showing a
window is slower to start up than one *with* functionality, that seems
to me to disprove your statement. 1 second *is* slower than
"instantaneous", however untechnical the comparison is. If you showed
users (technical or not) two things, one of which started up in 1
millisecond and one of which started up in 1 second, do you not think
they'd all say that the 1 second app was "slower in start up"?

My point was that the statement was made with vauge benchmarks. It didn't
really sound like Lloyd had actually measured the start up time. He also
didn't indicate if the .NET applicaiton had already been JIT-ted or NGEN'd,
hence my suspicion of the remak.

If you want to revise your statement to only include ngen'd
applications, that's fine, but I don't think it's reasonable to claim
that your statement as originally made *only* includes ngen'd
applications.

It sure is reasonable. I've been discussing NGEN/JIT for the last 3 messages
in this post after I brought it up as a counterpoint to Lloyd's slow startup
remarks.

 

[Jon Skeet [C# MVP]]

I had already discussed NGEN earlier in this thread and the fact that once
NGEN happens, it is no longer an issue is what that statement is referring
to. The IL to Native code compilation delay is not a reasonable reason to
make the statement that ".NET applications start slower than un-managed
apps." because it is easily overcome by NGEN

There are various disadvantages to Ngen, however. Are you going to make
your app detect when it's no longer running the Ngen'd version (eg
because someone's changed processor) and re-ngen it?

as well as the fact that
ASP.NET apps. only suffer the hit on the first call to the application, not
every call.

Where was this discussion restricted to ASP.NET apps though?

So since the IL to Native compilation is just something that
you can easily fix, it is perfectly reasonable to say ".NET apps. do
not/are not slower in start up, period."

I'm afraid I think we'll have to disagree on that.

My point was that the statement was made with vauge benchmarks. It didn't
really sound like Lloyd had actually measured the start up time. He also
didn't indicate if the .NET applicaiton had already been JIT-ted or NGEN'd,
hence my suspicion of the remak.

The difference between "instant" and "a second" doesn't need precise
timing to be noticeable though - and the app didn't need to have been
Ngen'd in my view, as very few apps *are* ngen'd.

It sure is reasonable. I've been discussing NGEN/JIT for the last 3 messages
in this post after I brought it up as a counterpoint to Lloyd's slow startup
remarks.

Your statement is that all .NET apps are not slower at startup. If your
statement only holds for Ngen'd apps, does that mean you believe that
all .NET apps are Ngen'd? That's clearly not true.

 

[Willy Denoyette [MVP]]

DirectX remains DirectX, that is native code, all there for managed
development is a managed API layer, but the core remains native code.

Willy.

| Oh really? I thought DirectX is going to be "managed" as well... :O
|
| "Willy Denoyette [MVP]" <[email protected]>
¼¶¼g©ó¶l¥ó·s»D:%[email protected]...
| > If you mean "Avalon" or WPF, you are right this is a managed API, but
this
| > is an API it's not part of the OS, it's optional. Vista runs without it
no
| > problem. If you mean everything that sits under avalon (the rendering
| > engines for avalon, DirectX, GDI) well, this is still unmanaged code
which
| > sits in top of USER and win32k.sys (longhorn kernel version).
| >
| > Willy.
| >
| >
| >
| > | >> I'll place amendment here - Afterall, they did attempt to rewrite the
| >> "visual part of" OS with as much managed code as possible...
| >>
| >> "Willy Denoyette [MVP]" <[email protected]>
¼¶¼g©ó¶l¥ó·s»D:[email protected]...
| >>>
| >>> | >>>> Don't ask me. It's the management. XD
| >>>>
| >>>> I think they may think that Microsoft will use Office to demo the
power
| >>>> of .NET framework, just like what they did for Office 95...
| >>>>
| >>>> But I think it's not impossible, just quite unlikely. Afterall, they
| >>>> did attempt to rewrite the OS with as much managed code as
possible...
| >>>
| >>>
| >>> Really? what part of the OS?
| >>>
| >>> Willy.
| >>>
| >>>
| >>>
| >>
| >>
| >
| >
|
|

 

[Stefan Simek]

Hi,

I'm with Jon on this one. I've written a simple app in C# and C++ that
does nothing but opens a form and closes it on OnActivated/WM_ACTIVATE
respectively. These are the results I've achieved with managed/managed
NGENd/unmanaged versions respectively (the app runtime is measured from
Process.Start untill Process.WaitForExit returns)

-------------------------------------------------
Benchmarking 'BenchmarkFX.ManagedUnmanagedStart - Void StartManaged()'
Generating code...
Running benchmark...
Result: Performed 100 iterations in 12,8041460576693 sec
Single call took: 128,041 ms
-------------------------------------------------
Benchmarking 'BenchmarkFX.ManagedUnmanagedStart - Void StartManagedNgend()'
Generating code...
Running benchmark...
Result: Performed 100 iterations in 11,9177518371748 sec
Single call took: 119,178 ms
-------------------------------------------------
Benchmarking 'BenchmarkFX.ManagedUnmanagedStart - Void StartUnmanaged()'
Generating code...
Running benchmark...
Result: Performed 100 iterations in 3,31624214809424 sec
Single call took: 33,162 ms
Done

You can clearly see that the unmanaged app starts almost instantly,
whereas there is almost no difference between jitted and ngen'd managed
version. Not mentioning that there is certainly a constant process
startup time included in all the measurements, which would make the
absolute difference in startup much more than 4x.

Note that 120 ms is a duration that is perfectly perceptible by humans -
it's exactly when you get the feeling something happened *almost*
instantly, but not instantly (as for durations under 50 ms).

This makes your statement completely untrue for both ngen'd and jitted
apps. Note that I'm not talking about ASP.NET apps, this is a completely
different story, including the startup time only when the application is
accessed for the first time. From then on, as far as I understand, the
application assembly is more or less permanently loaded in an appdomain
in the aspnet_wp and all that happens are mere method calls to the
compiled and jitted assembly (I don't believe NGEN is used in this case,
it would make no sense).

I just love this kind of discussion

Stefan

 

[Scott M.]

The difference between "instant" and "a second" doesn't need precise

timing to be noticeable though - and the app didn't need to have been
Ngen'd in my view, as very few apps *are* ngen'd.

If someone is going to complain about start up time, then NGEN becomes part
of the discussion.

Your statement is that all .NET apps are not slower at startup. If your
statement only holds for Ngen'd apps, does that mean you believe that
all .NET apps are Ngen'd? That's clearly not true.

See above remark. NGEN is not some 3rd party add-on for .NET that helps
overcome some inherant flaw in the design of the architecture. It is a
valid and integral part of the toolset for .NET and is applicable to all
..NET assemblies. Since all .NET assemblies can use NGEN, then my statement
holds.

I just see Lloyd's comments like someone who goes to the doctor complaining
of an ailment, the doctor giving a prescription to cure the problem and the
patient just throwing the prescription away and continuing to complain about
the ailment.