1999. október 12. – Ebben a problémában:

  1. A BELSŐ RENDSZEREK ÚJDONSÁGAI

    • NTFS a Windows 98/NTFSDOS Professional
    • HibakeresésView v3.21
    • Filemon és Regmon v4.21
    • Diskmon v1.1
    • Belső rendszerek a www.microsoft.com
    • Októberi "NT Internals"
    • Nem annyira új dolgok
  2. BELSŐ HÍREK

    • Megjelent a Win2K RC2 DDK
    • Új Win2K RC kernel API-k
    • Szoftverfejlesztés 2019. keleti régiója
    • A DiskEdit használata
  3. MI LESZ A KÖVETKEZŐ?

    • Win2K API-robbanás

SZPONZOR: A TÉLI SZOFTVER

A systems internals hírlevelet a Küldő Software szponzorálja, a weben a következő webhelyen: http://www.winternals.com. A Modern szoftver az NT/2K-hez használható fejlett rendszereszközök vezető fejlesztője Windows szolgáltatója. A Téli szoftvertermékek közé tartozik a FAT32 az Windows NT 4.0, ERD Commander (az Windows NT rendszerindítási lemezes képessége) és az NTRecover.

A Téli szoftver Távoli helyreállítás szolgáltatása lehetővé teszi, hogy a vállalaton belül bárhonnan hozzáférjen egy nem rendszerelhető számítógép meghajtóihoz TCP/IP-n keresztül. Időt és támogatást takaríthat meg, ha távolról javítja az NT- vagy Win9x-rendszereket távolról megoldó illesztő-, fájlrendszer- és konfigurációs problémákat. Akár távoli chkdsk- vagy particionálási műveleteket is végrehajthat a Távoli helyreállítás használatával, ami egy sokoldalú vészhelyreállítási eszköz. Töltsön le egy ingyenes, csak olvasható próbaverziót a következő ről: , és vásárolja meg az http://www.sysinternals.com/rrecover.htm olvasási/írási verziót a következőn: http://www.winternals.com.

Üdvözlök mindenkit!

Üdvözöljük a Belső rendszerek hírlevelen. A hírlevelenek jelenleg 10 000 előfizetője van.

A 2000-es Windows (Win2K) megjelenése látszólag azt a mintát követi, hogy a rendszer egyre jobban megtetsszen, majd vissza lesz nyomtatva. A legújabb hírek szerint februárban válik elérhetővé. A Win2K-szállítás dátummal kapcsolatos egyetlen információ pedig a fogavasakban van, mivel a Microsoft nem is mondja el az operációs rendszernek vagy a partnereknek, hogy mikor szállítják. Ezek a következőek: "akkor lesz szállítva, amikor készen áll" (nem kényszerítem a dátummal valót, amely a borok itt való értékesítésével kapcsolatos).

A Microsoftnál az a legizgalabb, hogy a termékekről generált press azt jelenti, hogy mindig úgy tűnik, mintha egy kis szállítási útvonalon lenne, még akkor is, ha a termékek kártevők. A legutóbbi példa a 98-as Windows lett. A Microsoft nem is olyan régen nagy leküldést végzett rajta, mintha kész termék lenne, készen arra, hogy az összes háztartás berendezését intelligens eszközökké konvertálja. Az ivadék az, hogy a cikkek egy rövid idővel később kiderült, hogy a Microsoft még nem definiálta teljesen a terméket, és valószínűleg egy vagy több év is eltelik, mielőtt a polcokon látjuk.

Ez a minta nem új, és nem én vagyok az első, aki erről ír. Ez azonban nem akadályoz meg attól, hogy spekuláljon arról, hogy a lát látás mekkora része egy gondosan vezényelt terv, és hogy mekkora az eredménye a szoftvermérnöki főmérnökök teljes hiányának. Ha az előző nézőpontot is figyelembe veszi, ahogyan az elméletek is teszik, a Microsoft nagyszerűen megtorolja az ügyfeleket azzal a lenyűgöző termékkel, amely ha egy kicsit tovább várakoznak, érdemes várniuk, és nem kell a Microsofton kívüli termékhez fordulnunk. Az utóbbi nézőpont szerint a Microsoft soha nem tanulja meg a szoftverfejlesztési folyamatot, és folyamatosan alulbecsüli a mérnöki munkát, és túlbecsüli a bétakód minőségét.

Azon a kerítésen ücsökök, hogy melyik elméletnek vagyok kiírva. Azt hiszem, a minta oka részben mindkettő. Szerintem segített a Microsoftnak úgy cselekedni, Active Directory már majdnem két éve készen áll. Vannak olyan ügyfelek, akik már régóta a Novell Directory Serviceshez fordultak volna, ha előre tudják, hogy mennyi ideig kellene várniuk a Win2K-re. A Microsoft viszont ismétlődő fekete szemeket kapott a presszástól az ígéretes termékszállítástól, majd a késéstől. Szerintem a Microsoft vezetősége nem érti, milyen nehéz reprodukálni, elkülöníteni és kijavítani a hibák utolsó 5%-át.

A Microsoft fejlesztési gyakorlatait a kiadás előtti elnevezési sémájuk az egyik legnagyobb baffing, amit valaha is láthattam. A bétaverziójuk valóban alfa, a kiadásra jelölt változatuk pedig valójában bétaverzió. És még ezeknek a definícióknak a használata sem jelent problémát: a Microsoftnak nincsenek problémája a szoftvereikben az egyik kiadási jelöltről a következőre, vagy akár újak hozzáadására. Ezt az NT 4.0-val, a Win2K-val csinálják. Ez a gyakorlat nem gyorsítsa fel a kiadási ciklust.

A Win2K is februárban lesz kiszivárgva? Azt hiszem, az alagút végén a világítás látható. Végül is csak néhány új API van az RC2-ben...

A legutóbbi hírlevelet, ahol a Microsoftnál a mozaikszók keveredésről beszéltünk, az olvasó, Janczuk egy másik példát is talált. A "Extending to the Mainframe Transaction-Processing World" című szakaszban a cikk a CISC – Complex Instruction Set Computing (CISC – Összetett utasításkészlet-számítástechnika) című szakaszra http://msdn.microsoft.com/library/backgrnd/html/msdn_windnapps.htm vonatkozik. A nagyszámítógépes alkalmazásokban jártasak számára nyilvánvaló, hogy a kívánt betűszó a CICS – Customer Information Control System. Fordított betűsor, és teljesen más technológiai területen van.

A szokásos módon adja át a hírlevelet a barátainak, hogy érdekesnek találhatja.

Köszönjük!

-Mark (Megjelölés)

A BELSŐ RENDSZEREK ÚJDONSÁGAI

NTFS WINDOWS 98/NTFSDOS PROFESSIONAL ESETÉN

Végül végeztünk vele. Bryce és én 1996 tavaszi kiadott NTFSDOS 1.0-s verzió óta a Windows fájlrendszer-kompatibilitás: az NTFS olvasási/írási hozzáférését Windows 9x és a DOS között keressük. Már régóta megállapítottuk, hogy az NTFS-formátum visszafejtése és az illesztő írása ehhez az összetett naplózási fájlrendszerhez nehéz és kockázatos ajánlat lenne. Még ha pontosan meg is határozzák a formátum minden részletét, a formátum frissítése, például a Win2K NTFS 5.0-s verzió, teljesen új visszafejtését és fejlesztését igényli. Továbbá a fájlrendszer-illesztőprogramok helyességét olyan bonyolult formátumra kell érvényesen állítani, mint az NTFS formátuma, ijesztő ajánlat.

Ezért nem volt jó.

Az Windows 98-hoz használható NTFS teljes olvasási/írási hozzáférést biztosít az NTFS-meghajtókhoz Windows 95-ös vagy Windows 98-as rendszerről, az NTFSDOS Professional pedig teljes NTFS olvasási/írási hozzáférést biztosít a DOS-ból. Sem a 98 Windows, sem az NTFSDOS Professional számára nem rendelkezik ntfs fájlrendszer-formátummal kapcsolatos ismeretekkel. Inkább az NT vagy Windows 2000 2000-es Windows NTFS-illesztőprogramját hajtják végre. Mindkét segédprogram ugyanazt a kódbázist használja, amely környezeti burkolóként szolgál az NTFS fájlrendszer-illesztőprogramhoz. A Windows 98-hoz használható NTFS illesztőfelületet biztosít az WINDOWS fájlrendszer 9x-es API-ja számára az NTFS fölött, a Windows 9x-es lemezszolgáltatások pedig az NTFS alatt. Az Windows 98-hoz használható NTFS-interfész az NTFS natív Windows NT/2K környezetéhez hasonlít, integrációs pontokkal, az I/O-kezelővel, a Gyorsítótárkezelővel, az NT-stílusú lemezeszközökkal és az NTFS által kommunikáló egyéb NT/2K alrendszerekkel.

Az NTFSDOS Professional ugyanúgy működik, mint az NTFS Windows 98 esetén, azzal a kivételekkel, hogy az NTFS-t a fenti DOS-szolgáltatásokhoz és az alábbi BIOS 13 lemezszolgáltatáshoz csatolja. Az NT/2K-szerű környezet létrehozásához az NTOSKRNL számos függvényére, az NT/2K kernelfájlra támaszkodunk. Mindkét segédprogram az NTOSKRNL-t ntfs fájlrendszerrel együtt tölti be, így az NTFS közvetlenül használhatja a kernel natív szolgáltatásainak májusi használatát.

Nagyon szórakoztató volt az NTFS-környezet kiépítése, hogy egy lépéssel továbbmentünk: ugyanezt megtettünk az NT autochk rendszerindítási chkdsk segédprogrammal. A 98-as Windows NTFSDOS Professional és NTFS NTFS fájlrendszerű chkdsk segédprogramja NTFSCHK. Az NTFSCHK ugyanazon a rendszeren működik, mint az NTFS fájlrendszer burkolója, ahol NT-hez hasonló környezetet hoz létre az Autochk programhoz, így az Autochk a 95/98-as és a DOS-Windows fut. Ennek a bonyolult műveletnek az eredménye a 95/98-as és a DOS teljes NTFS olvasási Windows/írási támogatása.

Az NTFS egy csak olvasható verzióját a Windows 98-as verziójához a következő e-Windows, az NTFSDOS Professional ingyenes, csak olvasható verzióját pedig itt http://www.sysinternals.com/ntfs98.htm töltheti le:http://www.sysinternalscom/ntfspro.htm. Mindkét eszköz teljes olvasási/írási verzióját a Következő oldalon vásárolhatja meg: http://www.winternals.com.

DEBUGVIEW V3.21

A DebugView egy hibakeresési kimenetet figyelő monitor, amely a kernel és a Win32 hibakeresési kimenetét Windows 95, Windows 98, NT 4.0 és Windows 2000 alatt rögzíti. Fejlett szűrési, kiemelési és naplózási képességekkel rendelkezik, és akár egy rendszer hibakeresési kimenetét is rögzítheti a hálózaton. A legújabb, 3.21-es kiadás a 16 bites OutputDebugString kimenet 95-ös és Windows 98-as Windows monitorozását teszi lehetővé.

A DebugView v3.21-et itt töltheti le: http://www.sysinternals.com/dbgview.htm.

FILEMON ÉS REGMON V4.21

A Filemon és a Regmon a Windows 95, 98, NT 4.0 és Win2K fájlrendszer- és beállításjegyzék-beli segédprogramjai. Folyamatosan fejlődnek az új használhatósági funkciókkal, és a 4.21-es kiadással (a Filemon és a Regmon szinkronizálta a verziószámokat), fejlettebb szűrést vezetnek be a legutóbbi szűrőlistákkal, a kiemelési szűrő (egyéni színekkel is), testre szabható betűtípus, vágólap-támogatás és cuI-kompatibilis billentyűparancsok. Az illesztőprogram forráskódját is átdolgozták, és robusztusabb paraméter-érvényesítést tartalmaznak a GUI-interfész függvényében.

Töltse le a Filemon v4.21-et a következő http://www.sysinternals.com/filemon.htm címről: és Regmon v4.21 at http://www.sysinternals.com/regmon.htm.

DISKMON V1.1

A Diskmon egy olyan eszköz, amely figyeli és megjeleníti a logikai és fizikai lemez tevékenységét. Az 1.1-es verzió úgy frissíti a Diskmont, hogy az működjön Windows 2000-es verziójával, és új használhatósági fejlesztéseket vezet be. Emellett a Diskmon mostantól nagy számú lemez- és tömeges tárolási I/O-vezérlőkódot is értelmez, és a hexadecimális kódjaik szöveges ábrázolásként vannak lefordítva a Diskmon kimeneti ablakában.

A Diskmon v1.1 nem csupán lemezmonitorként működik, de szoftveralapú lemezfényként is használható. Lemezes világos módban a Diskmon úgy minimalizálja magát a rendszertálcán, hogy az zöld színű legyen, ha lemez olvasási hozzáféréssel rendelkezik, illetve pirossal, ha lemezírási hozzáféréssel rendelkezik.

Töltse le a Diskmon v1.1-et itt: http://www.sysinternals.com/diskmon.htm.

BELSŐ RENDSZEREK A WWW.MICROSOFT.COM

A belső rendszerek (korábban NT Internals) történetének figyelembe véve nagyon egyszerű, hogy a Microsoft sysinternals.com erőforrásként hivatkozik az ügyfelei számára. Egyre több olyan cikk Microsoft tudásbázis, amelyek a Systems Internals segédprogramjaira mutatnak. Íme a legújabb:

  • Q183060 INFO: Troubleshooting Guide for 80004005 & Other Error Messages http://support.microsoft.com/support/kb/articles/Q183/0/60.ASP
    Ez a cikk azt ismerteti, hogyan használhatja a Filemont az adatelérési hibák okának javítására a OLE DB, ActiveX adatobjektumok és a távoli adatszolgáltatásban.

  • 196453. negyedév – NTVDM- és WOW indítási hibák elhárítása http://support.microsoft.com/support/kb/articles/Q196/4/53.ASP
    Ez a cikk a Filemonra is mutat, amely az NTVDM (az NT Win16/DOS kompatibilitási környezete) indítási hibáit okozó hiányzó fájlok meghatározására szolgáló eszköz.

  • 216368. negyedév – PRB: Hozzáférés-megsértés az alkalmazás beállítása során, ha a fájl használatban van http://support.microsoft.com/support/kb/articles/Q216/3/68.ASP
    A HandleEx és a DLLView ajánlott eszközök a telepítőprogramok és a telepítővarázsló által létrehozott telepítőprogramok Visual Basic telepítővarázsló okának meghatározásához.

  • 232830. negyedév – HOWTO: A fájlkezelő tulajdonjogának meghatározása http://support.microsoft.com/support/kb/articles/Q232/8/30.ASP
    A HandleEx ismét megkapja a cikkben található terjesztést, amely azt ismerteti, hogy melyik folyamatnak van megnyitott fájlja vagy könyvtára.

OCTOBER "NT INTERNALS"

Az "NT Internals" oszlop a Windows NT Magazine októberi számában az "Inside Win2K Reliability Enhancements, Part 3" (A Win2K megbízhatóságának fejlesztései, 3. rész) A háromrészes sorozat ezen harmadik része két olyan hatékony Win2K-funkciót ismertet, amelyek segítségével a fejlesztők és a rendszergazdák segítenek a hibás illesztőprogramok kitűzésében: az írás által védett kernelmemória és a Driver Verifier.

Az orosz olvasók most már a saját natív nevükben olvashatják a cikkeket. Tekintse meg a Windows NT Magazine orosz kiadását a következő címen: , és tekintse meg az első lefordított http://www.osp.ru/win2000/ NT Internals oszlopot: Inside the Boot Process (http://www.osp.ru/win2000/1999/10/59.htm). Köszönjük, Hogy Rouzanov tudatta velem ezt.

Augusztus elejétől az Windows NT Magazine cikkének online verziói csak előfizetők számára érhetők el, és a cikkek minden új problémáról online érhetők el. Ha még nem előfizetett, tekintse meg a következőt: előfizetési hivatkozás a http://www.sysinternals.com/publ.htm Systems Internals-előfizetési kedvezményért.

NEM ANNYIRA ÚJ DOLGOK

A WinObj hatékony eszköz a Windows NT/2K objektumnévtér felfedezéséhez. Az Objektum névtér egyike az NT/2K három névterének: az objektumnévtér, a beállításjegyzék névtere és a fájlrendszer névtere. A beállításjegyzék és a fájlrendszer névterei az Objektum névtérben található objektumokon keresztül szabadulnak fel. Amikor például egy Win32-program megnyitja a beállításkulcsot, a ADVAPI32.DLL kódtár átalakítja a nevet a névre, mielőtt a HKEY_LOCAL_MACHINE\Software\Microsoft\Registry\Machine\Software\Microsoft kernelszolgáltatást NtCreateKey hívja. Ha megnézi az objektumnévtér gyökerét a WinObjben, látni fog egy Registry nevű "kulcs" típusú objektumot. A beállításjegyzék neve megegyezik a kulcsnév első összetevőjével, így az NT/2K object Manager átadja a név többi részét () a kulcsobjektumot meghatározó \Machine\Software\Microsoft alrendszernek. A Konfigurációkezelő kernel alrendszere tartja karban a beállításjegyzéket és a kulcsobjektumokat, ezért a név többi részét elemezve megkeresi a kívánt kulcsot.

A WinObj használatával megismerheti az objektumnévteret, és megtekintheti vagy beállíthatja az objektumbiztonsági tulajdonságokat. A Winobj letöltése: http://www.sysinternals.com/winobj.htm. Az Object Manager-névteret és a WinObj-t az "Inside the Object Manager" (Az objektumkezelőn belül) 1997. októberi NT Internals (Belső NT) oszlopban tárgyalom. Kövesse az oszlop online verziójára mutató hivatkozást a következő oldalon: http://www.sysinternals.com/publ.htm.

BELSŐ HÍREK

MEGJELENT A WIN2K RC2 DDK

A Microsoft Device Driver Development Kit (DDK) Win2K RC2 kiadását itt töltheti le: http://www.microsoft.com/ddk/ddkRC2.htm. A csomagot ingyenesen letöltheti, vagy online is böngészheti a dokumentációt.

ÚJ WIN2K RC2 KERNEL API-K

Úgy tűnik, hogy a rendszer stabilizálja a legújabb Win2K kernelt. Az RC3-ban csak négy új, exportált kernel API van, nem pedig körülbelül egy tucat, amely (és még fél tucat eltűnt) jelent meg a 3. bétaverzióból az RC1-be. Az új függvények közül több is érdekes, ezért úgy döntöttünk, hogy dokumentálom őket. Az első a , és bár a prototípusa nem dokumentált, megtalálható az MmGetSystemRoutineAddress RC2 DDK ntddk.h fejlécfájljában:

NTKERNELAPI
PVOID
MmGetSystemRoutineAddress (
    IN PUNICODE_STRING SystemRoutineName
    );

A használata olyan egyszerű, amilyennek tűnik. Adja meg egy olyan függvény nevét, amely egy NTOSKRNL.EXE vagy HAL.DLL található, és vissza fogja kapni a belépési pontjának címét. Ez a függvény valójában használhatatlan a Win2K első kiadásában, de az úton nagyon hasznos lehet, és egy olyan függvény, amit a Microsoftnak az NT első kiadásában (3.1) is bele kellett volna foglalnia. A Win32-alkalmazások felhasználói területéhez hasonló ez a függvény lehetővé teszi, hogy az illesztő dinamikusan megállapítsa az GetProcAddress API rendelkezésre állását. Ha a Microsoft új API-kat ad hozzá a Win2K szervizcsomagjaihoz (és biztos vagyok benne, hogy fognak), akkor megírhatja az illesztőprogramokat, hogy kihasználják az API-k előnyeit, de a Win2K régebbi verziói esetében is, vagy ha olyan módban futnak, amelyben nem használják az API-kat. Ennek az illesztőprogramnak az a kulcsa, hogy a betöltés után ellenőrizheti az API-k jelenlétét. E funkció nélkül az illesztőnek statikusan kell összekapcsolni a használt függvényekkel, és ha az illesztőprogram betöltésekor a függvények nincsenek jelen, a kernelbetöltő egy csúnya hibát jelent a felhasználónak, és nem tudja betölteni az illesztőt.

A második új API a MmGetPhysicalMemoryPages . A prototípus az RC2 ntddk.h fájlban van, de nincs dokumentálva. Prototípusa a következő:

NTKERNELAPI
PPHYSICAL_MEMORY_RANGE
MmGetPhysicalMemoryRanges (
    VOID
    );

Hol PHYSICAL_MEMORY_RANGE van:

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

Ez a függvény olyan bejegyzések tömböt ad vissza, amelyek végén egy olyan bejegyzés van megjelölve, amely a és a PHYSICAL_MEMORY_RANGE 0 értékekkel BaseAddressNumberOfBytes rendelkezik. A MmGetSystemRoutineAddress -hez hasonló ez is egy elég egyszerű API. Ez visszaadja az összes olyan fizikai memória leírását, amelyről a Win2K tud. A Win2K támogatja a memória a és az API-kval történő, illetve azokkal történő, a gépről történő, illetve azokkal történő MmAddPhysicalMemoryMmRemovePhysicalMemory eltávolítását. Ez motiválja egy olyan API meglétét, amely lehetővé teszi a memóriatartományok lekérdezését. MmAddPhysicalMemory az RC1-ben és az MmRemovePhysicalMemory RC2-ben lett hozzáadva. Mindkét függvény prototípusa az ntddk.h fájlban is elérhető.

Mik a többi új RC2 API? PoShutdownBugCheck és RtlInvertRangeList. PoShutdownBugCheck A lehetővé teszi a rendszer összeomlását, és egy energiagazdálkodással kapcsolatos művelet, például a felfüggesztés elvégzését. Ezt néhány helyen az RC2 kernel használja. A tartományok általános kezdőpont-specifikációk, amelyek felhasználó által definiáltak, és számos kernel API támogatja a kezelésük, rendezésük és iteraikjuk iterait. A Win2K Plug-and-Play erőforrás-arbiterek a hardvererőforrás-követelmények nyomon követésére és rendszerezésre használják őket. Bár a tartománylista API-k nincsenek dokumentálva, az összes prototípusuk és struktúradefiníciójuk megtalálható az ntddk.h fájlban, így feltehetően az API-val kezelheti a saját kezdő orientált adatait.

A nem dokumentált API-k a későbbi hírlevelekben még szórakoztatóbbak.

SZOFTVERFEJLESZTÉS 99 KELET

A szoftverfejlesztés 1999-es keleti parti kiadása Washington D.C. november 8-tól 12-ig tart. Az utolsó napon három előadásokon vagyok: What's New in Windows 2000 For Developers, Inside the Windows NT/2000 Blue Screen és Inside Windows NT/2000 Networking (Az Windows 2000 for Developers újdonsága, az Windows NT/2000 Blue Screen és az Inside Windows NT/2000 Networking. Emellett Dave Inside Windows NT 2nd Edition írója és egy szomszédja (mindössze 20 percig él tőlem, és minden helyről, Danemet, CT-t) és én egy Windows NT/2K belső táblázatot tartunk. Együtt fogjuk megválaszolni az NT/2K belső Windows legnagyobb kérdéseit. Mondja el a hello-t, és említse meg a hírlevelet, én pedig egy ingyenes Systems Internals t-shirt-t adunk!

Keresse fel a szoftverfejlesztési webhelyet a következő helyen: http://www.sdexpo.com.

A DISKEDIT HASZNÁLATA

Lehet, hogy nem ismeri, de van egy lemezszerkesztő segédprogram a Windows NT-hez, amely a doS-hez használható, nagymértelmű Lemezszerkesztő stílusában. Mi több, a segédprogram a FAT és az NTFS fájlrendszert is érti, és ingyenes. Úgy tűnik, hogy a Microsoft véletlenül kiszállította a DiskEdit eszközt, amely egy belső hibakereső eszköznek kell lennie a fájlrendszer-csapatok számára az Windows NT 4.0 Service Pack 4 CD-n. A DiskEdit egy egyszerű felülettel rendelkezik, amely kis manuálisan dokumentálható, de most egy egyszerű útmutatóval fog kezdeni. Arra összpontosítok, hogy a DiskEdit használatával unravelem az NTFS fájlrendszerformátumot, mivel a DiskEdit az egyetlen nyilvánosan elérhető eszköz, amelyről tudom, hogy megértette az NTFS fájlrendszert.

Először be kell szereznie a DiskEditet a Service Pack 4 (SP4) CD-ROM-ról. Egyszerűen másolja az \i386 könyvtárból a merevlemezre. Ha a DiskEditet a Win2K alatt szeretné használni, létre kell hoznia egy privát könyvtárat, és a következő DLL-eket kell másolnia egy SP4 winnt\system32 könyvtárból (vagy SP4 CD-ről) ugyanoda, mint a DiskEdit: IFSUTIL.DLL, ULIB.DLL, UNTFS.DLL és UFAT.DLL. Most már elindíthatja a DiskEditet.

Ebben az útmutatóban hozzon létre egy TEMP nevű könyvtárat egy NTFS-meghajtó gyökerében, és hozzon létre egy OUT.TXT nevű fájlt abban a könyvtárban. Ehhez írja be a következő parancsot egy parancssori ablakba, jelenlegi könyvtárként pedig a TEMP könyvtárat: echo hello > out.txt . Válassza ki az új fájllal OUT.TXT meghajtót a DiskEdit (Lemez)File (Fájl) kiválasztásával| Nyissa meg a menüelemet, és írja be a meghajtó betűjelét az eredményül kapott párbeszédpanel Kötet neve mezőjébe. Ügyeljen arra, hogy a kettőspontot is tartalmazza, például: " d: ". Gyakorlatilag a DiskEdit összes funkcióját meg kell nyitnia egy meghajtón.

Az NTFS-meghajtó gyökérkönyvtárában OUT.TXT meg a OUT.TXT fájlt. Válassza az Olvasás menüpontot| NTFS-fájlrekord egy párbeszédpanel megnyitásához, amely lehetővé teszi bármely MFT-rekordbejegyzés megtekintését a számuk megadásával. Minden NTFS-meghajtó első 16 MFT-rekordbejegyzése fenn van tartva, és az előre definiált NTFS-metaadatfájloknak felelnek meg. A szám-hozzárendelések a következőek (vegye figyelembe, hogy a DiskEdit minden bemenetet hexadecimálisként értelmez):

        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)

Nézze meg ezeket az MFT-bejegyzéseket. Egy gyakori témát fog látni: ezek olyan attribútumokat tartalmaznak, mint a $INDEX_ROOT , a és a $FILE_NAME$DATA . Olyan attribútumban található, ahol a fájlspecifikus adatok vannak tárolva. Ha az attribútumadatok kis méretűek, az MFT-rekordban az adatok "helyi" adatokként vannak tárolva, és nagy méretű NTFS esetén a lemezen lévő fürtökön kívüli adatok nem helyi adatokként vannak tárolva.

Most adja meg az "5" számot a fájlszámként, és a gyökérkönyvtár fájlját fogja megtekinti. A gyökérkönyvtárban található fájlokat és könyvtárakat a könyvtár attribútumának, a könyvtár tartalmát rekordjainak attribútumának megtekintésével fogjuk $INDEX_ALLOCATION megnézzük. Válassza az Olvasás lehetőséget| NTFS-attribútum menübejegyzés, amely egy újabb párbeszédpanelt nyit meg. A DiskEdit megkülönbözteti a kis- és nagybetűket, ezért pontosan úgy írja be a következőket, ahogy a listában szerepel:

        Base Frs Number: 5

A Base Frs (Alap fájlrekordszegmens) az MFT-szám másik neve. Adja meg az 5 értéket, hogy be szeretne olvasni egy attribútumot a gyökérkönyvtárból.

        Attribute Type: $INDEX_ALLOCATION

Ez jelzi a DiskEdit számára, hogy be szeretné olvasni a könyvtár tartalomadatokat. Azt javasoljuk, hogy a lekért menüben válassza ki a kívánt attribútumot, mivel a DiskEdit nagyon válogatósan írja be az attribútumtípust.

        Attribute Name: $I30

Ha megtekinti a gyökérkönyvtár attribútumát, láthatja, hogy a " " a neveként szerepel a "" sorban, ezért ezt kell megadnia $INDEX_ALLOCATION$I30Type code, name attribútumnévként.

Nyomja le az OK gombot, és egy hexadecimális memóriaképet fog látni az attribútum tartalmáról. Valami érthetőbbet szeretnénk látni, ezért válassza a Nézet lehetőséget| NTFS-indexpuffer menüpont. Meg fog jelenni a könyvtár tartalmának listája. Görgessen végig a listán, amíg meg nem látja a " " TEMP nevű bejegyzést. Ha nem látja, akkor előfordulhat, hogy a bejegyzés a gyökérkönyvtár attribútumában, a könyvtárakhoz társított attribútumtípusban található, és annak értéke mindig $INDEX_ROOT az MFT-rekordban van tárolva. Az indexgyöker-bejegyzések és a foglalási bejegyzések együtt alkotják a könyvtár összes bejegyzését tároló B+ fastruktúrát. Ha meg kell tekintenie az attribútumot, csak kövesse az attribútum megtekintésének lépéseit, mint $INDEX_ROOT az attribútum $INDEX_ALLOCATION megtekintéséhez. Az indexpuffer görgetésekor két sornyi csillagot is előfordulhat: ezek jelölik az egyik indexpuffer végét és a következő elejét.

Miután megtalálta a TEMP könyvtár bejegyzését, jegyezze fel a fájlhivatkozását (FRS). Válassza az Olvasás lehetőséget| NTFS-fájlrekord, és írja be a TEMP fájlmegosztási (FRS) nevét. Most a TEMP könyvtár MFT-rekordját nézi. Szeretnénk megtalálni a OUT.TXT fájlt, ezért át kell nézni a TEMP tartalmát, hogy megtaláljuk. Tekintse meg a TEMP könyvtár (vagy ) attribútumát, váltson az adatok NTFS-indexpufferként való megtekintésére, és keresse meg $INDEX_ALLOCATION$INDEX_ROOT a OUT.TXT fájlt. Az attribútumválasztási párbeszédpanelen ne felejtse el megadni a TEMP fájlbeszúrásos fájlbeszúrás (FRS) értékét alapként. Ha most hozta létre a TEMP-et, az csak egy -t fog kapni (ha rosszul írja be azt, amit a DiskEdit üres hibapaneljeiben látni $INDEX_ROOT fog).

Ha megtalálta a megfelelő OUT.TXT és meghatározta, hogy a frS olvasást használ| NTFS-fájlrekord az MFT-bejegyzésének megnyitásához. Görgessen lefelé, amíg meg nem találja $DATA attribútumot. Most már a OUT.TXT adatait keresi. Mivel kis méretű fájlt készítettünk, az adatok az MFT-rekordban tárolódnak. Ha a DiskEdit OUT.TXT használatával próbálja megtekinteni az attribútumot, nem fog látni semmit, mivel a DiskEdit nem megfelelően mutatja a helyi adatokat (a DiskEdit egyik számos $DATA hibaa). Másolja tehát a szövegfájlt a következőbe: >\TEMP\ OUT.TXT . Most már kétféleképpen OUT.TXT a két módszer egyikével: az olvasással megvizsgálhatja az adatok elejének (vagy az összesnek a lemezen való összefüggő tárolása esetén| NTFS-fürt és az első "lcn" érték megadása, amely OUT.TXT "Extent List" attribútumában található, vagy használhatja az $DATA Olvasást| NTFS-attribútum, és adja meg a " " attribútumtípust, és semmit (például ne írjon be semmit ebbe a $DATA mezőbe) attribútumnévként.

A kiterjedési listák az attribútum nem helyi adatainak helyét írják le. A legfeljebb 16 fürt hosszúságú, összefüggő adatblokkokat egy egységlista-bejegyzés írja le. A extent list bejegyzés megadja a virtuális fürt számát (vcn), a logikai fürt számát (lcn) és a futtatás hosszát. A Vcn az a fürt abban a fájlban, amelyen a bejegyzés által leírt adatok elindulnak. Az LCN kijelöli a logikai fürtöt, ahol az adatok lemezen vannak tárolva, a futási út pedig az adott helyen található attribútumadatok bájtszáma (ne feledje, hogy a DiskEdit hexadecimális értékeket mutat).

A könyvtár tartalmának beolvasását OUT.TXT MFT-rekord megkeresését mutattam be. Van azonban egy parancsikon: válassza a Crack lehetőséget| NTFS elérési út, és írja be a TEMP\OUT.TXT. Meg fog jelenni a OUT.TXT FRS, és használhatja az Olvasást| NTFS-fájlrekord a jobb ugráshoz.

Ezzel elérkezek a DiskEdit bevezető végére. Javasoljuk, hogy a FAT- vagy NTFS-meghajtók tallózásával használja ezt a nem megfelelő eszközt. Nagyon valószínűtlen, hogy valaha is a DiskEdit használatával módosítja az adatokat, hogy kihozza a lemezt a elakadásból, de ha kíváncsi a lemezen lévő NTFS formátumra (a FAT formátum jól dokumentált), ez a tökéletes eszköz a vizsgálathoz.

MI LESZ A KÖVETKEZŐ?

WIN2K API-ROBBANÁS

Bár az RC2-ben csak 4 új exportált, kernel módú API van, a Microsoft által az NT 4.0 óta bevezetett api-k száma mind a kernelben, mind a win32-fájlmagban megőrzendő. A következő hónapban el tudom mondani, hogy pontosan hány új API található, és hol jelentek meg, és sajnos ugyanakkor azt is megadjuk az embereknek, akik úgy vélik, hogy a Win2K egy nagybajom, az alt.advocacy.linux Usenet-rants remekül néz ki.


Köszönjük, hogy elolvasta a belső rendszerek hírlevelet.

Published Wednesday, October 20, 1999 19:10 PM by ottoh

[Hírlevelek archívuma ^][ Volume 1, Number 4][Volume 2, Number 1 ]

[Hírlevelek archívuma ^][ Volume 1, Number 4][Volume 2, Number 1 ]

A rendszerek belső hírlevele, 1. kötet, 5. szám

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