• Cikk

[Hírlevelek archívuma ^][< 1. kötet, 2. szám][1. kötet, 4. >szám ]

The Systems Internals Newsletter Volume 1, Number 3

http://www.sysinternals.com
Copyright (C) 1999 Mark Russinovich

1999. június 19. – Ebben a kérdésben:

  1. A SYSTEMS INTERNALS ÚJDONSÁGAI

    • SDelete v1.1
    • Sztringek v2.0
    • LoggedOn
    • Filemon v4.13
    • DebugView/Enterprise kiadás v3.1
    • "NT-hálózatkezelésen belül"
    • Júniusi "NT Internals"
    • NTFrob-frissítés állapota
    • Nem annyira új dolgok

  2. BELSŐ HÍREK

    • Megjelent a Numega DriverStudio
    • Júniusi platform SDK elérhető
    • Win2K system file protector (SFP)
    • A hálózatról megnyitott fájlok bezárása

  3. MI VÁRHATÓ?

    • Egy "AWE"- néhány Win2K API

SZPONZOR: WINTERNALS SZOFTVER

A Systems Internals Hírlevél által szponzorált Winternals Software, a weben a http://www.winternals.com. A Winternals Software a Windows NT/2K fejlett rendszereszközök vezető fejlesztője és szolgáltatója. A Winternals szoftvertermékek közé tartozik a FAT32 a Windows NT 4.0-hoz, az ERD Commander (a Windows NT rendszerindító lemezes képessége) és az NTRecover.

A Winternals Software bejelenti a Regmon és a Filemon Enterprise kiadás kiadását. Ezek a segédprogramok biztosítják az ingyenes Filemon és Regmon összes funkcióját, és hozzáadják az alábbi hatékony funkciókat:

  • távoli Win9x/NT rendszereken végzett beállításjegyzék- és fájlrendszer-tevékenységek megtekintése
  • naplófájl kimenetének valós idejű naplózása egy fájlba
  • kimeneti sorok másolása a vágólapra
  • szűrőnek megfelelő vonalak kiemelése
  • a különböző számítógépek kimenetének egyidejű megtekintése
  • kimenet nyomtatása közvetlenül egy nyomtatóra
  • egyszerűen visszahívhatja az utolsó 5 szűrőkijelölést

Rendelési és díjszabási információk lekérése a következő címen: http://www.winternals.com.

Üdvözlök mindenkit!

Üdvözöljük a Systems Internals hírlevél harmadik kiadásában. A hírlevélnek jelenleg 4400 előfizetője van.

Az utolsó hírlevélben rámutattam, hogy a Microsoft hogyan végezte el a Halál kék képernyőjét, mivel tudjuk, hogy előre halad a Windows 2000 -re (Win2K). Az új Win2K Kék képernyő nem rendelkezik a Windows NT korábbi verzióinak kék képernyőjén található betöltött illesztővel és veremkép információval. Megkérdeztem, hogy találja-e a Microsoft által hasznosnak tartott információkat, és azt kívánom, hogy egyedül hagyják a dolgokat. A válasz gyakorlatilag egyhangú volt, és minden válaszadó (egy kivételével) azon gondolkodott, hogy miért a Microsoft a legalacsonyabb közös nevezőt választja. Íme egy tipikus vélemény, amelyet Tony Lavinio küldött be:

Tehát, más szóval, ez az ügyfél válasza, amelyre a Microsoft a következő döntésre alapoz:

"Nem értem, ezért rossznak kell lennie; hogy eltűnjön."

Miért nem távolítják el az egész képernyőt, és tesznek fel egy üzenetet a "Pull Plug, Reinsert Plug, Start Over"? Miért veszik el az egyiket a kevés nyom közül, ami arra utal, hogy a dolgok miért savanyúak?

Legalábbis korábban, ha vírusolvasó, töredezettségmentesítő vagy hibás illesztőprogram volt, akkor van egy pont, ahonnan elkezdhetjük a keresést.

Ha ez az eszköz csak 10 000-ből 1-nek segít, az NT üzembe helyezésének széles bázisával megéri. Különösen azért, mert 0,01% támogatja a jó részét a másik 99,99%.

Ki volt a magányos dissenter? Nem meglepő, hogy valaki a Microsofttól, aki a Kék képernyő összeomlási jelentéseit írja. Itt van a ferde a változás, ami megerősíti Tony spekuláció, hogy az oka:

A PSS NT telepítő csoportjában dolgozom az MS-nél (amely a kék képernyő hibaelhárítását kezeli). Biztosíthatom, hogy a legtöbb ember, akivel beszélek, nem tudom, mit tegyek a 4.0-s kék képernyő információival. Biztos vagyok benne, hogy látott egy stop 0xA a NAIFILTR.SYS-vel az egész veremben, amelyet a víruskereső frissítéséhez ismer, de a legtöbb ember nem teszi ezt a kapcsolatot, és valójában nem veszik észre, hogy a stop kód és a paramok hasznosak számukra. Kapcsolatok, akik megértik a kék képernyős adatok értelmezését, valószínűleg bosszankodnak, de sajnos kisebbségben vannak.

Ahogy az előző hírlevélben is említettem, úgy érzem, hogy a Microsoftnak tovább kell vinnie az NT 4.0 Kék képernyőt, megtartva a betöltött illesztőprogramok listáját és a veremképet. Azt is hiszem, hogy ők is, hogy a kék képernyő jobb azáltal, hogy több információt, nem kevesebb. Például miért nem jelenik meg a jelenleg végrehajtó folyamat neve az összeomlás időpontjában? Vagy több BugCheck-hívás is átadja a hibaelhárító címét, nem csak a hibás címet? A PSS fő oka, hogy olyan sok olyan ügyfélrel futott be, akik a Kék képernyővel kapcsolatban tanácstalanok, az, hogy a Microsoft soha nem írt dokumentációt arról, hogyan kell elolvasni. A felhasználói tudatlanság okának legalább egy része ezért a Microsoft saját vállán nyugszik.

Ha többet szeretne tudni a kék képernyők előfordulásáról és a (NT 4.) Kék képernyő, lásd az én 1997 decemberi cikk, "Inside the Blue Screen", a Windows NT Magazine (akkor kap a on-line verzió a http://www.sysinternals.com/publ.htm).

Mint általában, kérjük, adja át a hírlevelet a barátok, hogy úgy gondolja, lehet, hogy érdekes.

Thanks!

-Mark

A SYSTEMS INTERNALS ÚJDONSÁGAI

SDELETE V1.1

Az utolsó hírlevélben bevezettem a SDelete-t, egy biztonságos törlési segédprogramot, amellyel helyreállíthatatlanul megsemmisítheti a fájladatokat, valamint hogy megtisztítsa a lemez szabad területét a korábban törölt adatokból. A SDelete első verziója nem tudta biztonságosan felülírni a vele törölt fájlok nevét. A fájlok neve gyakran felfedi a bizalmas információkat, és ha a SDelete használatával töröl egy felfedő nevű fájlt, az felfedheti ezeket az információkat. Ennek a kiskapunak a kezelése érdekében frissítettem a SDelete-t, hogy ne csak biztonságosan írja felül a fájladatokat, hanem a fájlneveket is. A SDelete biztonságosan törli a fájlnevet úgy, hogy 26-szor átnevezi a fájlt, és a fájl nevének minden betűjét az ábécé egymást követő betűire cseréli, az "A"-ről a "Z"-re.

Töltse le a SDelete 1.1-et teljes forráskóddal: http://www.sysinternals.com/sdelete.htm.

SZTRINGEK V2.0

A végrehajtható fájlokban és DLL-ekben gyakran vannak olyan sztringek, amelyek felfedhetik a nem dokumentált beállításjegyzék-értékeket és hibaüzeneteket, amelyek a nem dokumentált funkciókra utalnak. Sajnos a Windows NT/2K rendszer DLL-jeinek és EXE-jeinek többsége Unicode karaktersztringek használatára van megírva, míg a hagyományos sztringkereső eszközök, például a Grep csak ASCII-sztringeket nyernek ki. Néhány évvel ezelőtt írtam a Strings segédprogram első verzióját, hogy bináris fájlokat vizsgálhassak ASCII- vagy Unicode-karaktersztringek alapján. Sokszor használtam már ezt az NT-belső kutatásaim során, hogy kiderítsem, mi az, amit a Microsoft nem dokumentál.

A sztringeknek azonban mindig volt egy nagy hibája, és ez volt az a hiba, amely miatt nem lehetett helyettesítő karaktereket megadni fájlkijelölőként, hogy több fájlt is beolvashass egy lövésben. Ezt a funkciót akartam, hogy például egy beállításjegyzék-érték nevének megadva könnyen megállapíthassam, hogy mely rendszer DLL-ekre hivatkoznak.

Végre frissítettem a sztringeket, hogy teljes helyettesítőkártya-fájlneveket vegyek fel, valamint hogy újra elővehessem a könyvtárakat. Ha egy helyettesítő kártya kifejezést ad meg, a sztringek automatikusan előtagot adnak a kimeneti soroknak a fájl nevével, amelyben egy sztring található, így a következőhöz hasonlót végezhet:

strings *.dll | grep SafeBoot

A kifejezés kimenetének megtekintése (a Grep egy verziója elérhető a Windows NT Resource Kit Posix segédprogramjaiban) tájékoztatja arról, hogy mely rendszer DLL-jei ellenőrzik a Széf Boot beállításkulcsot Windows 2000 rendszeren. A sztringek rendkívül hasznosak a Win2K rendszer DLL-jeinek, illesztőprogramjainak és végrehajtható fájljainak új beállításjegyzék-értékeinek megtekintéséhez. Sztringekkel hasonlítottam össze például az NT 4.0 SP4 TCP/IP veremben (tcpip.sys) hivatkozott beállításjegyzék-értékeket a Windows 2000 TCPIP-verem által hivatkozott értékekkel. Íme a Win2K TCPIP-veremének új értékeinek körülbelül fele (amelyek mindegyike asszum alatt található HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters):

ReservedPorts
DefaultGatewayMetric
InterfaceMetric
TempLeaseExpirationTime
TempIpAddress
TempMask
DhcpDefaultGateway
TcpWindowSize
TcpInitialRTT
TcpDelAckTicks
EnableTrafficControl
EnableTOSetting
MaxNormLookupMemory
MaxSendSegments
MaxFreeConnections
MaxFreeTWTcbs
FFPFastForwardingCacheSize

Nem várom, hogy a Microsoft dokumentálja a verem új konfigurációs paramétereit.

A Sztringek 2.0-s verziót innen töltheti le: http://www.sysinternals.com/misc.htm.

NAPLÓZVA

Szerette volna tudni, hogy ki jelentkezett be egy távoli NT-rendszerbe? Ha igen, töltse le a LoggedOnt. A LoggedOn egy egyszerű segédprogram, amelyből megtudhatja, hogy a rendszer milyen felhasználókat naplóz interaktívan a helyi számítógépre vagy egy távoli számítógépre, valamint azt, hogy milyen felhasználókat naplóznak erőforrás-kapcsolatokon keresztül (például fájl- vagy nyomtatómegosztás). Íme egy példa a LoggedOn kimenetre:

C:\>loggedon main

LoggedOn v1.0 - Logon Session Displayer
Copyright (C) 1999 Mark Russinovich
Systems Internals - http://www.sysinternals.com

Users logged on locally:
MAIN\Administrator

Users logged on via resource shares:
MAINDOM\MARK

A Windows NT és a Win2K nem biztosít olyan API-t, amellyel az alkalmazások megállapíthatják, hogy ki van bejelentkezve a számítógépre, de a LoggedOn ezt a rendszer beállításjegyzékfáiba HKEY\USERS betöltött beállításkulcsok megtekintésével határozza meg. Az interaktívan bejelentkezett felhasználók profiljai ebbe a kulcsba vannak betöltve, és a profilok nevei azonosítják a profil társított felhasználói fiókjának SID-azonosítóját (biztonsági azonosítóját). Ha például megnyitja a Regeditet, és az alatta HKEY_USERS keres, a következőhöz hasonlót fog látni:

HKEY_USERS\.DEFAULT\S-1-5-21-734676951-386466661-1233803906-500

Itt csak egy felhasználó van interaktívan bejelentkezve. A helyi vagy tartományi rendszergazdát is megadhatja, mert a relatív azonosító (relatív azonosító) 500, ami a rendszergazdai fiókok rid NT-tartaléka.

Ha olyan API-kat használ, amelyek lehetővé teszik az egyik rendszer számára egy másik rendszer beállításjegyzékének megtekintését, a LoggedOn beolvassa egy távoli számítógép HKEY_UStandard kiadás RS-kulcsát, és fióknevekké alakítja a talált SID-ket. Annak megállapításához, hogy ki jelentkezik be erőforrásmegosztáson keresztül, a LoggedOn az SDK-ban dokumentált NET API-t használja. A Net parancssori eszköz széles körben használja a NET API-t. A LoggedOn egy távoli rendszer beállításjegyzékéhez való hozzáférésének egyik mellékhatása, hogy a LoggedOnt futtató fiók mindig úgy jelenik meg, ahogy bejelentkezett egy távoli rendszerbe a LoggedOn kimenetében lévő erőforrás-megosztáson keresztül.

A LoggedOn teljes forráskóddal tölthető le: http://www.sysinternals.com/misc.htm.

FILEMON V4.13

A Filemon v4.13 nemrég jelent meg, egy frissítés, amely tükrözi a Windows NT filer illesztőprogramjának változásait, és kijavít egy véletlenül a 4.12-illesztőbe bevezetett hibát. A 4.13 szűrőillesztő a következő módosításokat hajtja végre:

  • az erőforrás-szinkronizálási típust használja egyes belső adatstruktúrák védelmére
  • kezeli az új Win2K IRP-t, IRP_MJ_PNP_POWER

Az erőforrás-szinkronizálás típusa gyakorlatilag visszavonva a Windows NT 4.0-s és a Win2K-eszközillesztő-fejlesztőkészletekben (DDK-kban). A tervezési útmutató nem is említi az erőforrásokat, míg a funkcióikat a "Vezetői támogatási rutinok" szakaszban található referencia tartalmazza. Az erőforrások olyan adatstruktúrák védelmének hasznos mechanizmusai, amelyek különböző szálakkal egyidejűleg olvashatók, de a frissítés során kizárólagos hozzáférést igényelnek egy száltól. Így ezek olvasói/írói zárolások, amelyeket az olvasók közös hozzáférésre és az írók kizárólagos hozzáférésére szereznek be. A fájlrendszer-illesztőprogramok széles körben használják az erőforrásokat, ezért helyénvalónak éreztem a Filemon frissítését, hogy szükség esetén használják őket.

A Filemon v4.13 az új IRP_MJ_PNP_POWER IRP-t is kezeli, így a Win2K alatt futtatott power és plug-and-play felhasználóbarát szűrőillesztő. Az ilyen típusú integrációs házirendek kezeléséhez a fájlrendszer szűrőillesztőjének egyetlen követelménye, hogy átadja azokat azoknak a fájlrendszer-eszközöknek, amelyhez a szűrő csatlakoztatva van.

A Filemon v4.13-at teljes forráskóddal töltheti le a http://www.sysinternals.com/filemon.htm.

DEBUGVIEW/Enterprise kiadás V3.1

A DebugView/Enterprise kiadás egy sokoldalú hibakeresési kimeneti monitor, amellyel rögzítheti a Win32-programok vagy kernelmódú eszközillesztők által a Win95, a Win98, a WinNT és a Win2K alatt létrehozott helyi vagy távoli hibakeresési kimenetet. Hasznossága korlátozott azokban a környezetekben, ahol a felhasználó összeomlást tapasztal egy eszközillesztő használatával, azonban – az összeomlás előtt a DebugView összes hibakeresési kimenete rögzít. A DebugView/Enterprise kiadás legújabb verziója a Windows NT/2K rendszeren kezeli ezt a problémát. Ha egy felhasználó egy eszközillesztő által generált kernel módú kimenetet rögzít, és a felhasználó konfigurálta az NT-t összeomlási memóriakép mentésére, akkor a DebugView/Enterprise kiadás kinyerheti a hibakeresési kimenetet a memóriaképfájlból, amikor a rendszer újraindul. A DebugView/Enterprise kiadás szerkesztésének használata|Az Összeomlási memóriakép menü kiválasztásával memóriaképet vizsgálhat a hibakeresési kimenethez. Ez a funkció lehetővé teszi, hogy a felhasználók egy szöveges fájlt küldjenek vissza, amely tartalmazza az illesztőprogram által generált hibakeresési kimenetet az összeomlás időpontjáig.

Töltse le a DebugView/Enterprise kiadás 3.1-et ahttp://www.sysinternals.com/debugview.htm.

"NT-HÁLÓZATKEZELÉSEN BELÜL"

Az 1999. márciusi Windows NT Magazine "NT Internals" oszlopom most már on-line. Ismerje meg az NT hálózati architektúráját felülről lefelé, beleértve az általa implementálandó API-kat, a protokollveremek API-kkal való felületét, valamint azt, hogy a hardvergyártók hogyan írnak hálózati illesztőprogramokat a protokollillesztők használatához. Emellett megismerkedhet a Win2K hálózatkezelésének néhány új funkciójával, beleértve a deszerializált NDIS-t és az ATM-támogatást.

Olvassa el az "Inside NT Networking" (Belső NT-hálózatkezelés) és más korábbi NT Internals-oszlopok on-line http://www.sysinternals.com/publ.htm.

JÚNIUSI "NT INTERNALS"

A Június részlet az én Windows NT Magazine oszlop a "Inside EFS, Part 1". Ez a cikk a Microsoft titkosító fájlrendszerének (EFS) architektúráját ismerteti, és részletes áttekintést nyújt a fájlok titkosítása során az EFS által követett lépésekről. Az EFS egy transzparens titkosítási lehetőséget biztosít a Win2K NTFS-meghajtók számára, és a Microsoft kifejezetten arra fejlesztette ki, hogy az NTFSDOS-eszköz képes legyen az NTFS-fájlok biztonsági szempontból való olvasására. Ez az oszlop három hónapon belül elérhető lesz online.

Két hírlevél ezelőtt beszéltem arról, hogy a titkosított fájlok biztonsági mentéséhez és visszaállításához szükséges EFS API-k visszavonásra kerülnek. Sajnos ezek az API-k még mindig nincsenek dokumentálva az MSDN aktuális kiadásában. Értesültem azonban arról, hogy a Microsoft elküldi a "Microsoft Confidential"-ként megjelölt dokumentációt partnereinek és a szoftvergyártók biztonsági mentésének. David Golds, a Microsoft fájlrendszer-programmenedzsere is előadást tartott a Win2K fájlrendszer-fejlesztéseiről a Legutóbbi Microsoft TechEd konferencián Dallasban. A bemutatóban azokat a diákat, amelyeken az on-line http://www.teched99.com/slides/1-337.pptmegtekinthető, megemlíti, hogy a biztonsági mentési API-k nincsenek visszavonva, de azt is megteheti, hogy beszúrja a dokumentációt. Sajnos az e-mail címe nem szerepel a diákon.

Keresse fel http://www.winntmag.com a Windows NT Magazine előfizetési adatait.

NTFROB FRISSÍTÉS ÁLLAPOTA

Az NTFrob egy segédprogram, amelyet néhány évvel ezelőtt kiadottam, amely lehetővé teszi az előtér- és háttérfolyamatok kvantumhosszainak pontos konfigurálását az NT 4.0-n. Az NTFrob az NT-kernelen belül módosítja az adatstruktúrát, így kifejezetten Service Pack-specifikus. Az NT 4.0 Service Pack 5 kiadása óta olyan lekérdezésekkel voltam meglepve, amelyek azt kérdezik, mikor fogom kiadni az NTFrob 1.5-ös verziót, az SP 5 frissítést. A válasz az, hogy a frissítés hamarosan el fog készülni – arra várok, hogy a Microsoft az MSDN-előfizetők számára sp5-öt biztosítson, beleértve a hibakeresési információkat is. Hibakeresési információkra van szükségem az új szervizcsomagok NTFrob frissítéséhez.

Az NTFrobot az NT 4 SP0-4-hez a következő címen töltheti le: http://www.sysinternals.com/ntfrob.htm.

NEM ÚJ DOLGOK

Néhány hónappal ezelőtt kiadtam egy Win9x/NT/2K soros és párhuzamos portmonitort a Systems Internalsben. A Portmon segítségével pontosan láthatja, hogy az alkalmazások hogyan használják a soros és párhuzamos portokat, beleértve az általuk küldött és fogadott adatokat is. Segítségével megtekintheti a betárcsázós munkameneteket, a laplink soros kapcsolatait vagy a nyomtatótevékenységeket. A Portmon hatalmas sikert aratott, és a közelmúltban 5 csillagot gyűjtött be a Ziff-Davis szoftverkönyvtárából, a lehető legmagasabb minősítést. Az 5 csillagot szerzett rendszerek belső eszközei közé tartozik a Regmon, az NTFSDOS és a BlueSave.

Portmon letöltése: http://www.sysinternals.com/portmon.htm.

BELSŐ HÍREK

DRIVERSTUDIO RELEA STANDARD KIADÁS D

A CompuWare NuMega Labs kiadásában megjelent a DriverStudio, amely átfogó eszközkészlet a Windows 9x/NT/2K eszközillesztő-fejlesztők számára. Tartalmazza a SoftICE 4.0-t, az illesztőprogramokhoz készült BoundsCheckert, a VtoolsD-t, a DriverAgentet, a DriverWorkset, a FieldAgentet az illesztőprogramokhoz, a jövőben pedig a TrueTime-ot az illesztőprogramokhoz, a TrueCoverage-et pedig az illesztőprogramokhoz. Mint mondtam a legutóbbi hírlevélben, ez egy elengedhetetlen fejlesztői eszközkészlet. A NuMega egy "Driver Central" nevű, fejlesztőközpontú eszközillesztő-webhelyet is elindított. http://www.numega.com/drivercentral/default.asp.

JUNE PLATFORM SDK RELEA STANDARD KIADÁS D

A Microsoft Platform SDK júniusi kiadását innen töltheti le: http://www.msdn.microsoft.com/developer/sdk/platform.asp.

WIN2K SYSTEM FILE PROTECTOR (SFP)

Az NT-rendszerek rendszergazdáinak és felhasználóinak egyik legnagyobb fogása az NT "DLL Hell" tulajdonsága. A DLL az oka annak, hogy számos alkalmazás frissíti a kulcsrendszer DLL-jeit az általuk csomagolt verziókkal. Az alkalmazások általában azért teszik ezt, hogy garantálhassák a megfelelő működést, azonban ha lecserélnek egy DLL-t, akkor sokszor nem kompatibilis verziók telepítésével vagy egy DLL régebbi verzióra való "frissítésével" szakítják meg a többi alkalmazást.

A Microsoft megoldotta a DLL-verziószámozási problémákat a Win2K-ban a System File Protector (SFP) bevezetésével. Valójában a neve hamarosan windowsos fájlvédőre (WFP) változik, de a 3. bétaverziótól (2031-es build) még mindig SFP. Az SFP egy sfc.dll nevű DLL-ben van implementálva, amelyet a Winlogon-folyamat (winlogon.exe) betölt a rendszer indításakor. Az SFP körülbelül 3000 szabványos Win2K rendszer DLL-jét, végrehajtható fájlokat (.exe), telepítési fájlokat (.inf), illesztőprogramokat (.sys) és betűtípusfájlokat (.fon) tartalmaz, amelyek 30-40 különböző könyvtárban vannak telepítve. Az SFP inicializálásakor egy változásértesítési könyvtárműveletet hajt végre minden olyan könyvtáron, amely az általa védett fájlokat tartalmazza. Amikor egy fájl illetéktelen módosítását észleli, megjelenik egy párbeszédpanel, amely tájékoztatja az aktuális felhasználót, egyenletesen ír az eseménynaplóba, és lecseréli a módosított fájlt a(z) %systemroot%\system32\dllcache fájlban tárolt biztonsági másolatra. Ha az SFP által a dllcache-ben kereshető biztonsági mentési fájl hiányzik, vagy azt is módosították, az SFP egy friss másolatot kér le a Win2K telepítési adathordozójáról.

Ha meg szeretné tekinteni, hogy az SFP mely fájlokat védi, a hírlevélben máshol említett Strings segédprogrammal a(z) %systemroot%\system32\sfc.dll fájlba beágyazott Unicode-sztringneveket törölheti.

A rendszerfájlok frissítésére az egyetlen segédprogram a hotfix.exe, a szervizcsomagok (update.exe), a frissítési telepítések és a Win2K Update szolgáltatás. Hogyan kerülik meg ezek az eszközök az SFP-t? Ideiglenesen letiltják az exportált SfcTerminateWatcherThread SfcTerminateWatcherThread függvény meghívásával, és gondoskodnak arról, hogy tükrözzék a dllcache alkönyvtár frissítéseit. Vegye figyelembe, hogy a Win2K megköveteli, hogy az összes rendszerfájlt digitálisan aláírja a Microsoft, ezért általában nem lehet frissíteni egy rendszerfájlt egy tetszőleges saját verzióval.

A Win32-programok a FindFirstChangeNotification és a FindNextChangeNotification Win32 API-k használatával figyelhetik a címtárak változásait. Ezek az API-k azonban egyszerűen tájékoztatják az alkalmazásokat arról, hogy valami megváltozott; nem közlik az alkalmazással, hogy pontosan mi változott. Ezért egy alkalmazásnak egy teljes könyvtárat kell beolvasnia annak megállapításához, hogy mely fájlok vagy alkönyvtárak módosulhattak. Az SFP az NT Native API-val hajt végre egy változásértesítési kérelmet, amelyben az NT pontosan közli, hogy milyen fájlok vagy alkönyvtárak változnak a figyelt könyvtárakban. Az SFP függvény neve NtNotifyChangeDirectoryFile, és az NT natív API-jának 90%-ához hasonlóan visszavonásra kerül. Keressen egy kisalkalmazást a Systems Internalsben a közeljövőben, amely bemutatja, hogyan használhatja az NtNotifyChangeDirectoryFile fájlt.

A szeptemberi "NT Internals" oszlopom, az "Inside Win2K Reliability Enhancements, Part 2" (Belső win2K megbízhatósági fejlesztések, 2. rész) című cikk részletesebben ismerteti az SFP-t.

A HÁLÓZATRÓL MEGNYITOTT FÁJLOK BEZÁRÁSA

Az egyik leggyakoribb kérdés, amit a Systems Internals látogatóitól kapok, az a "hogyan zárhatom be a felhasználók által a hálózatról megnyitott fájlokat?" Ha egy felhasználó távolról megnyitott egy fájlt vagy könyvtárat, akkor nem lehet helyileg törölni, átnevezni vagy frissíteni a fájlt vagy könyvtárat. Hasonló kérdés: "Hogyan látni, hogy a felhasználók milyen fájlokat nyitottak meg a hálózatról?" Mindkét kérdésre választ ad a Windows NT/2K-hoz tartozó Net parancssori segédprogram. A megnyitott fájlok megtekintéséhez egyszerűen írja be a "net file" kifejezést. Ekkor megjelenik a megnyitott fájlnevek, a megfelelő fájlnév-azonosítók és a megnyitott fájlokat tartalmazó felhasználók neve. A megnyitott fájlok egyikének bezárásához írja be a következőt net file <id> /close: A helyileg megnyitott fájlok megtekintéséhez használhatja az NTHandle- vagy a HandleEx-eszközöket.

A Net-parancs fájlmegtekintési és -záró funkciójának alapjául tartozó API-k a Platform SDK-ban és az MSDN-kódtárban vannak dokumentálva. A NetFileEnum API-val számba lehet adni a megnyitott fájlokat, a NetFileClose API-t pedig egy megnyitott fájl bezárásához. Az API-k valójában lehetővé teszik a távoli kiszolgálókon megnyitott fájlok számbavételét, amit a Net parancs nem engedélyez.

Az NTHandle a következő címen érhető el: http://www.sysinternals.com/nthandle.htm. A HandleEx a következő címen érhető el: http://www.sysinternals.com/handleex.htm.

MI VÁRHATÓ?

EGY "AWE"- NÉHÁNY WIN2K API

A Win2K egy új, AWE (Address Window Extensions) nevű API-t vezet be, amelyet a memóriaigényes alkalmazások nagy mennyiségű fizikai RAM közvetlen elérésére és kezelésére használhatnak – akár több mint 3 GB-ot, a RAM felső határát, amelyet egy Windows NT-alkalmazás képes kezelni a virtuális címtérben. Valójában, ha egy x86 rendszer P Standard kiadás (Page Size Extensions) és több mint 4 GB RAM, az alkalmazás használhatja AWE kihasználni az összes számítógép memóriáját. Ez az API ezért ideális memóriaigényű alkalmazásokhoz, például webkiszolgálókhoz és adatbázis-kiszolgálókhoz. Legközelebb elmondom, hogyan használhatja az API-kat, mind a Win32-alkalmazásokból, mind az eszközillesztőkből.

Míg én vagyok a témában memória-éhes alkalmazások, itt van egy tipp, aki ír egy alkalmazást, amely gyorsítótárazza a fájlokat (például egy webkiszolgáló). A Windows NT Cache Manager a Gyorsítótár memóriáját 256 KB-os, "nézeteknek" nevezett tárolóhelyekre osztja. Ha egy 256 KB-nál kisebb méretű fájl gyorsítótárazva van, a Cache Managernek továbbra is hozzá kell rendelnie a fájlt egy teljes 256 KB-os ponthoz, ami azt jelenti, hogy a gyorsítótár virtuális memóriájának egy része elvesztek. Így általában hatékonyabb a 256 KB-nál kisebb méretű fájlok gyorsítótárazása a saját alkalmazás virtuális memóriájában, és a fájlrendszerre támaszkodni a 256 KB-nál nagyobb méretű fájlok gyorsítótárazásához. Az IIS 5.0 ezt a trükköt használja.

Köszönjük, hogy elolvasta a Systems Internals Hírlevél.

Közzétéve: 1999. június 19. szombat, 19:14

[Hírlevelek archívuma ^][< 1. kötet, 2. szám][1. kötet, 4. >szám ]