Windows 3.1 के लिए AI assistant WinGPT
(dialup.net)- WinGPT एक ऐसा प्रोजेक्ट है जो Windows 3.1 पर भी OpenAI API-आधारित chatbot चलाने की कोशिश करता है, और 386 जैसे पुराने PC से आधुनिक AI services को कॉल करने पर केंद्रित है
- इसका implementation C और standard Windows API पर आधारित है, और Open Watcom v2 की बदौलत Windows 11 पर भी 16-bit Windows के लिए build करना संभव है
- OpenAI API server से proxy के बिना सीधे TLS 1.3 के जरिए कनेक्ट किया जाता है, लेकिन यह भी स्पष्ट किया गया है कि यह TLS implementation सुरक्षित नहीं है
- Windows 3.1 के basic UI controls सीमित हैं, इसलिए status bar जैसे elements भी सीधे implement करने पड़े या पुराने public domain code को modify करना पड़ा
- memory constraints की वजह से responses को छोटा रखने के लिए कहा जाता है और पिछले conversation turns नहीं भेजे जाते, इसलिए conversation context बनाए नहीं रखा जा सकता
Windows 3.1 पर OpenAI API को कॉल करने का एक प्रयोग
- WinGPT Windows 3.1 के लिए एक AI assistant है, जो OpenAI API के जरिए सवाल-जवाब, jokes, और documents·spreadsheets के draft लिखने जैसे उपयोग सामने रखता है
- footnote में बताया गया है कि यह विवरण व्यंग्य है, और चूंकि यह ऐसे काम विश्वसनीय रूप से नहीं कर सकता, इसलिए इस पर निर्भर न रहें
- इसका implementation C और standard Windows API पर आधारित है
- compiler के रूप में Open Watcom v2 का उपयोग किया गया है
- Open Watcom v2, Windows 11 पर भी 16-bit Windows target के लिए cross compile कर सकता है
- OpenAI API server से TLS 1.3 के जरिए सीधे कनेक्ट किया जाता है
- modern machine पर TLS terminate करने वाले proxy की जरूरत नहीं पड़ती
- “Modern TLS on 16-bit Windows” में implementation method और कठिनाइयों पर चर्चा है, और साफ कहा गया है कि यह TLS implementation सुरक्षित नहीं है
पुराने Windows API से पैदा हुई UI implementation की चुनौतियां
- Windows 3.1 में अगर सिर्फ basic Windows API का इस्तेमाल किया जाए, तो UI बनाने की क्षमता बहुत सीमित है
- UI का अधिकतर हिस्सा C code में सीधे बनाया गया, और window size बदलने पर हर component सही आकार बनाए रखे, इसके लिए resizing logic भी लिखना पड़ा
- standard controls लगभग push button, check box, radio button, edit box तक सीमित हैं
- status bar के implementation में Windows 3.1 की सीमाएं खास तौर पर सामने आईं
- File Manager और Control Panel में status bar है, लेकिन Microsoft ने Windows 95 से पहले इसे सामान्य app developers के लिए व्यापक रूप से उपलब्ध नहीं कराया था
- जब ChatGPT से status bar इस्तेमाल करने का तरीका पूछा गया, तो उसने बाद के Windows versions में मौजूद header files सुझाईं, और दोबारा पूछने पर ऐसा UI library नाम गढ़ दिया जो शायद अस्तित्व में ही नहीं है
- आखिरकार Philip J. Erdelsky की 1997 की status bar implementation का उपयोग किया गया, और उसे Microsoft programs के status bar से pixel level पर अधिक मिलता-जुलता बनाने के लिए modify किया गया
- icons Borland Image Editor से बनाए गए
- Windows 3.1 के program icons 32x32 होते हैं और Program Manager व task switcher में दिखते हैं
- बाद के Windows versions में दिखने वाले 16x16 icons भी अलग से बनाए गए
memory constraints और चलाने की शर्तें
- Windows 3.1 machine की memory constraints के कारण API requests और response processing में memory usage कम रखना पड़ता है
- modern API का JSON response size के लिहाज से optimized नहीं होता, और OpenAI API भी इसका अपवाद नहीं है
- responses छोटे रखने के लिए model से संक्षेप में जवाब देने को कहा जाता है
- पिछले conversation turns का text API call में शामिल नहीं किया जाता, इसलिए पिछले conversation context का उपयोग नहीं हो पाता
- WinGPT GNU GPL v2 license के तहत है
- यह Windows 3.1 के बाद के 16-bit या 32-bit Windows पर चलता है
- Winsock implementation जरूरी है, और इसे Microsoft TCP/IP-32 3.11b इंस्टॉल किए हुए Windows 3.11 for Workgroups तथा default Windows 2000 पर test किया गया है
- यह 64-bit Windows पर नहीं चलता, लेकिन Wine में चलाया जा सकता है
- OpenAI से communication के लिए OpenAI API key चाहिए, और run करने के बाद
File | Options...में secret key दर्ज की जाती है - download: Binaries for 16-bit and 32-bit Windows
- source modified WolfSSL source code में शामिल है, और उसका location
watcom16/wingptहै
2 टिप्पणियां
हाहाहाहाहाहाहाहाहा
Hacker News की राय
उस दौर के MS Office version में डालना भी अच्छा लग सकता है
उस समय की असली office supplies को skeuomorphic तरीके से personified character बनाया जा सकता था, जैसे rubber band… या… paperclip जैसी कोई चीज़…
Windows 3.1 पर TLS 1.2 और 1.3 चलाकर WinGPT को किसी modern machine के TLS termination पर निर्भर हुए बिना सीधे OpenAI servers से connect कराने वाला हिस्सा अलग से है: https://www.dialup.net/wingpt/tls.html
यह पढ़ने लायक है। IoT जैसे deeply embedded environments में, यहां तक कि bank switching इस्तेमाल करने वाले 8-bit CPU पर भी TLS 1.2 support अक्सर होता है, इसलिए code और data के 64KB के अंदर TLS implementation फिट करना इतना मुश्किल था—यह थोड़ा चौंकाने वाला लगा
थोड़े पुराने operating systems को internet access में दिक्कत होती है, यह दुखद है
Windows 3.1, 95, 98 का दौर सच में याद आता है। Interface उसके बाद बस और खराब ही होता गया लगता है
386 या Pentium चालू करते समय हर बार हैरानी होती है कि GUI कितना साफ-सुथरा और कम तनाव वाला था। Apple/Google style के low-contrast popup hell से सचमुच थक गया हूं
अब localization करने पर UI के आधे हिस्से में "Tap to...." जैसे labels दिखते हैं। कमाल के modern UI tools और उन्हें संभालने वाले star developers अक्सर एक draggable sidebar तक नहीं बना पाते
space को CPU time से trade off करना हो तो SAX-style parsing इस्तेमाल कर सकते हैं
SAX-style parsing tree को ऊपर से नीचे traverse करते हुए हर node visit पर events emit करती है। JSON को पूरी तरह parse करने की तुलना में memory जरूरत नगण्य होती है, और JSON के लिए custom SAX-style parser लिखना भी ज्यादा मुश्किल नहीं लगता। Reference के लिए existing SAX-style JSON parsers भी हैं
[1]: https://en.wikipedia.org/wiki/Simple_API_for_XML
[2]: https://rapidjson.org/md_doc_sax.html
सही। मैं JSMN(https://github.com/zserge/jsmn) इस्तेमाल कर रहा हूं; यह streaming parser है जो हर token को sequentially visit करता है, इसलिए JSON response की सिर्फ एक copy memory में रहती है
जितना हो सके new intermediate memory allocations से भी बचता हूं। उदाहरण के लिए JSON string के backslash escapes हटाते समय, non-backslash characters को memory के आगे की तरफ खिसकाता हूं और null terminator को और आगे ले जाकर string को काट देता हूं—एक destructive loop इस्तेमाल करता हूं। आजकल के environment में ऐसा शायद ही किया जाएगा, लेकिन जैसा कहा, CPU time खर्च करके थोड़ी space बचाई जा सकती है :)
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';
}
जिस textbox control में मैं अभी type कर रहा हूं, उसके supporting infrastructure के पूरे WinGPT से ज्यादा system resources खा लेने की संभावना बड़ी है
यह दिखाता है कि developer productivity थोड़ी बढ़ाने के लिए memory सचमुच कई orders of magnitude तक waste की जाती है। Pure Windows controls programming मुश्किल है क्या? बेशक मुश्किल है, लेकिन Win95 के Delphi या VB को modern UI toolkits से कहीं ज्यादा productive भी माना जा सकता है, और बनी हुई apps बहुत कम resources इस्तेमाल करती थीं। असल में जो मुख्य कमी थी, वह mobile support और DPI awareness जैसी चीज़ें थीं
"developer productivity का छोटा फायदा" कहना ईमानदारी से कम करके आंकना है
बचपन में native code से जूझकर जो चीज़ें बनानी पड़ती थीं, वे अब web browser को target करने वाली ready-made libraries और tools से लगभग कोई भी कर सकता है। यह अपने आप में शानदार उपलब्धि है और बुरी बात नहीं है। सबसे अफसोस की बात यह है कि browser कुल मिलाकर "बेहतर" विकल्प बनते हुए native apps को खत्म कर रहा है
आजकल software companies स्वाभाविक मानती हैं कि उन्हें network service को web access देना ही होगा, इसलिए वे पहले web बनाती हैं। फिर वे iPhone, Windows, Android, macOS, Linux तक support करना चाहती हैं। हर platform को कुछ हद तक cover करने वाले options मौजूद हैं, लेकिन उस समय तक browser में proof of concept पहले से होता है, और NPM install भर से उसे अलग window में चलाकर installer और distribution system जोड़कर ship किया जा सकता है। शानदार नहीं, पर हो जाता है
अगर कोई production-quality efficient native GUI framework होता जो Windows, macOS, Android, iPhone के DOM और native UI को efficiently target करता, IME और platform-specific semantics वाले native text input, screen reader integration वाली accessibility, अलग-अलग screen sizes के हिसाब से responsive UI changes, और fractional scaling को सही से handle करने वाले robust और fast DPI-independent visual elements—सब support करता, तो समस्या कम होती। आसान काम ही होगा, है न?
लेकिन ऐसा कुछ है नहीं। मुझे Delphi VCL या pure Win32 पसंद हैं, लेकिन वे भी ज़्यादातर ज़रूरतें पूरी नहीं करते। इन सभी platforms को support करना बहुत मुश्किल है। Browser यह काम काफ़ी अच्छी तरह करते हैं, और गहरे platform-specific code लिखते समय reference के लिए बेहतरीन example code sources में से एक भी हैं। ऊपर से, वैसे भी ज़्यादातर चीज़ें web को target करती हैं और browser engine भी “native code” ही होता है, इसलिए browser environment में भी चलने वाला isomorphic native code समाधान बनाने की तुलना में, उस platform के साथ browser या कम से कम JS engine ship करना कहीं आसान है जो पहले से native code चला रहा है।
“इसे कहीं ज़्यादा productive भी माना जा सकता है” वाले हिस्से को थोड़ा और समझा सकते हैं?
Productivity में deployment की अवधारणा भी शामिल होनी चाहिए। उस दौर के standards के हिसाब से Delphi/VB ने इस सवाल को पूरी तरह ignore किया।
अगर कोई simple zip utility होती, तो firewall के अंदर LAN के किसी network mount पर single EXE copy कर देना ही काफ़ी था। Windows ने binary के अंदर icon और string loading जैसे कामों के लिए एक pseudo-filesystem डाल रखा था, और वह पर्याप्त था। लेकिन अगर DLL और registry entries की ज़रूरत वाला ज़्यादा complex app होता, तो सैकड़ों dollars देकर InstallShield खरीदना और InstallScript सीखना पड़ता। MSI और WiX आने तक इसके बीच का कोई रास्ता नहीं था, और 1990s के mid तक भी Microsoft internet को किसी exotic trend जैसा देखता था; कम bandwidth के कारण उसे लगता था कि network से software distribute करना practical नहीं है। Software CD-ROM के लिए होता था, और shipping सचमुच जहाज़ पर लादकर भेजना था।
समस्या यह थी कि लोग pure productivity से भी ज़्यादा iteration speed को लगभग हर चीज़ से ऊपर मानते थे। दुनिया Delphi से तेज़ बदल रही थी। Borland यह समझ सकता था कि browser को ज़बरदस्ती app की तरह इस्तेमाल करने की लहर एक ऐसी मूलभूत ज़रूरत दिखाती है जो शब्दों में साफ़ नहीं कही गई थी, और वह Object Pascal interpreter जैसी कोई चीज़ बना सकता था। मसलन अगर उसने “Delphi Browser” जैसा कुछ बनाया होता तो उसे अपनाया जाता, लेकिन codebase मूल रूप से native Windows app production के लिए बना था, इसलिए ऐसा shift मुश्किल होता। इसके अलावा Borland, Windows platform का एक guest जैसा था और Microsoft की दिशा follow करता था। Microsoft ने web और Windows world को जोड़ने के तरीके के रूप में ActiveX को push किया, और Borland ने बहुत देर से समझा कि ActiveX लोगों की ज़रूरतें पूरी नहीं करेगा। उसने web को पहले competitor नहीं माना, बाद में Delphi apps के simple delivery vehicle के रूप में देखा, और फिर और बाद में Delphi से web server लिखने के लिए push किया, लेकिन उसकी ताकत वहाँ fit नहीं होती थी।
यहाँ से सीख यह है कि लोगों के कहे पर नहीं, बल्कि वे वास्तव में क्या करते हैं उसे देखकर सीखने वाली unspoken preferences, और deployment का जबरदस्त महत्व। Deployment आज भी ज़्यादातर web competitors के लिए blind spot है। पिछले साल तक भी ऐसे Delphi-जैसे platforms बहुत कम थे जिनमें web-style deployment हो, यानी app चलाते ही हर बार refresh हो जाए। Electron तक सिर्फ़ पूरी तरह asynchronous desktop-style updates देता है। मैं एक छोटी कंपनी चलाता हूँ जो native platform constraints के भीतर desktop app deployment को ठीक करने वाला product बनाती है, और हमने aggressive updates नाम का web-style deployment mode जोड़ा है (https://hydraulic.dev/)। इस mode में हर run पर update check होता है, इसलिए अगर user कभी-कभी app restart करता है या सही समय पर restart को force किया जा सकता है, तो बहुत तेज़ी से iterate किया जा सकता है। यह SPA में tab बंद करके फिर reload करने को कहने से अलग नहीं है।
इसलिए मैं इस बात से सहमत नहीं हूँ कि missing core चीज़ mobile और DPI थी। Delphi, VB, GTK, Cocoa वगैरह smartphone के महत्वपूर्ण होने से पहले ही desktop हार चुके थे। उनके पास अच्छा deployment/update system नहीं था, और fixes और changes को तुरंत push करने की क्षमता बाकी सारी features को मिलाकर भी उनसे ज़्यादा महत्वपूर्ण थी।
लगता है technical progress की रफ़्तार इतनी तेज़ हो गई है कि हम अपनी ही culture से आने वाले culture shock, यानी future shock, को महसूस करने लगे हैं। यह रफ़्तार हमारे lifetime में और तेज़ होगी।
Windows 3.1 software को फिर से देखना अच्छा लगा। Retro enthusiasts के लिए यह भी छोड़ रहा हूँ: https://www.xfce-look.org/p/1016410
native TLS सबसे impressive हिस्सा है।
मुझे याद है कि सुना था modern encryption पुराने CPUs पर usable नहीं होती, क्योंकि इसमें hard-to-optimize numeric computation बहुत ज़्यादा होता है। जैसे key exchange algorithm के कुछ steps इतने देर लेते हैं कि server timeout हो सकता है। लेकिन लगता है पुराने और slow 386 पर यह समस्या नहीं है?
real-time video encryption जैसे जिन systems का embedded use नहीं होता, उनमें शायद ऐसा हो सकता है, लेकिन हर कोई latest iPhone से internet connect नहीं करता।
वाकई शानदार। शायद अपनी असली Windows 3.1 machines में से किसी एक पर इसे आज़माऊँगा :)
एक सुझाव: Options dialog में system prompt customize करने की सुविधा हो तो अच्छा होगा। 1992 वाली setting मज़ेदार है, लेकिन थोड़ी limited भी। अगर आप किसी retro computer पर problem solve कर रहे हैं, तो latest computer या smartphone निकालने के बजाय इसे इस्तेमाल करना कुछ हद तक reasonable हो सकता है।
Windows 3.1 पर Win32s इस्तेमाल करें तो segmented memory model की चिंता नहीं करनी पड़ती, और यह 64-bit Windows पर भी चल सकता है।