WinGPT, asisten AI untuk Windows 3.1
(dialup.net)- WinGPT adalah proyek untuk mencoba menjalankan chatbot berbasis OpenAI API bahkan di Windows 3.1, dengan fokus pada pemanggilan layanan AI modern dari PC lawas seperti 386
- Implementasinya berbasis C dan Windows API standar, dan berkat Open Watcom v2, build untuk Windows 16-bit tetap bisa dibuat bahkan di Windows 11
- Koneksi ke server OpenAI API dilakukan langsung dengan TLS 1.3 tanpa proxy, tetapi disebutkan secara jelas bahwa implementasi TLS ini bukan implementasi yang aman
- Karena kontrol UI bawaan Windows 3.1 sangat terbatas, elemen seperti bilah status pun harus diimplementasikan sendiri atau dengan memodifikasi kode domain publik lama
- Karena keterbatasan memori, aplikasi meminta jawaban singkat dan tidak mengirim giliran percakapan sebelumnya, sehingga konteks percakapan tidak bisa dipertahankan
Eksperimen memanggil OpenAI API dari Windows 3.1
- WinGPT adalah asisten AI untuk Windows 3.1 yang mengusung penggunaan seperti tanya jawab, lelucon, dan penulisan draf dokumen maupun spreadsheet melalui OpenAI API
- Dalam catatan kaki dijelaskan bahwa deskripsi ini adalah satire, dan pengguna diminta untuk tidak bergantung padanya karena fungsi-fungsi tersebut tidak dapat dijalankan secara andal
- Implementasinya berbasis C dan Windows API standar
- Kompilernya menggunakan Open Watcom v2
- Open Watcom v2 memungkinkan cross-compile untuk target Windows 16-bit bahkan di Windows 11
- Koneksi ke server OpenAI API dilakukan langsung dengan TLS 1.3
- Tidak diperlukan proxy yang melakukan terminasi TLS di mesin modern
- Di “Modern TLS on 16-bit Windows”, dibahas cara implementasi dan kesulitannya, serta disebutkan bahwa implementasi TLS ini tidak aman
Tantangan implementasi UI akibat Windows API yang kuno
- Di Windows 3.1, jika hanya memakai Windows API bawaan, kemampuan membangun UI sangat terbatas
- Sebagian besar UI dibuat langsung di kode C, dan logika resize juga ditulis agar tiap komponen tetap memiliki ukuran yang benar saat ukuran jendela berubah
- Kontrol standar terbatas pada push button, check box, radio button, dan edit box
- Keterbatasan Windows 3.1 terlihat sangat jelas saat mengimplementasikan bilah status
- File Manager dan Control Panel memang punya bilah status, tetapi Microsoft tidak menyediakannya secara luas untuk pengembang aplikasi umum sampai Windows 95
- Saat ChatGPT ditanya cara memakai bilah status, ia malah memberikan header file yang hanya ada di versi Windows yang lebih baru, dan ketika ditanya lagi, ia mengarang nama library UI yang tampaknya tidak pernah ada
- Akhirnya digunakan implementasi status bar dari Philip J. Erdelsky tahun 1997, lalu dimodifikasi agar secara piksel lebih mirip dengan bilah status di program Microsoft
- Ikon dibuat dengan Borland Image Editor
- Ikon program di Windows 3.1 berukuran 32x32 dan ditampilkan di Program Manager serta pengalih tugas
- Ikon 16x16 untuk versi Windows yang lebih baru juga dibuat secara terpisah
Keterbatasan memori dan syarat menjalankan aplikasi
- Karena keterbatasan memori pada mesin Windows 3.1, penggunaan memori harus ditekan saat memproses permintaan dan respons API
- Respons JSON dari API modern tidak dioptimalkan untuk ukuran, dan OpenAI API juga tidak terkecuali
- Agar respons tetap kecil, model diminta untuk menjawab secara singkat
- Karena teks dari giliran percakapan sebelumnya tidak disertakan dalam pemanggilan API, konteks percakapan sebelumnya tidak dapat dimanfaatkan
- WinGPT menggunakan lisensi GNU GPL v2
- Dapat berjalan di Windows 16-bit atau 32-bit setelah era Windows 3.1
- Membutuhkan implementasi Winsock, dan telah diuji di Windows 3.11 for Workgroups dengan Microsoft TCP/IP-32 3.11b terpasang, serta Windows 2000 bawaan
- Tidak berjalan di Windows 64-bit, tetapi bisa dijalankan di Wine
- Untuk berkomunikasi dengan OpenAI, dibutuhkan OpenAI API key, dan setelah dijalankan secret key dimasukkan melalui
File | Options... - Unduhan: Binaries for 16-bit and 32-bit Windows
- Source code disertakan dalam modified WolfSSL source code, dengan lokasi di
watcom16/wingpt
2 komentar
Wkwkwkwkwkwkwkwkwkwkwk
Komentar Hacker News
Sepertinya akan cocok juga jika dimasukkan ke versi MS Office pada masa itu
Bahkan bisa dibuat sebagai karakter antropomorfik skeuomorfik dari perlengkapan kantor sungguhan pada zaman itu, misalnya karet gelang… atau… sesuatu seperti penjepit kertas
Ada bagian terpisah tentang bagaimana TLS 1.2 dan 1.3 dijalankan di Windows 3.1 sehingga WinGPT bisa terhubung langsung ke server OpenAI tanpa bergantung pada terminasi TLS dari mesin modern: https://www.dialup.net/wingpt/tls.html
Sangat layak dibaca. Di lingkungan embedded yang sangat dalam seperti IoT, bahkan pada CPU 8-bit yang memakai bank switching, dukungan TLS 1.2 cukup sering ada, jadi cukup mengejutkan bahwa sulit memasukkan implementasi TLS ke dalam 64KB kode dan data
Agak menyedihkan ketika sistem operasi lama kesulitan mengakses internet
Sangat rindu era Windows 3.1, 95, dan 98. Antarmukanya terasa hanya makin buruk setelah itu
Setiap kali menyalakan 386 atau Pentium, selalu terkejut lagi betapa rapi dan minim stres GUI-nya. Sudah benar-benar lelah dengan neraka popup kontras rendah ala Apple/Google
Sekarang, setelah dilokalkan, setengah UI malah menampilkan label seperti "Tap to....". Dengan semua alat UI modern yang hebat dan para developer bintang yang memakainya, sering kali mereka bahkan tidak bisa membuat satu sidebar yang bisa di-drag
Untuk menukar ruang dengan waktu CPU, bisa memakai parsing gaya SAX
Parsing gaya SAX menelusuri pohon dari atas ke bawah dan memicu event saat setiap node dikunjungi. Dibandingkan mem-parsing JSON secara penuh, memori yang dibutuhkan nyaris bisa diabaikan, dan menulis parser JSON kustom bergaya SAX pun tampaknya tidak terlalu sulit. Ada juga parser JSON bergaya SAX yang sudah ada sebagai referensi
[1]: https://en.wikipedia.org/wiki/Simple_API_for_XML
[2]: https://rapidjson.org/md_doc_sax.html
Betul. Saya memakai JSMN(https://github.com/zserge/jsmn), parser streaming yang mengunjungi tiap token secara berurutan, jadi hanya ada satu salinan respons JSON di memori
Saya juga sebisa mungkin menghindari alokasi memori perantara baru. Misalnya, saat melepaskan escape backslash pada string JSON, saya memakai loop destruktif yang memindahkan karakter non-backslash ke bagian depan memori dan memindahkan null terminator lebih ke depan untuk memotong string. Ini hampir tidak pernah dilakukan di lingkungan modern, tetapi seperti yang Anda bilang, sedikit ruang bisa dihemat dengan menukar waktu CPU :)
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';
}
Sangat mungkin infrastruktur pendukung untuk kontrol kotak teks yang sedang saya pakai untuk mengetik sekarang memakan lebih banyak sumber daya sistem daripada WinGPT secara keseluruhan
Ini menunjukkan bahwa demi sedikit peningkatan produktivitas developer, kita benar-benar memboroskan memori sampai beberapa orde besaran. Apakah pemrograman kontrol Windows murni itu sulit? Tentu saja. Tapi bisa juga dibilang Delphi atau VB di Win95 jauh lebih produktif daripada toolkit UI modern, dan aplikasi yang dihasilkan memakai sumber daya jauh lebih sedikit. Kekurangan utamanya saat itu kurang lebih hanya dukungan mobile dan kesadaran DPI
Ungkapan "sedikit peningkatan produktivitas developer" menurut saya terus terang meremehkan
Hal-hal yang dulu saya susah payah buat dengan kode native waktu kecil sekarang hampir bisa dilakukan siapa saja dengan library dan alat siap pakai yang menargetkan web browser. Itu sendiri pencapaian yang luar biasa dan bukan hal buruk. Yang paling disayangkan adalah ketika browser secara keseluruhan menjadi opsi yang "lebih baik", lalu aplikasi native jadi mati
Perusahaan software masa kini menganggap wajar bahwa mereka harus menyediakan akses web ke layanan jaringan, jadi mereka membuat versi web lebih dulu. Setelah itu mereka ingin mendukung iPhone, Windows, Android, macOS, dan Linux. Ada beberapa pilihan yang bisa menutupi sebagian platform itu, tetapi pada titik itu biasanya sudah ada semacam proof of concept di browser, dan dengan sekali instal NPM, itu bisa dikirim sebagai jendela terpisah lengkap dengan installer dan sistem distribusi. Tidak bagus, tapi bisa dilakukan
Kalau ada framework GUI native yang efisien dengan kualitas production yang bisa secara efisien menargetkan DOM dan UI native di Windows, macOS, Android, dan iPhone; mendukung input teks native dengan IME dan semantik khusus platform; aksesibilitas lewat integrasi screen reader; perubahan UI responsif untuk berbagai ukuran layar; serta elemen visual yang tangguh dan cepat, independen DPI, dan menangani skala pecahan dengan benar, mungkin masalahnya akan lebih ringan. Mudah, kan?
Tetapi tidak ada yang seperti itu. Saya menyukai Delphi VCL atau Win32 murni, tetapi keduanya juga tidak memenuhi sebagian besar kebutuhan. Mendukung semua platform ini sangatlah sulit. Browser melakukan pekerjaan ini dengan cukup baik, dan juga merupakan salah satu sumber contoh kode terbaik untuk dirujuk saat menulis kode spesifik platform yang mendalam. Lagi pula, pada akhirnya kebanyakan memang menargetkan web, dan mesin browser juga merupakan "kode native", jadi jauh lebih mudah mendistribusikan browser atau setidaknya mesin JS bersama platform yang sudah menjalankan kode native daripada membuat solusi kode native isomorfik yang juga berjalan di lingkungan browser
Bisa dijelaskan lebih lanjut bagian "bisa juga dianggap jauh lebih produktif"?
Produktivitas juga harus mencakup konsep distribusi. Pada masa itu, Delphi/VB sepenuhnya mengabaikan pertanyaan ini sesuai standar zaman
Jika itu utilitas zip sederhana, cukup salin satu EXE ke suatu network mount di dalam LAN di balik firewall, dan selesai. Windows menyediakan semacam pseudo-filesystem di dalam biner untuk memuat ikon dan string, dan itu sudah cukup. Untuk aplikasi yang lebih kompleks yang memerlukan DLL dan entri registry, Anda harus membayar ratusan dolar untuk membeli InstallShield dan mempelajari InstallScript. Sebelum MSI dan WiX muncul, tidak ada jalan tengah, dan hingga pertengahan 1990-an Microsoft masih menganggap internet sebagai tren eksotis sesaat, serta menilai distribusi perangkat lunak lewat jaringan tidak praktis karena bandwidth rendah. Perangkat lunak dibuat untuk CD-ROM, dan pengiriman benar-benar berarti mengangkutnya dengan kapal
Masalahnya adalah orang-orang ternyata menganggap kecepatan iterasi hampir lebih penting daripada produktivitas murni. Dunia berubah lebih cepat daripada Delphi. Borland sebenarnya bisa saja menyadari bahwa tren memaksa browser dipakai seperti aplikasi mencerminkan kebutuhan mendasar yang tak terucapkan, lalu membuat sesuatu seperti interpreter Object Pascal. Misalnya, jika mereka membuat "Delphi Browser", kemungkinan itu akan diadopsi, tetapi codebase-nya pada dasarnya disusun untuk menghasilkan aplikasi Windows native sehingga pergeseran seperti itu mungkin sulit. Selain itu, Borland lebih seperti tamu di platform Windows dan cenderung mengikuti arah Microsoft. Microsoft mendorong ActiveX sebagai cara menjembatani dunia web dan Windows, dan Borland terlambat menyadari bahwa ActiveX tidak akan memenuhi kebutuhan orang. Awalnya mereka tidak melihat web sebagai pesaing, lalu melihatnya sebagai sekadar sarana pengangkut aplikasi Delphi, dan belakangan mendorong penggunaan Delphi untuk web server, padahal kekuatannya tidak cocok untuk itu
Pelajaran di sini adalah pentingnya preferensi tak terucapkan yang harus dipelajari dengan melihat apa yang benar-benar dilakukan orang, bukan apa yang mereka katakan, serta betapa pentingnya distribusi secara mutlak. Distribusi bahkan hingga kini masih menjadi titik buta bagi sebagian besar pesaing web modern. Bahkan sampai tahun lalu, hampir tidak ada platform mirip Delphi yang memiliki distribusi ala web yang selalu diperbarui setiap kali aplikasi dijalankan. Bahkan Electron pun hanya menyediakan pembaruan ala desktop yang sepenuhnya asinkron. Saya menjalankan perusahaan kecil yang membuat produk untuk memperbaiki distribusi aplikasi desktop dalam batasan platform native, dan saya menambahkan mode distribusi ala web bernama aggressive updates(https://hydraulic.dev/). Dalam mode ini, pembaruan diperiksa setiap kali dijalankan, sehingga jika pengguna sesekali me-restart aplikasi atau bisa dipaksa restart pada saat yang tepat, iterasi bisa berlangsung sangat cepat. Ini tidak berbeda dengan meminta pengguna menutup tab dan memuat ulang di SPA
Jadi saya tidak setuju bahwa yang kurang secara krusial adalah mobile dan DPI. Delphi, VB, GTK, Cocoa, dan lainnya sudah kehilangan desktop sebelum smartphone menjadi penting. Mereka tidak punya sistem distribusi dan pembaruan yang baik, dan kemampuan mendorong perbaikan serta perubahan secara instan lebih penting daripada semua fitur lain digabungkan
Laju perkembangan teknologi tampaknya sudah begitu cepat sehingga kita mulai mengalami kejutan budaya yang berasal dari budaya kita sendiri, yaitu future shock. Kecepatan ini akan makin meningkat selama masa hidup kita
Senang melihat kembali perangkat lunak Windows 3.1. Saya tinggalkan ini juga untuk para penggemar retro: https://www.xfce-look.org/p/1016410
Bagian yang paling mengesankan adalah TLS native
Saya ingat pernah mendengar bahwa kriptografi modern tidak bisa dipakai pada CPU lama karena beban perhitungan angka yang sulit dioptimalkan. Katanya beberapa tahap algoritma pertukaran kunci bisa memakan waktu terlalu lama sampai server timeout. Tapi tampaknya pada 386 yang tua dan lambat ini bukan masalah?
Mungkin itu bisa berlaku untuk sistem yang tidak punya use case embedded, seperti enkripsi video real-time, tetapi tidak semua orang terhubung ke internet dengan iPhone terbaru
Keren sekali. Saya mungkin akan mencobanya di salah satu mesin Windows 3.1 asli :)
Sebagai saran, akan bagus jika kotak dialog Options memungkinkan kustomisasi system prompt. Pengaturan tahun 1992 memang lucu, tetapi agak membatasi. Jika seseorang sedang mencoba memecahkan masalah di komputer retro, memakai ini alih-alih mengeluarkan komputer modern atau smartphone mungkin cukup masuk akal
Jika menggunakan Win32s di Windows 3.1, Anda tidak perlu memikirkan model memori tersegmentasi, dan itu juga bisa berjalan di Windows 64-bit