Neden hem TMP hem de TEMP ortam değişkeni var? (2015)

 (devblogs.microsoft.com)
1 puan yazan GN⁺ 2 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Windows'ta geçici dosya konumunu gösteren hem TMP hem de TEMP hâlâ bulunur; ikisi farklıysa hangisinin kullanılacağı programın nasıl yazıldığına bağlıdır
  • CP/M'de ortam değişkenleri yoktu; bu yüzden geçici dosya konumu her program için ayrı ayrı ayarlanmalıydı ve WordStar gibi programlar davranışı değiştirmek için çalıştırılabilir dosyanın belirli baytlarını patch'leme yöntemini kullanıyordu
  • MS-DOS, CP/M uyumluluğunu güçlü biçimde gözetirken ortam değişkenlerini ekledi; ancak ilk MS-DOS programları, CP/M'den gelen alışkanlık nedeniyle TEMP ya da TMP'yi neredeyse hiç kullanmadı
  • MS-DOS programları ortam değişkenlerini ayar saklama yöntemi olarak kullanmaya başlayınca TEMP ve TMP rekabet etmeye başladı; DISKCOPY ve EDIT gibi bazı programlar TMP'den önce TEMP'i arıyordu
  • MS-DOS 2.0'ın pipe uygulaması geçici dosya konumu olarak TEMP'i seçti, ancak Windows'un GetTempFileName işlevi önce TMP'yi kontrol ettiği için iki değişken birlikte varlığını sürdürdü

TMP ve TEMP ikisinin birden kalmasının arka planı

  • Windows ortam değişkenlerinde geçici dosya konumunu belirtmek için hem TMP hem de TEMP bulunur; ikisi birbirinden farklıysa hangisinin doğru kabul edileceği programa göre değişir
  • Belirli bir programın geçici dosyayı nereye oluşturacağı, o programın uygulanışına bağlıdır; Windows programları büyük olasılıkla GetTempFileName işlevini kullanır ve bu durumda TMP önceliklidir
  • Ortam değişkenleri ayar penceresinde TMP ile TEMP'in birlikte görünmesinin nedeni, tek bir tarafın standart olarak kesin biçimde yerleşmemiş olması ve tarihsel olarak farklı tercihlerin bir arada kalmasıdır

CP/M'de ortam değişkenleri yoktu

  • 1973 civarında mikro bilgisayarlarda yaygın olan işletim sistemi CP/M idi ve CP/M'de ortam değişkenleri yoktu
  • Ortam değişkenleri olmadığı için TMP ya da TEMP ortam değişkenleri de yoktu
  • Programa geçici dosya kaydetme konumunu belirtmek için program başına yapılandırma gerekiyordu; örneğin çalıştırılabilir dosyanın belirli baytlarını patch'leyerek geçici dosyaların konacağı sürücü harfi belirtiliyordu
  • WordStar gibi programlar, hangi bayt patch'lenirse hangi davranışın değişeceğini kılavuzlarında açıklıyordu ve yazıcı desteği gibi özel alt yordamlar eklenebilecek patch alanları da sunuyordu

MS-DOS ve ortam değişkenlerinin ortaya çıkışı

  • 1981'de 8086 işlemcisi ve MS-DOS ortaya çıktı; ikisi de CP/M'den güçlü biçimde etkilenmişti
  • MS-DOS'un ilk tasarım hedeflerinden biri, 8080 işlemcisi için yazılmış CP/M programlarının 8086 işlemcisi için MS-DOS programlarına makine çevirisiyle dönüştürülebilmesiydi
  • Bu çevirici; kendi kendini değiştiren kod, komutun ortasına atlama ve kodu veri olarak kullanma gibi sıra dışı tekniklerin kullanılmadığını varsayıyordu
  • 8080'ün H ve L yazmaçları, 8086'nın BH ve BL yazmaçlarına karşılık geliyordu; 8080'de hesaplanan adres erişiminde kullanılabilen yazmacın yalnızca HL olması, 8086'da AX, BX, CX ve DX arasından bellek erişiminde neden yalnızca BX'in kullanılabildiğinin sebebiydi
  • MS-DOS, CP/M uyumluluğunun yanında ortam değişkenlerini de ekledi; ancak mevcut CP/M programları ortam değişkeni kullanmadığı için ilk MS-DOS programları da ortam değişkenlerini kullanmadı
  • Kullanıcı TEMP ya da TMP ayarlayabiliyordu ama ilk programlar bunu dikkate almıyordu

Piyasada TEMP ve TMP rekabet etti

  • Zamanla ana hedefi MS-DOS olan programlar yazılmaya başlayınca, programlar ortam değişkenlerini ayar verisi saklama aracı olarak kullanmaya başladı
  • Geçici dosya konumunu belirtmek için TEMP ve TMP adlı ortam değişkenleri kullanılmaya başlandı ve ikisi de başlıca adaylar hâline geldi
  • Hangi değişkenin önce kontrol edileceği programın uygulanış tercihine bağlıydı
  • Birçok program her iki tarafı da desteklemek için hem TEMP hem de TMP'yi kontrol etti, ancak hangisine önce bakılacağı uygulamadan uygulamaya değişti
  • Eski DISKCOPY ve EDIT programları TMP'den önce TEMP'i arıyordu

MS-DOS 2.0'ın pipe özelliği ve TEMP

  • MS-DOS 2.0, bir programın çıktısını başka bir programın girdisine aktaran pipe özelliğini tanıttı
  • MS-DOS tek görevli bir işletim sistemi olduğu için, pipe işlevi ilk programın çıktısını geçici bir dosyaya yönlendirip programı sonuna kadar çalıştırdıktan sonra ikinci programı bu geçici dosyayı girdi olarak kullanacak şekilde başlatarak taklit ediliyordu
  • Bu özellik nedeniyle MS-DOS'un kendisinin de geçici dosyaları oluşturacağı bir konuma ihtiyaç duyması gerekiyordu
  • Bu geçici dosya konumunu denetleyen değişken olarak TEMP seçildi
  • COMMAND.COM TEMP'i seçmiş olsa da, diğer programların TEMP mi yoksa TMP mi kullanacağı yine her programın kendi tercihine bırakılmıştı

Windows'ta TMP'yi öne çıkaran bir yol oluştu

  • Windows da benzer bir süreç yaşadı, ancak ilk GetTempFileName uygulaması TEMP'ten önce TMP'yi kontrol edecek şekilde tasarlandı
  • Windows programları geçici dosya oluştururken GetTempFileName kullanırsa TMP'yi daha çok tercih etmiş olur
  • Bu nedenle “hangi değişken doğru?” sorusunun tek bir cevabı yoktur; programın hangi API'yi ya da kendi mantığını kullandığına göre sonuç değişir
  • Bugün de ortam değişkeni ayar penceresinde hem TMP hem de TEMP bulunur ve iki değişken geçici dosya konumu için birlikte varlığını sürdürür

İlgili okumalar

1 yorum

 
GN⁺ 2 시간 전
Hacker News yorumları

  • İlginçmiş. Benim dönemimden önceki bir şey, CP/M programlarını yama ile yapılandırdıklarını daha önce hiç duymamıştım

    • Evet, gerçekten böyle bir yöntem vardı ve yama kodunun Z80/8080 makine dili olması gerekiyordu
      Bu özellik sayesinde WordStar’ım için daha hızlı klavye ve ekran çıktı rutinlerini kendim yazmıştım
    • Evet, gerçekten vardı ve başlangıçta CP/M programı olan bazı yazılımlar DOS için WordStar 7.0 dönemine kadar uzun süre yaşamayı sürdürdü
      WordStar 7 belgelerinde, programın davranışını DOS’un debug.exe aracıyla değiştirmek için kullanılabilecek yama konumları olduğunu hatırlıyorum
    • Bugün bile bir ölçüde sürüyor. suckless’ın yaptığı işler genelde config.h değiştirilip yeniden derlenerek yapılandırılıyor
      https://suckless.org/
      Bu arada, bu sayfadaki başka bir alt başlıkta bundan zaten söz edildiğini sonradan fark ettim
    • Bu yöntem gerekliydi çünkü RAM ve disk alanı aşırı derecede sınırlıydı ve neredeyse her bilgisayarda bir assembler bulunuyordu
      Birçok CP/M programının 32K RAM ve yavaş 130K disketlerde, hatta bazen kasetlerde bile çalışması gerekiyordu. 64K RAM ve 360K disk varsa bu epey ayrıcalıklı sayılırdı
      O dönemde, bugünün aksine, programlar pazarın üst ucuna değil alt ucuna göre optimize edilirdi. Daha fazla sistemde çalışırlarsa daha çok satarlardı ve müşteriye donanım yükseltmesini dayatmazlardı
      Harici yapılandırma dosyaları ya da o dosyaları oluşturacak bir program için yer yoktu; komut satırı argümanlarını işlemek bile değerli baytlar tüketiyordu
      Bugün insanlar MacBook Neo’nun yalnızca 8,000,000,000 bayt RAM’i olduğundan şikâyet ediyor ama 1978’de 2,048 baytlık temel bir IDE bile yapılabiliyordu

  • Raymond’un blogunu seviyorum ama 1973’te mikro bilgisayarlarda CP/M’in yaygın olduğunu söylemek tuhaf
    1973’teki mikro bilgisayarlar, Intel Intellec gibi geliştirme sistemleri düzeyinde prototiplere daha yakındı ve işletim sistemleri yoktu. Kildall’ın 1973’te CP/M geliştirmeye başladığı doğru ama o zaman yalnızca PDP-10 ana bilgisayarındaki bir simülatörde çalışıyordu
    1979 olsa anlarım ama 1973 çok erken

    • Wikipedia’da CP/M’in 1974’te yaratıldığı yazıyor; dolayısıyla buradaki zaman çizelgesi kesinlikle kaymış görünüyor
    • 1979 ile 1973 arasındaki farkın, bugünkü zamanla 2020 arasındaki farkla aynı olması ilginç
      Böyle düşününce 2020’de ChatGPT’nin olmadığını fark ediyor insan

  • İlk geliştiricilerin neredeyse düşünmeden verdiği bir kararın onlarca yıl kalıcı olmasına iyi bir örnek

    • Kısa süre çalıştığım bir S&P500 ürününün temel tablolarından biri sonsuza kadar attornies adını taşıyacak. Çünkü ilk başta kimse yazım hatasını fark etmedi
    • Geçici kararlar kadar kalıcı bir şey yoktur

  • Programların TMP’yi seçmesinin nedeni muhtemelen MS-DOS’ta dosya uzantılarının en fazla 3 karakter olması ve geçici dosya adlarında .TMP uzantısının yaygın kullanılmasıydı

  • Unix programlarının http_proxy mi yoksa HTTP_PROXY mi okuyacağı konusunda tutarsız olmasına benziyor
    Günümüzde birçok program ikisini de kontrol ediyor ama kontrol sırası aynı olmayabiliyor

  • CP/M’den söz edilmesi kafa karıştırıcı. Yazar, bunun sonradan önemli olacağını söylüyor ama sonunda CP/M ya da 8080 CPU ile ilgisi olmadığını açıklıyor gibi görünüyor

    • Katılıyorum. Bu hikâyenin ne CP/M’le ne de 8080/8086 tarafına sapmayla çok ilgisi var
      Asıl mesele, Microsoft’un bunu bizzat kullanmasına rağmen standartlaştırmayı hiç düşünmemiş olması
    • Eğer CP/M yapılandırma için ortam değişkenleri kullanmış olsaydı, TMP ile TEMP arasında hangisinin kullanılacağı konusunda zaten bir standart oluşur ve DOS da onu izlerdi
      Ama asıl engel CP/M’de dizinlerin olmamasıydı, DOS 1.0’da da yoktu
    • Hangi cümleden söz ettiğini alıntılayabilir misin?

  • 1995 civarında Telstra’da, yani Australia Telecom’da, kurum genelinde yaklaşık 50 bin masaüstü vardı
    Bir gün herkesin ağ ana dizininde null adında küçük bir dosya belirdi; muhtemelen bir Unix kullanıcısı ilk kez bir .bat dosyası yazmayı denemişti
    Madem mevcut standartlar var, neden onları izleyelim ki. “Neden standartlaştıralım ki?” diye sormak isterdim ama bunun Kuzey Amerikalıları da şaşırtabileceğini düşündüm

    • Muhtemelen önce /dev/null denedi, olmayınca sadece null yaptı
      Aksi halde bunu bir Unix programcısının yapmış olması pek mantıklı değil. Daha olası olan, bir DOS programcısının NUL yerine yanlışlıkla null yazmış olması
    • Atmaya çalıştığı metnin ne olduğunu merak ediyorum
    • Bir Logitech sürücü kurulum programı da benzer bir şey yapmıştı
      Sabit diskte NULL adında bir dosya arıyordu; tabii .BAT dosyasında > NULL gibi bir ifade vardı

  • Dürüst olmak gerekirse, birçok programın ana dizine nokta dosyaları saçması yerine CP/M tarzı yama yapılandırması daha iyi olabilirdi

    • İnsanlar sadece XDG Base Directory Specification’a uysa, yapılandırma dosyalarının her yana saçılması sorun olmaz
      Firefox gibi direnen projeler de dahil olmak üzere giderek daha fazla proje bunu benimsiyor
    • suckless tarafındaki biraz sıra dışı felsefelerden biri de, projelerin genel olarak kaynak kod değiştirilip yeniden derlenerek yapılandırılması
      Modern açık kaynak anlayışı açısından bakınca benzer bir yaklaşım sayılabilir. Yine de genel çileciliği nedeniyle projeler herkese hitap etmeyebilir
    • Aslında her şeyin .config içinde olması gerekiyor
      Sorun, birçok uygulama geliştiricisinin kendi uygulamasının özel olduğunu ve ayrı bir dizini hak ettiğini düşünmesi
    • Merkezî ikili kayıt defterinin orasına burasına dağılmış ayarlardansa, grep ile aranabilen ve metin düzenleyiciyle yönetilebilen nokta dosyalarını tercih ederim
      Belki de sadece alışkanlıktandır
    • Keşke bu konu standartlaştırılsa. .config klasörünü bir şekilde zorunlu kılabilen bir dağıtım varsa, benim için kazanan odur
      Gerçi bunun için zamanın çoktan kaçmış olabileceğini de düşünüyorum

  • Bunun bu kadar kafa karıştırıcı olduğunu bilmiyordum
    Çıkarılacak ders herhalde her zaman aynı yolu işaret etmek, yoksa başına iş almak

  • Microsoft’un bu tür can sıkıcı şeylerini onlarca yıldır gündeme getiriyorum
    Eskiden orada her şeyi biliyormuş gibi davranan bir “kıdemli geliştirici” mutlaka bir cevap verirdi. “temp temporary demek, tmp ise troubleshoot my pc; hata ayıklama günlükleri için. O yüzden ben kıdemliyim, sen değilsin” gibi
    Ben de daha kıdemli hale geldikçe, şüphe duymakta haklı olduğumu gördüm; şimdi de eski Microsoft geliştiricileriyle konuşunca bunun bir hata olduğunu ama geriye dönük uyumluluk yüzünden korunduğunu söylüyorlar
    Ama sonra insan, bu mazeretin neden geçerli olduğunu sorguluyor. Çünkü geriye dönük uyumluluğu bahane ederken, New Outlook gibi temel uyumluluğu ve gerçek iş akışlarını sık sık bozan değişiklikleri yine de dayatıyorlar. Sonra da “Ben kötü geliştirici değilim, yenilere sorun” diye sıyrılıyorlar
    Yeni gelenlere sormak da mümkün olmuyor; onlar LeetCode tarzı eleme bariyerlerinin arkasına gizlenmiş durumda. Bu yüzden bu gerçek sorunların düzeltilmemesi ve New Outlook gibi şeylerin çıkması da şaşırtıcı değil. O eski kıdemli geliştirici artık orada çalışıyor, gerçek geliştiriciler ise emekli oldu
    Kullanıcının ana dizinindeki Documents klasörünün rastgele programlar tarafından uygunsuz biçimde kullanılması ya da OneDrive’ın onu yanlışlıkla zorla silmesi gibi konularda Microsoft’tan makul görünen bir yanıt alsanız bile, 6 ay içinde Microsoft rastgele bir değişiklik dayatıp davranışı daha kötü bir yöne çevirerek o temel mantığı çökertiyor
    Notepad de benzer. Geliştirici röportajlarında risk sıfır olmalı diye son derece basit bir program olması gerektiği söyleniyordu; sonra içine Microsoft hesabı girişi ve Copilot eklendi
    LeetCode usulü geliştirici tavrının ve Microsoft kültürünün tüm sektörü bozduğunu düşünüyorum. Sakin bir tartışma yürümüyor; iş dönüp dolaşıp “Microsoft’ta çalışmıyorsun, o yüzden argümanın geçersiz” noktasına geliyor
    Google Chrome’un yönetici yetkilerini aşmak için AppData altına kurulması olayı özellikle aklımda kaldı. O özelliğin asıl amacı, üçüncü tarafların yönetici yetkisi olmadan kurulum yapması değildi
    Ama o dönemde Chrome iyiydi ve kilitli kurumsal bilgisayarlardaki milyonlarca makineye üçüncü taraf istisna programları dağıtmanın yarattığı karmaşayla uğraşmak gerekiyordu; şimdi geliştiriciler bunu sonradan amaçlanmış bir özellikmiş gibi yeniden çerçeveliyor