🚀 go-pugleaf

>> No zaraz... Przecież każdy exek (mówimy o DOS/Windows i wykluczamy
>> pliki .com) zaczyna się od MZ, czy 16 czy 32-bitowy... Dopiero
>> później jest inna sygnatura - "NE" (New Executable) dla 16-bitowych
>> exeków rodem z Win3.xx, "LE" (Linear Executable) - chyba z OS/2,

Między innymi, format LE mają też programy DOS-owe stworzone kompilatorem 
Watcom.

>> ale głowy nie dam, i "PE" (Portable Executable) dla exeków 32-bitowych
>> (i pewnie 64-bitowych też).

też. Co nie znaczy, że uruchomienie 64-bitowego PE w 32-bitowym systemie się 
powiedzie :-)
komunikat brzmi: "c:\foo\bar64.exe is not a valid Win32 application."


> Całkiem możliwe, bo zawierają zaślepkę w celu napisania na ekranie
> "This program cannot be run in DOS mode" (czy jakoś tak), gdy się je
> uruchomi z DOSa. Nie zagłębiałem się w szczegóły budowy binarek aż tak
> bardzo. Poza tym, w tej chwili nie umiem znaleźć pliku windowsowego
> (poza DLL), który zaczynałby się od "PE". Pewnie masz rację.

To "this program itp..." jest właśnie zwykłym, 16-bitowym DOS-owym programem 
(tak zwanym stubem), który jest umieszczany na początku każdego programu 
windowsowego. Za nim następuje nagłówek PE i właściwy program Windowsowy. 
Gdy uruchomimy exeka pod DOS-em, włączy się program "this itd..", gdy pod 
windą - właściwy program.

32-bitowe programy pod DOS-a wykorzystują podobną sztuczkę - nagłówek MZ z 
DOS-extenderem, który uruchomiony załaduje właściwy, 32-bitowy kod, 
znajdujący się dalej.

To wszystko się zgadza, jeśli program ma strukturę standardową.

W rzeczywistości można napisać program niby-16-bitowy, uruchamiany pod 
dosem, a który sam sobie uruchomi tryb powiedzmy 64-bitowy, przestanie 
odwoływać się do DOS-u i BIOS-u i będzie działać jak samodzielny system 
operacyjny. Na czymś takim każdy debugger się wysypie :-)

-- 
Azarien