1 puan yazan GN⁺ 2023-08-20 | 1 yorum | WhatsApp'ta paylaş
  • En yeni Windows 11'in 18 Ağustos 1993'te derlenmiş bir ikili dosyayı çalıştırması, Microsoft'un uzun vadeli geriye dönük uyumluluğunu öne çıkarıyor
  • Söz konusu program, paylaşım anı itibarıyla 30 yıl önce oluşturulmuş bir ikili dosya; eski Windows yazılımlarının modern ortamlarda da çalışabildiğini gösteriyor
  • Örneğin temel noktası, işletim sisteminin yeni sürümünün geçmişteki çalıştırılabilir dosyaları olduğu gibi kabul eden geriye dönük uyumluluğunda yatıyor
  • Ayrı bir dönüştürme, yeniden derleme veya ek ayar gerekip gerekmediği, kamuya açık bilgilerden doğrulanamıyor
  • Eski ikili dosyaları çalıştırabilme olasılığı, kurumsal ve bireysel kullanıcıların uzun süre saklanan yazılımlarla çalışırken önemli bir kararlılık sinyali niteliği taşıyor

Windows 11'in 30 yıl önceki ikili dosyayı çalıştırma örneği

  • Windows 11, 18 Ağustos 1993 tarihinde derlenmiş bir ikili dosyayı çalıştırıyor
  • Bu örnek, Microsoft'un geriye dönük uyumluluğunun çok güçlü olduğu değerlendirmesiyle birlikte paylaşıldı
  • Doğrulanan bilgiler, çalıştırılabilirlik ve derleme tarihiyle sınırlı
    • İkili dosyanın adı, geliştirme dili, çalıştırma yöntemi ve ek ayar gerekip gerekmediği dahil değil

1 yorum

 
GN⁺ 2023-08-20
Hacker News görüşleri
  • Referans olarak Joel Spolsky’nin yazısı da var: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
    SimCity geliştiricilerinden birinin söylediğine göre, DOS’ta tesadüfen düzgün çalışan ama Windows’ta bozulan ölümcül bir hata varmış. Serbest bırakılmış belleği yeniden kullanma hatasıymış; Windows ekibindeki testçiler popüler uygulamaları çalıştırırken SimCity’nin sürekli çöktüğünü fark etmiş. Windows geliştiricileri SimCity’yi disassemble edip debugger ile izleyerek hatayı bulmuş, ardından SimCity’nin çalışıp çalışmadığını kontrol eden ve yalnızca bu durumda bellek ayırıcısını, bellek serbest bırakıldıktan sonra bile kullanılmaya devam edilebilen özel bir modda çalıştıran kod eklemişler

    • Karşı örnek olarak Soldier of Fortune, modern Windows’ta yanlış uygulanmış bir uyumluluk hack’i yüzünden bozuluyor. Çalıştırılabilir dosyanın adını değiştirince sorunsuz çalışıyor
      Bu tür geriye dönük uyumluluk uygulamaları şeffaf değil ve geçici çözüm niteliğinde olduğu için pek iyi değil. Benzer araçlar rakip uygulamaları bozmak için de kullanılmıştı. Genelde hangi eski Windows sürümüyle çalıştırılacağını tek tek denemeye dönüşüyor. Linux da kararlı bir ABI’si olmadığı için daha iyi değil; Mac ise mükemmel Rosetta ile sebepsiz uygulama bozulmalarının karışımı gibi. FreeBSD daha mı iyi yaptı? VMS gibi artık yok olmuş “olgun” işletim sistemleri daha mı iyiydi diye düşünüyor insan
    • Günümüzde GPU sürücü güncellemeleri de çoğunlukla buna benziyor. Geliştiricinin oyunu düzeltmesi yerine, Nvidia oyun hatasını GPU sürücüsü seviyesinde düzeltip dağıtmanın kendi çıkarına olduğunu hesaplıyor
    • Bu, aksine geriye dönük uyumluluğun kırılması gerektiğine dair mükemmel bir gerekçe gibi görünüyor. Böyle saçma hack’ler birilerine bakım ve debugging yükü oluyor, tüm işletim sisteminin üzerine vergi gibi biniyor. Bence izleri de epey görünür halde
    • Raymond Chen’in “The Old New Thing” bonus bölümüne bakarsanız, popüler uygulamaları tek tek kontrol edip yeni işletim sisteminde çalıştırmak için Windows’u hack’leyen özel bir ekibin olduğu pek çok örnek çıkıyor
    • Öte yandan Asahi Linux GPU sürücüsü, süreç adının ilk harfinin X olup olmadığına bakıyor; öyleyse doğrudan reddediyor
      Neden hâlâ Xorg çalıştırıyorsun? Artık Wayland’e geçmiş olmalıydın, tarzında
      https://social.treehouse.systems/@marcan/110904454552941656
  • Raymond Chen bu konu hakkında onlarca yıldır içeriden bir bakış sunuyor: https://devblogs.microsoft.com/oldnewthing/

  • Windows API’sinin genel istikrarı sayesinde, Win32/DX’in Wine/Proton’ın muazzam çalışmasıyla Linux ve diğer işletim sistemlerinde çok kararlı ve güvenilir bir “evrensel” API hâline gelmesi ilginç. Oyunların Linux native sürüm çıkarmaktan vazgeçip doğrudan Proton için yayımlandığını görmeye devam ediyorum

  • Bu çılgınca değil; bir araçtan doğal olarak beklenen seviye bu. Çekicim, 30 yıl önce aldığım çivilerde hâlâ kusursuz çalışıyor
    Sürekli geriye dönük uyumluluğu bozan sallantılı bir temel üzerine bir şey inşa edemezsiniz. Sonunda geliştirmeye harcadığınız zamandan fazlasını bakıma harcarsınız. Sonra tekerleği yeniden icat edersiniz; kullanıcı açısından da o parlak yeni tekerlek mutlaka daha iyi değildir. Kullandığım yazılımların çoğu 10 yıldan eski; bazıları hâlâ güncelleniyor, bazıları güncellenmiyor ya da buluta taşındı, ben de memnuniyetle geride kaldım

  • Eskiden buna inanırdım, artık inanmıyorum
    Games for Windows – Live hizmetini kullanan Steam oyunlarından, hizmetin 2014’te kapanmasından sonra güncellenmeyenler Windows 10 ve sonrasında çalışmıyor. Çünkü ilgili hizmet DLL’i kaldırıldı. Bir süre insanlar üçüncü taraf sitelerden DLL indirerek çözdü ama artık o da olmuyor

    • DRM ya da ağ hizmeti olmayan eski oyunlar da grafik uyumluluğu yüzünden çalışmayabiliyor. Yine de cnc-ddraw bunların önemli bir kısmını hayata döndürüyor: https://github.com/FunkyFr3sh/cnc-ddraw
    • Yine de o oyunların korsan sürümleri hâlâ çalışıyor olabilir ;)
  • Daha “çılgın” örnekler de var
    z/OS (OS360, MVS olarak da bilinir) 1960’lardaki programları bile destekliyor; IBM’deki bir DE, Apollo 11 görevi zamanlarında derlenmiş bir programı hâlâ kullandıklarını söylemişti

    • Mainframe dünyasında bu olağan bir şey. Unisys (eski Univac), 1962’de çıkan Univac 1100 ile binary uyumlu Dorado mainframe’lere hâlâ sahip
    • DE ne demek? Ayrıca o programın ne iş yaptığını da söyledi mi?
      30 yıldan eski binary’leri çalıştıran ya da otomatik dönüştüren başka sistemler de var. POWER üzerindeki IBM i (i5/AS400), System/38 (1980) dönemindeki programları çalıştırabiliyor olmalı; X86-64 üzerindeki HPE NonStop (Tandem Guardian olarak da bilinir) ise 1970’lerin sonlarındaki özgün tescilli TNS sistemi ve 1991 MIPS sisteminin binary’lerini çalıştırabiliyor ya da dönüştürebiliyor
  • Windows’un geriye dönük uyumluluk konusunda takıntılı olduğu bilinir, ama DOS CLI uygulamaları için DOS alt sistemi fiilen donmuş durumda olduğundan bunun çok büyük bir zorluk olmadığı hissi var. Daha fazla gereksinimi olan DOS tarzı programları ya da erken dönem Win16 uygulamalarını çalıştırınca nasıl olur merak ediyorum. Örneğin 1986 tarihli Zortech C++ ve Phar Lap DOS extender ya da Windows 3.1’deki Minesweeper gibi şeyler çalışır mı?

    • O bir DOS uygulaması değil, Win32 konsol uygulaması. DOS uygulamaları (16 bit de olsa 32 bit de olsa) ya da Win16 uygulamaları yerel olarak çalıştırılmaz.
    • Zortech C++ bir süre kullandığım araçtı ve güzel anılarım var. Phar Lap’in çok derine müdahale ettiği için güncel Windows’ta çalışmasının zor olduğunu düşünüyorum, ama denemeye değer. Muhtemelen genişletilmiş/uzatılmış bellekle ilgili özelliklerin çoğu artık çalışmaz.
  • Bu hiç de büyük bir başarı olarak görülmemeli. Gündelik ve doğal bir şey sayılmalı; çalışmıyorsa da çok utanç verici ve kabul edilemez bir başarısızlık olarak görülmeli.
    2023’ün karmaşa standartlarına göre etkileyici değil demek istemiyorum. Kastım, hedeflememiz gereken normun bu olduğu.

    • Katılıyorum. Çoğu statik derlenmiş ikilinin çalışmayı bırakması için hiçbir neden yok.
  • Birileri Linux için de aynı şeyi söyleyecektir ve teknik olarak doğru, ama pratikte oldukça zor.
    Çekirdek ABI’si kararlı, fakat geri kalanı neredeyse saf kaos; bunun nedeni de Linux’ta uygulamaların genelde paketlenme biçimi. Uygulamanın kendisi yüklenebilse bile (a.out biçiminde değilse) büyük olasılıkla çoğu kütüphaneyi yüklerken başarısız olur. Sonuçta referans alınacak tüm bir Linux dağıtımı chroot’u ya da başka bir çalışma zamanı gerekir; 30 yıllık bir dağıtım arşivini bulup bulamayacağınız bile kesin değil. Üstelik çekirdek ABI’sinin gerçekten tek bit bile değişmediğini ve /proc ya da /sys gibi diğer arayüzlerin de değişmediğini varsaymak gerekir. /sys 30 yıl önce yoktu sanırım. Xorg uygulamasıysa protokol düzeyi uyumluluğa öğle yemeği paramı yatırmazdım.

    • Linux’ta da Windows’takiyle aynı şekilde çalışır. Gerekli dinamik kütüphaneler ve yapılandırma yoksa çalışmaz.
      Bunun neden Linux için eksi puan olup Windows için olmadığını anlamak zor.
  • Eski Mac yazılımlarının doğrudan çalışmaması beni hep üzmüştür. Apple’ın yeni mimarilere geçmesi kaçınılmaz olmuş olabilir. Ama birkaç yıl sonra emülatörün bozulması sorun.
    Microsoft’un müşterilerine gösterdiği bağlılık bu kadar şaşırtıcı bir şey olmamalı. Tüm şirketler böyle davranmalı.

    • Apple’ın da bir zamanlar 1. nesil iMac’e (300 MHz?) bile en yeni Mac OS X’i kurmaya izin verdiği dönemler vardı. RAM’i maksimuma çıkarmak gerekmiş olabilir, ama o kadarı yeterliydi ve gerçekten de oldukça kullanılabilirdi.