compilation of .net languages...

[Mark Broadbent]

I think I know the outcome to this question (please forgive me because I
know it is probably asked a thousand times!)

Does Microsoft plan to bring out some kind of mechanism to compile directly
to machine code (i.e. bypassing IL (or further protecting the IL code).
I know that there is a third party encryption software around that Microsoft
is offering on MSDN downloads. I have also seen the interview with Anders
Heljsberg discussing that it would be quicker to re-write some software
rather than reverse engineer it from IL etc etc (therefore native code not
needed).

I just cant stop thinking that one of the biggest reasons for the slowish
uptake of .NET is this lack of native code issue ...and yes I know that the
IL/JIT is fundamental to the interoperability between .NET languages *but* I
feel the option should be there to compile one step further if the assembly
is not for reuse.

I'm sure technically it would be relatively simple for microsoft to create a
software bridge to "hook" native machine code (.net) to the CLR.

Anyone know of such plans?

--

--

Br,
Mark Broadbent
mcdba , mcse+i
=============

 

[Marina]

Check out the ngen.exe utility that comes with the framework.

 

[Michael Giagnocavo [MVP]]

I don't see why they'd want to go around IL. The CLR can outperform just
normal native code in some scenarios (due to garbage collection). IL is also
optimized per-machine when compiled down to native code. So, for instance,
the same IL on a P4 will produce different machine code than when used on a
Pentium.

A lot of Longhorn (Avalon, the cool new graphics) is written in C# and
compiled to IL. They are going to pre-JIT things (ngen). Currently ngen is
recommended to reduce startup time, but the code output by pre-JIT is ~5%
slower than the normal JIT. There are plans to improve this in the future.

As far as IP property protection, I don't see IL vrs. x86 as a huge issue
(and I'm in the obfuscation business: www.invisiSource.com). Native code can
be cracked easily as well (I wrote a small tutorial:
http://www.atrevido.net/blog/PermaLink.aspx?guid=ec99e239-8917-48e3-bd4f-af866b730150).

Going back to native code is just more problems. There are differences for
different platforms (x86 vrs IA64, vs AMD's 64-bit stuff, smaller processors
(Compact Framework), etc.). The benefits of IL far outweigh any perceived
problems.

-mike
MVP

 

[Mark Broadbent]

Hi Mike. Thanks for your post. To a large degree you are preaching to the
converted.
My arguments for this functionality is based largely on industry
perception -I think Java did a lot of damage (in the very early days of the
internet) with regards to speeds of JIT compilation against native code
....and mud sticks.
I also think that some kind of protection mechanism that is part of the .NET
standards should be available to encourage to uptake of .NET with software
distributors (regardless of whether the code is really any more secure or
not). It's perception that counts -and betamax died a death because of it.

Maybe Im wrong with my perception of the industry!

Thanks for the info.

--

--

Br,
Mark Broadbent
mcdba , mcse+i
=============

 

[Mark Broadbent]

thx Marina.

--

--

Br,
Mark Broadbent
mcdba , mcse+i
=============

 

[Michael Giagnocavo [MVP]]

Well, if it's just perception you are worried about, then it's no problem --
Microsoft can put their marketing engine behind any misperceptions .
That's the upswing of using the largest software company in the world.

As for the "industry" companies who are making platform decisions based on
such misperceptions, well, sucks to work at one of those companies. Java was
slow because IIRC, some JVMs were interpreted. IL was never meant to be
interpreted. And, virtual machine technology is nowhere near new -- it's
been around for a long time before java.


-mike
MVP