En otras palabras, ¿el framework .NET eventualmente hace llamadas en alguna parte para hacer su trabajo? ¿O Microsoft recreó completamente toda la funcionalidad de la biblioteca win32 en su .NET Framework.¿El tiempo de ejecución de .NET se correlaciona internamente con las llamadas a la función win32?
Gracias!
Es una mezcla. Obviamente, cosas como winforms son en gran parte envoltorios alrededor de la funcionalidad Win32 (o una combinación de ambos mundos), pero WPF es mucho más administrado (en términos del código de control real; bajo el capó, como notas de Mash, puede usar DirectX para el representación). Del mismo modo, elementos como el acceso a archivos/redes son (por necesidad) envoltorios alrededor de los objetos del SO, al igual que los objetos de bloqueo no administrados como Mutex, pero muchas otras cosas se administran al 100%.
Así que no es una respuesta simple.
(corregir) Además, tenga en cuenta que ".NET" es un término muy vago; Compact Framework, Micro Framework, Silverlight, etc. pueden tener diferentes implementaciones no win32.
En algunos casos (¿la mayoría, tal vez? No he reflejado todo el marco) el .NET framework hace llamadas a win32. La mayoría de los controles son simplemente controles win32 envueltos con algunas características nuevas.
Una aplicación .NET es solo otro proceso de Win32, por lo que no hay magia y obviamente va a utilizar el sistema operativo de subrayado. Incluso las bibliotecas .NET usan Win32 en gran medida.
Ejemplos:
gestión de memoria es manejada internamente para código administrado, pero para el proceso en sí es manejado simplemente como cualquier otro proceso Win32.
Actualmente, los hilos gestionados son implementados como hilos del sistema operativo.
Sí, llama a las funciones de win32 internamente. Por ejemplo, el método OpenRead en la clase de archivos contiene:
return new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read);
y con el tiempo se llame:
SafeFileHandle handle = CreateFile(lpFileName, dwDesiredAccess, dwShareMode, securityAttrs, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile);
que es una función nativa de Win32, en el fondo en el método.
Llama a .NET API como lo hacen todas las aplicaciones de Windows. Pero es más que un simple contenedor o mapa, se describe con más precisión como una abstracción.
Actualización: me di cuenta de que respondí la pregunta incorrecta (dijiste el tiempo de ejecución no la biblioteca de clases) ... ¡bueno, de todas maneras mantendré el guff abajo!
Depende de la parte de la biblioteca:
Eso es sólo de tocar el violín con reflector. Obviamente, al ser un servidor COM, Microsoft CLR también depende en gran medida de win32.
¡Genial! ¡Gracias! – abatishchev
Mono es una implementación del tiempo de ejecución de .NET, y ciertamente no se asigna a las llamadas de función Win32 (al menos en Linux)
supongo que su pregunta se refería a la implementación de Microsoft del tiempo de ejecución de .NET.
Es discutible si WPF es mucho más administrado, mientras que internamente depende en gran medida de DirectX ... – Mash
@Mash - Buen punto –
Así porque .NET depende en gran medida de que win32 haga su trabajo, nunca podría "reemplazarlo" como el WINAPI primario, ¿verdad? ¿O ese es el objetivo final? – tyler