avatar_razor1995

WIM - czyli o kompresji i przechwytywaniu Windows słów kilka

Zaczęty przez razor1995, 02 Luty 2025, 17:29:44

Poprzedni wątek - Następny wątek

0 użytkowników i 2 Gości przegląda ten wątek.

razor1995

Na początek trochę teorii.
Struktura pliku WIM:

Nagłówek WIM—Definiuje zawartość pliku .wim, w tym lokalizację pamięci kluczowych zasobów (zasób metadanych, tabela wyszukiwania, dane XML) oraz różne atrybuty pliku .wim (wersja, rozmiar, typ kompresji).
Zasoby plików—Seria pakietów zawierających przechwycone dane, takie jak pliki źródłowe.
Zasób metadanych—Zawiera informacje o plikach, które są przechwytywane, w tym strukturę katalogów i atrybuty plików. Dla każdego obrazu w pliku .wim istnieje jeden zasób metadanych.
Tabela wyszukiwania—Zawiera lokalizację pamięci plików zasobów plików w pliku .wim.
Dane XML—Zawiera dodatkowe dane o obrazie.
Tabela integralności—Zawiera informacje o haszach bezpieczeństwa używanych do weryfikacji integralności obrazu podczas operacji zastosowania (instalacja/wypakowanie WIM).

Jak przebiega proces przechwytywania?
  • Nagłówek WIM jest tworzony na dysku (c:\data.wim) z początkowymi wartościami.
  • Zasób metadanych jest tworzony w pamięci, a zawartość c:\mydata jest skanowana i indeksowana.
  • Używając zasobu metadanych, zawartość c:\mydata jest zapisywana na dysku w postaci kawałków plików zasobów o rozmiarze 32 KB. Jednocześnie lokalizacja pamięci każdego kawałka jest zapisywana w tabeli wyszukiwania w pamięci.
  • Gdy wszystkie dane zostaną przechwycone, zasób metadanych, tabela wyszukiwania i dane XML są zapisywane na dysku.
  • Nagłówek WIM jest aktualizowany.
  • Przechwytywanie jest zakończone.
Jak przebiega proces instalacji (wypakowania) WIM?
  • Nagłówek WIM jest otwierany, a lokalizacja zasobu metadanych jest odnajdywana.
  • Zasób metadanych jest ładowany do pamięci.
  • Zasób metadanych przetwarza tabelę wyszukiwania w celu określenia lokalizacji plików zasobów.
  • Tworzona jest struktura katalogów.
  • Pliki są zapisywane do struktury katalogów, a atrybuty plików są stosowane.
  • Powtarzaj poprzedni krok, aż wszystkie pliki zostaną zapisane w docelowej lokalizacji.


Przechodząc do praktyki.
Mamy plik wim, Windows 10 21H1 (dość stary, bo dawno robiłem screeny :E ):

Jak wiadomo, plik WIM zawiera obrazy kilku edycji systemu Windows, różnice między edycjami mamy opisane w metadanych, każda kolejna edycja zawiera tylko informację o różnicy w plikach. Ale można te edycje usunąć, zwalniając kilka MB z pliku WIM:

W praktyce usunięcie sprowadza się do ponownego zapisania jednej, wybranej edycji do nowego pliku WIM, jak powyżej
To oszczędza kilkaset megabajtów. Mamy poprawę, ale wciąż niezbyt wielką (np. nadal nie mieści się na pendrivie USB FAT32). Spróbujmy zatem jeszcze lepiej skompresować pli. Najpierw przyjrzyjmy się, jak odbywa się kompresja, co niestety najłatwiej zrobić za pomocą (bardzo) starego narzędzia IMAGEX.EXE, które nadal znajduje się w ADK.

Więc używa kompresji LZX z rozmiarem fragmentu 32K. Ale jak to się przekłada na dostępne typy kompresji: ,,fast", ,,max" i ,,none"?
Jeśli przejdziemy do Nie masz uprawnień do wyświetlania linków. Zarejestruj się lub Zaloguj (który, wciąż jest opublikowany jako plik RTF - choć truno dostępny), znajdziesz tam taką informację:
  • LZX = maksymalna kompresja
  • XPRESS = szybka kompresja
  • none = brak kompresji
Więc na tej podstawie, jeśli wyeksportujemy ten obraz, ale określimy inny typ kompresji, powinno to zająć więcej czasu (ponieważ musi zdekompresować i ponownie skompresować całą zawartość), ale wynikowy rozmiar powinien być inny.

Więc to potwierdza powyższe: eksportowanie jako ,,max" daje dokładnie ten sam rozmiar pliku, ,,fast" jest nieco większy, a ,,none" jest ogromny. (Najszybszy eksport był również przy użyciu ,,max", co jasno pokazuje, że w tym przypadku nie było ponownej kompresji zawartości).
Czyli w zasadzie nic nie osiągnęliśmy w tym eksperymencie, więc po co to robić? Cóż, w dokumentacji DISM jest jeszcze jeden typ kompresji – ,,recovery". Co się stanie, jeśli go użyjemy?

Teraz robi się ciekawie. Plik WIM z kompresją ,,recovery" został zmniejszony o ponad gigabajt, do 3,4 GB. Jak to możliwe? Algorytmy kompresji mogą co prawda wycisnąć niewielkie dodatkowe oszczędności, ale to zdecydowanie nie jest drobna różnica. Więc jak to się stało?
Przyjrzyjmy się temu trochę dokładniej:

Słyszeliście o ESD? :E
Tutaj używany jest inny algorytm kompresji – LZMS. Niektórzy mogą pamiętać ten algorytm, który pojawił się mniej więcej w czasach Windows 8.1 i jest obecnie stosowany w plikach WIM publikowanych w Windows Update, ale z innym rozszerzeniem – .ESD.
Eksportowanie z opcją ,,recovery" tworzy więc niezaszyfrowany plik ESD, który nadal jest plikiem WIM. Ale jest pewne ograniczenie – tych plików nie można zamontować
Dlaczego?
Ponieważ są one skompresowane przy użyciu techniki nazywanej (przynajmniej nieformalnie) ,,solid compression". W standardowych plikach WIM każdy plik jest kompresowany osobno, co umożliwia ich montowanie i edytowanie – można po prostu dodać nowy plik na końcu i unieważnić istniejący w środku.
Natomiast w przypadku solid compression wszystkie pliki są traktowane jak jeden duży strumień danych i kompresowane razem, co daje znacznie lepsze wyniki, ale uniemożliwia montowanie i edycję.

Jeśli kiedykolwiek przyglądałeś się, jak działają algorytmy kompresji, albo po prostu obserwowałeś, co się dzieje, gdy dodajesz dużą liczbę małych plików do archiwum ZIP, to pewnie zauważyłeś, że współczynniki kompresji nie są wtedy najlepsze.
Windows nie jest idealnym przypadkiem dla algorytmów kompresji, ponieważ system składa się z ogromnej liczby małych plików. Jeśli jednak połączysz je wszystkie w jeden duży ,,blob" pliku, kompresja działa znacznie lepiej.
Problem w tym, że w takiej sytuacji jedynym sposobem na dostęp do pojedynczego pliku jest rozpoczęcie dekompresji od początku, aż do momentu jego znalezienia. To świetne rozwiązanie, jeśli zamierzasz rozpakować cały obraz, ale bardzo niepraktyczne, gdy chcesz zmodyfikować tylko jeden mały element (np. zamontować obraz, wprowadzić zmianę i zatwierdzić ją).
Zatem - jeśli nie chcesz później modyfikować swojego pliku WIM - kompresuj z parametrem recovery - daje to dużo mniejszy plik, ale w przypadku jego późniejszej modyfikacji należy go rozpakować i przechwycić ponownie do "edytowalnego" formatu/metody kompresji.
Laptop: Lenovo ThinkPad T480s | Intel Core i5 8250U | Intel HD 620 | 24GB RAM Hynix | Lexar NM620 NVME 1TB | Windows 10 Pro
Laptop testowy: Lenovo ThinkPad T430 | Intel Core i7 3740QM | Intel HD 4000 | 16GB RAM Hynix | Samsung 850 Pro 256GB | Windows 7 Pro | Windows XP Pro x64
PC: MSI Z87-G43 | Intel Xeon E3-1240 v3 | nVidia RTX 3060Ti 8GB | 32GB RAM Hynix | GoodRAM PX 500 NVME 512GB | Windows 10 Pro
Mobile: Google Pixel 6 | Google Tensor GS101 @2.8 GHz | Mali-G78 MP20 | 8GB RAM | 128GB MMC | Android 15
Sieć: Cudy WR3000 AX OpenWRT | Huawei HG8010H | Netia 1Gb/s
PlayStation 4 | CUH-1116A | 1TB SSD|