活動Windows可執行文件的最小內存空間

我認爲最小的程序是無限循環的程序。在fasm中，它看起來像這樣：活動Windows可執行文件的最小內存空間

format PE console 
entry start 

section '.text' code readable executable 
start: 
    JMP start

編譯並從命令提示符運行時，taskmanger報告它需要108kb的物理內存。當從資源管理器運行它報告116kb。我在nasm上嘗試了一個類似的程序，並嘗試了不同的鏈接器選項，但108kb始終是最小的內存佔用量。

這是一個活動進程可以擁有的絕對最小內存空間嗎？可以變小嗎？

來源

2017-03-01 ChrisD

您正在使用哪個鏈接器？並使用鏈接器選項？ – Anders

這與Windows版本非常相關。在你的進程中加載了'ntdll.dll'和'kernel32.dll'（+'kernelbase.dll'從win7開始）。初始化不同的內存結構..這個〜100kb不是你的小exe，而是系統dll，PEB，TEB，堆棧等在什麼是實際問題？ – RbMm

@Anders for fasm，我只是直接用fasm來編寫它。在nasm中，我使用GoLink以及Microsoft的鏈接器。我玩堆/棧大小，但不能減少最小值。 – ChrisD

不確定爲什麼這是一個有用的練習，任何真正有用的應用程序都會加載至少兩個Windows .DLL，這可能會增加內存使用量。

108kb並沒有告訴我們什麼時候你沒有說你用哪種應用程序進行了測量。

內存佔用還取決於Windows版本。在Windows 7和更高版本中，有3個核心.DLL; ntdll，kernelbase和kernel32，而以前的版本只有ntdll和kernel32。如果您在64位Windows上運行32位應用程序，則還會在您的進程中加載wow64，wow64cpu和wow64win。在除Windows 2000之外的每個版本中，加載器都會自動加載kernel32及其依賴關係。每個.DLL都有一些不可避免的開銷。存儲在PEB中的已加載的.DLL的鏈接列表和加載器可能會修改每個.DLL中的導入表（unless這是一個新的從未更新過的Windows安裝），即使所有其他頁面都可以與其他進程共享。

從理論上講，你真的可以控制在一個「什麼都不做」 .EXE的唯一的事情就是optional header的SizeOfStackCommit和SizeOfHeapCommit成員，但堆疊系統的默認通常只有一個頁面，這些值四捨五入所以設置他們降低不會給你帶來什麼。您無法控制PEB和TEB（s）的大小，我不認爲您可以避免創建默認進程堆。

大多數人傾向於關注smaller file size，而不是內存佔用。您可以創建的最小可用PE EXE文件是32位Windows上的133 bytes。如果你沒有導入任何東西，你可以把它減少到97字節，但它不會在Windows 2000上運行，因爲它假設你從kernel32導入了一些東西。這些文件是黑客並將PE標頭放在DOS標頭的頂部等。

如果你的目標是簡單地得到108kb，那麼我會嘗試在Windows 95或者NT 4上的97字節的EXE文件。在Windows 95所有主要系統.DLL都由所有進程共享。

來源

2017-03-02 00:07:24 Anders

謝謝。正如我所提到的，我使用Window的任務管理器來測量物理內存。這是在32位Windows 10上。 – ChrisD

多年來，任務管理器已經改變了不同列的含義，所以它可能不是最好的工具。從SysInternals/TechNet嘗試Process Explorer和VMMap。 – Anders

活動Windows可執行文件的最小內存空間

回答

相關問題