Как работает 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 процесс создан.

Я писал об этом с некоторыми деталями.

 07 янв. 2018 г., 03:18
Большое спасибо!!! Я запутался в расчете некоторых смещений полей этой структуры, используя устаревшую информацию в Windows NT / 2000 Native API Reference.
Решение Вопроса

Это не очень хорошо задокументировано в любом месте, о котором я знаю, я могу лишь указать вам на соответствующую статью 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.

 15 янв. 2015 г., 21:37
Попробовал, не нашел ответа. Вероятно, эта магия вообще не сработает, если в ОС не установлено .NET. Что делает это бесполезным для нативных исполняемых файлов.
 Nullptr Dev01 мая 2012 г., 07:35
Спасибо за быстрый ответ. Это хорошая отправная точка. Я хотел узнать, как clr работает с разделами .reloc. Я копался в sscli, в основном в pedecoder.h / pewriter.cpp и нашел мои ответы. Тем не менее, есть много вопросов (например, как насчет Windows 2000 x64), но я думаю, что я найду ответы в sscli.
 01 мая 2012 г., 12:02
Это легко, Windows 2000 x64 в последний раз использовалась великим белым Yeti.
 04 июл. 2012 г., 05:48
Вот это да. Интересно, есть ли способ воспользоваться этой «особой осведомленностью»? создать надлежащие толстые (нативный код) двоичные файлы для Windows.

Ваш ответ на вопрос