Sysinternals Newsletter Vol. 1, No. 3 - Sysinternals

[Arsip Buletin ^] [< Volume 1, Nomor 2] [Volume 1, Angka 4 >]

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

19 Juni 1999 - Dalam masalah ini:

APA YANG BARU DI INTERNAL SISTEM
- SDelete v1.1
- String v2.0
- LoggedOn
- Filemon v4.13
- DebugView/EE v3.1
- "Di dalam Jaringan NT"
- Juni "Internal NT"
- Status Pembaruan NTFrob
- Hal-Hal Yang Tidak Begitu Baru
BERITA INTERNAL
- Numega DriverStudio Dirilis
- SDK Platform Juni Tersedia
- Pelindung File Sistem Win2K (SFP)
- Menutup File yang Dibuka dari Jaringan
APA YANG AKAN TERJADI
- API Win2K "AWE"-beberapa

SPONSOR: PERANGKAT LUNAK WINTERNALS

Buletin Internal Sistem disponsori oleh Winternals Software, di Web di http://www.winternals.com. Winternals Software adalah pengembang dan penyedia alat sistem canggih terkemuka untuk Windows NT/2K. Produk Perangkat Lunak Winternals termasuk FAT32 untuk Windows NT 4.0, ERD Commander (kemampuan boot-disk untuk Windows NT), dan NTRecover.

Winternals Software mengumumkan rilis Regmon dan Filemon Enterprise Editions. Utilitas ini menyediakan semua fungsionalitas Filemon dan Regmon freeware, dan menambahkan fitur canggih ini:

lihat Registri dan aktivitas sistem file yang berlangsung pada sistem Win9x/NT jarak jauh
output log ke file secara real-time
salin baris output ke clipboard
sorot baris yang cocok dengan filter
melihat output dari komputer yang berbeda secara bersamaan
cetak output langsung ke printer
mudah mengingat 5 pilihan filter terakhir Anda

Mendapatkan informasi pemesanan dan harga di http://www.winternals.com.

Halo semuanya,

Selamat datang di edisi ketiga buletin Systems Internals. Buletin saat ini memiliki 4400 pelanggan.

Di buletin terakhir saya menunjukkan bagaimana Microsoft telah melakukannya dengan Blue Screen of Death seperti yang kita tahu itu bergerak maju ke Windows 2000 (Win2K). Win2K Blue Screen baru tidak memiliki informasi driver dan stack dump yang dimuat yang ada di Blue Screen dari versi Windows NT sebelumnya. Saya bertanya apakah Anda menemukan informasi yang telah dilucuti Microsoft berguna dan berharap mereka telah meninggalkan hal-hal sendirian. Responsnya hampir bulat, dengan setiap responden tunggal (kecuali satu) bertanya-tanya mengapa Microsoft mencari penyebut umum terendah. Berikut adalah pendapat khas, yang dikirim oleh Tony Lavinio:

Jadi, dengan kata lain, ini adalah respons pelanggan bahwa Microsoft mendinginkan keputusan mereka tentang:

"Saya tidak mengerti, jadi itu harus buruk; Buatlah pergi.

Mengapa mereka tidak hanya menghapus seluruh layar, dan memasang pesan yang mengatakan "Pull Plug, Reinsert Plug, Start Over"? Mengapa mereka mengambil salah satu dari beberapa petunjuk yang kita miliki mengapa hal-hal menjadi asam?

Setidaknya sebelumnya, jika itu adalah pemindai virus atau defragmenter atau driver buggy, kita akan memiliki titik dari mana untuk mulai mencari.

Jika alat ini hanya membantu 1 dari 10.000 dari kita, dengan basis luas penyebaran NT, itu sepadan. Terutama karena kami .01% mendukung bagian yang baik dari 99,99% lainnya.

Siapa pembuangan kesepian? Tidak terlalu mengherankan bahwa seseorang dari Microsoft yang medan laporan crash Layar Biru. Berikut adalah sipit mereka pada perubahan, yang mengkonfirmasi spekulasi Tony tentang alasan untuk itu:

Saya bekerja di grup Penyiapan NT di PSS di MS (yang menangani pemecahan masalah layar biru). Saya dapat meyakinkan Anda bahwa sebagian besar orang yang saya ajak bicara tidak tahu apa yang harus dilakukan dengan informasi pada layar biru 4.0. Saya yakin jika Anda melihat pemberhentian 0xA dengan NAIFILTR.SYS di seluruh tumpukan yang Anda tahu untuk memperbarui antivirus Anda, tetapi kebanyakan orang tidak membuat koneksi itu, dan benar-benar mereka tidak menyadari bahwa kode berhenti dan param berguna bagi mereka. Orang yang memahami cara menginterpretasikan data layar biru mungkin akan kesal, tetapi sayangnya mereka adalah minoritas.

Seperti yang saya sebarkan di buletin terakhir, saya merasa bahwa Microsoft harus membawa Layar Biru NT 4.0 ke depan, menjaga daftar driver yang dimuat dan stack dump. Saya juga berpikir bahwa mereka dapat membuat Layar Biru lebih baik dengan memberikan lebih banyak informasi, tidak kurang. Misalnya, mengapa tidak menampilkan nama proses yang sedang dijalankan pada saat crash? Atau minta lebih banyak panggilan BugCheck meneruskan alamat kesalahan, bukan hanya alamat yang salah? Alasan utama PSS bertemu dengan begitu banyak pelanggan yang tidak tahu tentang Layar Biru adalah bahwa Microsoft tidak pernah menulis dokumentasi tentang cara membacanya. Setidaknya bagian dari kesalahan atas ketidaktahuan pengguna oleh karena itu berada di bahu Microsoft sendiri.

Jika Anda ingin tahu lebih banyak tentang bagaimana Layar Biru terjadi dan apa yang ada di (NT 4.) Blue Screen, lihat artikel Desember 1997 saya, "Inside the Blue Screen", from Windows NT Magazine (Anda bisa mendapatkan versi on-line dari http://www.sysinternals.com/publ.htm).

Seperti biasa, berikan buletin kepada teman-teman yang menurut Anda mungkin menarik.

Terima kasih!

-Tanda

APA YANG BARU DI INTERNAL SISTEM

SDELETE V1.1

Di buletin terakhir saya memperkenalkan SDelete, utilitas penghapusan aman yang dapat Anda gunakan untuk menghancurkan data file secara tidak dapat diambil, serta untuk membersihkan ruang kosong disk dari data yang dihapus sebelumnya. Versi pertama SDelete tidak dapat menimpa nama file yang Anda hapus dengan aman. Nama file sering mengungkapkan informasi sensitif, dan menggunakan SDelete untuk menghapus file dengan nama yang terungkap dapat membiarkan informasi tersebut terekspos. Untuk mengatasi celah ini, saya telah memperbarui SDelete untuk tidak hanya menimpa data file dengan aman, tetapi juga nama file. SDelete menghapus nama file dengan aman dengan mengganti nama file 26 kali, mengganti setiap huruf dalam nama file dengan huruf alfabet berturut-turut, dari 'A' menjadi 'Z'.

Unduh SDelete v1.1 dengan kode sumber lengkap di http://www.sysinternals.com/sdelete.htm.

STRINGS V2.0

Executable dan DLL sering memiliki string yang disematkan di dalamnya yang dapat mengungkapkan nilai Registri yang tidak terdokumentasi dan pesan kesalahan yang mengisyaratkan fungsionalitas yang tidak terdokumentasi. Sayangnya, sebagian besar DLL dan EXE sistem Windows NT/2K ditulis untuk menggunakan string karakter Unicode, sedangkan alat pencarian string tradisional seperti Grep hanya mengekstrak string ASCII. Saya menulis versi pertama utilitas String saya beberapa tahun yang lalu untuk memindai file biner untuk string karakter ASCII atau Unicode. Saya telah menggunakannya berkali-kali dalam penelitian internal NT saya untuk membantu mencari tahu hal-hal yang tidak didokumentasikan Microsoft.

String selalu memiliki kelemahan utama, meskipun, dan itu adalah ketidakmampuannya untuk mengambil ekspresi wild-card sebagai penentu file sehingga Anda dapat memindai beberapa file dalam satu bidikan. Saya menginginkan fitur ini sehingga, mengingat nama nilai Registri misalnya, saya dapat dengan mudah menentukan DLL sistem mana yang mereferensikannya.

Akhirnya, saya telah memperbarui String untuk mengambil nama file wild-card lengkap, serta untuk direktori berulang. Jika Anda menentukan String ekspresi kartubebas secara otomatis mengawali baris output dengan nama file tempat string ditemukan, sehingga Anda dapat melakukan sesuatu seperti ini:

strings *.dll | grep SafeBoot

Melihat output ekspresi ini (versi Grep tersedia di utilitas Windows NT Resource Kit Posix) memberi tahu Anda TENTANG DLL sistem mana yang memeriksa kunci SafeBoot Registry pada Windows 2000. String juga sangat berguna untuk melihat nilai Registri baru yang digunakan OLEH DLL sistem Win2K, driver, dan executable. Misalnya, saya menggunakan String untuk membandingkan nilai Registri yang direferensikan dalam tumpukan TCP/IP NT 4.0 SP4 (tcpip.sys) dengan yang direferensikan oleh tumpukan TCPIP Windows 2000. Berikut adalah sekitar setengah nilai yang baru untuk tumpukan TCPIP Win2K (yang semuanya saya asumsikan terletak di bawah HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters):

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

Saya tidak akan menahan napas menunggu Microsoft mendokumentasikan semua parameter konfigurasi baru tumpukan.

Anda dapat mengunduh String v2.0 di http://www.sysinternals.com/misc.htm.

LOGGEDON

Pernahkah Anda ingin tahu siapa yang masuk ke sistem NT jarak jauh? Jika demikian, maka Anda harus mengunduh LoggedOn. LoggedOn adalah utilitas sederhana yang akan memberi tahu Anda pengguna apa yang masuk secara interaktif ke komputer lokal atau yang jarak jauh, serta pengguna apa yang masuk melalui koneksi sumber daya (misalnya berbagi file atau printer). Berikut adalah contoh output LoggedOn:

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

Windows NT dan Win2K tidak menyediakan API yang dapat digunakan aplikasi untuk menentukan siapa yang masuk ke komputer, tetapi LoggedOn menentukan ini dengan melihat kunci Registri yang dimuat ke pohon Registri sistem HKEY\USERS . Profil setiap pengguna yang masuk secara interaktif dimuat ke dalam kunci ini, dan profil memiliki nama yang mengidentifikasi SID (ID Keamanan) akun pengguna terkait profil. Misalnya, jika Anda membuka Regedit dan melihat di bawah HKEY_USERS Anda akan melihat sesuatu seperti:

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

Di sini, hanya satu pengguna yang masuk secara interaktif. Anda dapat memberi tahu administrator lokal atau domainnya karena RID (ID Relatif) adalah 500, yang merupakan cadangan RID NT untuk akun administrator.

Dengan menggunakan API yang mengizinkan satu sistem untuk melihat ke Registri sistem lain, LoggedOn membaca kunci HKEY_USERS komputer jarak jauh dan mengonversi SID yang ditemukannya menjadi nama akun. Untuk menentukan siapa yang masuk melalui berbagi sumber daya LoggedOn menggunakan NET API, yang didokumenkan dalam SDK. Alat baris perintah Net memanfaatkan NET API secara ekstensif. Efek samping LoggedOn mengakses Registri sistem jarak jauh adalah bahwa akun yang Anda jalankan LoggedOn masuk akan selalu muncul sebagai masuk ke sistem jarak jauh melalui berbagi sumber daya di output LoggedOn.

Anda dapat mengunduh LoggedOn dengan kode sumber lengkap di http://www.sysinternals.com/misc.htm.

FILEMON V4.13

Filemon v4.13 baru saja dirilis, pembaruan yang mencerminkan perubahan pada driver filer Windows NT dan memperbaiki bug yang secara tidak sengaja saya masukkan ke driver 4.12. Driver filter 4.13 memiliki perubahan ini:

ini menggunakan jenis sinkronisasi Sumber Daya untuk melindungi beberapa struktur data internalnya
ini menangani IRP Win2K baru, IRP_MJ_PNP_POWER

Jenis sinkronisasi Sumber Daya hampir tidak terdokumentasi di Kit Pengembangan Driver Perangkat (DDK) Windows NT 4.0 dan Win2K. Panduan Desain bahkan tidak menyebutkan Sumber Daya, sementara fungsinya didokumenkan dalam Referensi di bawah bagian "Rutinitas Dukungan Eksekutif". Sumber daya adalah mekanisme yang berguna untuk melindungi struktur data yang dapat dibaca secara bersamaan oleh utas yang berbeda, tetapi memerlukan akses eksklusif oleh utas selama pembaruan. Dengan demikian, mereka adalah kunci pembaca/penulis yang diperoleh untuk akses bersama oleh pembaca dan akses eksklusif oleh penulis. Driver sistem file memanfaatkan Sumber Daya secara ekstensif, jadi saya merasa tepat untuk memperbarui Filemon untuk menggunakannya jika sesuai.

Filemon v4.13 juga menangani IRP IRP_MJ_PNP_POWER baru sehingga merupakan driver filter yang ramah plug-and-play dan daya saat berjalan di bawah Win2K. Satu-satunya persyaratan driver filter sistem file dalam menangani RUN jenis ini adalah meneruskannya ke perangkat sistem file tempat filter dilampirkan.

Anda dapat mengunduh Filemon v4.13 dengan kode sumber lengkap di http://www.sysinternals.com/filemon.htm.

DEBUGVIEW/EE V3.1

DebugView/EE adalah monitor output debug serbaguna yang dapat Anda gunakan untuk menangkap output debug lokal atau jarak jauh yang dihasilkan oleh program Win32 atau driver perangkat mode kernel di bawah Win95, Win98, WinNT, dan Win2K. Kegunaannya terbatas di lingkungan di mana pengguna mengalami crash menggunakan driver perangkat, namun - semua output debug DebugView ditangkap sebelum crash hilang. Versi terbaru DebugView/EE mengatasi masalah ini pada Windows NT/2K. Jika pengguna menangkap output mode kernel yang dihasilkan oleh driver perangkat dan pengguna telah mengonfigurasi NT untuk menyimpan crash dump, maka DebugView/EE dapat mengekstrak output debug dari file cadangan saat sistem reboot. Menggunakan Edit DebugView/EE|Proses pemilihan menu Crash Dump agar memindai cadangan memori untuk output debug. Fitur ini memungkinkan pengguna mengirimi Anda kembali file teks yang berisi output debug yang dihasilkan driver Anda hingga saat crash.

Unduh DebugView/EE v3.1 di http://www.sysinternals.com/debugview.htm.

"JARINGAN NT DALAM"

Kolom "NT Internal" Majalah Windows NT Maret 1999 saya sekarang on-line. Pelajari tentang arsitektur jaringan NT dari atas ke bawah, termasuk API apa yang diterapkannya, bagaimana protokol menumpuk antarmuka dengan API, dan bagaimana vendor perangkat keras menulis driver jaringan untuk bekerja dengan driver protokol. Selain itu, cari tahu tentang beberapa fitur baru jaringan Win2K, termasuk dukungan NDIS dan ATM yang dideserialisasi.

Baca "Di dalam Jaringan NT" dan kolom Internal NT sebelumnya lainnya secara on-line di http://www.sysinternals.com/publ.htm.

JUNI "INTERNAL NT"

Angsuran Juni dari kolom Majalah Windows NT saya adalah "Inside EFS, Bagian 1". Artikel ini menjelaskan arsitektur Sistem File Enkripsi Microsoft (EFS), dan membawa Anda menelusuri langkah-langkah terperinci yang diikuti EFS saat mengenkripsi file. EFS menyediakan fasilitas enkripsi transparan untuk drive Win2K NTFS dan Microsoft mengembangkannya secara khusus untuk mengatasi kemampuan alat NTFSDOS kami untuk membaca file NTFS tanpa memperhatikan keamanannya. Kolom ini akan tersedia secara on-line dalam tiga bulan.

Dua buletin yang lalu saya berbicara tentang bagaimana API EFS yang diperlukan untuk mencadangkan dan memulihkan file terenkripsi tidak terdokumentasi. Sayangnya, API ini masih belum didokumentasikan dalam edisi MSDN saat ini. Namun, saya telah diberi tahu bahwa Microsoft mengirim dokumentasi, yang ditandai sebagai "Microsoft Confidential", kepada mitranya dan untuk mencadangkan vendor perangkat lunak. Selain itu, David Golds, Manajer Program Sistem File di Microsoft, menyajikan pembicaraan tentang peningkatan sistem file untuk Win2K pada konferensi Microsoft TechEd baru-baru ini di Dallas. Dalam presentasi, slide yang dapat Anda lihat secara on-line di http://www.teched99.com/slides/1-337.ppt, ia menyebutkan bahwa API cadangan tidak terdokumentasi tetapi Anda dapat mengganggunya dari Anda menginginkan dokumentasi. Sayangnya, alamat emailnya tidak tercantum di slide.

Kunjungi http://www.winntmag.com untuk informasi langganan Windows NT Magazine.

STATUS PEMBARUAN NTFROB

NTFrob adalah utilitas yang saya rilis beberapa tahun yang lalu yang memungkinkan Anda untuk secara tepat mengonfigurasi panjang kuantum proses latar depan dan latar belakang pada NT 4.0. NTFrob memodifikasi struktur data internal ke kernel NT, sehingga sangat khusus Paket Layanan. Sejak rilis NT 4.0 Service Pack 5 saya telah didelegasikan dengan kueri yang menanyakan kapan saya akan merilis NTFrob v1.5, pembaruan SP 5. Jawabannya adalah bahwa pembaruan akan datang - Saya menunggu Microsoft menyediakan pelanggan MSDN dengan SP5, termasuk informasi debug. Saya memerlukan informasi debug untuk memperbarui NTFrob untuk Paket Layanan baru.

Anda dapat mengunduh NTFrob untuk NT 4 SP0-4 di http://www.sysinternals.com/ntfrob.htm.

HAL-HAL YANG TIDAK BEGITU BARU

Beberapa bulan yang lalu saya merilis seriAl Win9x/NT/2K dan pemantau port paralel di Systems Internals. Portmon memungkinkan Anda untuk melihat dengan tepat bagaimana aplikasi berinteraksi dengan port serial dan paralel, termasuk data apa yang mereka kirim dan terima. Anda dapat menggunakannya untuk menonton sesi dial-up, koneksi serial laplink, atau aktivitas printer. Portmon telah menjadi hit besar, dan baru-baru ini mengumpulkan 5 bintang dari Ziff-Davis' Software Library, peringkat tertinggi mungkin. Alat Internal Sistem lainnya yang telah mendapatkan bintang 5 termasuk Regmon, NTFSDOS, dan BlueSave.

Unduh Portmon di http://www.sysinternals.com/portmon.htm.

BERITA INTERNAL

DRIVERSTUDIO DIRILIS

NuMega Labs CompuWare telah merilis DriverStudio, toolkit komprehensif untuk pengembang driver perangkat Windows 9x/NT/2K. Ini termasuk SoftICE 4.0, BoundsChecker untuk Driver, VtoolsD, DriverAgent, DriverWorks, FieldAgent untuk Driver, dan di masa depan akan menambahkan TrueTime untuk Driver dan TrueCoverage untuk Driver. Seperti yang saya katakan di buletin terakhir, ini adalah toolkit pengembang yang harus dimiliki. NuMega juga telah meluncurkan situs web berorientasi pengembang driver perangkat yang disebut "Driver Central" - http://www.numega.com/drivercentral/default.asp.

SDK PLATFORM JUNI DIRILIS

Anda dapat mengunduh rilis Juni SDK Platform Microsoft sekarang di http://www.msdn.microsoft.com/developer/sdk/platform.asp.

PELINDUNG FILE SISTEM WIN2K (SFP)

Salah satu keluhan terbesar administrator dan pengguna sistem NT adalah "DLL Hell" NT. DLL hell adalah hasil dari banyak aplikasi yang memperbarui DLL sistem kunci dengan versi yang dibundelnya. Aplikasi biasanya melakukan ini sehingga mereka dapat menjamin bahwa mereka bekerja dengan benar, namun, ketika mereka mengganti DLL, mereka berkali-kali merusak aplikasi lain dengan menginstal versi yang tidak kompatibel, atau bahkan "memperbarui" DLL ke versi yang lebih lama.

Microsoft telah mengatasi masalah penerapan versi DLL di Win2K dengan pengenalan System File Protector (SFP). Sebenarnya, namanya akan segera berubah menjadi Windows File Protector (WFP), tetapi per Beta 3 (build 2031) masih SFP. SFP diimplementasikan dalam DLL bernama sfc.dll yang dimuat proses Winlogon (winlogon.exe) saat sistem melakukan booting. SFP mencakup daftar bawaan sekitar 3000 DLL sistem Win2K standar, file executable (.exe), file penginstalan (.inf), driver (.sys) dan font (.fon) yang diinstal dalam 30-40 direktori berbeda. Ketika SFP menginisialisasi, SFP menjalankan operasi direktori change-notify pada setiap direktori yang berisi file yang dilindunginya. Ketika mendeteksi perubahan dengan file, kotak dialog muncul yang menginformasikan pengguna saat ini, menulis bahkan ke log peristiwa, dan mengganti file yang dimodifikasi dengan cadangan yang disimpan di %systemroot%\system32\dllcache. Jika file cadangan yang dicari SFP di dllcache hilang atau juga telah dirusak, SFP mengambil salinan baru dari media penginstalan Win2K.

Untuk melihat file apa yang dilindungi SFP, Anda dapat menggunakan utilitas String yang disebutkan di tempat lain dalam buletin ini untuk mencadangkan nama string Unicode yang disematkan dalam %systemroot%\system32\sfc.dll.

Satu-satunya utilitas yang dapat memperbarui file sistem adalah hotfix.exe, paket layanan (update.exe), penginstalan peningkatan, dan layanan Pembaruan Win2K. Bagaimana alat-alat ini melewati SFP? Mereka menonaktifkannya untuk sementara waktu dengan memanggil fungsi sfc.dll yang diekspor SfcTerminateWatcherThread, dan mereka memastikan untuk mencerminkan pembaruan dalam subdirektori dllcache. Anda harus mencatat bahwa Win2K mengharuskan semua file sistem ditandatangani secara digital oleh Microsoft, jadi umumnya tidak mungkin untuk memperbarui file sistem dengan versi sewenang-wenang Anda sendiri.

Program Win32 dapat melihat perubahan dalam direktori dengan menggunakan API FindFirstChangeNotification dan FindNextChangeNotification Win32. Namun, API ini hanya menginformasikan aplikasi bahwa sesuatu telah berubah; mereka tidak memberi tahu aplikasi dengan tepat apa yang telah berubah. Oleh karena itu, aplikasi diperlukan untuk memindai seluruh direktori untuk menentukan file atau subdirektori mana yang mungkin telah berubah. SFP menggunakan NT Native API untuk melakukan permintaan pemberitahuan perubahan di mana NT memberi tahunya dengan tepat file atau subdirektori apa yang berubah dalam direktori yang dipantau. Fungsi yang digunakan SFP diberi nama NtNotifyChangeDirectoryFile, dan, seperti 90% dari NATIVE API NT, tidak terdokumentasi. Cari applet di Systems Internals dalam waktu dekat yang menunjukkan kepada Anda cara menggunakan NtNotifyChangeDirectoryFile.

Kolom "Internal NT" September saya, "Di dalam Penyempurnaan Keandalan Win2K, Bagian 2" menjelaskan SFP secara lebih rinci.

MENUTUP FILE YANG DIBUKA DARI JARINGAN

Salah satu pertanyaan paling sering saya dapatkan dari pengunjung Systems Internals adalah "bagaimana cara menutup file yang telah dibuka pengguna dari jaringan?" Jika pengguna memiliki file atau direktori yang dibuka dari jarak jauh, Anda tidak dapat menghapus, mengganti nama, atau memperbarui file atau direktori secara lokal. Pertanyaan serupa adalah, "Bagaimana cara melihat file apa yang telah dibuka pengguna dari jaringan?" Kedua pertanyaan ini dijawab dengan utilitas baris perintah Net yang dilengkapi dengan Windows NT/2K. Untuk melihat file apa yang dibuka, cukup ketik "file bersih". Anda akan mendapatkan daftar nama file terbuka, pengidentifikasi nama file yang sesuai, dan nama pengguna yang memiliki file yang dibuka. Untuk menutup salah satu file yang Anda lihat terbuka, Ketik net file <id> /close. Untuk melihat file yang dibuka secara lokal, Anda dapat menggunakan alat NTHandle atau HandleEx saya.

API yang mendasar fungsionalitas tampilan dan penutupan file perintah Net didokumenkan di SDK Platform dan di Pustaka MSDN. Gunakan NETFileEnum API untuk menghitung file terbuka dan API NetFileClose untuk menutup file yang terbuka. API sebenarnya memungkinkan Anda menghitung file yang terbuka di server jarak jauh, sesuatu yang tidak diizinkan oleh perintah Net.

NTHandle tersedia di http://www.sysinternals.com/nthandle.htm. HandleEx tersedia di http://www.sysinternals.com/handleex.htm.

APA YANG AKAN TERJADI

AN "AWE"-SOME WIN2K API

Win2K memperkenalkan API baru yang disebut AWE (Address Window Extensions) yang dapat digunakan aplikasi intensif memori untuk langsung mengakses dan mengelola RAM fisik dalam jumlah besar - bahkan lebih dari 3GB, batas atas RAM yang dapat ditangani aplikasi Windows NT di ruang alamat virtualnya. Bahkan, jika sistem x86 memiliki PSE (Ekstensi Ukuran Halaman) dan RAM lebih dari 4GB, aplikasi dapat menggunakan AWE untuk memanfaatkan semua memori komputer. OLEH KARENA ITU, API ini sangat ideal untuk aplikasi lapar memori seperti server Web dan server database. Lain kali saya akan memberi tahu Anda cara menggunakan API, baik dari aplikasi Win32 maupun dari driver perangkat.

Sementara saya berada di subjek aplikasi yang lapar memori, berikut adalah tips untuk siapa saja yang menulis aplikasi yang menyimpan file (seperti Server Web). Windows NT Cache Manager membagi memori Cache-nya menjadi slot 256KB yang disebut "tampilan". Jika file berukuran kurang dari 256KB di-cache, Cache Manager masih harus menetapkan seluruh slot 256KB file, yang berarti bahwa bagian dari memori virtual Cache terbuang-. Dengan demikian, umumnya lebih efisien performa untuk cache file berukuran kurang dari 256KB dalam memori virtual aplikasi Anda sendiri, dan untuk mengandalkan sistem file untuk menyimpan file yang berukuran lebih besar dari 256KB. IIS 5.0 menggunakan trik ini.

Terima kasih telah membaca Buletin Internal Sistem.

Diterbitkan Sabtu, Juni 19, 1999 7:14 PM oleh ottoh