В ядре NT с самого начала была возможность честного форка процесса — с клонированием таблиц страниц и copy-on-write. Она недокументирована и до неё нельзя достучаться через Win32 API, но для отдельной подсистемы это не проблема. Cygwin/MinGW работают через Win32 API, поэтому у них, да, проблемы.
Перед передачей LZMA-распаковщику нужно дописать впереди нулевой байт (LZMA-поток всегда начинается с нулевого байта) и, возможно, bswap-нуть первый dword (а может быть, и нет, не помню точно). Кроме того, в зависимости от флагов после LZMA-потока могут быть данные для постпроцессинга (instruction-relative offset <-> absolute address; постпроцессинг для распаковщика, препроцессинг для упаковщика) E8/E9 и 0F 8x.
i386 как платформы, туда же относится и 486-й, я так понимаю, что нужны пентиумные инструкции минимум теперь для 32-битного ядра
Неправильно понимаете. Убрали именно поддержку 386, потому что для SMP очень полезны инструкции xadd и cmpxchg, которые появились в 486. А 486-е всё ещё поддерживаются.
На XP и семёрке, казалось бы, никаких проблем: yadi.sk/d/4yHs4lWioPtmW
В восьмёрке добавили несколько странную проверку, что EntryPoint должна быть либо 0, либо не меньше SizeOfHeaders, причём 0 для exe-шника — валидное значение (MZ = dec ebp, pop edx), так что можно так: yadi.sk/d/jY0Tn_lSoPvGc
Но вообще формула выше — таки только для ветки с SectionAlignment >= PAGE_SIZE, на ветке с SectionAlignment < PAGE_SIZE весь файл просто маппится одним куском, так что можно просто сделать ImageSize побольше и даже не менять SizeOfHeaders: yadi.sk/d/c_Oc3oyooPwS8
Естественно. LdrpInitializeProcess возвращает 0xC000007B, а уже верхний уровень бросает исключение.
Тупой способ выяснить, откуда оно — после останова на LdrInitializeThunk выполнить команду r;t;z(eax!=c000007b)
подождать, посмотреть, где остановилось, и посмотреть команды перед этим — чтобы понять, почему управление дошло до этой ветки кода.
Более интеллектуальный — настроить символы .sympath SRV*c:\symcache*http://msdl.microsoft.com/download/symbols .reload
(папку c:\symcache потом можно почистить), поставить bp ntdll!LdrpSnapIAT, дождаться второго срабатывания (первый вызов — для kernel32 -> ntdll) и запустить команду выше уже с этого момента.
У WinDbg в настройках можно включить Debug -> Event filters -> Create process -> enabled, перезагрузить процесс, сделать bu ntdll!LdrInitializeThunk, g, и отлаживать совсем с начала.
Но у меня появилась мысль, что может быть не так.
часть таблицы импорта (последние 0x16 её байт нулевые, и в файле не хранятся)
Если честно добить файл нулями, проблема будет воспроизводиться?
У меня на виртуалке запускается совершенно стабильно. Ошибка явно от юзермодного загрузчика, ему на файловый кэш должно быть ну совсем пофиг.
WinDbg на машине есть?
если хотя бы одна секция объявлена, то FileAlignment должен быть не меньше 0x200, а SectionAlignment должен быть 0x1000
Строго говоря, можно. Например, если размеры всех секций кратны 0x1000, то проблем не будет и при SectionAlignment, меньшем размера страницы. (Вообще-то, соответствующий код в подсистеме WOW64 писался не под энтузиастов минимизации вроде нас с вами, а ровно под такую ситуацию. Конкретно — эмуляция x86 на Itanium, где винда использует размер страницы 0x2000.) Но не очень полезно — если честно записывать все дополняющие нули в файл, то о минимизации размера можно забыть, а если не писать, то винда от такой наглости может даже в BSOD выпасть. (ЕМНИП починили где-то между XP SP1 и SP2. Это к вопросу о винтажности. Хотя, конечно, истинно винтажная система — Windows 95.)
Минуточку. На XP SP3 оно вполне работает. (DataDirectory[IMAGE_DIRECTORY_ENTRY_DEBUG].Size у вас хоть и не 0, но 3, но пока оно меньше 0x1C, это нормально.) При отсутствии IMAGE_DIRECTORY_ENTRY_IAT = 0xC в XP есть засада, что таблица импорта должна быть в какой-нибудь секции, не в заголовке, но это проблема, только если делать программу целиком в заголовке без секций.
Существующие примеры программ размером 268 байт не содержат ни одной секции, и фактически, целиком помещаются внутри заголовка PE, для загрузки которого Windows выделяет одну страницу памяти (4КБ).
Для загрузки заголовка выделяется ALIGN_UP(SizeOfHeaders, max(SectionAlignment, PAGE_SIZE)). Так что можно поставить SizeOfHeaders больше страницы и без секций обойтись.
На WinXP моя программа, к сожалению, не работает: та отказывается загружать программы, у которых в каталоге менее 0xD записей.
Там просто часть кода поддержки совместимости смотрит на Directories[DEBUG].Size, не проверяя, что DEBUG действительно есть. Если выставить соответствующий dword в нуль, всё будет работать.
Забавно. Если файл есть в кэше данных — может быть короче 252 байт. Если нет (тот же самый файл на сетевом диске без дополнительных условий, или тот же самый файл на свежевставленной флешке либо после перезагрузки системы при прямой загрузке в WinDbg) — будет ntvdm.
В семёрке шизофрению пофиксили, там не грузится консистентно.
++a!В Lua, кстати, унарного плюса нет.
https://www.wolframalpha.com/input/?i=acos%28-2%29
В восьмёрке добавили несколько странную проверку, что EntryPoint должна быть либо 0, либо не меньше SizeOfHeaders, причём 0 для exe-шника — валидное значение (MZ = dec ebp, pop edx), так что можно так: yadi.sk/d/jY0Tn_lSoPvGc
Но вообще формула выше — таки только для ветки с SectionAlignment >= PAGE_SIZE, на ветке с SectionAlignment < PAGE_SIZE весь файл просто маппится одним куском, так что можно просто сделать ImageSize побольше и даже не менять SizeOfHeaders: yadi.sk/d/c_Oc3oyooPwS8
Тупой способ выяснить, откуда оно — после останова на LdrInitializeThunk выполнить команду
r;t;z(eax!=c000007b)подождать, посмотреть, где остановилось, и посмотреть команды перед этим — чтобы понять, почему управление дошло до этой ветки кода.
Более интеллектуальный — настроить символы
.sympath SRV*c:\symcache*http://msdl.microsoft.com/download/symbols.reload(папку c:\symcache потом можно почистить), поставить
bp ntdll!LdrpSnapIAT, дождаться второго срабатывания (первый вызов — для kernel32 -> ntdll) и запустить команду выше уже с этого момента.Но у меня появилась мысль, что может быть не так.
Если честно добить файл нулями, проблема будет воспроизводиться?
WinDbg на машине есть?
Строго говоря, можно. Например, если размеры всех секций кратны 0x1000, то проблем не будет и при SectionAlignment, меньшем размера страницы. (Вообще-то, соответствующий код в подсистеме WOW64 писался не под энтузиастов минимизации вроде нас с вами, а ровно под такую ситуацию. Конкретно — эмуляция x86 на Itanium, где винда использует размер страницы 0x2000.) Но не очень полезно — если честно записывать все дополняющие нули в файл, то о минимизации размера можно забыть, а если не писать, то винда от такой наглости может даже в BSOD выпасть. (ЕМНИП починили где-то между XP SP1 и SP2. Это к вопросу о винтажности. Хотя, конечно, истинно винтажная система — Windows 95.)
Для загрузки заголовка выделяется
ALIGN_UP(SizeOfHeaders, max(SectionAlignment, PAGE_SIZE)). Так что можно поставить SizeOfHeaders больше страницы и без секций обойтись.Там просто часть кода поддержки совместимости смотрит на Directories[DEBUG].Size, не проверяя, что DEBUG действительно есть. Если выставить соответствующий dword в нуль, всё будет работать.
В семёрке шизофрению пофиксили, там не грузится консистентно.
У меня на руках виртуалка с ntoskrnl.exe версии 5.1.2600.5512, в ней подобное не проходит.