jemný detail o tom, jak jsou dll přemístěny v důsledku kolize základní adresy, a důsledky

Raymonda

19. ledna, 2017

pokud DLL musí být přemístěna kvůli konfliktu základní adresy, pak bude obrázek přemístěn a celá přemístěná DLL je nyní podporována souborem stránky.

pokud si přečtete popis pečlivěji, uvidíte, že to není přesně celá přemístěná knihovna DLL, která je podporována souborem stránky. Přesněji řečeno, všechny stránky, které obsahovaly opravy, jsou vloženy do souboru stránky. Pokud budete mít štěstí a máte stránku bez jakýchkoli oprav, bude tato stránka stále požadována z obrázku, protože jádro na ni nepoužilo žádné opravy,a proto pro tuto stránku nevznikla kopie při zápisu, takže je nadále podporována obrazem systému souborů.

jedním z argumentů, které jsem viděl pro úmyslné způsobení kolize základní adresy, je to, že přemístěná DLL se zkopíruje do souboru stránky, což je výhra, pokud je soubor stránky na rychlejším médiu než DLL. Soubor stránky může být například na jednotce SSD nebo (gasp) na jednotce RAM.

tato logika nezohledňuje případ stránek bez oprav. Tyto stránky budou stále stránkovat přímo z původního souboru, což je problém, pokud je původní soubor na velmi pomalém médiu nebo na médiu, které by mohlo být ztraceno, jako je jednotka CD-ROM nebo síťová jednotka.

naštěstí nemusíte hrát zábavné hry se základními konflikty adres, abyste získali celou knihovnu DLL načtenou do souboru stránky. Místo toho použijte příznak / SWAPRUN linker, který vám umožní v záhlaví modulu určit, že zavaděč by měl zkopírovat obrázek do odkládacího souboru.

Raymond Chen

Následovat

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.