Windows 3.1 için yapay zeka asistanı WinGPT
(dialup.net)- WinGPT, Windows 3.1 üzerinde de OpenAI API tabanlı bir chatbot çalıştırmayı amaçlayan bir proje; 386 gibi eski PC'lerden modern yapay zeka servislerini çağırmaya odaklanıyor
- Uygulama C ve standart Windows API tabanlı; Open Watcom v2 sayesinde Windows 11 üzerinde bile 16 bit Windows için derleme yapılabiliyor
- OpenAI API sunucusuna bir proxy olmadan doğrudan TLS 1.3 ile bağlanıyor, ancak bu TLS uygulamasının güvenli bir uygulama olmadığı özellikle belirtiliyor
- Windows 3.1'in temel UI kontrolleri sınırlı olduğundan, durum çubuğu gibi ögeler de doğrudan uygulanmak veya eski kamu malı kodlar değiştirilmek zorunda kalmış
- Bellek kısıtları nedeniyle yanıtların kısa tutulması isteniyor ve önceki konuşma turları gönderilmiyor; bu yüzden konuşma bağlamı korunamıyor
Windows 3.1'de OpenAI API çağırma deneyi
- WinGPT, Windows 3.1 için bir yapay zeka asistanı; OpenAI API üzerinden soru yanıtlama, şaka üretme, belge ve hesap tablosu taslağı hazırlama gibi kullanım senaryoları öne sürülüyor
- Dipnotta bu açıklamanın hiciv olduğu ve bu tür görevleri güvenilir biçimde yerine getiremediği, dolayısıyla buna bel bağlanmaması gerektiği belirtiliyor
- Uygulama C ve standart Windows API tabanlı
- Derleyici olarak Open Watcom v2 kullanılıyor
- Open Watcom v2, Windows 11 üzerinde bile 16 bit Windows hedefi için çapraz derleme yapabiliyor
- OpenAI API sunucusuna doğrudan TLS 1.3 ile bağlanıyor
- TLS'i modern bir makinede sonlandıran bir proxy gerekmiyor
- “Modern TLS on 16-bit Windows” yazısında uygulama yöntemi ve zorluklar ele alınıyor; ayrıca bu TLS uygulamasının güvenli olmadığı açıkça belirtiliyor
Eski Windows API'sinin yarattığı UI uygulama zorlukları
- Windows 3.1'de yalnızca temel Windows API kullanıldığında UI oluşturma yetenekleri oldukça sınırlı
- Arayüzün büyük bölümü C kodunda doğrudan oluşturulmuş; pencere boyutu değiştiğinde her bileşenin doğru boyutta kalması için yeniden boyutlandırma mantığı da yazılmış
- Standart kontroller push button, check box, radio button ve edit box ile sınırlı
- Durum çubuğu uygulamasında Windows 3.1'in sınırları özellikle belirginleşiyor
- File Manager ve Control Panel'de durum çubuğu var, ancak Microsoft bunu Windows 95'e kadar genel uygulama geliştiricilere yaygın biçimde sunmamış
- ChatGPT'ye durum çubuğunun nasıl kullanılacağı sorulduğunda, yalnızca sonraki Windows sürümlerinde bulunan başlık dosyalarını önerdi; tekrar sorulduğunda ise görünüşe göre var olmayan bir UI kütüphanesi adı uydurdu
- Sonunda Philip J. Erdelsky'nin 1997 tarihli status bar implementation kodu kullanılmış ve Microsoft programlarındaki durum çubuklarına piksel düzeyinde daha çok benzemesi için değiştirilmiş
- Simgeler Borland Image Editor ile hazırlanmış
- Windows 3.1'de program simgeleri 32x32 boyutunda ve Program Manager ile görev değiştiricide gösteriliyor
- Daha sonraki Windows sürümlerinde görüntülenen 16x16 simgeler de ayrıca hazırlanmış
Bellek kısıtları ve çalışma koşulları
- Windows 3.1 makinelerindeki bellek kısıtları nedeniyle API istekleri ve yanıt işleme sırasında bellek kullanımını azaltmak gerekiyor
- Modern API'lerin JSON yanıtları boyut açısından optimize edilmiş değil ve OpenAI API de buna istisna değil
- Yanıtları küçük tutmak için modele kısa cevap vermesi isteniyor
- Önceki konuşma turlarının metni API çağrısına dahil edilmediğinden önceki konuşma bağlamı kullanılamıyor
- WinGPT, GNU GPL v2 lisansı ile sunuluyor
- Windows 3.1 sonrası 16 bit veya 32 bit Windows sürümlerinde çalışıyor
- Bir Winsock uygulaması gerekiyor; Microsoft TCP/IP-32 3.11b yüklü Windows 3.11 for Workgroups ve varsayılan Windows 2000 üzerinde test edilmiş
- 64 bit Windows'ta çalışmıyor, ancak Wine üzerinde çalıştırılabiliyor
- OpenAI ile iletişim kurmak için bir OpenAI API anahtarı gerekiyor; çalıştırdıktan sonra
File | Options...menüsünden secret key giriliyor - İndirme: Binaries for 16-bit and 32-bit Windows
- Kaynak kodu modified WolfSSL source code içinde yer alıyor ve konumu
watcom16/wingpt
2 yorum
hahahahahahahahahahahaha
Hacker News görüşleri
Dönemin MS Office sürümüne de koymak güzel olurdu
O dönemin gerçek ofis malzemelerini skeuomorfik biçimde kişileştiren bir karaktere dönüştürülebilir, mesela lastik bant… ya da… ataç gibi bir şey…
Windows 3.1'de TLS 1.2 ve 1.3 çalıştırıp WinGPT'nin modern bir makinedeki TLS sonlandırmasına bağımlı olmadan doğrudan OpenAI sunucularına bağlanmasını sağlayan ayrı bir bölüm de var: https://www.dialup.net/wingpt/tls.html
Kesinlikle okumaya değer. IoT gibi derin gömülü ortamlarda, hatta bank switching kullanan 8 bit CPU'larda bile TLS 1.2 desteği sık görüldüğü için, kod ve veriyi 64KB içine sığdırarak bir TLS uygulaması yerleştirmenin zor olmuş olması şaşırtıcı geliyor
Biraz eski işletim sistemlerinin internete erişimde zorlanması üzücü
Windows 3.1, 95, 98 dönemi gerçekten özleniyor. Arayüz sanki ondan sonra hep daha kötüye gitti
386 ya da Pentium açtığımda GUI'nin ne kadar temiz ve stressiz olduğuna her seferinde şaşırıyorum. Apple/Google tarzı düşük kontrastlı popup cehenneminden gerçekten bıktım
Şimdi yerelleştirme olunca arayüzün yarısında "Tap to...." gibi etiketler çıkıyor. Harika modern UI araçları ve onları kullanan yıldız geliştiriciler, sürüklenebilir tek bir sidebar bile yapamıyor çoğu zaman
Alanı CPU süresiyle takas etmek için SAX tarzı ayrıştırma kullanılabilir
SAX tarzı ayrıştırma, ağacı yukarıdan aşağı dolaşırken her düğüm ziyaretinde olay üretir. JSON'u tamamen ayrıştırmaya kıyasla gereken bellek ihmal edilebilir düzeydedir ve JSON için özel bir SAX tarzı ayrıştırıcı yazmak da çok zor görünmüyor. Bakılabilecek mevcut SAX tarzı JSON ayrıştırıcıları da var
[1]: https://en.wikipedia.org/wiki/Simple_API_for_XML
[2]: https://rapidjson.org/md_doc_sax.html
Evet. JSMN(https://github.com/zserge/jsmn) kullanıyorum; bu, her token'ı sırayla gezen bir akış ayrıştırıcısı olduğu için JSON yanıtının bellekte yalnızca tek bir kopyası bulunuyor
Mümkün olduğunca yeni ara bellek tahsislerinden de kaçınıyorum. Örneğin JSON dizelerindeki ters eğik çizgi kaçışlarını çözerken, ters eğik çizgi olmayan karakterleri bellekte öne taşıyıp null sonlandırıcıyı da daha öne alarak diziyi kısaltan yıkıcı bir döngü kullanıyorum. Günümüzde pek yapılmayan bir yöntem ama dediğiniz gibi, biraz CPU süresi harcayıp az miktarda alan kazanılabiliyor :)
void DestructivelyUnescapeStr(LPSTR lpInput) {
int offset = 0;
int i = 0;
while (lpInput[i] != '\0') {
if (lpInput[i] == '\') {
offset++;
} else {
lpInput[i - offset] = lpInput[i];
}
i++;
}
lpInput[i - offset] = '\0';
}
Şu anda yazmakta olduğum metin kutusu kontrolünü destekleyen altyapının WinGPT'nin tamamından daha fazla sistem kaynağı tüketiyor olma ihtimali yüksek
Bu, geliştirici üretkenliğinde küçük bir artış uğruna belleğin kelimenin tam anlamıyla birkaç basamak mertebesinde israf edildiğini gösteriyor. Saf Windows kontrol programlama zor muydu? Elbette zordu, ama Win95 dönemindeki Delphi ya da VB'nin modern UI toolkit'lerden çok daha üretken olduğu ve ortaya çıkan uygulamaların çok daha az kaynak kullandığı da söylenebilir. Eksik olan temel şeyler mobil desteği ve DPI farkındalığıydı
"Geliştirici üretkenliğinde küçük bir artış" ifadesi bana açıkçası hafif kalıyor
Çocukken native code ile uğraşarak yaptığım şeylerin çoğu artık web tarayıcısını hedefleyen hazır kütüphaneler ve araçlarla neredeyse herkesin yapabileceği işler haline geldi. Bu başlı başına etkileyici bir başarı ve kötü bir şey değil. En üzücü tarafı, tarayıcının genel olarak "daha iyi" seçenek haline gelmesiyle native app'leri öldürüyor olması
Günümüz yazılım şirketleri, ağ hizmetlerine web erişimi sunmaları gerektiğini doğal kabul ediyor; bu yüzden önce web'i yapıyorlar. Sonra iPhone, Windows, Android, macOS ve Linux'u da desteklemek istiyorlar. Her platformu bir ölçüde kapsayan seçenekler var ama o noktaya gelindiğinde zaten tarayıcıda bir kavram kanıtı elde edilmiş oluyor ve tek bir NPM kurulumu ile ayrı pencerede çalışan, kurulum programı ve dağıtım sistemi de eklenmiş bir şey olarak sevk etmek mümkün oluyor. Mükemmel değil ama yapılabiliyor
Windows, macOS, Android ve iPhone'da DOM ve native UI'yi verimli biçimde hedefleyebilen; IME ve platforma özgü anlambilime sahip native metin girişini, ekran okuyucu entegrasyonlu erişilebilirliği, farklı ekran boyutlarına göre tepkisel UI değişimlerini ve kesirli ölçeklendirmeyi doğru ele alan sağlam ve hızlı DPI bağımsız görsel öğeleri destekleyen üretim kalitesinde, verimli bir native GUI framework'ü olsaydı, sorun daha küçük olurdu. Kolay bir iş tabii?
Ama öyle bir şey yok. Delphi VCL’i ya da saf Win32’yi seviyorum, ancak onlar da gereksinimlerin çoğunu karşılamıyor. Tüm bu platformları desteklemek çok zor. Tarayıcı bunu oldukça iyi yapıyor ve derin platforma özgü kod yazarken başvurulabilecek en iyi örnek kod kaynaklarından biri de yine o. Üstelik zaten çoğu şey web’i hedefliyor ve tarayıcı motoru da sonuçta “native code” olduğu için, tarayıcı ortamında da çalışan izomorfik bir native code çözümü üretmeye çalışmaktansa, zaten native code çalıştıran bir platformla birlikte tarayıcıyı ya da en azından bir JS motorunu dağıtmak çok daha kolay
"Çok daha üretken olduğu da söylenebilir" kısmını biraz daha açabilir misin?
Üretkenliğin içine dağıtım kavramı da girmeli. Delphi/VB, dönemin standardına uygun şekilde bu soruyu tamamen görmezden geldi.
Basit bir zip yardımcı programıysa, güvenlik duvarı içindeki LAN’da bir yerdeki ağ sürücüsüne tek bir EXE kopyalamak yeterliydi. Windows, ikonu ve string yükleme gibi şeyler için ikili dosyanın içine yarı dosya sistemi benzeri bir yapı koymuştu ve bu da yeterliydi. DLL’ler ve registry girdileri gerektiren daha karmaşık uygulamalarda ise yüzlerce dolar verip InstallShield satın almanız ve InstallScript öğrenmeniz gerekiyordu. MSI ve WiX çıkana kadar arada bir seçenek yoktu ve 1990’ların ortalarına kadar Microsoft interneti egzotik bir moda gibi görüyordu; düşük bant genişliği nedeniyle yazılımı ağ üzerinden dağıtmayı pratik bulmuyordu. Yazılım CD-ROM içindi ve “shipping” gerçekten gemiyle sevkiyat demekti
Sorun şu ki insanlar, saf üretkenlikten bile daha fazla, neredeyse her şeyin üstünde iterasyon hızına değer veriyordu. Dünya Delphi’den daha hızlı değişiyordu. Borland, tarayıcıyı zorla uygulama gibi kullanma eğiliminin dile getirilemeyen temel bir ihtiyacı yansıttığını fark edip Object Pascal yorumlayıcısı benzeri bir şey geliştirebilirdi. Örneğin bir "Delphi Browser" yapsalardı benimsenebilirdi, ama kod tabanı temelden native Windows uygulamaları üretmeye göre şekillendiği için böyle bir dönüşüm zor olurdu. Ayrıca Borland, Windows platformunda daha çok bir misafir gibiydi ve Microsoft’un yönünü takip etme eğilimindeydi. Microsoft, web ile Windows dünyasını birleştirmenin yolu olarak ActiveX’i öne çıkardı ve Borland, ActiveX’in insanların ihtiyaçlarını karşılamayacağını çok geç fark etti. İlk başta web’i rakip olarak görmedi, sonra onu Delphi uygulamaları için yalnızca basit bir taşıma aracı gibi gördü, daha sonra da Delphi ile web sunucusu kullanımını itmeye çalıştı ama güçlü olduğu alan o değildi
Buradan çıkarılacak ders, insanların söylediklerinden değil gerçekten ne yaptıklarından öğrenilmesi gereken ifade edilmemiş tercihlerin varlığı ve dağıtımın ezici önemidir. Dağıtım, bugün çoğu web rakibi için bile hâlâ kör nokta. Geçen yıla kadar, her uygulama çalıştırılışında daima yenilenen web tarzı dağıtıma sahip Delphi benzeri platform neredeyse yoktu. Electron bile yalnızca tamamen asenkron, masaüstü tarzı güncellemeler sunuyor. Ben, native platform kısıtları içinde masaüstü uygulaması dağıtımını düzeltmeye çalışan küçük bir şirket işletiyorum ve aggressive updates adında web tarzı bir dağıtım modu ekledim (https://hydraulic.dev/). Bu modda her çalıştırmada güncelleme kontrolü yapılıyor; dolayısıyla kullanıcıyı ara sıra uygulamayı yeniden başlatmaya ikna edebiliyorsanız ya da uygun zamanda zorla yeniden başlatabiliyorsanız, çok hızlı iterasyon yapabilirsiniz. Bu, bir SPA’de sekmeyi kapatıp yeniden yüklemesini istemekten farklı değil
Bu yüzden asıl eksik olanın mobil ve DPI olduğu fikrine katılmıyorum. Delphi, VB, GTK, Cocoa ve diğerleri, akıllı telefonlar önem kazanmadan önce zaten masaüstünü kaybetmişti. İyi bir dağıtım/güncelleme sistemi yoktu ve düzeltmeleri ile değişiklikleri anında ulaştırabilme yeteneği, diğer tüm özelliklerin toplamından daha önemliydi
Teknolojik ilerleme hızı o kadar arttı ki, sanki kendi kültürümüzden kaynaklanan bir kültür şoku, yani gelecek şoku yaşamaya başladık. Bu hız, yaşamlarımız içinde daha da artacak.
Windows 3.1 yazılımlarına tekrar bakmak güzel. Retro meraklıları için bunu da bırakayım: https://www.xfce-look.org/p/1016410
En etkileyici kısım native TLS
Modern kriptografinin, optimize edilmesi zor sayısal hesap yükü nedeniyle eski CPU’larda kullanılamadığını duymuş gibi hatırlıyorum. Anahtar değişim algoritmalarının bazı adımları o kadar uzun sürüyormuş ki sunucu zaman aşımına uğrayabiliyormuş. Ama anlaşılan eski ve yavaş bir 386 için bu sorun değil?
Gerçek zamanlı video şifreleme gibi gömülü olmayan kullanım alanlarında belki böyle olabilir, ama herkes internete en yeni iPhone ile bağlanmıyor
Gerçekten çok havalı. Bunu gerçek Windows 3.1 makinelerimden birinde deneyeceğim galiba :)
Bir öneri olarak, Options iletişim kutusunda sistem prompt’unu özelleştirebilmek güzel olurdu. 1992 ayarı eğlenceli ama biraz kısıtlayıcı. Retro bir bilgisayarda sorun çözmeye çalışıyorsanız, modern bir bilgisayarı ya da akıllı telefonu çıkarmak yerine bunu kullanmak bir ölçüde mantıklı olabilir
Windows 3.1’de Win32s kullanırsanız segmentli bellek modeliyle uğraşmanız gerekmez ve 64 bit Windows’ta da çalışabilir