[Archivio newsletter ^] [< Volume 2, Numero 2] [Volume 2, Numero 4 >]
Newsletter Systems Internals Volume 2, Numero 3
http://www.sysinternals.com
Copyright © 2000 Mark Russinovich
14 giugno 2000 - In questo numero:
EDITORIALE
NOVITÀ DI SYSINTERNALS
- Regmon v4.25
- ListDlls v2.22
- TDImon v1.0
- AutoRuns v1.1
- LDMDump v1.0
- Rubriche di Internals di aprile/giugno
INFORMAZIONI SU INTERNALS
- Cronologia build di Windows NT
- Risoluzione timer di Windows NT/2000
- Modifica del mapping della tastiera
- Mapping della memoria di sistema sicuro
- Registrazione nascosta del file system di Windows 98
- WinDev '00 West
SVILUPPI FUTURI
- Chiavi del Registro di sistema di Windows 98 "Secure"
SPONSOR: WINTERNALS SOFTWARE
La newsletter Systems Internals è sponsorizzata da Winternals Software, presente sul Web all'indirizzo http://www.winternals.com. Winternals Software è il principale sviluppatore e provider di strumenti avanzati di sistemi per Windows NT/2K. I prodotti di Winternals Software includono FAT32 per Windows NT 4.0, ERD Commander Professional Edition (funzionalità avanzata del disco di avvio per Windows NT), e Remote Recover.
Lo strumento TCPView Pro appena rilasciato consente di monitorare l'attività TCP/IP nei sistemi Windows NT 4.0, Windows 2000 e Windows 95/98. A differenza degli strumenti di monitoraggio TCP/IP predefiniti forniti con Windows, ad esempio netstat, TCPView Pro mostra il processo associato a ogni indirizzo TCP/IP, semplificando l'individuazione dell'applicazione responsabile di connessioni e attività specifiche. TCPView Pro offre una visualizzazione dinamica e una visualizzazione statica. La visualizzazione statica mostra gli indirizzi IP locali attualmente aperti, il processo associato a ogni endpoint e l'indirizzo IP remoto a cui è connesso un endpoint. La visualizzazione dinamica, non disponibile con altre utilità, consente di visualizzare l'attività TCP/IP per processo in tempo reale.
Per informazioni sui prezzi e scaricare una versione di valutazione di 14 giorni, vedere http://www.winternals.com/products/tcpview.shtml.
Ciao a tutti.
Benvenuti nella newsletter System Internals. La newsletter conta attualmente 22.000 abbonati.
Dave Solomon e io siamo nelle fasi finali della realizzazione di "Inside Windows 2000, 3rd Ed.", che significa che il libro sarà disponibile a metà agosto anziché alla fine di luglio (non sarebbe un prodotto Microsoft senza un piccolo ritardo sulla data prevista). Ora che il libro è finalizzato, posso dare alcune anticipazioni sugli argomenti trattati. In primo luogo, include circa il 50% di più contenuti rispetto all'edizione precedente, con quattro capitoli completamente nuovi. Ecco il sommario:
- Introduzione
- Architettura
- Meccanismi di sistema
- Avvio e arresto
- Meccanismi di gestione
- Processi e thread
- Gestione della memoria
- Sicurezza
- Sistema di I/O
- Storage
- Gestore della cache
- File system
- Rete
Come la seconda edizione, il libro è ricco di esperimenti che illustrano i concetti descritti. Il libro include anche un CD con una copia dell'intero sito Web SysInternals, oltre ad alcuni degli strumenti usati negli esperimenti.
Due strumenti che ho scritto appositamente per il libro sono stati accolti molto positivamente dai revisori del libro. Il primo si chiama LiveKD e consente di eseguire uno qualsiasi dei debugger del kernel di Windows 2000 (i386kd, kd, WinDbg) in un sistema live. Ciò significa che si avvia LiveKD, specificando il debugger che si vuole ospitare, quindi si accede al debugger e tutti i comandi del debugger sono disponibili come quando si esegue il debug di un dump di arresto anomalo del sistema. Praticamente tutti gli esperimenti basati sul debugger nel libro possono essere eseguiti usando LiveKD e quindi non è necessario usare un secondo sistema o un cavo seriale per eseguirli.
Il secondo strumento è un'estensione del monitoraggio delle prestazioni che consente di visualizzare i valori in tempo reale di qualsiasi variabile del kernel. Se si vuole monitorare la quantità di pool non di paging in uso con PerfMon, ad esempio, è necessario selezionare la variabile MmAllocatedNonPagedPool.
Comunicherò in questa newsletter la data di uscita del libro, ma è possibile preordinarlo ora attraverso il collegamento ad Amazon.com nella pagina www.sysinternals.com/links.htm. Come di consueto, invito tutti i lettori a condividere la newsletter con gli amici che potrebbero trovarla interessante.
Grazie.
- Mark
NOVITÀ DI SYSTEMS INTERNALS
REGMON V4.25
L'ultimo aggiornamento allo strumento di monitoraggio del Registro di sistema Regmon include il supporto di Windows 2000 per il nuovo tipo di query KeyNameInformation per i servizi di sistema di ZwEnumerateKey e ZwQuerykey. Questa funzionalità non viene esportata per l'uso da parte delle applicazioni Win32, ma viene usata dalle funzioni del Registro di sistema in ADVAPI32 come parte dell'uso del sistema di hive del Registro di sistema di registrazione classi per utente.
Esistono due modi in cui le applicazioni Win32 in Windows 2000 possono aprire la parte Registrazione classi del Registro di sistema: possono specificare HKEY_CLASS_ROOT o possono specificare HKLM\Software\Classes. Il primo restituisce un handle alla chiave della classe per utente combinata con la chiave della classe globale e il secondo restituisce un handle solo alle informazioni globali. La funzione del Registro di sistema ADVAPI32 può determinare solo quale dei due l'utente ha specificato esaminando il nome sottostante dell'handle della chiave del Registro di sistema passato da un utente, da qui il requisito per il nuovo tipo di query. Per altre informazioni, vedere la documentazione dell'SDK su RegOpenKeyEx.
È possibile scaricare Regmon v4.25 all'indirizzo http:www.sysinternals.com/regmon.htm.
ListDLLs V2.22
Quando uno sviluppatore crea una libreria a collegamento dinamico (DLL), indica al linker l'"indirizzo di base" della DLL, ovvero l'indirizzo per cui il linker crea le informazioni sull'indirizzo relativo nel file di immagine della DLL. Se una DLL viene caricata in un indirizzo diverso dal relativo indirizzo di base, il caricatore deve correggere tutti gli indirizzi relativi nell'immagine della DLL caricata per tenere conto della differenza.
Queste correzioni, o rilocazione, possono aumentare il tempo di avvio di un'applicazione, quindi gli sviluppatori vogliono ovviamente impedire il verificarsi delle rilocazioni. Tuttavia, è noioso esaminare l'output di un programma come ListDLLs, confrontando gli indirizzi di caricamento con l'indirizzo di base. Nella versione 2.22, ListDLLs accetta quindi una nuova opzione, -r, che indica le DLL rilocate nel relativo output.
È possibile scaricare ListDLLs v2.22 all'indirizzo http://www.sysinternals.com/listdlls.htm.
TDImon v1.0
TDImon è l'ultimo della potente suite di strumenti di monitoraggio di SysInternals, che mostra l'attività TCP e UDP nel sistema non appena avviene. Lo strumento prende il nome dal fatto che monitora l'attività TCP e UDP a livello dell'interfaccia dello stack TCP/IP e tale interfaccia viene chiamata Transport Driver Interface (TDI). Tutte le attività TCP e UDP dell'applicazione e del driver devono passare attraverso questa interfaccia, che significa che nessuna attività TCP o UDP può passare da TDImon senza essere rilevata.
TDIMon condivide la stessa interfaccia grafica utente dei cugini, Filemon, Regmon, Portmon e DebugView e, come questi altri strumenti di monitoraggio, mostra i nomi dei processi che eseguono attività, i timestamp e dispone di funzionalità di filtro ed evidenziazione. Questo rende TDIMon uno strumento ideale per la risoluzione dei problemi di rete per gli amministratori e uno strumento di debug TCP/IP per gli sviluppatori di applicazioni. TDImon funziona in Windows 95, 98, NT 4 e Windows 2000.
È possibile scaricare TDImon v1.0 all'indirizzo http://www.sysinternals.com/tdimon.htm.
LDMDump v1.0
Windows 2000 include un nuovo formato di partizionamento denominato partizionamento virtuale che supera alcuni degli svantaggi del partizionamento in stile MS-DOS usato da tutti i sistemi operativi Windows fino ad ora questto momento. Un componente denominato Gestione dischi logici (LDM) gestisce i volumi nei dischi formattati con partizioni virtuali, denominate dischi dinamici (i dischi con il partizionamento in stile MS-DOS sono chiamati dischi di base). Oltre a essere più affidabili in virtù del mirroring delle partizioni che implementano, i dischi dinamici hanno il vantaggio di creare volumi con più partizioni senza dover riavviare il sistema affinché vengano riconosciuti e montati dai driver del file system.
Microsoft non ha documentato il formato del database di partizionamento di Gestione dischi logici (LDM) e poiché la tecnologia è stata concessa in licenza da Veritas, che ha usato lo stesso database nel software di gestione dei volumi UNIX, i contratti di licenza potrebbero impedire a Microsoft di documentarlo. Forse potrà essere disponibile un'interfaccia IOCTL Win32 per Gestione dischi logici (LDM), ma nel frattempo ho individuato il formato e scritto uno strumento denominato LDMDump che è possibile usare per guardare all'interno del database di un disco dinamico. LDMDump mostra approssimativamente le stesse informazioni dello strumento DmDiag di Windows 2000 Resource Kit, ma LDMDump presenta le informazioni in (credo) un modo molto più pulito. Al momento non offro codice sorgente per questo strumento, ma coloro che sono interessati a ottenere una licenza per le proprie applicazioni possono contattarmi.
È possibile trovare altre informazioni sul database di Gestione dischi logici (LDM) nella mia rubrica "Inside Storage, Part 2" in Windows 2000 Magazinehttp://www.sysinternals.com/publ.htm.
È possibile scaricare LDMDump v1.0 all'indirizzo http://www.sysinternals.com/ldmdump.htm.
AutoRuns V1.1
È possibile che si abbia già familiarità con AutoRuns, che è stato rilasciato negli ultimi due mesi. AutoRuns mostra le impostazioni di esecuzione automatica per ogni posizione nei file del Registro di sistema e INI in cui tali informazioni sono specificate (o così pensavamo). Il feedback degli utenti ci ha indicato alcune posizioni in cui mancava AutoRuns e questa versione più recente ora le mostra.
È possibile scaricare AutoRuns v1.1 all'indirizzo http://www.sysinternals.com/misc.htm.
RUBRICHE DI INTERNALS DI GIUGNO/LUGLIO
Qualcuno si è mai chiesto esattamente quali sono le differenze tra i servizi Win32 e le applicazioni Win32 standard? O perché la sequenza di avvio o arresto di NT richiede così tanto tempo. Rispondo a queste domande e ad altre ancora nella mia serie di giugno/luglio in due parti sui servizi Win32 in Windows 2000 Magazine.
Nella parte 1 viene illustrata in modo dettagliato la struttura di un servizio Win32, spiegando come accetta i comandi dalle applicazioni client. Si procede quindi con la descrizione di Gestione controllo servizi (SCM), responsabile della gestione dei servizi Win32, tra cui l'avvio e l'arresto. Nella parte 2 viene completata la descrizione del processo di avvio del servizio, che avviene durante l'avvio del sistema e quindi spiego come Gestione controllo servizi arresta i servizi. Vengono anche illustrati i miglioramenti apportati da Microsoft a Gestione controllo servizi in Windows 2000 con un approfondimento sullo strumento SrvAny Resource Kit.
I sottoscrittori di Windows 2000 Magazine possono leggere le rubriche online all'indirizzo http://www.sysinternals.com/publ.htm.
INFORMAZIONI SU INTERNALS
CRONOLOGIA BUILD DI WINDOWS NT
Come illustrato nelle newsletter precedenti, il numero di build per Windows NT (ora Windows 2000) aumenta ogni giorno quando il team delle build genera una nuova build con le sincronizzazioni del codice del giorno. Usando i miei vecchi CD delle versioni beta e Release Candidate e con l'aiuto di altri utenti che hanno usato Windows NT più a lungo di quanto abbia fatto io, ho compilato un elenco dei numeri di build che corrispondono alle versioni pubbliche (versioni beta, Release Candidate e versioni complete). Si noti che le date sono le date della build, non la data di rilascio della build. Ad esempio, la build finale di Win2K, 2195, è stata realizzata nel mese di dicembre, ma è stata rilasciata al pubblico nel mese di febbraio.
| Creazione | Rilascio | Data |
|---|---|---|
| 297 | PDC | 1992 |
| 340 | NT 3.1 Beta 1 | Ottobre 1992 |
| 397 | NT 3.1 Beta 2 | Marzo 1993 |
| 511 | NT 3.1 | Luglio 1993 |
| 611 | NT 3.5 Beta 1 | Aprile 1994 |
| 683 | NT 3.5 Beta 2 | Giugno 1994 |
| 756 | NT 3.5 RC 1 | Agosto 1994 |
| 807 | NT 3.5 | Settembre 1994 |
| 944 | NT 3.51 Beta 1 | Febbraio 1995 |
| 1057 | NT 3.51 | Maggio 1995 |
| 1234 | NT 4.0 Beta 1 | Gennaio 1996 |
| 1314 | NT 4.0 Beta 2 | Maggio 1996 |
| 1381 | NT 4.0 | Luglio 1996 |
| 1671 | NT 5.0 Beta 1 | Settembre 1997 |
| 1877 | NT 5.0 Beta 2 | Settembre 1998 |
| 1946 | Win2K RC0 di Beta 3 | Dicembre 1998 |
| 2000.3 | Win2K RC1 di Beta 3 | Marzo 1999 |
| 2031 | Win2K Beta 3 | Aprile 1999 |
| 2072 | Win2K RC1 | Luglio 1999 |
| 2128 | Win2K RC2 | Settembre 1999 |
| 2183 | Win2K RC3 | Novembre 1999 |
| 2195 | Win2K | Dicembre 1999 |
RISOLUZIONE TIMER DI WINDOWS NT/2000
Sebbene Windows NT/2000 fornisca servizi, tra cui QueryPerformanceCounter, che consentono di misurare i tempi fino alla risoluzione del contatore di cicli Pentium, i relativi servizi di temporizzazione degli intervalli presentano una risoluzione leggermente inferiore. Infatti, la risoluzione timer predefinita corrisponde all'intervallo di clock di sistema, ovvero 10 ms nei sistemi uniprocessore x86 (in genere 7,5 ms o 15 ms nei sistemi SMP). Le applicazioni possono usare le funzioni timer multimediali nello spazio utente per aumentare la risoluzione a 1 ms, ma i driver non ci sono per risoluzioni più elevate, almeno fino a Windows 2000.
Windows 2000 introduce una nuova funzione DDK, ExSetTimerResolution, che i driver possono usare per ridurre l'intervallo del timer di sistema a 1 ms. Per sapere cosa accade dietro le quinte dei timer multimediali e ExSetTimerResolution, vedere "Inside Windows NT High Resolution Timers" all'indirizzo http://www.sysinternals.com/timer.htm.
MAPPING DI MEMORIA DI SISTEMA SICURO
Poiché si sta parlando delle nuove funzioni del kernel di Windows 2000 per sviluppatori di driver, vale la pena citare MmGetSystemAddressForMdlSafe. Nelle versioni precedenti di Windows NT uno sviluppatore di driver che voleva ottenere un puntatore dello spazio degli indirizzi di sistema per il buffer di un utente o una parte di memoria fisica doveva passare un MDL (Elenco descrittore di memoria) che descriveva il buffer fisico a MmGetSystemAddressForMdl.
La creazione di un mapping virtuale nello spazio indirizzi del sistema usa la risorsa denominata Voci tabella pagine di sistema, in cui è necessaria una voce tabella pagine di sistema per ogni pagina fisica mappata. Purtroppo, le voci tabella pagine di sistema sono risorse limitate e possono esaurirsi se i driver eseguono il mapping di grandi quantità di memoria. Cosa accade quando MmGetSystemAddressForMdl non riesce a ottenere le Voci tabella pagine di sistema necessarie? Si potrebbe pensare che faccia qualcosa di utile, come restituire un oggetto NULL come indirizzo virtuale mappato. Ma no, rinuncia e il sistema mostra una schermata blu. Questo comportamento si riflette negativamente sul driver che effettua la richiesta.
MmGetSystemAddressForMdlSafe di Windows 2000 fa quello che avrebbe dovuto fare MmGetSystemAddressForMdl: restituisce un valore NULL se non sono presenti voci tabella pagine di sistema sufficienti per creare il mapping per il buffer. Usare questa funzione per evitare un dump imbarazzante che punta al driver. Se è presente un driver in esecuzione in NT 4 e Windows 2000, vale la pena rilasciare due versioni diverse, una per ogni piattaforma, in modo da poter sfruttare questa nuova API in Windows 2000.
MODIFICA DEL MAPPING DELLA TASTIERA
Quelli come me hanno iniziato a lavorare su una tastiera UNIX in cui era presente un tasto CTRL nella posizione ora occupata dal tasto BLOC MAIUSC sulle tastiere per PC. Per migliorare la velocità di battitura e imparare qualcosa sullo sviluppo di driver per i dispositiv in Windows 9x e Windows NT, uno dei miei primi progetti di driver in entrambi questi sistemi operativi è stata l'implementazione di un driver per la modifica del mapping della tastiera. La versione per Windows 9x è disponibile all'indirizzo http://www.sysinternals.com/c2cap95.htm e la versione per Windows NT/2K è disponibile all'indirizzo http://www.sysinternals.com/ctrl2cap.htm.
In Windows NT/2K è disponibile un'alternativa all'uso di un driver di filtro tastiera. Tramite la definizione di nuove voci di mapping per i codici tasto nel Registro di sistema, è possibile riprogrammare completamente il comportamento della tastiera. In effetti, Windows 2000 Resource Kit include uno strumento denominato RemapKey che consente di scambiare i tasti usando una rappresentazione grafica della tastiera. Questo articolo nel sito Web di Microsoft illustra lo strumento di modifica del mapping della tastiera e il relativo funzionamento: http://www.microsoft.com/HWDEV/input/W2kscan-map.htm. Si noti che lo strumento funziona anche su NT 4.
Si supponga di non avere Windows 2000 Resource Kit e di non voler spendere denaro per acquistarlo (da parte mia consiglio questo acquisto, in quanto include numerosi strumenti di tutti i tipi con la relativa documentazione). In questo caso, è possibile modificare manualmente il mapping della tastiera. L'articolo di Microsoft citato sopra indica il formato della chiave del Registro di sistema in cui il driver della tastiera cerca i codici di mapping (HKLM\ SYSTEM\CurrentControlSet\Control\Keyboard Layout\Scancode Map) e questo articolo, anch'esso di Microsoft, indica i codici tasto corrispondenti: http://www.microsoft.com/hwdev/download/desinit/scancode.zip.
Se occorre semplicemente scambiare il tasto CTRL con il tasto BLOC MAIUSC (si noti che la mia tastiera esclude completamente il tasto BLOC MAIUSC dal momento che non lo uso mai), è possibile copiare il testo seguente (senza i separatori "----") in un file (assegnandogli un nome simile a swapcaps.reg) e fare doppio clic sul file. Le impostazioni verranno importate nel Registro di sistema e diventeranno effettive al riavvio successivo.
REGEDIT4
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
"Scancode Map"=hex:00,00,00,00,00,00,00,00,03,00,00,00,3a,00,1d,00,1d,00,3a,00,\
00,00,00,00
Se si vuole annullare il mapping, è sufficiente eliminare il valore del mapping del codice tasto dal Registro di sistema e riavviare.
REGISTRAZIONE NASCOSTA DEL FILE SYSTEM DI WINDOWS 98
Se qualcuno ha mai provato a esplorare la directory di sistema di Windows 98, avrà notato una sottodirectory denominata \Windows\Applog. All'interno di questa directory è probabile che siano presenti file con nomi corrispondenti a quelli delle applicazioni eseguite di recente ed estensioni come LGC e LGD. Se si apre uno dei file in Blocco note sarà possibile visualizzare una traccia dell'attività del file system, completa di nomi di file, offset e chiamate aperte e chiuse. Si tratta di un virus che genera questi log o è un'utilità segreta inclusa in Windows 98 che segnala a Microsoft i modelli di utilizzo dell'applicazione? Nessuno dei due (in caso contrario, questo argomento sarebbe citato nella stampa commerciale, non nella newsletter SysInternals). Fa parte della funzionalità "che carica le applicazioni usate più di frequente con una velocità maggiore fino al 36%" di Windows 98.
A causa della voce Taskmon in HKLM\Software\Microsoft\Windows\CurrentVersion\Run, Windows 98 avvia un programma del servizio denominato Taskmon all'avvio. Taskmon carica un VxD denominato FioLog (\Windows\System\FioLog.Vxd) per installare un hook di attività del file system per visualizzare l'utilizzo dei file durante l'avvio dell'applicazione. Taskmon monitora l'attività del file system di tutte le applicazioni durante l'avvio, ad eccezione di quelle elencate in HKLM\Software\Microsoft\Windows\CurrentVersion\Taskmon\ExcludeApps. FioLog registra l'attività del file system di avvio dell'applicazione nella directory Applog. I file di log creati iniziano con l'estensione LGA. Non è chiaro come determina quando eliminare un log e quando crearne uno nuovo per un'applicazione con una nuova estensione con l'ultima lettera incrementata. Ecco una parte di un file di log di esempio:
{
o da3034d0 d000 "C:\WINDOWS\NOTEPAD.EXE"
R da3034d0 0 40
R da3034d0 80 f8
R da3034d0 80 1c0
R da3034d0 7000 1000
R da3034d0 6000 e00
o da2b2610 156000 "C:\WINDOWS\SYSTEM\SHELL32.DLL"
R da2b2610 83000 1000
o da2b2f40 45110 "C:\WINDOWS\SYSTEM\SHLWAPI.DLL"
R da2b2f40 3c000 1000
R da2b2f40 3c000 1000
...
Le righe sono suddivise in quattro campi: la prima è il codice dell'operazione, dove o sta per apertura, R sta per lettura e C sta per chiusura. Non verrà visualizzata una lettera W (per la scrittura) perché FioLog registra solo le operazioni di lettura durante l'avvio dell'applicazione per ottimizzarlo. Il secondo campo è il puntatore del file interno. Il terzo e il quarto campo devono essere interpretati in base al codice dell'operazione della riga. Se il codice dell'operazione è R il terzo campo è l'offset del file e il quarto campo è la lunghezza della lettura. Tuttavia, se il codice dell'operazione è o il terzo campo è il flag aperto e il quarto è il nome del file aperto. Nella traccia di esempio l'apertura di notepad.exe restituisce il puntatore del file da3034d0, che è usato nelle operazioni di lettura successive.
Quando si avvia un'operazione di deframmentazione, il programma Defrag.Exe esegue un programma denominato CvtApLog (\Windows\System\Cvtaplog.exe) per elaborare i file di log. CvtApLog usa una DLL denominata ClusAlgo.Dll (\Windows\System\Clusalgo.dll) per determinare il posizionamento ottimale del cluster in base ai file di log letti e registra queste informazioni in file denominati \Windows\Applog\Applog.d* che guidano il processo di deframmentazione. CvtApLog genera anche un file denominato \Windows\Applog\Optlog.txt che riepiloga le ottimizzazioni dell'avvio dell'applicazione dettate dai file di log. Ecco il contenuto parziale di un file Optlog.txt:
Program Launch Optimization Log - Created Tue Jun 13 11:42:52 2000
Programs Eligible for Optimization:
Ord Flag ProgName Uses LastExecDate Program Path
1 RUNDLL32 65 2000.06.13 C:\WINDOWS\RUNDLL32.EXE
2 ATIPTAAB 31 2000.06.13 C:\WINDOWS\SYSTEM\ATIPTAAB.EXE
3 NOTEPAD 22 2000.06.13 C:\WINDOWS\NOTEPAD.EXE
4 PING 9 2000.06.10 C:\WINDOWS\PING.EXE
…
17 IEXPLORE 2 2000.06.01 C:\PROGRAM FILES\INTERNET EXPLORER\IEXPLORE.EXE
Programs Ineligible for Optimization:
Ord Flag ProgName Uses LastExecDate Program Path
18 S GREP 5 2000.06.13 C:\BIN\GREP.EXE
19 S STRINGS 12 2000.06.13 C:\BIN\STRINGS.EXE
20 S ATI2CWXX 31 2000.06.13 C:\WINDOWS\SYSTEM\ATI2CWXX.EXE
Control Parameters:
Use app profile = Yes
Minimum log size = 1000
Maximum no use days = 90
Maximum apps = 50
Flags for Ineligible Programs:
S = Log size smaller than <Minimum log size>
U = Program not used for more than <Maximum no use days>
P = No profile for program
E = Associated program no longer exists
D = Log deleted (may be combined with one of the above)
La capacità di Windows 98 di spostare le parti dei file usati durante l'avvio di un'applicazione in un'area contigua su disco è la tecnologia concessa in licenza da Intel a Microsoft (per una conferma, eseguire manualmente Defrag.exe e verrà visualizzato il testo "Intel Application Launch Accelerator").
WINDEV '00 WEST
L'evento WinDev '00 East ha avuto luogo la scorsa settimana con una partecipazione record di 660 persone (tutte quelle che l'hotel poteva ospitare). I relatori presenti alla conferenza rappresentano i nomi più importanti in ogni area dello sviluppo di Windows, tra cui Don Box, il guru di COM, e gli esperti di driver Jamie Hanrahan e Brian Catlin. Le mie sessioni hanno riguardato "Windows 2000 Internals", "Driver avanzati", "Driver del file system Windows NT/2000" e "Server cluster".
Per coloro che non hanno potuto partecipare, c'è una seconda possibilità. WinDev '00 West si terrà a Santa Clara, CA dall'11 al 15 settembre, con la partecipazione degli stessi relatori. Presenterò le stesse sessioni, e come a WinDev East, regalerò T-shirt SysInternals ai partecipanti che rispondono alle mie domande o che pongono domande particolarmente interessanti. Altre informazioni sono disponibili all'indirizzo http://www.butrain.com/windev/west/default.htm.
SVILUPPI FUTURI
CHIAVI DEL REGISTRO DI SISTEMA DI WINDOWS 98 "SECURE"
Anche se il Registro di sistema di Windows 98 non supporta la sicurezza, Microsoft ha implementato un meccanismo per la definizione delle chiavi del Registro di sistema nascoste. Quale applicazione usa questa tecnologia invisibile? Internet Explorer, naturalmente. La prossima volta spiegherò quali sono le chiavi Internet Explorer nasconde e come Windows 98 le implementa.
Grazie per aver letto la newsletter Systems Internals.
Pubblicata da ottoh mercoledì 14 giugno 2000 alle 19:08
[Archivio newsletter ^] [< Volume 2, Numero 2] [Volume 2, Numero 4 >]