:DPues que mejor, en mi opinion siempre es mucho mejor alternativa aprender C# o cualquier lenguaje .NET que aprender java.

hasta donde entiendo la opcion de codigo nativo no implica que el programa cambie la manera en que se ejecuta, es decir tambien requiere que se use como intermediario el framework puesto que aun depende de sus servicios como por ejemplo el GC.

Lo que realmente hace esta utilidad es llevar a cabo el proceso que hace el JIT  por anticipado, lo cual acelera el tiempo de carga de la aplicacion ya que esta previamente convertida en codigo nativo.

Recordemos que en .NET el codigo se encuentra en estado de compilacion intermedia y una vez se ejecuta se termina la compilacion del codigo, sin embargo esta compilacion no es total y se va pasando por el JIT solo lo que se va necesitando, por ello la primera vez que ase accede a una funcion o modulo se demora un poco más mientras se realiza el proceso de compilacion final, pero ya una vez sucede esto la función se ejecuta en codigo nativo y es identica en rendimiento que un programa hecho en lenguaje nativo directamente; asi que la utilidad de convertir a codigo nativo lo que hace es terminar el proceso de compilacion del ensamblado de tal froma que cuando se use el programa no existan tiempos de carga porque ya esta todo convertido a codigo nativo.

La desventaja de esto es que el proceso que convierte todo a codigo nativo no es tan eficiente como el JIT, ya que el JIT genera codigo nativo de acuerdo a una situacion particular de la maquina incluso dependiendo de en un momento determinado en el consumo de recursos.

La opcion de generar el ensamblado en codigo nativo tambien tiene el problema que al llevar tu ejecutab le o tus librerias .net a otra plataforma no van a funcionar por lo cual se recomienda hacer algo como lo que hace el instalador de Sharp develop, es decir una vez copiados o instalados los ensamblados en codigo CIL se ejecuta un batch que inicia el proceso de generacion de codigo nativo utilizando ngen.

Aunque este en codigo nativo debes ejecutarlo usando
mono miprograma.

Por otro lado en windows la opcion no esta incuida en el compilador  sino que es una utilidad aparte que se usa por la consola de comandos llamada ngen.

ngen nombreensamblado

Entiendo tu punto de vista, pero cabe aclarar que delphi es PASCAL y la forma de trabajo depascal es muy parecida realmente no a la de .NET sino a la de Visual Basic... porque de hecho Visual basic salio del Basic y del QBasic  y asi sucesivamente nos iremos cada vez  mas para atras.

De pronto se te hace parecido la implementacion de POO, pero estan muy distanciados el uno del otro, El modelo de objetos de .NET mas parece una version más actualizada y utilizable del modelo que propuso smallTalk, de alli que se suele afirmar quwe la implementacion mas completa de POO es la que se ha hecho con .NET.

No olvides tambien que la gente que usa java dice que .net e incluso que C# se copiaron de java... pero nadie dice que C# es mas otra version de C++ sintacticamente hablando, al igual que lo es java, y que el concepto de memoria administrada ya habia sido inventado hace años pero que no se implemento porque no habia el hardware conla velocidad suficiente.

Y respecto a lo que dice BADBYTE-K, estoy muy de acuerdo... esta muy de moda hechar piedras a Microsfot y nadie ve todo lo que microsoft ha hecho por la industria , ni lo que le ha regalado a la industria como C#, CLI, CTS etc.

Respeto a mono, no es nada cierto que omno sea pagado por MIcrosoft... de donde sacas eso???? eso es una mentira. 

Mono nacio libre y sigue libre.. o más o menos...
Microsoft tiene tan poco que ver con mono, que mono en este momento esta colgado en la implementacion de las bibliotecas que conforman la version 2 de .NET Framework cuando ya se vino con Windows Vista el .NET framework 3.0..

Tan es falso lo que dices que a mono lo compro Novell o mejor dicho lo financia Novell... por eso el mayor soporte de mono es para SuSe Linux (ahora Novell linux).

Si en verdad no eres Anti Microsoft, ten cuidado con lo que lees y sobre todo con las fuentes, porque has dicho cosas sin fundamento. Trata de averiguar siempre desde fuentes confiables porque luego luego puedes quedar mal sin tener culpa ni mala intención.

http://www.mono-project.com/Main_Page

Revisa donde dice Novell y alli pueden verificar de lo que he hablado asi como en otras fuentes en internet.

No habia escuchadop especificamente el terminmo API nativa, pero lo poco que pude ver asi por encima es que si se refere a programar en modo kernel, y de ser asi casi puedo asegurar que bo hay soporte para VB 6.0.

te refieres a desarrollar en modo kernel? 

Siempre es recomendable buscar primero en google:

http://www.elguille.info/VB/VB_API.HTM

Claor que si, desde visual basic es perfectamente accesible la api de windows, averigua por platfrom SDK.

El problema es que si es VB 6.0... probablemente haya alguna limitacion en el soporte por ser una herramienta ya dejada atras.

Bueno tu comentario esta un poco fuera de lugar, pues no estas muy enterado del contexto real de las cosas. Los unicos lenguajes microsoft en .net son ASP , J#, C# y VB y hay otros menores, pero hay proyectos de libre implementacion para hacerce de esta tecnologia.

Incluso lenguajes como C# que originalmente fueron desarrollados por microsoft para su tecnologia .net , son de acceso libre y proyuectos como mono o Boo uisan ese lenguaje en libre implementacion  sin cobrar un $ esto debido  auq ela especificacion del CLI  microsoft la hizo un estandart abierto al que cualquiera puede aceder y conbase a los documentos hacer su compilador de un lenguaje determinado o de uno ya existente siguiendo los parametros establecidos en el estandart y listo ya queda compatible con .net.

Microsoft no recibe un peso de mono ni de Boo, ni siquiera de la version de mono para windows que facilmente les llegaria a quitar los compradores de visual studio algun dia.   

Por otro lado microsoft .net no tiene nada que ver con delphy que es un IDE y no un lengueje, el equivalente a delphy es visual studio no C# y no tienen nada parecido, y respecto a java el marco de trabajo apenas si se parece, si ,net fucionara como java seria igual de lento que este ultimo, y no es asi porque nisiquiera existe maquina virtual en .net.

Y respecto al staff tambien es una mentira y un mito, de hecho muchas de las persona que lideraron el desarrollo de .net ya trabajaron antes con microsoft en las implementaciones anteriores de COM y activeX.

si estas hablando de PASCASL.NET es valido ( hay PASCAL .NET??)

Y por otro lado aunque no fuera pascal, cualquier exe se puede descompilar  , el punto es que no haya sido utilizada ninguna tcnica de ofuscacion para endurecer la tarea.

Por otro lado aunque lo puedas descompilar, llevarlo a pascal nmo sera nada facil , de seguro mas facil llevarlo a C y eso solo devolviendote los llamados a la API... de ahi para arriba... complicadisimo, si tienes suerte encontraras algun buen decompilador a C++ pero no creo que a PASCAL, te tocaria buscar.