Как Windows различает обычный EXE и .NET EXE?

Question

В одном из интервью меня спросили, как ОС Windows различает обычный EXE-файл и EXE-файл .NET.

Мой ответ был: когда исполняется сборка .NET, компилятор помещает некоторую информацию в заголовок. Информация PE32 или PE32 +. Windows проверяет заголовок, чтобы определить, нужно ли загружать MSCOREE.dll, который загружает CLR и выполняет EXE.

Правильный ли мой ответ?

Answer 1

Я думаю, что следующие две ссылки - хороший ресурс, чтобы понять структуру файлов PE и загрузчик Windows.

• Углубленный взгляд на формат исполняемых файлов Win32 (MSDN Mag Feb 2002)
• Углубленный анализ формата исполняемых файлов Win32, часть 2 (MSDN Mag Mar 2002)

Точная цитата из статьи за март 2002 года, которая, как мне кажется, отвечает на ваш вопрос:

Основная цель .NET исполняемый файл, чтобы получить .NET-специфичный информация, такая как метаданные и средний язык (IL) в объем памяти. Кроме того, .NET исполняемые ссылки на Mscoree.dll . Эта DLL является отправная точка для .NET-процесса. Когда загружается исполняемый файл .NET, его точкой входа обычно является крошечная заглушка код. Этот пень просто прыгает к экспортированная функция в MSCOREE.DLL (_CorExeMain или _CorDllMain) . От там, MSCOREE берет на себя ответственность, и начинает использовать метаданные и IL из исполняемый файл. Эта настройка похоже на то, как приложения в Visual Основной (до .NET) используется MSVBVM60.DLL.

Answer 2

Хотя я согласен с GregC в целом, бывают случаи, когда этот тип информации полезен.Но это один сложный вопрос, на который нужно ответить в интервью (если только он не предназначен для команды CLR:)

Веб-страницы и блоги ...

• Портативный исполняемый файл (википедия)

Книги ...

• Expert .NET 2.0 IL Assembler (я думал, что это отличная книга)

Answer 3

Короче говоря, это было какое-то время, поэтому некоторые из них могут быть немного устаревшими ...

Для XP и более поздних версий загрузчик ОС расширен для обнаружения управляемых сборок на основе записи каталога PE, если запись в каталоге присутствует, загрузчик автоматически загружает файл mscoree.dll и выполняется переход к функции в mscoree, _CorExeMain (2) для исполняемых файлов и _CorDllMain для DLL. _CorExeMain затем отвечает за загрузку CLR и запуск выполнения управляемого кода.

Я использовал следующее, чтобы напомнить себе имена точек входа ...

C:\Windows\System32>dumpbin -exports mscoree.dll
Microsoft (R) COFF/PE Dumper Version 9.00.30729.01
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file mscoree.dll

File Type: DLL

  Section contains the following exports for mscoree.dll

    00000000 characteristics
    4AF3AF84 time date stamp Fri Nov 06 07:09:24 2009
        0.00 version
          17 ordinal base
         126 number of functions
         123 number of names

    ordinal hint RVA      name

         38    0 0001AAA0 CLRCreateInstance
... Lots of stuff left out...
        136   76 00015030 _CorDllMain
        138   77 00004DDB _CorExeMain
        137   78 0001A981 _CorExeMain2
        139   79 0002033B _CorImageUnloading
        140   7A 000042D0 _CorValidateImage
         24      00008017 [NONAME]
        142      00014C4D [NONAME]

  Summary

        4000 .data
        4000 .reloc
        1000 .rsrc
       40000 .text

Answer 4

Сложный вопрос. Вы получили работу? ; -)

Я знаю, что это было давно, но для тех, кто ищет ответ: Ответ можно найти в MSDN здесь: https://docs.microsoft.com/en-us/dotnet/framework/unmanaged-api/hosting/corvalidateimage-function

В Windows XP и более поздних версиях загрузчик операционной системы проверяет наличие управляемых модулей путем проверки бита каталога дескрипторов COM в заголовке формата общего объектного файла (COFF). Установленный бит указывает на управляемый модуль. Если загрузчик обнаруживает управляемый модуль, он загружает MsCorEE.dll и вызывает _CorValidateImage ...

Вы можете проверить это самостоятельно с помощью dumpbin /clrheader (который будет пустым для собственного модуля).

Если вы думаете об этом (по крайней мере, в .NET4 +), это должно быть сделано загрузчиком до запуска процесса (то есть вы не могли ждать, пока модуль вызовет процедуры инициализации CLR), поскольку AnyCPU означает, что загрузчик динамически определяет битность процесса, которая, очевидно, должна быть известна до начала процесса.