Windows 11 Menjalankan Biner yang Dikompilasi 30 Tahun Lalu

 (twitter.com/mikko)
1 poin oleh GN⁺ 2023-08-20 | 1 komentar | Bagikan ke WhatsApp
  • Windows 11 terbaru menjalankan biner yang dikompilasi pada 18 Agustus 1993, menyoroti kompatibilitas mundur jangka panjang Microsoft
  • Program tersebut merupakan biner yang dibuat 30 tahun lalu pada saat dipublikasikan, menunjukkan bahwa perangkat lunak Windows lama masih dapat berjalan di lingkungan modern
  • Inti dari kasus ini adalah kompatibilitas mundur, di mana versi baru sistem operasi tetap menerima berkas eksekusi lama apa adanya
  • Dari informasi yang dipublikasikan, tidak dapat dipastikan apakah diperlukan konversi terpisah, kompilasi ulang, atau pengaturan tambahan
  • Kemampuan menjalankan biner lama menjadi sinyal stabilitas penting bagi pengguna perusahaan maupun individu saat menangani perangkat lunak yang disimpan untuk jangka panjang

Kasus Windows 11 Menjalankan Biner Berusia 30 Tahun

  • Windows 11 menjalankan biner yang dikompilasi pada 18 Agustus 1993
  • Kasus ini dibagikan bersama penilaian bahwa kompatibilitas mundur Microsoft sangat kuat
  • Informasi yang terkonfirmasi terbatas pada apakah biner dapat dijalankan dan tanggal kompilasinya
    • Nama biner, bahasa pengembangan, cara menjalankan, dan ada tidaknya pengaturan tambahan tidak disertakan

Bacaan terkait

1 komentar

 
GN⁺ 2023-08-20
Pendapat Hacker News

  • Sebagai referensi, ada juga tulisan Joel Spolsky: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
    Menurut salah satu pengembang SimCity, ada bug fatal yang kebetulan berjalan baik di DOS, tetapi rusak di Windows. Bug itu menggunakan kembali memori yang sudah dibebaskan, dan para tester tim Windows menemukan bahwa SimCity terus crash saat mencoba menjalankan aplikasi populer. Katanya, para pengembang Windows membongkar SimCity dengan disassembler dan melacaknya dengan debugger hingga menemukan bug tersebut, lalu menambahkan kode yang memeriksa apakah SimCity sedang dijalankan, dan hanya dalam kasus itu menjalankan memory allocator dalam mode khusus yang tetap mengizinkan memori dipakai setelah dibebaskan.

    • Sebagai contoh tandingan, Soldier of Fortune rusak di Windows modern karena compatibility hack yang diterapkan secara keliru. Jika nama file executable diubah, game itu berjalan tanpa masalah.
      Implementasi backward compatibility seperti ini tidak transparan dan bersifat tambal sulam, jadi kurang bagus. Alat serupa juga pernah dipakai untuk merusak aplikasi pesaing. Biasanya pengguna akhirnya mencoba satu per satu versi Windows lama mana yang dipakai untuk menjalankannya. Linux juga tidak lebih baik karena tidak punya ABI yang stabil, sedangkan Mac adalah campuran antara Rosetta yang luar biasa dan aplikasi yang rusak tanpa alasan jelas. Entah apakah FreeBSD melakukannya lebih baik? Mungkin sistem operasi “matang” yang sudah punah seperti VMS lebih baik.
    • Belakangan ini pembaruan driver GPU juga umumnya seperti ini. Alih-alih pengembang memperbaiki game, Nvidia menghitung bahwa lebih menguntungkan bagi mereka untuk memperbaiki bug game di level driver GPU lalu mendistribusikannya.
    • Ini justru terlihat seperti argumen yang sangat bagus bahwa backward compatibility harus dipatahkan. Hack konyol seperti ini menjadi beban pemeliharaan dan debugging bagi seseorang, dan seperti pajak yang ditambahkan ke seluruh sistem operasi. Menurut saya jejaknya cukup terlihat dalam praktik.
    • Jika mencari bab bonus “The Old New Thing” karya Raymond Chen, ada banyak contoh tentang adanya tim khusus yang meretas Windows untuk memeriksa aplikasi populer satu per satu dan membuatnya berjalan di sistem operasi baru.
    • Di sisi lain, driver GPU Asahi Linux memeriksa apakah huruf pertama nama proses adalah X, dan jika ya, langsung menolaknya.
      Kurang lebih maksudnya: kenapa masih menjalankan Xorg? Seharusnya sudah pindah ke Wayland sekarang.
      https://social.treehouse.systems/@marcan/110904454552941656

  • Raymond Chen telah memberikan perspektif orang dalam tentang topik ini selama puluhan tahun: https://devblogs.microsoft.com/oldnewthing/

  • Menarik bahwa berkat stabilitas umum Windows API, Win32/DX melalui kerja besar Wine/Proton telah menjadi API “universal” yang sangat stabil dan andal di Linux serta sistem operasi lain. Saya terus melihat game berhenti merilis versi native Linux dan cukup merilis untuk Proton.

  • Ini bukan hal gila, melainkan tingkat ekspektasi yang wajar terhadap sebuah alat. Palu saya masih bekerja sempurna pada paku yang dibeli 30 tahun lalu.
    Kita tidak bisa membangun sesuatu di atas fondasi goyah yang terus mematahkan backward compatibility. Pada akhirnya, waktu untuk memelihara jadi lebih banyak daripada waktu untuk membuat. Lalu roda diciptakan ulang, padahal dari sudut pandang pengguna, roda baru yang mengilap belum tentu lebih baik. Sebagian besar software yang saya pakai berusia lebih dari 10 tahun; sebagian masih diperbarui, tetapi sebagian tidak, atau sudah pindah ke cloud, dan saya dengan senang hati tertinggal di belakang.

  • Dulu saya percaya begitu, tetapi sekarang tidak lagi.
    Game Steam yang memakai layanan Games for Windows – Live dan tidak diperbarui setelah layanan itu dihentikan pada 2014 tidak bisa dijalankan di Windows 10 dan setelahnya. Penyebabnya, DLL layanan tersebut telah dihapus. Untuk sementara, orang-orang mengatasinya dengan mengunduh DLL dari situs pihak ketiga, tetapi sekarang itu pun tidak bisa.

    • Game lama tanpa DRM atau layanan jaringan pun bisa tidak berjalan karena kompatibilitas grafis. Namun cnc-ddraw menyelamatkan cukup banyak di antaranya: https://github.com/FunkyFr3sh/cnc-ddraw
    • Tapi sepertinya versi bajakan game-game itu masih bisa jalan ;)

  • Ada juga contoh yang lebih “gila”.
    z/OS(juga disebut OS360, MVS) mendukung program sampai dari era 1960-an, dan seorang DE di IBM mengatakan mereka masih memakai program yang dikompilasi sekitar masa misi Apollo 11.

    • Di dunia mainframe, ini hal biasa. Unisys(dulu Univac) masih punya mainframe Dorado yang kompatibel biner dengan Univac 1100 yang dirilis pada 1962.
    • Apa itu DE? Dan apakah dia juga memberi tahu program itu melakukan apa?
      Ada juga sistem lain yang menjalankan atau mengonversi otomatis binary berusia lebih dari 30 tahun. IBM i on POWER(i5/AS400) tampaknya bisa menjalankan program dari era System/38(1980), dan HPE NonStop(juga disebut Tandem Guardian) on X86-64 bisa menjalankan atau mengonversi binary dari sistem TNS orisinal proprietary akhir 1970-an dan sistem MIPS tahun 1991.

  • Windows memang terkenal sangat gigih menjaga kompatibilitas ke belakang, tetapi untuk aplikasi DOS CLI, subsistem DOS pada dasarnya sudah membeku, jadi rasanya itu bukan tantangan besar. Saya penasaran bagaimana jika menjalankan program bergaya DOS yang tuntutannya lebih besar atau aplikasi Win16 awal. Misalnya, apakah Zortech C++ tahun 1986 dengan ekstender DOS Phar Lap, atau Minesweeper dari Windows 3.1, bisa berjalan?

    • Itu bukan aplikasi DOS, melainkan aplikasi konsol Win32. Aplikasi DOS (baik 16-bit maupun 32-bit) atau aplikasi Win16 tidak berjalan secara native
    • Zortech C++ pernah menjadi perangkat yang saya pakai untuk beberapa waktu dan saya punya kenangan baik dengannya. Menurut saya Phar Lap terlalu dalam ikut campur sehingga sulit berjalan di Windows saat ini, tetapi layak dicoba. Mungkin sebagian besar fitur terkait expanded/extended memory sekarang sudah tidak akan berfungsi

  • Ini sama sekali tidak seharusnya dianggap luar biasa. Seharusnya dilihat sebagai sesuatu yang sehari-hari dan wajar, dan jika tidak bisa, itu harus dianggap sebagai kegagalan yang sangat memalukan dan tidak dapat diterima
    Maksud saya bukan bahwa ini tidak luar biasa menurut standar kekacauan tahun 2023. Maksud saya, norma yang harus kita tuju memang seperti itu

    • Setuju. Tidak ada alasan sama sekali mengapa sebagian besar binary yang dikompilasi statis harus berhenti berfungsi

  • Akan ada yang bilang Linux juga begitu, dan secara teknis itu benar, tetapi dalam praktiknya cukup sulit
    ABI kernel memang stabil, tetapi sisanya nyaris murni kekacauan, dan ini karena cara aplikasi biasanya dipaketkan di Linux. Aplikasinya sendiri mungkin bisa dimuat (kalau bukan format a.out), tetapi kemungkinan besar akan gagal saat memuat sebagian besar library. Pada akhirnya diperlukan seluruh chroot distro Linux yang menjadi acuan atau runtime lain, dan belum tentu arsip distro berusia 30 tahun masih bisa ditemukan. Selain itu, kita harus berasumsi bahwa ABI kernel benar-benar tidak berubah satu bit pun, dan antarmuka lain seperti /proc atau /sys juga tidak berubah. Sepertinya /sys belum ada 30 tahun lalu. Kalau itu aplikasi Xorg, saya tidak akan mempertaruhkan uang makan siang untuk kompatibilitas di level protokol

    • Di Linux pun ini bekerja dengan cara yang sama seperti Windows. Jika library dinamis dan konfigurasi yang diperlukan tidak ada, ia tidak akan berjalan
      Sulit memahami mengapa ini menjadi poin minus untuk Linux tetapi bukan untuk Windows

  • Saya selalu menyayangkan software Mac lama yang begitu saja tidak bisa berjalan. Mungkin Apple memang tidak punya pilihan selain berpindah ke arsitektur baru. Namun masalahnya adalah bagian emulator yang rusak beberapa tahun kemudian
    Dedikasi Microsoft yang terlihat oleh pelanggan seharusnya bukan sesuatu yang begitu mengejutkan. Semua perusahaan seharusnya bertindak seperti itu

    • Apple juga dulu pernah punya masa ketika iMac generasi pertama (300MHz?) pun bisa dipasangi Mac OS X terbaru. Mungkin RAM-nya harus dimaksimalkan, tetapi itu saja sudah cukup, dan dalam praktiknya cukup layak dipakai