- Di Windows, simbol atau karakter non-ASCII selain A~Z juga bisa digunakan sebagai huruf drive
- Secara internal, path Win32 (
C:\foo) diproses setelah diubah menjadi path namespace NT (\??\C:\foo)
- Struktur ini dikelola oleh Object Manager, dan huruf drive seperti
C: hanya ada sebagai objek symbolic link biasa
- Dengan perintah
subst, kita bisa membuat huruf drive nonstandar seperti +: atau €:, tetapi Explorer dan PowerShell tidak dapat mengenalinya
- Perilaku ini menjadi petunjuk penting untuk memahami struktur internal pemrosesan path Windows dan cara encoding-nya (WTF-16, dll.)
Struktur internal huruf drive
- Path biasa Windows (
C:\foo) adalah path namespace Win32, dan saat API dipanggil akan diubah menjadi path namespace NT
- Contoh: saat memanggil
CreateFileW("C:\foo"), secara internal diubah menjadi NtCreateFile("\??\C:\foo")
\?? adalah folder virtual milik Object Manager, berupa gabungan \GLOBAL?? dan folder DosDevices per pengguna- Objek
C: ada sebagai symbolic link di dalam \GLOBAL??, dan terhubung ke path perangkat nyata \Device\HarddiskVolume4
- Karena itu,
C: bukan karakter khusus yang dicadangkan, melainkan diperlakukan sebagai nama symbolic link biasa
Definisi huruf drive
- Huruf drive adalah hasil dari proses konversi path Win32 menjadi path NT
- Fungsi konversi
RtlDosPathNameToNtPathName_U mengubah C:\foo menjadi \??\C:\foo
- Fungsi ini juga menangani karakter nonstandar seperti
+: dengan cara yang sama, jadi jika objek +: ada, path +:\ juga akan berfungsi normal
- Objek
+: yang dibuat dengan perintah subst +: C:\foo disimpan di folder DosDevices per pengguna
Perilaku huruf drive nonstandar
- Explorer.exe hanya memindai rentang A~Z, jadi drive
+: tidak akan ditampilkan
- PowerShell juga tidak bisa mengenali drive non-ASCII dan akan mengembalikan error
- Namun di cmd.exe, drive seperti
+: atau €: berfungsi normal
Huruf drive non-ASCII dan Unicode
- Dengan perintah
subst €: C:\foo, kita bisa membuat drive dengan simbol euro (€)
- Bekerja tanpa membedakan huruf besar/kecil (
Λ: dan λ: dikenali sama)
- Huruf drive dibatasi pada satu unit kode WTF-16 tunggal (U+FFFF ke bawah)
- Karakter seperti
𤭢: yang melampaui U+FFFF akan memicu error di subst
- Jika
MountPointManager dipanggil langsung, pembuatan memang bisa berhasil, tetapi tidak bisa diakses karena konversi path Win32 gagal
- Ini menunjukkan bahwa Windows tidak sepenuhnya mendukung pasangan surrogate UTF-16
Masalah penentuan path dan encoding
- Implementasi penanganan path di tiap bahasa bisa berbeda dari
RtlDosPathNameToNtPathName_U
- Contoh: Rust hanya mengenali
A-Z sebagai path absolut (C:\ = true, +:\ = false)
- Bergantung pada cara encoding (WTF-8 vs WTF-16), indeks seperti
path[0], path[1], dan seterusnya bisa berbeda, sehingga hasil penentuan path absolut juga bisa berbeda
- Standard library Zig mempertimbangkan perbedaan ini dan diimplementasikan agar mengenali hingga rentang
<= U+FFFF
Bug penanganan non-ASCII di SetVolumeMountPointW
- Saat memanggil
SetVolumeMountPointW("€:\", volume), pemanggilan berhasil, tetapi link yang benar-benar dibuat muncul sebagai ¬:
- Hal ini diduga karena
0x20AC (€) terpotong dan disimpan sebagai 0xAC
- Ini adalah contoh yang menunjukkan keterbatasan API dalam menangani huruf drive non-ASCII
Kesimpulan
- Secara internal, Windows tidak membatasi huruf drive pada A~Z
- Pembatasan muncul karena perbedaan implementasi pada alat level lebih tinggi seperti Explorer dan PowerShell
- Dengan memahami struktur konversi antara namespace Win32 dan NT, pemrosesan encoding, serta cara kerja Object Manager, kita bisa memahami mekanisme internal sistem file Windows dengan lebih dalam
Belum ada komentar.