A menudo repito que .NET Core es de código abierto y funciona "en todas partes". MonoGame, Unity, Apple Watch, Raspberry Pi y microcontroladores, una docena de Linux, Windows, etc. Ya mucho

Pero alguien todavía no es suficiente. Michal Strehowski quiere lanzar C # realmente en todas partes .


C # en Windows 3.11

Ejecutó el código C # en dos sistemas "imposibles" que ahora complementan nuestra definición de "funciona en todas partes". Aunque estos son experimentos divertidos (no los repita en producción), enfatizan tanto las habilidades técnicas de Michal como la flexibilidad de la plataforma base.

Ejecutando C # en Windows 3.11

En siete tweets, Michal habla sobre cómo logró ejecutar el código C # en Windows 3.11. La aplicación es simple, solo hay una llamada a la función MessageBoxA con la visualización del cuadro de diálogo correspondiente, que está en Windows desde los primeros días. Para llamar a la función y obtener el resultado , se utiliza DllImport / PInvoke.

Primero mostré esta aplicación para Windows 3.11 porque es genial. Pero en realidad, el autor comenzó desde el lugar donde terminó su experimento con DOS. Compila el código nativo de C #, y después de eso las reglas ya no existen.

En este ejemplo, se ejecuta en la plataforma Win16, no en Win32. Sin embargo, en 1992 (sí, ¡viví y programé, y lo usé en mis proyectos!) Hubo un cierto puente tecnológico llamado Win32s : un subconjunto de las API de Windows NT que se transfirieron a Windows 3.11. Por lo tanto, teniendo en cuenta algunas restricciones, puede escribir código de 32 bits y acceder a Win32 desde Win16.

Michal se dio cuenta de que los archivos de objetos creados por el compilador CoreRT AOT en 2020 podían ser ensamblados por el vinculador de la muestra de Visual C ++ 2.0 de 1994. El resultado es un código de máquina vinculado con interfaces Win32s que se ejecutan en Windows 3.11 de 16 bits. La magia Respeta a Michalu.


Aplicación simple Hello World C #

Ejecutando C # a 8K bajo DOS

He escrito sobre ejecutables independientes de .NET Core 3.x antes, soy un gran admirador de esto. Mi aplicación ya se ha reducido a 28 megabytes. Esto es bastante, dado que incluye el tiempo de ejecución de .NET y muchos otros recursos. Por supuesto, uno no debe juzgar VM / runtime por el tamaño del programa más pequeño posible, pero Michal quería ver hasta qué límite puede ir, ¡y establecer un objetivo de 8000 bytes!

El programa funciona en modo texto, lo cual, en mi opinión, es genial . También elimina la necesidad de un recolector de basura, ya que no hay asignación de recursos. Esto significa que no puede usar nuevo en ningún lado. No hay tipos de referencia.

Para declarar matrices estáticas, utiliza campos fixed char [] : deben vivir en la pila, y tenemos una pequeña pila.

Por supuesto, cuando intenta hacer algún tipo de .NET independiente ejecutable, inicialmente obtiene un archivo de 65 megabytes, que incluye la aplicación, el tiempo de ejecución y las bibliotecas estándar.

dotnet publish -r win-x64 -c Release

Puede usar ILLinker y PublishedTrimmed para optimizar Tree Trimming desde .NET Core 3.x, pero de esta manera reduce el archivo a solo 25 megabytes.

Intentó usar Mono y mkbundle, elevando el tamaño a 18.2 megabytes, pero luego detectó un error. Y el tiempo de ejecución sigue ahí.

Por lo tanto, el único tiempo de ejecución adecuado era CoreRT, que no incluye una máquina virtual, sino solo funciones auxiliares.

dotnet publish -r win-x64 -c Release /p:Mode=CoreRT

Entonces obtuvo 4,7 megabytes, pero aún es demasiado. Con algunas configuraciones, puede caminar hasta 3 megabytes. Puede extender completamente la reflexión y alcanzar 1.2 megabytes. ¡Ahora cabe en un disquete!

dotnet publish -r win-x64 -c Release /p:Mode=CoreRT-ReflectionFree

Este tamaño de un megabyte parece un límite estricto solo para el SDK de .NET.

Aquí es donde Michal se aleja de las herramientas estándar . ¡Hace un trozo de reimplementación para los tipos básicos de Sistema ! Luego se vuelve a compilar con algunos interruptores mágicos para que solo se publique la versión IL del ejecutable.

csc.exe /debug /O /noconfig /nostdlib /runtimemetadataversion:v4.0.30319 MiniBCL.cs Game\FrameBuffer.cs Game\Random.cs Game\Game.cs Game\Snake.cs Pal\Thread.Windows.cs Pal\Environment.Windows.cs Pal\Console.Windows.cs /out:zerosnake.ilexe /langversion:latest /unsafe

Luego pasa esto a CoreRT para obtener el código nativo.

ilc.exe zerosnake.ilexe -o zerosnake.obj --systemmodule zerosnake --Os -g

Y aqui estamos.

“Ahora tenemos zerosnake.obj, un archivo de objetos estándar, no diferente de los archivos de objetos creados por otros compiladores nativos, como C o C ++. El último paso es armarlo ".

Unos cuantos trucos más, ¡y la salida es de 27 KB! Luego, elimina varios modificadores del enlazador para deshabilitar y eliminar varias cosas usando los mismos métodos que usan los desarrolladores del ensamblador, lo que resulta en 8176 bytes. Thriller épico.

link.exe /debug:full /subsystem:console zerosnake.obj /entry:__managed__Main kernel32.lib ucrt.lib /merge:.modules=.rdata /merge:.pdata=.rdata /incremental:no /DYNAMICBASE:NO /filealign:16 /align:16

Sigue a Michal en Twitter y aplaudenlo.