Здравствуйте, AlexGin, Вы писали:
ARK>>Это пофиг. Тяжелые приложения не нужны (совсем). AG>Прощайте: AG>вижуалка, оффис, современные многопользовательские игры, и многое, многое другое
Большое спасибо.
AG>Тот самый, который загружает .NET в ту систему, где дотнет не тесно интегрирован. AG>Там утверждается, что эта тесная интеграция начиная с XP: AG>
AG>In Windows XP and above, the OS loader knows natively what to do with .NET executable assemblies, and fires up an instance of the CLR.
AG>У меня нет более авторитетного источника, сам что-то сомневаюсь, моя память подсказывает, что в XP x86 таки ещё не было нативной поддержки .NET в загрузчике.
Но тут возникает такой вопрос, а нужен ли дотнет при старте системы? Ну да, "OS loader knows natively what to do with .NET executable assemblies", но это вроде как не означает, что без дотнета система работать не будет.
Впрочем, направление дальнейших изысканий ясно.
UPD. Пардон, неверно понял предложение про загрузчик (думал, речь идет о загрузке системы, а речь о загрузчике приложений). Впрочем, это ничего не меняет.
Здравствуйте, Михаил Романов, Вы писали:
МР>С другой стороны, если почитать, например Hosting Overview, то вроде как по шагам описывается, как инициализируется хост для .Net приложений, но не понятно, должен ли это делать stub в самом приложении (как это было исходно), или аналогичные действия может проделать сам загрузчик. МР>В любом случае, у .Net исполнимого файла должна быть ссылка на MSCorEE.dll из которой экспортируется CLRCreateInstance (для .Net 4) МР>И теоретически, можно найти все зависимые от .Net приложения, поискав, кто ссылаетсян на эту библиотеку, и импортирует данную функцию. МР>Только искать нужно именно по зависимостям, а не по тексту, а как это сделать быстро, я не очень представляю, если честно.
Ну, самый интересный вопрос — будет ли сама система работать и грузить unmanaged код (а не .NET приложения, которые не нужны ).
Здравствуйте, AlexRK, Вы писали:
ARK>UPD. Пардон, неверно понял предложение про загрузчик (думал, речь идет о загрузке системы, а речь о загрузчике приложений). Впрочем, это ничего не меняет.
Да, PE Loader, где PE это Portable Execuable, нативные и дотнетовские, 32 и 64 битные, EXEшники и DLLки. EXEшники прежде всего.
Загрузчик для нативных EXEшников была, есть, и будет в NTDLL.
С учётом того, что система сама знает что делать с .NET EXEшником, можно предположить такие варианты:
Ядро не знает про .Net, но NTDLL знает, и он уже грузит MSCorEE.dll. Самый логичный вариант. NTDLL не знает про .Net, но ядро знает, так что ядро сразу запускает не загрузчик из NTDLL, а что-то иное. Дурацкий вариант, если честно. NTDLL то всё равно нужна, и её загрузочный код должен отработать.
И ядро, и NTDLL знают про .Net. Громоздкий, но реалистичный вариант.
Все варианты, в общем, сводятся к тому, что "совсем вычистить" будет сложно.
Upd: ниже по ветке сообщение от okman, где подтверждается, что загрузчик в XP знает о .Net и есть в NTDLL специфичные для .Net функции.
Здравствуйте, AlexRK, Вы писали:
ARK>Ну, самый интересный вопрос — будет ли сама система работать и грузить unmanaged код (а не .NET приложения, которые не нужны
Достоверно ответить не смогу.
Подозреваю, что да — будет.
Но единственный приходящий на ум способ хотябы примено понять, чем это обернется — тот что я привел выше, т.е. вручную вычислить зависимости.
Здравствуйте, Alexander G, Вы писали:
AG>... AG>У меня нет более авторитетного источника, сам что-то сомневаюсь, моя память подсказывает, что в XP x86 таки ещё не было нативной поддержки .NET в загрузчике.
Поддержка была.
В Windows XP загрузчик во время выполнения функций ntdll!_LdrpInitialize и ntdll!LdrpInitializeProcess
определяет .NET-приложение по наличию директории "CLR header" (индекс 0xE), после чего вызываются функции
ntdll!LdrpCorValidateImage (видимо, какие-то проверки) и ntdll!LdrpCorReplaceStartContext (подмена стартового
адреса в стеке на CorExeMain).
Это все было проверено на самой обычной WinXP-SP2-x86 без установленных .NET Framework, версия ntdll — 5.1.2600.2180.
Здравствуйте, Михаил Романов, Вы писали:
МР>В любом случае, у .Net исполнимого файла должна быть ссылка на MSCorEE.dll из которой экспортируется CLRCreateInstance (для .Net 4)
Мои опыты показали, что 32 битное C# консольное приложение импортирует только _CorExeMain, а 64 битное консольное C# приложение вообще ничего не импортирует.
Впрочем, по структуре файла .Net не очень сложно определить — ImageDirectoryEntryToData с параметром IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR должна что-то хорошее возвращать для .Net
(Да, нет никакого COM Decriptor в Image Directory, но зато есть .Net Metadata вместо него).
Здравствуйте, okman, Вы писали:
O>Поддержка была.
O>В Windows XP загрузчик во время выполнения функций ntdll!_LdrpInitialize и ntdll!LdrpInitializeProcess O>определяет .NET-приложение по наличию директории "CLR header" (индекс 0xE), после чего вызываются функции O>ntdll!LdrpCorValidateImage (видимо, какие-то проверки) и ntdll!LdrpCorReplaceStartContext (подмена стартового O>адреса в стеке на CorExeMain).
O>Это все было проверено на самой обычной WinXP-SP2-x86 без установленных .NET Framework, версия ntdll — 5.1.2600.2180.
Возможно, потому что SP2, мне кажется, в "чистой" её нет.
(Вообще разные SP иногда сильно меняли подобные внутренности системы)
Здравствуйте, Alexander G, Вы писали:
AG>... AG>Возможно, потому что SP2, мне кажется, в "чистой" её нет.
Скорее всего, так и есть. WinXP зарелизили в 2001-ом году, а первая версия .NET вышла в 2002-ом.
По логике вещей, поддержку .NET в ntdll добавили в SP1 для Windows XP, т.к. он тоже вышел в 2002-ом.
Но проверить, увы, не на чем, т.к. WinXP без SP еще попробуй найди
Здравствуйте, AlexRK, Вы писали:
ARK>Ну, самый интересный вопрос — будет ли сама система работать и грузить unmanaged код (а не .NET приложения, которые не нужны ).
А, если цель уже в том, чтобы сломать все .NET приложения, а не совсем вычистить весь .NET, то, по идее, поддержка .NET в загрузчике мешать не будет.
Все зависимости в NTDLL.DLL на MSCorEE.dll динамические, иначе почему в нативных приложениях MSCorEE.dll нет.
Здравствуйте, Alexander G, Вы писали:
ARK>>Ну, самый интересный вопрос — будет ли сама система работать и грузить unmanaged код (а не .NET приложения, которые не нужны ).
AG>А, если цель уже в том, чтобы сломать все .NET приложения, а не совсем вычистить весь .NET, то, по идее, поддержка .NET в загрузчике мешать не будет. AG>Все зависимости в NTDLL.DLL на MSCorEE.dll динамические, иначе почему в нативных приложениях MSCorEE.dll нет.
Ну, не совсем так, цель — вычистить дотнет в той степени, в какой это возможно.
И, кстати, я нашел вроде как рабочий способ — утилита NTLite. Позволяет выкорчевать и дотнет, и трезубец, и кучу другого мусора.
Здравствуйте, flаt, Вы писали:
ARK>>И, кстати, я нашел вроде как рабочий способ — утилита NTLite. Позволяет выкорчевать и дотнет, и трезубец, и кучу другого мусора.
F>Что такое трезубец?
Здравствуйте, AlexRK, Вы писали:
ARK>И, кстати, я нашел вроде как рабочий способ — утилита NTLite. Позволяет выкорчевать и дотнет, и трезубец, и кучу другого мусора.
Здравствуйте, Ночной Смотрящий, Вы писали:
ARK>>И, кстати, я нашел вроде как рабочий способ — утилита NTLite. Позволяет выкорчевать и дотнет, и трезубец, и кучу другого мусора.
НС>Может уже тогда сразу Nano Server, не?
Честно говоря, не слышал вообще о таком. Интересно посмотреть.
Upd. А, оно без графического интерфейса — не подходит.
Кстати, на форуме NTLite народ ужал размер установленной Win 7 до одного гигабайта, с сохранением графического интерфейса и работы с сетью. Как раз то, что надо.
