Share via

  • Artykuł

[Archiwum biuletynów ^][< Wolumin 1, Numer 4][Wolumin 2, Liczba 1 >]

System wewnętrzny biuletyn woluminu 1, numer 5

http://www.sysinternals.com
Copyright 1999 Mark Russinovich

12 października 1999 r. — w tym problemie:

  1. CO NOWEGO W SYSTEMACH WEWNĘTRZNYCH

    • NTFS dla systemu Windows 98/NTFSDOS Professional
    • DebugView w wersji 3.21
    • Filemon i Regmon v4.21
    • Diskmon v1.1
    • Systemy wewnętrzne w www.microsoft.com
    • Październik "NT Internals"
    • Nie tak nowe rzeczy

  2. WIADOMOŚCI WEWNĘTRZNE

    • Wydany DDK Win2K RC2
    • Nowe interfejsy API jądra Win2K RC
    • Software Development '99 East
    • Korzystanie z elementu DiskEdit

  3. CO SIĘ DZIEJE

    • Eksplozja interfejsu API Win2K

SPONSOR: WINTERNALS SOFTWARE

Biuletyn Internals Systems jest sponsorowany przez Winternals Software, w Sieci Web http://www.winternals.com. Winternals Software jest wiodącym deweloperem i dostawcą zaawansowanych narzędzi systemów dla systemu Windows NT/2K. Produkty Winternals Software obejmują FAT32 dla systemu Windows NT 4.0, ERD Commander (możliwości rozruchu dla systemu Windows NT) i NTRecover.

Odzyskiwanie zdalne oprogramowania Winternals Software umożliwia dostęp do dysków komputera, który nie można uruchomić za pośrednictwem protokołu TCP/IP z dowolnego miejsca w przedsiębiorstwie. Oszczędzaj czas i obsługę dolarów dzięki zdalnej poprawienia sterowników, systemu plików i problemów z konfiguracją, które utrzymują systemy NT lub Win9x poza wierszem. Można nawet wykonywać zdalne operacje chkdsk lub partycjonowania przy użyciu odzyskiwania zdalnego, co sprawia, że jest to uniwersalne narzędzie odzyskiwania po awarii. Pobierz bezpłatną wersję próbną tylko do odczytu na http://www.sysinternals.com/rrecover.htmstronie i kup wersję do odczytu/zapisu na stronie http://www.winternals.com.

Witam wszystkich,

Witamy w biuletynie Systems Internals. Biuletyn ma obecnie 10 000 subskrybentów.

Wydanie systemu Windows 2000 (Win2K) wydaje się podążać za wzorcem zbliżania się, a następnie jest odepchnięty. Najnowsze plotki są, że stanie się dostępny w lutym. A jedyne informacje o dacie wysyłki Win2K są w plotkach, ponieważ Firma Microsoft nie mówi nawet OEM lub partnerom, kiedy będzie wysyłać. Cóż, są: "to będzie wysyłka, gdy jest gotowa" (nie będę zmuszać datowane mówiąc o sprzedaży wina na ciebie tutaj).

Irytujące jest to, że prasa, którą generują na temat swoich produktów, zawsze sprawia, że wydaje się, że są na skraju wysyłki, nawet gdy produkty są parą. Najnowszym przykładem jest Millennium, następca systemu Windows 98. Firma Microsoft nie zbyt dawno temu dokonała dużego wypchnięcia w prasie, jakby był to gotowy produkt, gotowy do konwersji wszystkich urządzeń gospodarstwa domowego na inteligentne urządzenia. Ironią jest to, że artykuły chwilę później ujawniły, że firma Microsoft jeszcze nie w pełni zdefiniowała produktu, a prawdopodobnie będzie rok lub więcej, zanim zobaczymy go na półkach sklepowych.

Ten wzorzec nie jest nowy i nie jestem pierwszym, aby o tym napisać. Ale to nie powstrzymuje mnie od spekulowania, jak wiele see-sawing jest starannie zorganizowany plan, i ile jest wynikiem całkowitego braku dyrektorów inżynierii oprogramowania. Jeśli kupujesz w byłym kątze, jak teoretycy spisku robią, Microsoft genialnie tłumi konkurencję, kusijąc klientów tym niesamowitym produktem, który, jeśli poczekają nieco dłużej, sprawi, że ich oczekiwania będą warte i niechętnie zwrócić się do produktu innego niż Microsoft. Ten ostatni kąt mówi, że firma Microsoft nigdy nie nauczy się procesu tworzenia oprogramowania i stale nie docenia wysiłku inżynieryjnego i przecenia jakość kodu beta.

Siedzę na ogrodzeniu, do którego teorii przypisuję. Myślę, że wzorzec jest spowodowany trochę obu. Myślę, że pomogło firmie Microsoft działać tak, jakby usługa Active Directory była już prawie gotowa od dwóch lat. Z pewnością są klienci, którzy od dawna zwróciliby się do Usług Katalogowych Novell, gdyby wiedzieli przed czasem, jak długo będą musieli czekać na Win2K. Z drugiej strony firma Microsoft uzyskała powtarzające się czarne oczy w prasie od obiecującego dostarczania produktów, a następnie opóźniania. Myślę, że zarządzanie firmą Microsoft po prostu nie rozumie, jak trudno jest odtworzyć, odizolować i naprawić te ostatnie 5% błędów.

Mówiąc o praktykach programistycznych firmy Microsoft, ich system nazewnictwa wersji wstępnej jest jednym z najbardziej zaskakujących, jakie widziałem. Ich wersje beta są naprawdę Alphas, a ich kandydatów do wydania są rzeczywiście beta. A nawet użycie tych definicji jest rozproszeniem: firma Microsoft nie ma problemu z zgrywaniem funkcji z oprogramowania przechodzącego od jednego kandydata do wydania do następnego, a nawet dodawania nowych. Zrobili to z NT 4.0 i robią to z Win2K. Ta praktyka z pewnością nie przyspiesza cyklu wydawania.

Więc czy win2K statek w lutym? Myślę, że widzimy światło na końcu tunelu. Po tym wszystkim, istnieje tylko kilka nowych interfejsów API w wersji RC2...

Jako kontynuacja ostatniego biuletynu, w którym mówiłem o zamieszaniu akronimów w firmie Microsoft, czytelnik George Janczuk znalazł inny przykład. W sekcji zatytułowanej : "Rozszerzanie na świat przetwarzania transakcji Mainframe", w artykule http://msdn.microsoft.com/library/backgrnd/html/msdn_windnapps.htm opisano ciSC — złożone przetwarzanie zestawu instrukcji. Jest oczywiste dla każdego, kto zna aplikacje mainframe, że zamierzonym akronimem jest CICS - Customer Information Control System. Sekwencja odwrotnej litery i jesteś w zupełnie innym obszarze technologii.

Jak zwykle, przekaż biuletyn do znajomych, że uważasz, że może to interesujące.

Dziękujemy.

-Mark

CO NOWEGO W SYSTEMACH WEWNĘTRZNYCH

NTFS DLA SYSTEMU WINDOWS 98/NTFSDOS PROFESSIONAL

W końcu to zrobiliśmy. Odkąd Bryce i ja wydaliśmy NTFSDOS 1.0 z powrotem na wiosnę 1996 roku byliśmy w poszukiwaniu świętego graala zgodności systemu plików Windows: dostęp do odczytu/zapisu dla systemu PLIKÓW NTFS z systemu Windows 9x i DOS. Ustaliliśmy dawno temu, że odwrotna inżynieria formatu NTFS i pisanie sterownika dla tego złożonego systemu plików dziennika byłoby trudne i ryzykowne propozycje. Nawet jeśli dokładnie określi każdy niuans formatu, aktualizacja formatu, taka jak ntfs 5.0 systemu Plików NTFS systemu Win2K, wymaga zupełnie nowego nakładu pracy w zakresie inżynierii odwrotnej i programowania. Ponadto weryfikowanie poprawności sterownika systemu plików dla formatu jako skomplikowanego, ponieważ system NTFS jest trudną propozycją.

Więc oszukaliśmy.

System PLIKÓW NTFS dla systemu Windows 98 zapewnia pełny dostęp do odczytu/zapisu na dyskach NTFS z systemu Windows 95 lub Windows 98, a NTFSDOS Professional zapewnia pełny dostęp do odczytu/zapisu NTFS z systemu DOS. System PLIKÓW NTFS dla systemu Windows 98 ani NTFSDOS Professional nie ma żadnej wiedzy na temat formatu systemu plików NTFS. Zamiast tego polegają na sterowniku NTFS z instalacji systemu Windows NT lub Windows 2000 w celu zaimplementowania tej wiedzy. Oba narzędzia używają tej samej bazy kodu, która służy jako otoka środowiska dla sterownika systemu plików NTFS. System PLIKÓW NTFS dla systemu Windows 98 udostępnia interfejs API systemu plików Windows 9x powyżej systemu PLIKÓW NTFS, a usługi dysków systemu Windows 9x poniżej systemu PLIKÓW NTFS. Interfejs NTFS dla systemu Windows 98 przedstawia system ntfs wygląda jak natywne środowisko systemu Windows NT/2K systemu NTFS, wraz z irps, Menedżer we/wy, Menedżer pamięci podręcznej, nt-style urządzeń dyskowych i innych podsystemów NT/2K, z którymi system plików NTFS współdziała.

NTFSDOS Professional działa tak samo jak NTFS dla systemu Windows 98, z tą różnicą, że interfejsy NTFS do usług DOS powyżej i BIOS Przerwanie 13 usług dysków poniżej. Aby ułatwić tworzenie środowiska przypominającego NT/2K, polegamy na wielu funkcjach w NTOSKRNL, pliku jądra NT/2K. Oba narzędzia ładują NTOSKRNL w połączeniu z ntfs, aby system NTFS mógł bezpośrednio korzystać z usług natywnych jądra.

Mieliśmy tyle zabawy podczas kompilowania środowiska NTFS, że poszliśmy o krok dalej: zrobiliśmy to samo z narzędziem chkdsk czasu rozruchu NT, Autochk. NTFSDOS Professional i NTFS dla systemu Windows 98 są dostarczane z narzędziem NTFS chkdsk o nazwie NTFSCHK. NTFSCHK działa na tej samej jednostce co otoka systemu plików NTFS, gdzie tworzy środowisko przypominające NT dla programu Autochk, tak aby autochk działa w systemie Windows 95/98 i DOS. Wynikiem tego sztuczki jest kompletna obsługa odczytu/zapisu NTFS dla systemu Windows 95/98 i systemu DOS.

Możesz pobrać bezpłatną wersję systemu plików NTFS tylko do odczytu dla systemu Windows 98 na stronie http://www.sysinternals.com/ntfs98.htm i bezpłatną wersję ntfsDOS Professional tylko do odczytu na stronie http://www.sysinternalscom/ntfspro.htm. Pełne wersje odczytu/zapisu obu narzędzi można kupić w winternals Software, http://www.winternals.com.

DEBUGVIEW V3.21

DebugView to monitor danych wyjściowych debugowania, który przechwytuje zarówno dane wyjściowe debugowania jądra, jak i win32 w systemach Windows 95, Windows 98, NT 4.0 i Windows 2000. Ma zaawansowane funkcje filtrowania, wyróżniania i rejestrowania, a nawet może przechwytywać dane wyjściowe debugowania z systemu w sieci. Najnowsza wersja, 3.21, wprowadza możliwość monitorowania 16-bitowych danych wyjściowych OutputDebugString w systemach Windows 95 i Windows 98.

Widok DebugView w wersji 3.21 można pobrać pod adresem http://www.sysinternals.com/dbgview.htm.

FILEMON I REGMON V4.21

Filemon i Regmon to systemy plików i narzędzia szpiegowskie rejestru dla systemów Windows 95, 98, NT 4.0 i Win2K. Nadal ewoluują dzięki nowym funkcjom użyteczności i wersji 4.21 (Plikimon i Regmon mają zsynchronizowane numery wersji) wprowadzają bardziej zaawansowane filtrowanie z listami ostatnich filtrów, możliwość definiowania filtru wyróżnienia (z niestandardowymi kolorami nawet), dostosowywania czcionki, obsługi schowka i większej liczby kluczy skrótów zgodnych z cuI. Kod źródłowy sterownika został również przerobiony i zawiera bardziej niezawodną walidację parametrów w funkcjach interfejsu graficznego interfejsu użytkownika.

Pobierz plikmon v4.21 na http://www.sysinternals.com/filemon.htm i Regmon v4.21 o http://www.sysinternals.com/regmon.htm.

DISKMON V1.1

Diskmon to narzędzie, które monitoruje i wyświetla aktywność dysku logicznego i fizycznego. Wersja 1.1 aktualizuje narzędzie Diskmon do pracy z systemem Windows 2000 i wprowadza nowe ulepszenia użyteczności. Ponadto diskmon interpretuje teraz dużą liczbę kodów kontroli we/wy dysku i pamięci masowej, tłumacząc ich kody szesnastkowe na reprezentacje tekstowe w oknie danych wyjściowych Diskmon.

Diskmon v1.1 nie tylko działa jako monitor dysku, ale można go również użyć jako światła dysku opartego na oprogramowaniu. Po ustawieniu go w trybie światła dyskowego Diskmon minimalizuje się do zasobnika systemu jako światło, które jest zielone, gdy istnieje dostęp do odczytu dysku i czerwony, gdy istnieje dostęp do zapisu dysku.

Pobierz program Diskmon w wersji 1.1 pod adresem http://www.sysinternals.com/diskmon.htm.

SYSTEMY WEWNĘTRZNE W WWW.MICROSOFT.COM

Biorąc pod uwagę historię systemów wewnętrznych (dawniej NT Internals), jest to wspaniałe pochlebne rzeczywiście, że firma Microsoft odwołuje się sysinternals.com jako zasób dla swoich klientów. Coraz więcej artykułów z bazy wiedzy Microsoft Knowledge Base znajduje się w artykule Systems Internals utilities (Narzędzia wewnętrzne systemów). Poniżej przedstawiono najnowsze informacje:

  • Q183060 INFO: Przewodnik rozwiązywania problemów z 80004005 i innymi komunikatami o błędach http://support.microsoft.com/support/kb/articles/Q183/0/60.ASP
    W tym artykule opisano, jak za pomocą narzędzia Filemon sprawdzić przyczynę błędów dostępu do danych w bazie danych OLE DB, obiektach danych ActiveX i usłudze danych zdalnych.

  • Q196453 — rozwiązywanie problemów z błędami uruchamiania NTVDM i WOW http://support.microsoft.com/support/kb/articles/Q196/4/53.ASP
    Ten artykuł wskazuje również na Filemon jako narzędzie do określania, jakie brakujące pliki powodują błędy uruchamiania ntVDM (środowisko zgodności Win16/DOS w NT).

  • Q216368 — PRB: naruszenie dostępu podczas instalacji aplikacji podczas korzystania z pliku http://support.microsoft.com/support/kb/articles/Q216/3/68.ASP
    HandleEx i DLLView to zalecane narzędzia do określania przyczyny błędu podczas wykonywania programów instalacyjnych generowanych przez Kreatora instalacji i Kreatora wdrażania języka Visual Basic.

  • Q232830 — INSTRUKCJE: Określanie własności dojścia do plików http://support.microsoft.com/support/kb/articles/Q232/8/30.ASP
    Narzędzie HandleEx ponownie pobiera odwołanie w tym artykule, które zawiera informacje o tym, jaki proces ma otwarty plik lub katalog.

PAŹDZIERNIK "NT INTERNALS"

Moja kolumna "NT Internals" w październikowym wydaniu magazynu Windows NT to "Inside Win2K Reliability Enhancements, Part 3". Ta trzecia z trzyczęściowej serii opisuje dwie zaawansowane funkcje Win2K, które pomagają deweloperom i administratorom wskazać sterowniki buggy: pamięć jądra chronionego przez zapis i weryfikator sterowników.

Rosyjscy czytelnicy mogą teraz czytać moje artykuły w ich ojczystym języku. Przejdź do rosyjskiego wydania Windows NT Magazine na http://www.osp.ru/win2000/ i zapoznaj się z pierwszą przetłumaczoną kolumną NT Internals, Inside the Boot Process (http://www.osp.ru/win2000/1999/10/59.htm). Dzięki IvanOwi Rouzanovowi za poinformowanie mnie o tym.

Od początku sierpnia wersje online artykułów windows NT Magazine są dostępne tylko dla subskrybentów, a artykuły są publikowane zgodnie z każdym nowym wydaniem. Jeśli subskrypcja nie została zasubskrybowana, przejdź za pośrednictwem linku subskrypcji pod adresem http://www.sysinternals.com/publ.htm , aby uzyskać rabat na subskrypcję Systemów wewnętrznych.

NIE TAK NOWE RZECZY

WinObj to zaawansowane narzędzie do eksplorowania przestrzeni nazw obiektów systemu Windows NT/2K. Przestrzeń nazw obiektów jest jedną z trzech przestrzeni nazw w nt/2K: przestrzeni nazw obiektu, przestrzeni nazw rejestru i przestrzeni nazw systemu plików. Dostęp do przestrzeni nazw rejestru i systemu plików można uzyskać za pośrednictwem obiektów w przestrzeni nazw obiektów. Na przykład gdy program Win32 otworzy klucz HKEY_LOCAL_MACHINE\Software\Microsoft rejestru, biblioteka ADVAPI32.DLL przekształca nazwę na \Registry\Machine\Software\Microsoft przed wywołaniem usługi NtCreateKeyjądra . Jeśli spojrzysz na katalog główny przestrzeni nazw obiektów w winobj, zobaczysz obiekt typu "klucz" o nazwie Registry. Nazwa rejestru jest zgodna z pierwszym składnikiem nazwy klucza, a więc Menedżer obiektów NT/2K przekazuje resztę nazwy , \Machine\Software\Microsoftdo podsystemu, który definiuje obiekt klucza. Podsystem jądra programu Configuration Manager obsługuje obiekty rejestru i kluczy, dlatego analizuje resztę nazwy, aby zlokalizować żądany klucz.

Możesz eksplorować przestrzeń nazw obiektów i wyświetlić lub ustawić właściwości zabezpieczeń obiektu przy użyciu winobj. Pobierz winobj pod adresem http://www.sysinternals.com/winobj.htm. Omawiam przestrzeń nazw Menedżera obiektów i WinObj w mojej kolumnie Internals NT z października 1997 r. "Inside the Object Manager". Postępuj zgodnie z linkiem do lokalnej wersji kolumny pod adresem http://www.sysinternals.com/publ.htm.

WIADOMOŚCI WEWNĘTRZNE

WYDANY DDK WIN2K RC2

Teraz możesz pobrać wersję Win2K RC2 zestawu Microsoft Device Driver Development Kit (DDK) http://www.microsoft.com/ddk/ddkRC2.htm. Zestaw można pobrać bezpłatnie lub przeglądać dokumentację online.

NOWE INTERFEJSY API JĄDRA WIN2K RC2

Rzeczy wyglądają na stabilizację w najnowszym jądrze Win2K. W wersji RC3 istnieją tylko cztery nowe, wyeksportowane interfejsy API jądra, w przeciwieństwie do około tuzina, które pojawiły się (i kolejne pół tuzina, które zniknęły) przechodzące z wersji Beta 3 do RC1. Kilka nowych funkcji jest nieco interesujących, więc postanowiłem je udokumentować dla Ciebie. Pierwszy to MmGetSystemRoutineAddress, i chociaż jest on nieudokumentowany jego prototyp jest zawarty w pliku nagłówkowym ntddk.h zestawu DDK RC2:

NTKERNELAPI
PVOID
MmGetSystemRoutineAddress (
    IN PUNICODE_STRING SystemRoutineName
    );

Jego użycie jest tak proste, jak wygląda. Przekaż nazwę funkcji, która znajduje się w NTOSKRNL.EXE lub HAL.DLL, a adres punktu wejścia zostanie przywrócony. Ta funkcja jest w rzeczywistości bezużyteczna w pierwszej wersji win2K, ale może stać się bardzo przydatna w dół drogi, a jest to funkcja, którą firma Microsoft powinna uwzględnić w pierwszej wersji NT (3.1). Podobnie jak GetProcAddress w przypadku aplikacji Win32 w przestrzeni użytkownika, ta funkcja pozwala kierowcy dynamicznie ustalić dostępność interfejsu API. Jeśli firma Microsoft dodaje nowe interfejsy API do dodatków Service Pack Win2K (i jestem pewien, że będą) sterowniki mogą być napisane w celu skorzystania z interfejsów API, ale także do bezproblemowego niepowodzenia w starszych wersjach zestawu Win2K lub do uruchamiania w trybie, w którym nie korzystają z interfejsów API. Kluczem do sterownika jest możliwość sprawdzenia obecności interfejsów API po załadowaniu. Bez tej funkcji sterownik musi statycznie łączyć się z używanymi funkcjami, a jeśli funkcje nie są obecne, gdy sterownik ładuje, moduł ładujący jądro zgłasza użytkownikowi brzydki błąd i nie może załadować sterownika.

Drugi nowy interfejs API to MmGetPhysicalMemoryPages. Ponownie, jego prototyp jest w RC2 ntddk.h, ale nie jest udokumentowany. Jego prototyp to:

NTKERNELAPI
PPHYSICAL_MEMORY_RANGE
MmGetPhysicalMemoryRanges (
    VOID
    );

Gdzie PHYSICAL_MEMORY_RANGE jest:

typedef struct _PHYSICAL_MEMORY_RANGE {
    PHYSICAL_ADDRESS BaseAddress;
    LARGE_INTEGER NumberOfBytes;
} PHYSICAL_MEMORY_RANGE, *PPHYSICAL_MEMORY_RANGE;

Ta funkcja zwraca tablicę PHYSICAL_MEMORY_RANGE wpisów z końcem tablicy oznaczonej przez wpis o wartości 0 dla wartości BaseAddress i NumberOfBytes. Podobnie jak MmGetSystemRoutineAddress, jest to dość prosty interfejs API. Zwraca on opis całej pamięci fizycznej, o której wie Win2K. Zestaw Win2K obsługuje dodawanie i usuwanie pamięci na bieżąco za pomocą MmAddPhysicalMemory interfejsów API i MmRemovePhysicalMemory . To motywuje przyczynę istnienia interfejsu API, który umożliwia wykonywanie zapytań o zakresy pamięci. MmAddPhysicalMemory dodano w wersji RC1 i MmRemovePhysicalMemory RC2. Oba te funkcje są również prototypowane w ntddk.h.

Jakie są inne nowe interfejsy API RC2? PoShutdownBugCheck i RtlInvertRangeList. PoShutdownBugCheck Umożliwia awarię systemu i wykonywanie akcji związanej z zasilaniem, takich jak zawieszenie. Jest on używany w kilku miejscach przez jądro RC2. Zakresy to ogólne specyfikacje początkowe, które są definiowane przez użytkownika i obsługiwane przez wiele interfejsów API jądra do zarządzania, sortowania i iteracji nad nimi. Arbitery zasobów Win2K Plug-and-Play używają ich do śledzenia i organizowania wymagań dotyczących zasobów sprzętowych. Mimo że interfejsy API listy zakresów nie są udokumentowane, wszystkie ich prototypy i definicje struktury są zawarte w ntddk.h, więc prawdopodobnie można użyć interfejsu API do zarządzania własnymi danymi zorientowanymi na początku.

Bądź na bieżąco z nieudokumentowanym interfejsem API w kolejnych biuletynach.

SOFTWARE DEVELOPMENT 99 EAST

Wydanie 1999 East Coast Software Development odbywa się w Waszyngtonie od 8-12 listopada. Przedstawiam trzy rozmowy w ostatnim dniu: Co nowego w systemie Windows 2000 for Developers, Inside the Windows NT/2000 Blue Screen i Inside Windows NT/2000 Networking. Ponadto Dave Solomon, autor Inside Windows NT 2nd Edition i sąsiad (mieszka zaledwie 20 minut ode mnie w, we wszystkich miejscach, Danbury, CT) i jestem gospodarzem Windows NT / 2K wewnętrznych stół. Będziemy razem odpowiadać na najtrudniejsze pytania dotyczące wewnętrznych systemu Windows NT/2K. Powiedz cześć i wspominam biuletyn i dam Ci darmowy t-shirt Systems Internals!

Odwiedź witrynę sieci Web tworzenia oprogramowania pod adresem http://www.sdexpo.com.

KORZYSTANIE Z DISKEDIT

Być może nie wiesz, ale istnieje narzędzie edytora dysków dla systemu Windows NT w stylu czcigodny Norton Disk Edit for DOS. Co więcej, narzędzie rozumie FAT i NTFS i jest bezpłatne. Firma Microsoft najwyraźniej przypadkowo wysłała diskEdit, narzędzie, które musi być wewnętrznym narzędziem debugowania dla swoich zespołów systemów plików, na dysku CD systemu Windows NT 4.0 z dodatkiem Service Pack 4. DiskEdit ma osobliwy interfejs, który zajmie mały podręcznik do dokumentu, ale zamierzam rozpocząć pracę z prostym przewodnikiem. Skoncentruję się na używaniu DiskEdit do rozwikłania formatu systemu plików NTFS, ponieważ DiskEdit jest jedynym publicznie dostępnym narzędziem, o których wiem, że rozumie ntfs.

Najpierw należy pobrać plik DiskEdit z dysku CD-ROM z dodatkiem Service Pack 4 (SP4). Po prostu skopiuj go z katalogu \i386 na dysk twardy. Jeśli chcesz użyć narzędzia DiskEdit w systemie Win2K, musisz utworzyć dla niego katalog prywatny i skopiować następujące biblioteki DLL z katalogu winnt\system32 sp4 (lub SP4 CD) do tego samego katalogu co DiskEdit: IFSUTIL.DLL, ULIB.DLL, UNTFS.DLL i UFAT.DLL. Teraz możesz uruchomić diskEdit.

W tym przewodniku utwórz katalog o nazwie TEMP w katalogu głównym dysku NTFS i utwórz plik o nazwie OUT.TXT w tym katalogu, wpisując następujące polecenie w oknie wiersza polecenia z temp jako bieżący katalog: echo hello > out.txt. Wybierz dysk z nowym plikiem OUT.TXT w obszarze DiskEdit, wybierając plik |Otwórz element menu i wprowadź literę dysku w polu Nazwa woluminu w wyświetlonym oknie dialogowym. Upewnij się, że dołączysz dwukropek, np. "d:". Praktycznie wszystkie funkcje DiskEdit wymagają otwarcia dysku.

Zlokalizuj plik OUT.TXT, zaczynając od katalogu głównego dysku NTFS. Wybierz wpis menu Odczyt|Rekord pliku NTFS, aby otworzyć okno dialogowe, które umożliwia wyświetlenie dowolnego wpisu rekordu MFT tylko przez wprowadzenie jego numeru. Pierwsze 16 wpisów rekordów MFT każdego dysku NTFS są zarezerwowane i odpowiadają wstępnie zdefiniowanym plikom metadanych NTFS. Poniżej przedstawiono przypisania liczb (zwróć uwagę, że Element DiskEdit interpretuje wszystkie dane wejściowe jako szesnastkowe):

        0: $MFT - MFT
        1: $MFTMirr - MFT Mirror (a copy of the first 4 entries of the MFT)
        2: $LogFile - NTFS LogFile
        3: $Volume - volume information file
        4: $AttrDef - the attribute definition file
        5: . - the root directory
        6: $Bitmap - the volume allocation bitmap file
        7: $Boot - the boot sector
        8: $BadClus - the bad cluster database file
        9: $Secure - new to SP4, the security attribute database
        A: $UpCase - the lower-to-upper case mapping file
        B: $Extend - new to Win2K, the directory that contains
                             the reparse, object ID, and quota metadata files
        C-F: Unused as of NTFS v5.0 (Win2K)

Przejdź dalej i przyjrzyj się niektórym z tych wpisów MFT. Zaczniesz zauważyć wspólny motyw: wszystkie składają się z atrybutów, takich jak $INDEX_ROOT, $FILE_NAMEi $DATA. Są to atrybuty, w których przechowywane są dane specyficzne dla pliku. Gdy dane atrybutu są małe NTFS przechowuje dane w rekordzie MFT pliku jako dane "rezydentne", a gdy dane są duże NTFS przechowuje dane zewnętrzne do rekordu w klastrach na dysku jako dane "nierezydentowe".

Teraz wprowadź wartość "5" jako numer pliku i wyświetlisz plik katalogu głównego. Przyjrzymy się plikom i katalogom, które znajdują się w katalogu głównym, wyświetlając atrybut katalogu $INDEX_ALLOCATION , atrybut specyficzny dla katalogów, które rejestrują zawartość katalogu. Aby to zrobić, wybierz pozycję Odczyt|Wpis menu NTFS, który otwiera inne okno dialogowe. Element DiskEdit jest wrażliwy na wielkość liter, więc wprowadź następujące polecenie dokładnie tak, jak został on wymieniony:

        Base Frs Number: 5

Base Frs (podstawowy segment rekordu pliku) to inna nazwa numeru MFT. Wprowadź wartość 5, aby określić, że chcesz odczytać atrybut z katalogu głównego.

        Attribute Type: $INDEX_ALLOCATION

Wskazuje to na DiskEdit, że chcesz odczytać dane zawartości katalogu. Zalecam użycie menu rozwijanego, aby wybrać odpowiedni atrybut, ponieważ DiskEdit jest bardzo picky o sposobie wprowadzania typu atrybutu.

        Attribute Name: $I30

Jeśli wyświetlisz $INDEX_ALLOCATION atrybut katalogu głównego, zobaczysz, że ciąg "$I30" jest wyświetlany jako jego nazwa w wierszu "Type code, name", tak aby to, co wprowadzasz jako nazwę atrybutu.

Naciśnij przycisk OK i zobaczysz zrzut szesnastkowy zawartości atrybutu. Chcemy zobaczyć coś bardziej zrozumiałego, więc wybierz widok |Wpis menu Bufor indeksu NTFS. Zostanie wyświetlona lista zawartości katalogu. Przewiń listę do momentu wyświetlenia wpisu o nazwie "TEMP". Jeśli go nie widzisz, wpis może znajdować się w atrybucie katalogu $INDEX_ROOT głównego, typ atrybutu skojarzony również z katalogami i zawsze ma jego wartość przechowywaną w rekordzie MFT. Indeksuj wpisy główne i wpisy alokacji razem tworzą strukturę drzewa B+ przechowując wszystkie wpisy katalogu. Jeśli musisz wyświetlić $INDEX_ROOT atrybut, wykonaj te same kroki, aby wyświetlić ten atrybut, tak jak w przypadku wyświetlania atrybutu $INDEX_ALLOCATION . Podczas przewijania buforu indeksu mogą pojawić się podwójne wiersze gwiazdki: wyznaczają one koniec jednego buforu indeksu i początek następnego.

Po znalezieniu wpisu katalogu TEMP zanotuj jego odwołanie do pliku (FRS). Wybierz pozycję Odczyt|Ntfs File Record (Rekord pliku NTFS) i wprowadź nazwę FRS w formacie TEMP. Teraz patrzysz na rekord MFT dla katalogu TEMP. Chcemy znaleźć plik OUT.TXT, więc musimy przejrzeć jego zawartość. $INDEX_ALLOCATION Wyświetl atrybut (lub $INDEX_ROOT) katalogu TEMP, przejdź do wyświetlania danych jako bufora indeksu NTFS i znajdź plik OUT.TXT. Pamiętaj, aby wprowadzić frS TEMP jako podstawowy numer FRS w oknie dialogowym wyboru atrybutu. Jeśli właśnie utworzono szablon TEMP, będzie on miał tylko wartość $INDEX_ROOT (jeśli błędnie wpiszesz coś, co będziesz widzieć w pustych oknach dialogowych błędu DiskEdit).

Po znalezieniu OUT.TXT i ustaleniu, że jego usługa FRS używa funkcji Read|Rekord pliku NTFS, aby przyjrzeć się jego wpisowi MFT. Przewiń w dół do momentu znalezienia atrybutu $DATA. Teraz patrzysz na lokalizację OUT. Dane TXT. Ponieważ utworzyliśmy mały plik, dane są przechowywane w rekordzie MFT. Jeśli spróbujesz wyświetlić wyjście. $DATA Atrybut TXT przy użyciu diskEdit nie zobaczysz nic, ponieważ DiskEdit nie pokazuje prawidłowo danych rezydentnych (jeden z wielu usterek DiskEdit). Dlatego skopiuj largish (> 2KB) plik tekstowy do \TEMP\ OUT.TXT. Teraz możesz wyświetlić dane OUT.TXT na jeden z dwóch sposobów: możesz sprawdzić początek danych (lub wszystkie, jeśli są one stale przechowywane na dysku) przy użyciu funkcji Odczyt|Klaster NTFS i określenie pierwszej wartości "lcn" widocznej w pozycji OUT. $DATA Atrybut TXT "Lista zakresów" lub można użyć funkcji Odczyt|Ntfs Atrybut i wprowadź "$DATA" jako typ atrybutu i nic (tak jak w nie wpisz nic w tym polu) jako nazwę atrybutu.

Listy zakresów opisują lokalizację danych niebędących rezydentami atrybutu. Każdy ciągły blok danych o długości do 16 klastrów jest opisywany przez jeden wpis listy zakresów. Wpis listy zakresów określa numer klastra wirtualnego (vcn), numer klastra logicznego (lcn) i długość przebiegu. Vcn to klaster w pliku, w którym zaczynają się dane opisane przez wpis. Lcn wyznacza klaster logiczny, w którym dane są przechowywane na dysku, a runlength jest liczbą bajtów danych atrybutów w tej lokalizacji (pamiętaj, DiskEdit wyświetla wartości szesnastkowe).

Przeszedłem przez długą drogę znajdowania rekordu MFT pliku OUT.TXT, pokazując, jak skanować zawartość katalogu. Istnieje jednak skrót: wybierz pozycję Crack|Ścieżka NTFS i wprowadź TEMP\OUT.TXT. Zostanie wyświetlona wartość OUT. USŁUGA FRS TXT i możesz użyć funkcji Read|Rekord pliku NTFS, aby przejść do niego bezpośrednio.

To prowadzi mnie do końca mojego primer DiskEdit. Zachęcam do zabawy z tym nifty narzędzie, przeglądając swoje dyski FAT lub NTFS. Jest bardzo mało prawdopodobne, że kiedykolwiek znajdziesz okazję do używania DiskEdit do modyfikowania danych w celu wydostania dysku z zacięcia, ale jeśli interesuje Cię format NTFS na dysku (format FAT jest dobrze udokumentowany) jest to idealne narzędzie do badania.

CO SIĘ DZIEJE

EKSPLOZJA INTERFEJSU API WIN2K

Chociaż istnieje tylko 4 nowe wyeksportowane interfejsy API trybu jądra, które zadebiutowały w wersji RC2, liczba łącznych interfejsów API, które firma Microsoft wprowadziła od NT 4.0, zarówno w jądrze, jak i w podstawowych bibliotekach DLL Win32, eksplodowała. W przyszłym miesiącu powiem dokładnie, ile nowych interfejsów API istnieje i gdzie się pojawiły, i niestety w tym samym czasie dać ludziom, którzy wierzą, że Win2K jest wzdęty potwor jakiś wielki amunicja dla ich alt.advocacy.linux Usenet rants.

Dziękujemy za przeczytanie biuletynu Systems Internals.

Opublikowano środę, 20 października 1999 19:10 przez ottoh

[Archiwum biuletynów ^][< Wolumin 1, Numer 4][Wolumin 2, Liczba 1 >]