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.

"Mark Broadbent" <no************@no-spam-please.com> wrote in message
news:OL**************@TK2MSFTNGP11.phx.gbl...

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
=============

[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/PermaLi...-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" <no************@no-spam-please.com> wrote in message
news:OL**************@TK2MSFTNGP11.phx.gbl...

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
=============