1. Inicio
  2. Pregunta y respuesta
  3. .NET Framework desde el punto de vista de un programador de bajo nivel

.NET Framework desde el punto de vista de un programador de bajo nivel

2010-06-29 15 views
7

Cuando estaba aprendiendo .NET lo vi como una plataforma que ejecuta mis programas .NET que tiene su propio Stack & Heap..NET Framework desde el punto de vista de un programador de bajo nivel

Pero ahora, después de aprender más sobre las cosas, veo una aplicación .NET como cualquier otra aplicación nativa de C/C++. Está en formato de archivo Portable Executable (PE) con el nuevo directorio de datos &. La sección de texto está llena de código MSIL en lugar de código de máquina. La única diferencia es que se cargan pocos archivos DLL (que se consideran como plataforma .NET) (como cualquier otra dependencia de Dll).

Supongo que en el mismo punto de entrada hay un código de máquina que llama al DLL cargado (plataforma .net) y las funciones de esos DLL leen el MSIL de la sección .text (segmento para ser más correcto) y generan máquinas equivalentes codificar y ponerlo en algún tipo de búfer (no sé qué área sería. No puedo ser .text & .data, ya que son de solo lectura. ¿Serán apilables o de montón?). Luego haga que el EIP apunte a este buffer de instrucciones. Las últimas instrucciones vuelven a llamar a las DLL para repetir el proceso para el resto de MSIL.

Como de Managed Heap & Managed Stack que son sólo una parte de los procesos Montón de & pila. es solo que algunas funciones (denominadas GC) mantendrán un registro de las asignaciones de memoria & desasignación de estas porciones de memoria.

Me gusta esta vista realista. No sé hasta qué punto soy cierto. Solo estoy adivinando estas cosas. Por favor corrígeme & cuéntame más sobre esto. ¿Qué tan lejos será similar a esta vista? ¿Dónde puedo obtener más información sobre la plataforma .NET desde este punto de vista?

Fuente

2010-06-29 claws

+1

recomendaría poner Java en una pregunta separada para obtener mejores respuestas. Además, con Java, la respuesta no es la misma en todas las plataformas (excepto en un nivel alto: el código se ejecuta en una VM). ¿Está interesado solo en cómo se hace en Windows? – Yishai

+0

Estoy de acuerdo con @Yishai; Java tiene numerosas diferencias * significativas * de .NET que probablemente enturbien la pregunta. Guárdalo para una pregunta separada. – Randolpho

Respuesta

3

Por salida CLR: CLR via C#.

Es realmente un gran libro, especialmente si está interesado en "bajo nivel" .NET/CLR.

Para la comprobación de JVM: Java Virtual Machine

Fuente

2010-06-29 19:27:22 Incognito

+0

+1 para CLR a través de C#. La sección de Recolección de basuras me pareció particularmente interesante, ya que la CLR GC está haciendo mucho más que simplemente rastrear la asignación. El CLR y el GC cooperan para que su código de ejecución pueda ser realmente secuestrado, hacer que sus referencias apunten a nuevas ubicaciones de memoria y luego comenzar a funcionar nuevamente como si nada hubiera sucedido. –

2

Su descripción no tiene una cosa: la mayoría del código en un ensamblado .NET es just-in-time (JIT) compilado, lo que significa que MSIL no se convierte en código de máquina hasta el momento anterior al método llamado por primera vez, en ese punto se almacena en caché para el futuro. Esto acelera enormemente el tiempo de inicio, a costa de una desaceleración menor la primera vez que se llama a cada método. (Omito detalles como el hecho de que el compilador JIT puede volver a optimizar la función después de haber sido llamada varias veces).

El código compilado JIT vive en el montón, desde la perspectiva del sistema operativo. El compilador JIT marcará el código como ejecutable y hará lo que sea necesario para hacer que funcione correctamente.

Fuente

2010-06-29 19:06:49

2

No es 100% exacto, pero diría que tiene una descripción decente de ciertas partes del marco.

Si desea saber más, le sugiero que eche un vistazo primero al .NET Framework FAQ y cuando termine con eso lea la serie de artículos .NET 1.1 Inside the .NET Framework. Estos artículos no cubrirán muchos de los avances que se han producido en las últimas 4 versiones, pero brindarán una base sólida y sólida de lo que trata .NET Framework.

Fuente

2010-06-29 19:09:19 Randolpho

1

Últimamente he estado leyendo Pro C# 2008 and the .NET 3.5 Platform (ahora también hay una versión VS2010/.NET 4.0), y hace un excelente trabajo explicando cómo funciona el bytecode .NET en el back-end, y cómo puede aprender acerca de lo que realmente se llama usar el reflector, etc. Es denso y largo (y a veces más información de la que yo quería), pero es una buena lectura informativa.

Fuente

2010-06-29 19:10:39 ewall

3

CLR via C# describe algunas cosas internas de .NET, incluido el proceso de carga de PE y el alojamiento de CLR en su propio proceso.

Fuente

2010-06-29 19:12:23 wRAR

+0

¿qué capítulo de este libro explica lo que usted dijo? – claws

+0

1 y 22, para la 3ª edición. – wRAR

4

Olvidaste un punto muy importante: el código CIL (anteriormente MSIL) es un código seguro.No se puede hacer puntero arbitrario con vudú, tipo de hechizo o cosas malas similares (excepto en algunas regiones de código inseguro). Esta es probablemente la diferencia más importante con otros lenguajes como C (++), Pascal, etc. Estas garantías de seguridad se basan profundamente en el lenguaje, el tipo de sistema y el diseño del tiempo de ejecución.

Fuente

2010-06-29 19:14:35

+0

+1 ¡maldita sea! Realmente lo extrañé. – claws

+0

+1, pero agregaría 'no se puede acceder a la matriz fuera de sus límites', lo que previene totalmente los escenarios de desbordamiento de búfer. –

+1

bueno, puedes hacer * algún * vudú. O al menos un hocuspocus. Algunos de los lenguajes lo aclaran, por ejemplo, al hacerte declarar regiones "inseguras". También hay * plenty * de construcciones MSIL no verificables (pero válidas). –

Cuestiones relacionadas

 Cuestiones relacionadas