Mengapa Ada Kedua Variabel Lingkungan TMP dan TEMP? (2015)

• Di Windows, TMP dan TEMP sama-sama masih ada sebagai penunjuk lokasi file sementara, dan ketika keduanya berbeda, yang dipakai bergantung pada implementasi program
• CP/M tidak memiliki variabel lingkungan, sehingga lokasi file sementara harus diatur per program, dan program seperti WordStar menggunakan cara menambal byte tertentu pada berkas eksekusi untuk mengubah perilaku
• MS-DOS menambahkan variabel lingkungan sambil tetap sangat memperhatikan kompatibilitas CP/M, tetapi program-program MS-DOS awal hampir tidak menggunakan TEMP atau TMP karena masih terbawa kebiasaan dari CP/M
• Saat program MS-DOS mulai memakai variabel lingkungan sebagai sarana penyimpanan konfigurasi, TEMP dan TMP pun bersaing, dan beberapa program seperti DISKCOPY dan EDIT mencari TEMP lebih dulu daripada TMP
• Implementasi pipe di MS-DOS 2.0 memilih TEMP untuk lokasi file sementara, tetapi GetTempFileName di Windows memeriksa TMP lebih dulu, sehingga kedua variabel itu terus hidup berdampingan

---

Latar belakang mengapa TMP dan TEMP sama-sama tersisa

• Di variabel lingkungan Windows, TMP dan TEMP sama-sama ada sebagai variabel untuk menentukan lokasi file sementara, dan jika keduanya berbeda, mana yang benar bergantung pada masing-masing program
• Lokasi pembuatan file sementara oleh suatu program bergantung pada implementasi program tersebut; program Windows kemungkinan besar menggunakan fungsi GetTempFileName, dan dalam kasus itu TMP didahulukan
• Alasan kotak dialog pengaturan variabel lingkungan menampilkan TMP dan TEMP bersamaan adalah karena tidak pernah ada satu standar yang sepenuhnya menyingkirkan yang lain, dan secara historis keduanya hidup berdampingan sebagai pilihan yang berbeda

CP/M tidak memiliki variabel lingkungan

• Sekitar tahun 1973, sistem operasi yang umum pada mikrokomputer adalah CP/M, dan CP/M tidak memiliki variabel lingkungan
• Karena tidak ada variabel lingkungan, variabel lingkungan TMP maupun TEMP juga tidak ada
• Untuk menentukan lokasi penyimpanan file sementara pada program, diperlukan pengaturan per program, misalnya dengan menambal byte tertentu pada berkas eksekusi untuk menentukan huruf drive tempat file sementara disimpan
• Program seperti WordStar mencantumkan di manual byte mana yang harus ditambal untuk mengubah perilaku tertentu, dan juga menyediakan ruang patch untuk menyisipkan subrutin kustom seperti dukungan printer

Kemunculan MS-DOS dan variabel lingkungan

• Pada tahun 1981, prosesor 8086 dan MS-DOS muncul, dan keduanya sangat dipengaruhi oleh CP/M
• Salah satu tujuan desain awal MS-DOS adalah memungkinkan program CP/M untuk prosesor 8080 diterjemahkan secara mekanis menjadi program MS-DOS untuk prosesor 8086
• Penerjemah ini berasumsi bahwa program tidak menggunakan pola-pola tidak lazim seperti kode yang memodifikasi dirinya sendiri, lompatan ke tengah instruksi, atau penggunaan kode sebagai data
• Register H dan L pada 8080 dipetakan ke register BH dan BL pada 8086, dan fakta bahwa pada 8080 hanya register HL yang bisa dipakai untuk mengakses alamat hasil perhitungan menjadi alasan mengapa pada 8086, dari AX, BX, CX, dan DX, hanya BX yang bisa dipakai untuk akses memori
• Selain kompatibilitas CP/M, MS-DOS juga menambahkan variabel lingkungan, tetapi karena program CP/M lama tidak memakai variabel lingkungan, program-program MS-DOS awal pun tidak menggunakannya
• Pengguna memang bisa mengatur TEMP atau TMP, tetapi program-program awal tidak memedulikannya

TEMP dan TMP bersaing di pasar

• Seiring waktu, ketika program mulai ditulis dengan MS-DOS sebagai target utama, program-program itu mulai memanfaatkan variabel lingkungan sebagai sarana penyimpanan data konfigurasi
• TEMP dan TMP mulai digunakan sebagai variabel lingkungan untuk menentukan lokasi file sementara, dan keduanya pun muncul sebagai kandidat utama
• Variabel mana yang diperiksa lebih dulu bergantung pada pilihan implementasi program
• Banyak program memeriksa keduanya agar kompatibel dengan kedua kubu, tetapi urutan pemeriksaannya berbeda-beda menurut implementasi
• Program lama DISKCOPY dan EDIT mencari TEMP lebih dulu daripada TMP

Pipe di MS-DOS 2.0 dan TEMP

• MS-DOS 2.0 memperkenalkan fitur pipe untuk meneruskan keluaran satu program ke masukan program lain
• Karena MS-DOS adalah sistem operasi tugas tunggal, pipe ditiru dengan cara mengalihkan keluaran program pertama ke file sementara, menjalankannya sampai selesai, lalu menjalankan program kedua dengan file sementara itu sebagai masukannya
• Karena fitur ini, MS-DOS sendiri perlu mengetahui lokasi untuk membuat file sementara
• Variabel yang dipilih untuk mengendalikan lokasi file sementara tersebut adalah TEMP
• Meskipun COMMAND.COM memilih TEMP, program lain tetap bebas memilih apakah akan menggunakan TEMP atau TMP

Di Windows muncul jalur yang memprioritaskan TMP

• Windows mengalami proses yang mirip, tetapi implementasi awal GetTempFileName dibuat untuk memeriksa TMP lebih dulu daripada TEMP
• Jika program Windows menggunakan GetTempFileName saat membuat file sementara, maka program itu akan lebih menyukai TMP
• Karena itu, tidak ada satu jawaban tunggal untuk pertanyaan “variabel mana yang benar”; jawabannya bergantung pada API atau logika internal yang digunakan program
• Sampai sekarang, kotak dialog pengaturan variabel lingkungan masih menampilkan TMP dan TEMP sekaligus, dan kedua variabel itu terus hidup berdampingan untuk lokasi file sementara

[GN⁺]

Komentar Hacker News

• Menarik. Ini terjadi sebelum zaman saya, jadi saya belum pernah dengar bahwa program CP/M dikonfigurasi lewat patch

  • Benar, itu memang dilakukan, dan kode patch-nya harus berupa bahasa mesin Z80/8080
    Dengan fitur itu saya menulis sendiri rutin output keyboard dan layar yang lebih cepat untuk WordStar saya
  • Ya, itu memang ada, dan beberapa program yang awalnya adalah program CP/M bertahan lama bahkan sampai WordStar 7.0 untuk DOS
    Saya ingat dokumentasi WordStar 7 memuat lokasi patch yang bisa dipakai untuk mengubah perilaku program dengan debug.exe milik DOS
  • Sampai sekarang masih ada sedikit jejaknya. Hal-hal yang dibuat oleh suckless biasanya dikonfigurasi dengan mengubah config.h lalu kompilasi ulang
    https://suckless.org/
    Tambahan, saya baru sadar belakangan bahwa ini sudah disebut di subthread lain pada halaman ini
  • Pendekatan itu dibutuhkan karena RAM dan ruang disk sangat terbatas, dan hampir semua komputer datang bersama assembler
    Banyak program CP/M harus bisa berjalan dengan RAM 32K dan floppy lambat 130K, bahkan kadang dari kaset. Kalau punya RAM 64K dan disk 360K, itu sudah termasuk cukup istimewa
    Pada masa itu, tidak seperti sekarang, program dioptimalkan untuk batas bawah pasar, bukan batas atas. Makin banyak sistem yang bisa menjalankannya, makin banyak yang bisa dijual, dan pelanggan tidak dipaksa meng-upgrade perangkat keras
    Tidak ada ruang untuk file konfigurasi eksternal atau program untuk membuat file konfigurasi itu, dan bahkan pemrosesan argumen command line pun menghabiskan byte yang berharga
    Sekarang orang mengeluh MacBook Neo cuma punya 8.000.000.000 byte RAM, tapi pada 1978 orang bahkan bisa membuat IDE dasar berukuran 2.048 byte

• Saya suka blog Raymond, tapi aneh kalau CP/M disebut umum di mikrokomputer pada 1973
  Mikrokomputer tahun 1973 lebih mirip prototipe setingkat sistem pengembangan seperti Intel Intellec, dan bahkan belum punya sistem operasi. Memang benar Kildall mulai mengembangkan CP/M pada 1973, tetapi saat itu ia hanya berjalan di simulator pada mainframe PDP-10
  Kalau 1979 mungkin masuk akal, tapi 1973 terlalu awal

  • Di Wikipedia tertulis CP/M dibuat pada 1974, jadi lini masa di sini memang tampak meleset
  • Lucu juga bahwa selisih antara 1979 dan 1973 sama seperti selisih antara 2020 dan sekarang
    Kalau dipikir-pikir, itu berarti pada 2020 belum ada ChatGPT

• Ini contoh bagus bagaimana keputusan yang dibuat pengembang awal tanpa banyak dipikirkan bisa bertahan puluhan tahun

  • Salah satu tabel inti dalam produk S&P500 yang sempat saya tangani akan selamanya bernama attornies, hanya karena tidak ada yang menangkap salah eja itu di awal
  • Tidak ada yang lebih permanen daripada keputusan TMPorary

• Kemungkinan program-program memilih TMP karena ekstensi file di MS-DOS maksimal 3 huruf, dan ada kebiasaan memakai ekstensi .TMP untuk nama file sementara

• Mirip dengan bagaimana program Unix tidak konsisten apakah akan melihat http_proxy atau HTTP_PROXY
  Sekarang banyak program memeriksa keduanya, tetapi urutan pengecekannya belum tentu sama

• Penyebutan CP/M di sini membingungkan. Penulis tampaknya bilang ini nantinya akan jadi penting, tetapi pada akhirnya justru menjelaskan bahwa ini tidak ada hubungannya dengan CP/M atau CPU 8080

  • Setuju. Cerita ini tidak terlalu berkaitan dengan CP/M, maupun cabang pembahasan ke 8080/8086
    Intinya cuma bahwa Microsoft memakainya sendiri tetapi tidak pernah berniat menstandarkannya
  • Kalau CP/M memang memakai variabel lingkungan untuk konfigurasi, standar soal apakah memakai TMP atau TEMP seharusnya sudah terbentuk, dan DOS tinggal mengikutinya
    Tetapi penghalang sebenarnya adalah bahwa CP/M tidak punya direktori, dan DOS 1.0 juga tidak
  • Bisa kutip kalimat mana yang Anda maksud?

• Sekitar 1995, Telstra, yaitu Australia Telecom, punya sekitar 50 ribu desktop di seluruh organisasi
  Suatu hari sebuah file kecil bernama null muncul di direktori home jaringan semua orang, dan tampaknya ada pengguna Unix yang mencoba menulis file .bat
  Itulah gunanya mengikuti standar yang sudah ada. Saya sempat ingin bertanya, “kenapa harus distandardisasi?”, tetapi lalu terpikir itu bisa membingungkan orang Amerika Utara

  • Mungkin awalnya mereka mencoba /dev/null, gagal, lalu menggantinya begitu saja menjadi null
    Kalau bukan begitu, sulit masuk akal kalau pelakunya programmer Unix. Lebih mungkin programmer DOS yang salah menulis NUL menjadi null
  • Saya jadi penasaran teks apa yang sebenarnya ingin dibuang
  • Ada juga installer driver Logitech yang melakukan hal serupa
    Ia mencari file bernama NULL di hard disk, dan tentu saja di dalam file .BAT ada sintaks seperti > NULL

• Sejujurnya, untuk banyak program, konfigurasi dengan patch ala CP/M mungkin lebih baik daripada menyebarkan dotfile di direktori home

  • Kalau orang-orang mau mengikuti XDG Base Directory Specification, kekacauan file konfigurasi bukan masalah besar
    Semakin banyak proyek yang mengadopsinya, termasuk proyek keras kepala seperti Firefox
  • Salah satu filosofi suckless yang agak khas adalah bahwa proyek mereka umumnya dikonfigurasi dengan mengubah source code lalu kompilasi ulang
    Kalau dilihat dari sudut open source modern, itu bisa dianggap pendekatan yang mirip. Hanya saja, karena asketismenya secara umum, proyek-proyek itu mungkin cukup soal selera
  • Sebenarnya semuanya memang seharusnya ada di dalam .config
    Masalahnya adalah banyak pengembang aplikasi merasa aplikasi merekalah yang spesial sehingga pantas punya direktori terpisah sendiri
  • Menurut saya dotfile yang bisa di-grep dan dikelola dengan editor teks lebih baik daripada konfigurasi yang tersebar di berbagai sudut registry biner terpusat
    Mungkin itu cuma karena saya sudah terbiasa
  • Saya berharap ini distandardisasi. Distro apa pun yang bisa memaksa folder .config adalah pemenang bagi saya
    Meski begitu, mungkin momen untuk itu sebenarnya sudah lewat

• Saya tidak tahu ternyata seruwet ini
  Pelajarannya mungkin pastikan selalu menunjuk ke path yang sama, kalau tidak akibatnya bisa buruk

• Saya sudah menyoroti hal-hal menyebalkan seperti ini dari Microsoft selama puluhan tahun
  Dulu selalu ada “pengembang senior” di sana yang seolah tahu segalanya dan selalu punya jawaban. Misalnya, “temp itu temporary dan tmp itu troubleshoot my pc, untuk log debug. Makanya saya senior dan kamu bukan”
  Setelah saya sendiri jadi lebih senior, ternyata memang benar saya patut mempertanyakannya, dan sekarang kalau bicara dengan pengembang Microsoft yang asli, mereka menjelaskan bahwa itu memang kesalahan, tetapi dipertahankan demi kompatibilitas mundur
  Lalu saya jadi bertanya kenapa alasan itu dianggap sah, karena sambil berlindung di balik kompatibilitas mundur, mereka juga terus mendorong perubahan seperti New Outlook yang sering merusak kompatibilitas inti dan alur kerja nyata. Lalu mereka menghindar dengan berkata, “saya bukan pengembang yang buruk, tanya saja orang baru”
  Orang-orang baru itu bahkan tidak bisa ditanya, dan mereka bersembunyi di balik penghalang seleksi LeetCode. Jadi tidak aneh kalau masalah nyata seperti ini tidak pernah diperbaiki dan yang muncul justru hal-hal seperti New Outlook. Pengembang senior zaman dulu sekarang bekerja di sana, dan pengembang sungguhan sudah pensiun
  Bahkan ketika saya mendapat jawaban yang terdengar masuk akal dari Microsoft tentang masalah seperti program sembarangan memakai folder Documents milik pengguna atau OneDrive yang tanpa sengaja menghapus paksa sesuatu, dalam waktu enam bulan Microsoft akan mendorong perubahan acak yang membuat perilakunya memburuk dan menghancurkan logika inti tadi
  Notepad juga begitu. Dalam wawancara pengembang, mereka bilang karena risikonya harus nol, program itu harus sangat sederhana, tetapi belakangan justru ditambahi login akun Microsoft dan Copilot
  Menurut saya sikap pengembang ala LeetCode dan budaya Microsoft telah merusak seluruh industri. Tidak ada ruang untuk diskusi tenang; arahnya selalu jadi, “kamu tidak bekerja di Microsoft, jadi pendapatmu tidak sah”
  Saya sangat ingat bagaimana Google Chrome dulu diinstal ke AppData untuk melewati kebutuhan hak admin. Jelas tujuan asli fitur itu bukan agar pihak ketiga bisa memasang sesuatu tanpa hak admin
  Tetapi karena Chrome saat itu memang bagus, dan ada kekacauan harus mendistribusikan program pengecualian pihak ketiga ke jutaan komputer perusahaan yang terkunci, para pengembang sekarang membingkai ulang itu seolah memang fitur yang dimaksudkan sejak awal