Bagikan melalui

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

Buletin Internal Sistem Volume 1, Nomor 5

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

12 Oktober 1999 - Dalam masalah ini:

  1. APA YANG BARU DI INTERNAL SISTEM

    • NTFS untuk Windows 98/NTFSDOS Professional
    • DebugView v3.21
    • Filemon dan Regmon v4.21
    • Diskmon v1.1
    • Sistem Internal pada www.microsoft.com
    • Oktober "Internal NT"
    • Hal-Hal Yang Tidak Begitu Baru

  2. BERITA INTERNAL

    • Win2K RC2 DDK Dirilis
    • API Kernel Win2K RC Baru
    • Pengembangan Perangkat Lunak '99 Timur
    • Menggunakan DiskEdit

  3. APA YANG AKAN TERJADI

    • Ledakan API Win2K

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.

Pemulihan Jarak Jauh Perangkat Lunak Winternals memungkinkan Anda mengakses drive komputer yang tidak dapat diboot melalui TCP/IP dari mana saja di perusahaan Anda. Hemat waktu dan dukung dolar dengan mengoreksi driver, sistem file, dan masalah konfigurasi dari jarak jauh yang menjaga sistem NT atau Win9x tetap off-line. Anda bahkan dapat melakukan operasi chkdsk jarak jauh atau pemartisian menggunakan Pemulihan Jarak Jauh, yang menjadikannya alat pemulihan bencana serbaguna. Unduh versi uji coba baca-saja gratis di http://www.sysinternals.com/rrecover.htm, dan beli versi baca/tulis di http://www.winternals.com.

Halo semuanya,

Selamat datang di buletin Sistem Internal. Buletin saat ini memiliki 10.000 pelanggan.

Rilis Windows 2000 (Win2K) tampaknya mengikuti pola menjadi segera dan kemudian didorong kembali. Rumor terbaru adalah bahwa itu akan tersedia pada bulan Februari. Dan satu-satunya informasi tentang tanggal pengiriman Win2K ada dalam rumor, karena Microsoft bahkan tidak memberi tahu OEM atau mitra kapan akan dikirim. Yah, mereka adalah: "itu akan dikirim ketika sudah siap" (saya tidak akan memaksa tanggal mengatakan tentang menjual anggur pada Anda di sini).

Hal yang menjengkelkan tentang Microsoft adalah bahwa pers yang mereka hasilkan tentang produk mereka selalu membuatnya seolah-olah mereka berada di ambang pengiriman bahkan ketika produk vaporware. Contoh terbaru adalah Millennium, penerus Windows 98. Microsoft belum lama ini membuat dorongan besar di pers seolah-olah itu adalah produk jadi, siap untuk mengonversi semua peralatan rumah tangga Anda menjadi perangkat cerdas. Ironisnya adalah bahwa artikel beberapa saat kemudian mengungkapkan bahwa Microsoft bahkan belum sepenuhnya menentukan produk, dan mungkin akan menjadi satu tahun atau lebih sebelum kita melihatnya di rak toko.

Pola ini bukan baru dan saya bukan yang pertama menulis tentang hal itu. Tetapi itu tidak menghentikan saya berspekulasi tentang berapa banyak melihat-gergaja adalah rencana yang diorkestrasi dengan hati-hati, dan berapa banyak hasil dari total kurangnya prinsip rekayasa perangkat lunak. Jika Anda membeli ke sudut sebelumnya, seperti yang dilakukan para ahli teori konspirasi, Microsoft dengan brilian menyesatkan persaingan dengan menggoda pelanggan dengan produk luar biasa itu bahwa, jika mereka menunggu hanya sedikit lebih lama, akan membuat penantian mereka berharga dan mengaburkan kebutuhan apa pun untuk beralih ke produk non-Microsoft. Sudut terakhir mengatakan bahwa Microsoft tidak akan pernah mempelajari proses pengembangan perangkat lunak, dan terus meremehkan upaya rekayasa dan melampau kualitas kode beta.

Aku duduk di pagar dengan teori yang aku tulis. Saya benar-benar berpikir pola adalah karena sedikit dari keduanya. Saya pikir itu telah membantu Microsoft untuk bertindak seperti Direktori Aktif telah hampir siap selama dua tahun sekarang. Tentunya ada pelanggan yang akan beralih ke Novell Directory Services sejak lama jika mereka tahu sebelumnya berapa lama mereka harus menunggu Win2K. Di sisi lain, Microsoft telah mendapatkan mata hitam berulang di pers dari menjanjikan pengiriman produk dan kemudian menunda. Saya pikir manajemen Microsoft hanya tidak memahami betapa sulitnya untuk mereproduksi, mengisolasi, dan memperbaiki 5% bug terakhir itu.

Berbicara tentang praktik pengembangan Microsoft, skema penamaan pra-rilis mereka adalah salah satu yang paling mencengangkan yang pernah saya lihat. Beta mereka benar-benar Alpha dan Kandidat Rilis mereka sebenarnya beta. Dan bahkan menggunakan definisi ini adalah peregangan: Microsoft tidak memiliki masalah merobek fitur dari perangkat lunak mereka dalam memulai dari satu Kandidat Rilis ke Kandidat Rilis berikutnya, atau bahkan menambahkan yang baru. Mereka melakukan itu dengan NT 4.0 dan mereka melakukannya dengan Win2K. Praktik itu tentu tidak mempercepat siklus rilis.

Jadi akan Win2K kapal pada bulan Februari? Kurasa kita melihat cahaya di ujung terowongan. Lagi pula, hanya ada beberapa API baru di RC2 ...

Sebagai tindak lanjut dari buletin terakhir di mana saya berbicara tentang kebingungan akronim di Microsoft, pembaca George Janczuk menemukan contoh lain. Di bagian berjudul: "Memperluas ke Dunia Pemrosesan Transaksi Mainframe", artikel mengacu pada http://msdn.microsoft.com/library/backgrnd/html/msdn_windnapps.htm CISC - Komputasi Set Instruksi Kompleks. Jelas bagi siapa pun yang terbiasa dengan aplikasi mainframe bahwa akronim yang dimaksudkan adalah CICS - Sistem Kontrol Informasi Pelanggan. Urutan huruf terbalik dan Anda berada di area teknologi yang sama sekali berbeda.

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

Terima kasih!

-Tanda

APA YANG BARU DI INTERNAL SISTEM

NTFS UNTUK WINDOWS 98/NTFSDOS PROFESSIONAL

Akhirnya kita berhasil. Sejak Bryce dan saya merilis NTFSDOS 1.0 kembali di Musim Semi 1996 kami telah mencari grail suci kompatibilitas sistem file Windows: akses baca/tulis untuk NTFS dari Windows 9x dan DOS. Kami menentukan sejak lama bahwa rekayasa balik format NTFS dan menulis driver untuk sistem file jurnal yang kompleks ini akan menjadi proposisi yang sulit dan berisiko. Bahkan jika satu tepat menentukan setiap nuansa format, pembaruan ke format, seperti NTFS v5.0 Win2K, memerlukan upaya rekayasa balik dan pengembangan yang sama sekali baru. Selanjutnya, memvalidasi kebenaran driver sistem file untuk format yang rumit karena NTFS adalah proposisi yang menakutkan.

Jadi kami curang.

NTFS untuk Windows 98 menyediakan akses baca/tulis penuh ke drive NTFS dari Windows 95 atau Windows 98, dan NTFSDOS Professional menyediakan akses baca/tulis NTFS penuh dari DOS. Baik NTFS untuk Windows 98 maupun NTFSDOS Professional tidak memiliki pengetahuan tentang format sistem file NTFS. Sebaliknya, mereka mengandalkan driver NTFS dari penginstalan Windows NT atau Windows 2000 untuk mengimplementasikan pengetahuan tersebut. Kedua utilitas menggunakan basis kode yang sama yang berfungsi sebagai pembungkus lingkungan untuk driver sistem file NTFS. NTFS untuk Windows 98 menyediakan antarmuka ke API sistem file Windows 9x di atas NTFS, dan layanan disk Windows 9x di bawah NTFS. Antarmuka NTFS untuk Windows 98 hadir ke NTFS terlihat seperti lingkungan Windows NT/2K asli NTFS, lengkap dengan IRP, Manajer I/O, Manajer Cache, perangkat disk gaya NT, dan subsistem NT/2K lainnya yang berinteraksi dengan NTFS.

NTFSDOS Professional bekerja dengan cara yang sama seperti NTFS untuk Windows 98, kecuali bahwa NTFS antarmuka ke layanan DOS di atas dan LAYANAN disk BIOS Interupsi 13 di bawah ini. Untuk membantu membuat lingkungan seperti NT/2K, kami mengandalkan banyak fungsi dalam NTOSKRNL, file kernel NT/2K. Kedua utilitas memuat NTOSKRNL bersama dengan NTFS, sehingga NTFS dapat langsung menggunakan mungkin dari layanan asli kernel.

Kami bersenang-senang membangun lingkungan NTFS sehingga kami melangkah lebih jauh: kami melakukan hal yang sama dengan utilitas chkdsk boot-time NT, Autochk. NTFSDOS Professional dan NTFS untuk Windows 98 dilengkapi dengan utilitas NTFS chkdsk bernama NTFSCHK. NTFSCHK bekerja pada prinsipal yang sama dengan pembungkus sistem file NTFS, di mana ia membuat lingkungan seperti NT untuk program Autochk sehingga Autochk berjalan di bawah Windows 95/98 dan DOS. Hasil dari trik ini adalah dukungan baca/tulis NTFS lengkap untuk Windows 95/98 dan untuk DOS.

Anda dapat mengunduh versi baca-saja gratis NTFS untuk Windows 98 di http://www.sysinternals.com/ntfs98.htm dan versi baca-saja gratis dari NTFSDOS Professional di http://www.sysinternalscom/ntfspro.htm. Anda dapat membeli versi baca/tulis lengkap dari kedua alat di Winternals Software, http://www.winternals.com.

DEBUGVIEW V3.21

DebugView adalah monitor debug-output yang menangkap output debug kernel dan Win32 di bawah Windows 95, Windows 98, NT 4.0 dan Windows 2000. Ini memiliki kemampuan pemfilteran, penyorotan, dan pengelogan tingkat lanjut, dan bahkan dapat mengambil output debug dari sistem di seluruh jaringan. Rilis terbarunya, 3.21, memperkenalkan kemampuan untuk memantau output OutputDebugString 16-bit di bawah Windows 95 dan Windows 98.

Anda dapat mengunduh DebugView v3.21 di http://www.sysinternals.com/dbgview.htm.

FILEMON DAN REGMON V4.21

Filemon dan Regmon adalah sistem file dan utilitas mata-mata Registri untuk Windows 95, 98, NT 4.0 dan Win2K. Mereka terus berkembang dengan fitur kegunaan baru dan dengan rilis 4.21 (Filemon dan Regmon memiliki nomor versi yang disinkronkan) mereka memperkenalkan pemfilteran yang lebih canggih dengan daftar filter terbaru, kemampuan untuk menentukan filter sorotan (bahkan dengan warna kustom), font yang dapat disesuaikan, dukungan clipboard, dan lebih banyak kunci panas yang kompatibel dengan CUI. Kode sumber driver juga telah dikerjakan ulang dan menyertakan validasi parameter yang lebih kuat dalam fungsi antarmuka GUI.

Unduh Filemon v4.21 di http://www.sysinternals.com/filemon.htm dan Regmon v4.21 di http://www.sysinternals.com/regmon.htm.

DISKMON V1.1

Diskmon adalah alat yang memantau dan menampilkan aktivitas disk logis dan fisik. Versi 1.1 memperbarui Diskmon untuk bekerja dengan Windows 2000 dan memperkenalkan peningkatan kegunaan baru. Selain itu, Diskmon sekarang menafsirkan sejumlah besar disk dan kode Kontrol I/O penyimpanan massal, menerjemahkan kode heksadesimal mereka ke dalam representasi teks di jendela output Diskmon.

Diskmon v1.1 tidak hanya berfungsi sebagai monitor disk, tetapi Anda juga dapat menggunakannya sebagai lampu disk berbasis perangkat lunak. Ketika Anda mengaturnya dalam mode disk-light Diskmon meminimalkan dirinya ke dalam baki sistem sebagai cahaya yang hijau ketika ada akses baca disk dan merah ketika ada akses tulis disk.

Unduh Diskmon v1.1 di http://www.sysinternals.com/diskmon.htm.

INTERNAL SISTEM PADA WWW.MICROSOFT.COM

Mempertimbangkan riwayat Internal Sistem (sebelumnya Internal NT), sangat disanjung memang bahwa Microsoft mereferensikan sysinternals.com sebagai sumber daya bagi pelanggannya. Ada semakin banyak artikel Pangkalan Pengetahuan Microsoft yang menunjuk utilitas Systems Internals. Berikut adalah yang terbaru:

  • Q183060 INFO: Panduan Pemecahan Masalah untuk 80004005 & Pesan Kesalahan Lainnya http://support.microsoft.com/support/kb/articles/Q183/0/60.ASP
    Artikel ini menjelaskan Bahwa Anda dapat menggunakan Filemon untuk memeriksa penyebab kesalahan akses data di OLE DB, Objek Data ActiveX, dan Layanan Data Jarak Jauh.

  • Q196453 - Pemecahan Masalah Kesalahan Startup NTVDM dan WOW http://support.microsoft.com/support/kb/articles/Q196/4/53.ASP
    Artikel ini juga menunjuk ke Filemon sebagai alat untuk menentukan file yang hilang yang menyebabkan kesalahan startup untuk NTVDM (lingkungan kompatibilitas Win16/DOS di NT).

  • Q216368 - PRB: Pelanggaran Akses Selama Penyiapan Aplikasi Saat File digunakan http://support.microsoft.com/support/kb/articles/Q216/3/68.ASP
    HandleEx dan DLLView adalah alat yang direkomendasikan untuk menentukan penyebab kesalahan selama eksekusi program penyiapan yang dihasilkan oleh Wizard Penyiapan Visual Basic dan Wizard Penyebaran.

  • Q232830 - HOWTO: Menentukan Kepemilikan Handel File http://support.microsoft.com/support/kb/articles/Q232/8/30.ASP
    HandleEx kembali mendapatkan rujukan dalam artikel ini yang membahas mencari tahu proses apa yang membuka file atau direktori.

OKTOBER "INTERNAL NT"

Kolom "Internal NT" saya di Majalah Windows NT edisi Oktober adalah "Penyempurnaan Keandalan Win2K Dalam, Bagian 3". Ketiga dalam seri tiga bagian ini menjelaskan dua fitur Win2K kuat yang membantu pengembang dan administrator menentukan driver buggy: memori kernel yang dilindungi penulisan dan Driver Verifier.

Pembaca Rusia sekarang dapat membaca artikel saya di lidah asli mereka. Buka Windows NT Magazine edisi Rusia di dan lihat kolom Internal NT pertama yang diterjemahkan http://www.osp.ru/win2000/ , Di dalam Proses Boot (http://www.osp.ru/win2000/1999/10/59.htm). Terima kasih kepada Ivan Rouzanov karena telah memberitahuku tentang hal ini.

Pada awal Agustus, versi online artikel Windows NT Magazine hanya dapat diakses oleh pelanggan, dan artikel diposting secara on-line dengan setiap masalah baru. Jika Anda belum berlangganan, silakan buka tautan langganan di http://www.sysinternals.com/publ.htm untuk mendapatkan diskon langganan Systems Internals.

HAL-HAL YANG TIDAK BEGITU BARU

WinObj adalah alat yang ampuh untuk menjelajahi namespace Objek Windows NT/2K. Namespace objek adalah salah satu dari tiga namespace layanan di NT/2K: namespace objek, namespace layanan Registri, dan namespace sistem file. Anda masuk ke namespace layanan Registri dan sistem file melalui objek di namespace objek. Misalnya, ketika program Win32 membuka kunci Registri, HKEY_LOCAL_MACHINE\Software\Microsoft pustaka ADVAPI32.DLL mengubah nama menjadi \Registry\Machine\Software\Microsoft sebelum memanggil layanan NtCreateKeykernel . Jika Anda melihat akar namespace objek di WinObj, Anda akan melihat objek jenis "kunci" bernama Registry. Nama Registri cocok dengan komponen pertama dari nama kunci sehingga NT/2K Object Manager meneruskan sisa nama, \Machine\Software\Microsoft, ke subsistem yang menentukan objek kunci. Subsistem kernel Configuration Manager mempertahankan Registri dan objek kunci, sehingga mengurai sisa nama untuk menemukan kunci yang diinginkan.

Anda dapat menjelajahi namespace objek dan melihat atau mengatur properti keamanan objek menggunakan WinObj. Unduh Winobj di http://www.sysinternals.com/winobj.htm. Saya membahas namespace Object Manager dan WinObj di kolom Internal NT Oktober 1997 saya, "Di dalam Object Manager". Ikuti tautan ke versi baris kolom di http://www.sysinternals.com/publ.htm.

BERITA INTERNAL

WIN2K RC2 DDK DIRILIS

Anda dapat mengunduh rilis Win2K RC2 dari Kit Pengembangan Driver Perangkat (DDK) Microsoft sekarang di http://www.microsoft.com/ddk/ddkRC2.htm. Anda dapat mengunduh kit secara gratis atau menelusuri dokumentasi secara on-line.

API KERNEL WIN2K RC2 BARU

Hal-hal terlihat stabil di kernel Win2K terbaru. Hanya ada empat API kernel baru yang diekspor di RC3, dibandingkan dengan sekitar selusin yang muncul (dan setengah lusin lainnya yang menghilang) dari Beta 3 ke RC1. Beberapa fungsi baru agak menarik, jadi saya telah memutuskan untuk mendokumentasikannya untuk Anda. Yang pertama adalah MmGetSystemRoutineAddress, dan meskipun tidak terdokumentasi prototipenya disertakan dalam file header ntddk.h dari RC2 DDK:

NTKERNELAPI
PVOID
MmGetSystemRoutineAddress (
    IN PUNICODE_STRING SystemRoutineName
    );

Penggunaannya sesering kelihatannya. Berikan nama fungsi yang berada di NTOSKRNL.EXE atau HAL.DLL dan Anda akan mendapatkan kembali alamat titik masuknya. Fungsi ini sebenarnya tidak berguna dalam rilis pertama Win2K, tetapi mungkin menjadi sangat berguna di jalan, dan itu adalah fungsi yang seharusnya disertakan Microsoft dalam rilis pertama NT (3.1). Seperti GetProcAddress di ruang pengguna untuk aplikasi Win32, fungsi ini memungkinkan driver secara dinamis memastikan ketersediaan API. Jika Microsoft menambahkan API baru ke paket layanan Win2K (dan saya yakin mereka akan) driver dapat ditulis untuk memanfaatkan API, tetapi juga gagal dengan baik pada versi Win2K yang lebih lama atau untuk berjalan dalam mode di mana mereka tidak menggunakan API. Kunci driver yang dapat melakukan ini adalah kemampuan untuk memeriksa keberadaan API setelah dimuat. Tanpa fungsionalitas ini, driver harus secara statis menautkan dengan fungsi yang digunakannya, dan jika fungsi tidak ada ketika driver dimuat maka loader kernel melaporkan kesalahan jelek kepada pengguna dan gagal memuat driver.

API baru kedua adalah MmGetPhysicalMemoryPages. Sekali lagi, prototipenya ada di RC2 ntddk.h tetapi tidak didokumenkan. Prototipenya adalah:

NTKERNELAPI
PPHYSICAL_MEMORY_RANGE
MmGetPhysicalMemoryRanges (
    VOID
    );

Di mana PHYSICAL_MEMORY_RANGE :

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

Fungsi ini mengembalikan array PHYSICAL_MEMORY_RANGE entri dengan akhir array yang ditandai oleh entri yang memiliki 0 untuk dan BaseAddress NumberOfBytes. Seperti MmGetSystemRoutineAddress, ini adalah API yang cukup sederhana. Ini mengembalikan deskripsi semua memori fisik yang diketahui Win2K. Win2K mendukung penambahan dan penghapusan memori dengan cepat dengan MmAddPhysicalMemory API dan MmRemovePhysicalMemory . Itu memotivasi alasan keberadaan API yang memungkinkan Anda mengkueri rentang memori. MmAddPhysicalMemory ditambahkan di RC1 dan MmRemovePhysicalMemory di RC2. Kedua fungsi ini juga diprototi dalam ntddk.h.

Apa SAJA API RC2 baru lainnya? PoShutdownBugCheck dan RtlInvertRangeList. PoShutdownBugCheck memungkinkan Anda menabrak sistem dan melakukan tindakan terkait daya seperti menangguhkan. Ini digunakan di beberapa tempat oleh kernel RC2. Rentang adalah spesifikasi start-end generik yang ditentukan pengguna dan didukung oleh sejumlah API kernel untuk mengelola, mengurutkan, dan melakukan iterasi di atasnya. Arbiter sumber daya Win2K Plug-and-Play menggunakannya untuk melacak dan mengatur persyaratan sumber daya perangkat keras. Meskipun API daftar rentang tidak didokumenkan, semua prototipe dan definisi strukturnya disertakan dalam ntddk.h, sehingga Anda mungkin dapat menggunakan API untuk mengelola data berorientasi start-end Anda sendiri.

Nantikan kesenangan lainnya dengan API yang tidak terdokumentasi di buletin berikutnya.

PENGEMBANGAN PERANGKAT LUNAK 99 TIMUR

Pengembangan Perangkat Lunak edisi East Coast 1999 berlangsung di Washington DC dari 8-12 November. Saya menyajikan tiga pembicaraan pada hari terakhir: Apa yang Baru di Windows 2000 Untuk Pengembang, Di dalam Windows NT/2000 Blue Screen, dan Inside Windows NT/2000 Networking. Selain itu, Dave Solomon, penulis Inside Windows NT NT 2nd Edition dan seorang tetangga (dia tinggal hanya 20 menit dari saya di, dari semua tempat, Danbury, CT), dan saya menghosting meja putar internal Windows NT/2K. Kami akan bersama-sama menjawab pertanyaan terberat Anda tentang internal Windows NT/2K. Katakan halo dan sebutkan buletin dan saya akan memberi Anda t-shirt Sistem Internal gratis!

Kunjungi situs Web Pengembangan Perangkat Lunak di http://www.sdexpo.com.

MENGGUNAKAN DISKEDIT

Anda mungkin tidak mengetahuinya, tetapi ada utilitas editor disk untuk Windows NT dengan gaya Norton Disk Edit yang dapat dimudahkan untuk DOS. Terlebih lagi, utilitas memahami FAT dan NTFS dan gratis. Microsoft rupanya mengirim DiskEdit secara tidak sengaja, alat yang harus menjadi alat penelusuran kesalahan internal untuk tim sistem file mereka, pada CD Windows NT 4.0 Service Pack 4. DiskEdit memiliki antarmuka aneh yang akan mengambil manual kecil untuk didokumenkan, tetapi saya akan membuat Anda memulai dengan panduan sederhana. Saya akan fokus menggunakan DiskEdit untuk mengurai format sistem file NTFS, karena DiskEdit adalah satu-satunya alat yang tersedia untuk umum yang saya tahu yang memahami NTFS.

Pertama, Anda perlu mendapatkan DiskEdit dari CD-ROM Paket Layanan 4 (SP4). Cukup salin dari direktori \i386 ke hard disk Anda. Jika Anda ingin menggunakan DiskEdit di bawah Win2K, Anda harus membuat direktori privat untuk itu dan menyalin DLL berikut dari direktori SP4 winnt\system32 (atau SP4 CD) ke direktori yang sama dengan DiskEdit: IFSUTIL.DLL, ULIB.DLL, UNTFS.DLL dan UFAT.DLL. Sekarang Anda dapat memulai DiskEdit.

Untuk panduan ini, buat direktori yang disebut TEMP di akar drive NTFS dan buat file yang disebut OUT.TXT di direktori tersebut dengan mengetik perintah berikut di jendela prompt perintah dengan TEMP sebagai direktori saat ini: echo hello > out.txt. Pilih drive dengan file OUT.TXT baru Anda di DiskEdit dengan memilih File|Buka item menu dan masukkan huruf drive di bidang Nama Volume dari kotak dialog yang dihasilkan. Pastikan Anda menyertakan titik dua misalnya "d:". Hampir semua fungsionalitas DiskEdit mengharuskan Anda membuka drive.

Kita akan menemukan file OUT.TXT dengan memulai di direktori akar drive NTFS. Pilih entri menu Baca|Catatan File NTFS untuk membuka kotak dialog yang memungkinkan Anda melihat entri catatan MFT hanya dengan memasukkan nomornya. 16 entri rekaman MFT pertama dari setiap drive NTFS dicadangkan dan sesuai dengan file metadata NTFS yang telah ditentukan sebelumnya. Berikut adalah penetapan angka (perhatikan bahwa DiskEdit menginterpretasikan semua input sebagai heksadesimal):

        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)

Lanjutkan dan lihat beberapa entri MFT ini. Anda akan mulai melihat tema umum: semuanya terdiri dari atribut seperti $INDEX_ROOT, $FILE_NAME, dan $DATA. Ini dalam atribut di mana data khusus untuk file disimpan. Ketika data atribut adalah NTFS kecil menyimpan data dalam catatan MFT file sebagai data "residen", dan ketika data besar NTFS menyimpan data di luar rekaman dalam kluster pada disk sebagai data "non-penduduk".

Sekarang masukkan "5" sebagai nomor file dan Anda akan melihat file direktori akar. Kita akan melihat file dan direktori yang ada di direktori akar dengan melihat atribut direktori $INDEX_ALLOCATION , atribut khusus untuk direktori yang merekam konten direktori. Untuk melakukannya, pilih Baca|Entri menu Atribut NTFS, yang membuka kotak dialog lain. DiskEdit sensitif terhadap huruf besar/kecil, jadi masukkan yang berikut ini tepat seperti yang telah saya cantumkan:

        Base Frs Number: 5

Base Frs (Base File Record Segment) adalah nama lain untuk nomor MFT. Anda memasukkan ke 5 untuk menentukan bahwa Anda ingin membaca atribut dari direktori akar.

        Attribute Type: $INDEX_ALLOCATION

Ini menunjukkan diskEdit bahwa Anda ingin membaca data konten direktori. Saya sarankan menggunakan menu tarik-turun untuk memilih atribut yang Anda inginkan karena DiskEdit sangat pilih-pilih tentang cara jenis atribut dimasukkan.

        Attribute Name: $I30

Jika Anda melihat $INDEX_ALLOCATION atribut direktori akar, Anda akan melihat bahwa "$I30" tercantum sebagai namanya di baris ""Type code, name, jadi itulah yang Anda masukkan sebagai nama atribut.

Tekan OK dan Anda akan melihat cadangan heksadesimal dari konten atribut. Kami ingin melihat sesuatu yang lebih cerdas, jadi pilih Tampilan|Entri menu Buffer Indeks NTFS. Anda akan disajikan dengan daftar konten direktori. Gulir daftar hingga Anda melihat entri yang memiliki nama "TEMP". Jika Anda tidak melihatnya, entri mungkin terletak di atribut direktori $INDEX_ROOT akar, jenis atribut yang juga terkait dengan direktori, dan yang selalu memiliki nilainya yang disimpan dalam catatan MFT. Entri akar indeks dan entri alokasi bersama-sama membentuk struktur pohon B+ yang menyimpan semua entri direktori. Jika Anda harus melihat $INDEX_ROOT atribut cukup ikuti langkah yang sama untuk melihat atribut tersebut seperti yang Anda lakukan untuk melihat $INDEX_ALLOCATION atribut . Saat Anda menggulir melalui buffer indeks, Anda mungkin mendapatkan garis ganda tanda bintang: ini menunjuk akhir dari satu buffer indeks dan awal berikutnya.

Setelah Anda menemukan entri direktori TEMP, catat Referensi File (FRS) -nya. Pilih Baca|NTFS File Record dan masukkan FRS TEMP. Sekarang Anda melihat catatan MFT untuk direktori TEMP. Kami ingin menemukan file OUT.TXT, jadi kita harus melihat konten TEMP untuk menemukannya. $INDEX_ALLOCATION Lihat atribut (atau $INDEX_ROOT) direktori TEMP, beralihlah untuk melihat data sebagai Buffer Indeks NTFS, dan temukan file OUT.TXT. Ingatlah untuk memasukkan FRS TEMP sebagai nomor FRS dasar dalam dialog pemilihan atribut. Jika Anda baru saja membuat TEMP maka itu hanya akan memiliki $INDEX_ROOT (jika Anda salah ketik sesuatu, Anda akan mendapatkan kesenangan melihat dialog kesalahan kosong DiskEdit).

Ketika Anda telah menemukan OUT.TXT dan menentukan FRS-nya menggunakan Read|Catatan File NTFS untuk melihat entri MFT-nya. Gulir ke bawah hingga Anda menemukan atribut $DATA. Anda sekarang melihat lokasi OUT. Data TXT. Karena kami membuat file kecil, data disimpan dalam catatan MFT. Jika Anda mencoba melihat OUT. Atribut TXT $DATA menggunakan DiskEdit Anda tidak akan melihat apa pun, karena DiskEdit tidak menampilkan data penduduk dengan benar (salah satu dari banyak bug DiskEdit). Jadi, salin file teks largish (> 2KB) ke \TEMP\ OUT.TXT. Sekarang Anda dapat melihat data OUT.TXT dengan salah satu dari dua cara: Anda dapat memeriksa awal data (atau semua data tersebut jika disimpan secara berdampingan di disk) dengan menggunakan Read|Kluster NTFS dan menentukan nilai "lcn" pertama yang Anda lihat di OUT. Atribut TXT $DATA "Extent List"; atau Anda dapat menggunakan Read|Atribut NTFS dan masukkan "$DATA" sebagai jenis atribut dan tidak ada (seperti dalam jangan ketik apa pun ke bidang tersebut) sebagai nama atribut.

Daftar tingkat menjelaskan lokasi data non-residen atribut. Setiap blok data yang berdekatan dengan hingga 16 kluster yang panjangnya dijelaskan oleh satu entri daftar tingkat. Entri daftar tingkat menentukan nomor kluster virtual (vcn), nomor kluster logis (lcn), dan panjang eksekusi. Vcn adalah kluster dalam file tempat data yang dijelaskan oleh entri dimulai. Lcn menunjuk kluster logis tempat data disimpan di disk, dan runlength adalah jumlah byte data atribut di lokasi tersebut (ingat, DiskEdit menunjukkan nilai heksadesimal).

Saya memandu Anda melalui jalan panjang untuk menemukan catatan MFT file OUT.TXT dengan menunjukkan kepada Anda cara memindai konten direktori. Namun, ada pintasan: pilih Crack|Jalur NTFS dan masukkan TEMP\OUT.TXT. Anda akan disajikan dengan OUT. FRS TXT dan Anda dapat menggunakan Read|Catatan File NTFS untuk langsung masuk ke sana.

Itu membawa saya ke akhir saya DiskEdit primer. Saya mendorong Anda untuk bermain-main dengan alat yang bagus ini dengan menelusuri drive FAT atau NTFS Anda. Sangat tidak mungkin Anda akan pernah menemukan kesempatan untuk menggunakan DiskEdit untuk memodifikasi data agar disk Anda keluar dari kemacetan, tetapi jika Anda ingin tahu tentang format NTFS pada disk (format FAT didokumentasikan dengan baik) ini adalah alat yang sempurna untuk menyelidiki.

APA YANG AKAN TERJADI

LEDAKAN API WIN2K

Meskipun hanya ada 4 API mode kernel baru yang diekspor yang melakukan debut di RC2, jumlah total API yang telah diperkenalkan Microsoft sejak NT 4.0, baik di kernel maupun di DLL Win32 inti, telah meledak. Bulan depan saya akan memberi tahu Anda dengan tepat berapa banyak API baru yang ada dan di mana mereka telah muncul, dan sayangnya pada saat yang sama memberi orang-orang yang percaya bahwa Win2K adalah monster yang kembung beberapa amunisi besar untuk rants Usenet alt.advocacy.linux mereka.

Terima kasih telah membaca Buletin Internal Sistem.

Diterbitkan Rabu, 20 Oktober 1999 19:10 PM oleh ottoh

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