c# - para - compilar y ejecutar c en windows
¿Por qué razón elegiría una configuración de alineación de archivos del compilador de C#distinta de 512? (1)
Puedo ver en MSDN cómo cambiar la alineación de archivos para la compilación de C # (a través de la configuración del proyecto y la línea de comandos).
He buscado en Google y he visto artículos que explican que una alineación de archivos de 512 Bytes reduce el tamaño del .dll. Me he probado con diferentes alineamientos de archivos y he visto que, sí, lo hace.
Mi pregunta es:
¿Por qué querría usar una alineación de archivo diferente? Debe haber escenarios donde esto es requerido o no existiría la opción?
Además, ¿qué hace exactamente? Las páginas de MSDN hablan de secciones? ¿Qué son secciones?
http://msdn.microsoft.com/en-us/library/0s4tzdf2.aspx
ACTUALIZAR
En mis propias investigaciones, tengo Google "alineación de archivos C #", "alineación de archivos de ensamblaje .net", etc., y finalmente encontré:
https://msdn.microsoft.com/en-us/magazine/bb985992.aspx
Es a partir de 2002, así que no sé cuánto ayudará. Si alguien me puede decir lo que debería estar buscando en Google ......
Es un detalle de implementación bastante técnico. Para comenzar, primero debe comprender la estructura de un archivo PE32, el formato de archivo para DLL y EXEs en Windows. El artículo canónico para eso es "Peering Inside the PE, Un recorrido por el formato de archivo ejecutable portátil Win32 de Matt Pietrik". Escrito hace 17 años pero aún relevante y disponible .
La configuración / filealign hace referencia al valor del campo IMAGE_OPTIONAL_HEADER.FileAlignment. Determina cómo se alinean los datos sin formato en una sección. Una sección es un fragmento de código o datos en el archivo. Casi exclusivamente datos en el caso de ensamblados .NET puros.
Existe una relación muy estrecha entre el formato de archivo y el disco. Una imagen ejecutable se utiliza como el archivo de respaldo de un archivo mapeado de memoria en Windows. Los ejecutables se cargan mapeando el archivo en el espacio de direcciones de la memoria virtual. Muy eficiente, cargar una DLL solo implica crear esa asignación, no se leen datos reales del archivo. Eso sucede de una manera perezosa cuando el proceso intenta leer un byte de una sección. Si aún no está cargado en la memoria, produce un error de página y el sistema operativo lee 4096 bytes del archivo en la memoria. La gran ventaja es que no paga por datos o códigos que no usa. También la razón por la que leer [atributos] es costoso cuando lo lees la primera vez.
La relevancia de la alineación de archivos es cómo se alinean los datos brutos en las secciones. La mayoría de los ejecutables modernos que contienen código de máquina usan una alineación de 4096 bytes, el tamaño de una página de memoria virtual. Eso no es muy relevante para los ensamblados que contienen código administrado, IL es solo información. Lo cual tendría sentido usar una alineación más pequeña, una que desperdicia menos espacio. 512 bytes (no kilobytes) es un número feliz allí, es el valor más pequeño permitido en el formato PE32.
La única razón posible que se me ocurre para agregar la opción a la IU es que el compilador de C # tiene muy pocas opciones de compilación en comparación con otros compiladores. "Otro" son compiladores que generan código nativo. Entonces la opción está ahí porque el compilador tiene la opción. Muchos de los ajustes están cubiertos por [atributos], lo que hace que la línea de comandos del compilador sea breve y ágil. Pero no hay ningún atributo para la alineación de archivos, debe conocerse antes de generar el archivo, un atributo sería demasiado tarde.
El ejemplo opuesto es el compilador y el enlazador C ++, el IDE ofrece diecinueve páginas de propiedades para configurarlos. Pero aún no los cubro a todos, los realmente oscuros deben establecerse en la página de opciones de "Línea de comando".