Как работает CorFlags.exe / 32BIT +?
Я думаю, мой вопрос оCLR Loader. Я хочу понять механику позадиCorFlags.exe /32BIT+ функциональность.
Мы знаем, что когда начинается сборка, скомпилированная сAny CPU Флаг установлен на 64-битной Windows, он запускается как 64-битный процесс. Если один прогонCorFlags /32BIT+ на этой сборке он запустится как 32-битный процесс. Я думаю, что это захватывающая особенность.
У меня так много вопросов по этому поводу:
How is it implemented? Does the OS Loader get involved? Is possible to build a custom application (I guess an unmanaged one) that loads 32-bit or 64-bit CLR at a wish?Есть ли статья, книга, блог и т. Д., Которые объясняют внутреннюю работу этой функции?
Ответы на вопрос(2)
Добавить на Ганса & apos; ответ, есть также некоторый код режима ядра Windows, который отвечает на этот флаг. Каждый загруженный исполняемый файл имеет структуру ядра,SECTION_IMAGE_INFORMATION, связанный с этим. Вот его символьная информация:
0: kd> dt nt!_SECTION_IMAGE_INFORMATION
+0x000 TransferAddress : Ptr64 Void
+0x008 ZeroBits : Uint4B
+0x010 MaximumStackSize : Uint8B
+0x018 CommittedStackSize : Uint8B
+0x020 SubSystemType : Uint4B
+0x024 SubSystemMinorVersion : Uint2B
+0x026 SubSystemMajorVersion : Uint2B
+0x024 SubSystemVersion : Uint4B
+0x028 GpValue : Uint4B
+0x02c ImageCharacteristics : Uint2B
+0x02e DllCharacteristics : Uint2B
+0x030 Machine : Uint2B
+0x032 ImageContainsCode : UChar
+0x033 ImageFlags : UChar
+0x033 ComPlusNativeReady : Pos 0, 1 Bit
+0x033 ComPlusILOnly : Pos 1, 1 Bit
+0x033 ImageDynamicallyRelocated : Pos 2, 1 Bit
+0x033 ImageMappedFlat : Pos 3, 1 Bit
+0x033 BaseBelow4gb : Pos 4, 1 Bit
+0x033 Reserved : Pos 5, 3 Bits
ФлагиComPlusILOnly а такжеComPlusNativeReady связаны с .NET,ComPlusILOnly просто говорит, если сборкаCIL только (не смешанный или нативный - в этом случае сборка уже зависит от архитектуры), иComPlusNativeReady равен 1, только если / 32BIT + не установлен (32BITREQ или 32BITPREF в более новой версии CorFlags). Эти флаги проверяются во времяnt!PspAllocateProcess и на их основе32-bit или же64-bit процесс создан.
Я писал об этом с некоторыми деталями.
Это не очень хорошо задокументировано в любом месте, о котором я знаю, я могу лишь указать вам на соответствующую статью MSDN. Да, ваше предположение верно, загрузчик в Windows XP и выше осведомлен об управляемых исполняемых файлах. Он автоматически загружает подкладку загрузчика .NET (c: \ windows \ system32 \ mscoree.dll), соответствующая точка входа_CorValidateImage (), Раздел «Примечания» в связанной статье MSDN описывает механизм, который превращает 32-разрядный файл .exe в 64-разрядный процесс:
In Windows XP and later versions, the operating system loader checks for managed modules by examining the COM Descriptor Directory bit in the common object file format (COFF) header. A set bit indicates a managed module. If the loader detects a managed module, it loads MsCorEE.dll and calls _CorValidateImage, which performs the following actions:
- Confirms that the image is a valid managed module.
- Changes the entry point in the image to an entry point in the common language runtime (CLR).
- For 64-bit versions of Windows, modifies the image that is in memory by transforming it from PE32 to PE32+ format.
- Returns to the loader when the managed module images are loaded.
For executable images, the operating system loader then calls the _CorExeMain function, regardless of the entry point specified in the executable. For DLL assembly images, the loader calls the _CorDllMain function.
_CorExeMain or _CorDllMain performs the following actions:
- Initializes the CLR.
- Locates the managed entry point from the assembly's CLR header.
- Begins execution.
The loader calls the _CorImageUnloading function when managed module images are unloaded. However, this function does not perform any action; it just returns.