30 साल पहले हमारे पास जो IDE थे, और जिन्हें अब हम खो चुके हैं

 (blogsystem5.substack.com)
4 पॉइंट द्वारा GN⁺ 2025-10-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 1990 के दशक की शुरुआत में text-based IDEs सीमित हार्डवेयर पर भी बेहतरीन फीचर्स देते थे
  • उस दौर की प्रतिनिधि IDE श्रृंखला Borland Turbo series में syntax highlighting, compiler integration, debugging, help आदि जैसे ऐसे फीचर्स थे जो आधुनिक IDEs की टक्कर के थे
  • Linux के Vim और Emacs कस्टमाइज़ किए जा सकते थे, लेकिन उन्हें सीखना मुश्किल था और शुरुआती उपयोगकर्ताओं के लिए वे सहज नहीं थे
  • हाल में TUIs (text UI) और IDE फीचर्स LSP जैसी नई तकनीकों के आने से धीरे-धीरे फिर लौट रहे हैं, लेकिन अब भी 90 के दशक जैसी एकीकृत अनुभूति की कमी है
  • TUI IDEs के फायदे हैं remote access, कम resource usage, open source की स्वतंत्रता; वहीं आधुनिक IDEs में फीचर जुड़ने के साथ bloating साफ़ दिखती है

परिचय: 1990 के दशक की शुरुआत के text-based IDEs की यादें

  • 1980 के दशक के उत्तरार्ध से 1990 के दशक की शुरुआत तक, लेखक ने DOSBox में पुराने development environments को फिर से आज़माते हुए आधुनिक समय से तुलना करने का आनंद लिया
  • उस समय के text-based IDEs हार्डवेयर सीमाओं के बावजूद कई फीचर्स से लैस थे
  • उसके बाद ज्यादातर फीचर्स Windows operating system के उभार के साथ लंबे समय तक गायब हो गए, और हाल के वर्षों में ही कुछ फीचर्स फिर से लौटे हैं

शुरुआती editors और TUI environments

  • 1990 के दशक में ज़्यादातर DOS programs full-screen Text User Interface(TUI) का इस्तेमाल करते थे, जो text-based windows, colors, shadows, यहाँ तक कि mouse support भी देते थे
  • हर program का design अलग था, लेकिन मिलते-जुलते काम करने के तरीके की वजह से उन्हें जल्दी सीखा जा सकता था
  • MS-DOS ने version 5 (1991) से built-in TUI editor दिया, लेकिन compile/run करने के लिए editor बंद करना पड़ता था, और फिर दोबारा खोलने पर काम की जगह वापस ढूँढनी पड़ती थी
  • SideKick Plus (1984) जैसे TSR (resident program) आधारित tools भी थे, जिनकी मदद से multitasking न करने वाले OS पर भी efficient code editing और build संभव हो पाता था
  • 1980 के दशक के मध्य और उत्तरार्ध तक Turbo Pascal, QuickBASIC जैसे शुरुआती IDEs आ चुके थे, जो integrated development experience देते थे

Borland Turbo series: integrated IDE का शिखर

  • Borland Turbo C++, Turbo Assembler, Turbo Pascal आदि विशिष्ट भाषाओं के लिए बने थे, लेकिन वे full-screen TUI और शक्तिशाली फीचर्स देते थे
  • प्रमुख फीचर्स:
    • syntax highlighting से code readability बेहतर होती थी
    • compiler integration और warnings/diagnostics
    • project/build system और multi-window support
    • debugger (breakpoints, call stack आदि)
    • built-in help/reference manuals
  • ये सभी फीचर्स 1990 के दशक की शुरुआत में internet के बिना भी एक self-contained और intuitive environment देते थे

उस समय के Linux environment की तुलना

  • Linux में भी text-based tools मुख्यधारा में थे, लेकिन full-screen TUI आम नहीं था
  • किताबों और community में सुझाए जाने वाले Vim, Emacs फीचर के लिहाज़ से extensible थे, लेकिन शुरुआती उपयोगकर्ता के नज़रिए से अनमने और कम intuitive लगते थे
  • उदाहरण के लिए Emacs में सादा-सा window, सीमित colors, अस्थिर mouse support, और कठिन व अपरिचित menu interface जैसी समस्याएँ थीं
  • Borland Turbo C++ जैसे IDEs में बिना किसी पूर्वज्ञान के भी कुछ ही मिनटों में “Hello World” program बनाया जा सकता था और environment को समझा जा सकता था

आज के text-based IDEs

  • आज के समय में पुराने TUI IDEs से सबसे मिलते-जुलते environments में RHIDE, Free Pascal, QB64 शामिल हैं
    • RHIDE लगभग Turbo C++ जैसा ही है, लेकिन केवल DOS के लिए है और इसका development बंद हो चुका है
    • Free Pascal Unix environments को support करता है और built-in calculator, ASCII table आदि वाला शक्तिशाली integrated environment देता है
    • QB64 TUI जैसा दिखता है, लेकिन असल में GUI simulation है और terminal में चल नहीं सकता
  • Free Pascal और QB64 दोनों का development हाल तक जारी रहा है, लेकिन पुरानी भाषाओं से जुड़े होने के कारण उनकी लोकप्रियता सीमित है

असली आधुनिक console IDEs

  • आधुनिक text-based integrated development environments में Neovim, Doom Emacs, Helix काफ़ी प्रसिद्ध हैं
  • ये विभिन्न plugins की वजह से IDE-स्तर का अनुभव देते हैं, लेकिन Borland उत्पादों जैसी language-specific integration और intuitiveness इनमें कम है
  • हाल में GNU Nano जैसे साधारण TUI editors भी लोकप्रिय हुए हैं, लेकिन उनमें IDE फीचर्स नहीं हैं, इसलिए उनका अनुभव WordStar जैसा लगता है
  • नतीजतन, आज के console editors या तो 1990 के दशक के अनुभव-स्तर तक नहीं पहुँचते, या फिर 30 साल पुराने फीचर्स को ही मुश्किल से वापस पा रहे हैं

TUI IDEs की आवश्यकता

  • भले ही VSCode की remote features बेहतरीन हों, TUI IDEs का फायदा यह है कि remote machine पर SSH से login करते ही उन्हें तुरंत इस्तेमाल किया जा सकता है
  • इसके अलावा VSCode का remote extension open source नहीं है, और कुछ OSes (जैसे FreeBSD) पर वह काम भी नहीं करता, इसलिए सीमाएँ हैं
  • TUI IDEs कम resources खर्च करते हैं, और remote environments में उनकी उपयोगिता और बढ़ जाती है

bloating और "Bloat" की समस्या

  • Borland Turbo C++ में सभी फीचर्स शामिल होने के बावजूद install size 9MB से कम थी, और वह 640KB RAM में चल सकता था
  • आज का Doom Emacs 500MB से अधिक का हो सकता है, और आधुनिक IDEs कई GB तक पहुँचते हैं, जिससे bloating गंभीर समस्या बन गई है
  • VSCode 350MB पर काफ़ी हल्का लगता है, लेकिन Electron-based होने की वजह से असली system resource usage ज़्यादा है
  • फीचर्स, refactoring आदि में कुछ प्रगति ज़रूर हुई है, लेकिन 30 साल पहले की तुलना में innovation सीमित ही दिखती है
  • AI code assistants हाल का बदलाव हैं, लेकिन व्यवहार में उनका ज़्यादातर हिस्सा remote services पर निर्भर है

निष्कर्ष

  • लेखक परिस्थिति के अनुसार Doom Emacs, Vim, VSCode, IntelliJ जैसे अलग-अलग development environments का उपयोग करता है
  • 30 साल पहले के TUI IDEs का एकीकृत development experience और efficiency, आज के IDEs की bloating और fragmentation से स्पष्ट विरोध में खड़े हैं
  • text-based IDEs का मूल्य और संभावनाएँ आज भी बरकरार हैं, और उनका विकास व पुनरुत्थान आगे कैसे होता है, यह देखना बाकी है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-10-19
Hacker News की राय

  • यह जानकर बड़ा झटका लगा कि graphical programming के क्षेत्र में Visual Basic सबसे बेहतरीन था। पहले एक ही दिन में मध्यम स्तर का GUI application बहुत तेजी से बनाया जा सकता था। C# WinForms कुछ हद तक इसके सबसे करीब आया, लेकिन उसके बाद के सभी tools ने individual developer के नज़रिए को ध्यान में नहीं रखा, यह अफसोस की बात है। एक नए शक्तिशाली development paradigm के रूप में voice/speech-based development (SDD/VDD) का प्रस्ताव है। काश बहुत टाइपिंग की पीड़ा से मुक्ति मिले और AI के साथ interaction सहकर्मियों से बातचीत जितना स्वाभाविक हो जाए। लेकिन इसे सही तरह से संभव बनाने के लिए AI models को इससे कहीं अधिक तेज़ होना होगा

    • Delphi उस समय भी Visual Basic से बेहतर था, और आज भी इस्तेमाल किया जा सकता है। Lazarus भी अभी तक मौजूद है। वास्तव में C# WinForms का अनुभव Delphi के सबसे करीब है

    • लगा कि Qt Creator, VB6 जैसा अनुभव देता है। क्या आपने इसे कभी इस्तेमाल किया है?

  • मेरा मानना है कि Emacs अभी भी ये सभी खूबियाँ देता है। बस लेखक जिसे “non-traditional” कहता है, वह वास्तव में उन conventions की वजह से है जिनसे वह परिचित नहीं है। Emacs पूरी तरह self-documenting है और interactive भी। अब तक मैंने जो सबसे बेहतरीन text-based interface इस्तेमाल किया है, वह Emacs के भीतर का Magit है (https://magit.vc/). काश Emacs का और ज़्यादा हिस्सा Magit जैसा हो। IDE कुछ भी हो, git client के रूप में मैं Emacs ही इस्तेमाल करता हूँ

    • Emacs एक ऐतिहासिक tool है, जो Apple के cmd-z/x/c/v shortcuts विकसित करने से भी पहले मौजूद था। उस समय programmers के editor shortcuts में Wordstar परिवार (जैसे अधिकांश Borland products) के shortcuts मुख्यधारा में थे। आज कम लोग जानते हैं कि 30~40 साल पहले भी शानदार IDE मौजूद थे। उदाहरण के लिए, Apple MPW (1986) एक GUI editor था जिसमें हर window एक Unix shell बन सकती थी, और shell scripts से windows और editing tasks को नियंत्रित किया जा सकता था, साथ ही source code management system भी built-in था। command टाइप करके option-Return दबाने पर GUI-आधारित 'Commando' window खुलती थी, जहाँ सभी options चुने जा सकते थे। Apple Dylan (1992-1995) एक Lisp/Smalltalk शैली का शक्तिशाली IDE था, और THINK Pascal तथा C (1986), Metrowerks Codewarrior (1993), Macintosh Allegro Common Lisp आदि भी बेहद innovative थे। 80 के दशक से 90 के शुरुआती दौर के 8~40MHz M68000, 2~32MB RAM वातावरण में इतने परिष्कृत IDE बन पाना हैरान करता है

    • Emacs के self-documenting और interactive होने वाली बात पर, असल में पहली बार इस्तेमाल करते समय तो यह तक आसानी से पता नहीं चलता था कि document save कैसे करें। vi से बेहतर हो सकता है, लेकिन beginner बिना किसी explanation के इसे तुरंत इस्तेमाल नहीं कर सकता

    • Magit सचमुच कमाल है। पता नहीं ऐसा data model कैसे सोचा गया। लगता है कि इसने git के data model से भी आगे कुछ implement किया है। git porcelain की बिखरी हुई प्रकृति के मुकाबले Magit में एक व्यवस्थित structure है

    • Turbo-Vision शैली के IDE में सिर्फ Alt, Tab, Return, Esc, arrow keys जैसी कुछ चीज़ें जान लेने से अधिकतर functions समझ में आ जाते हैं, जबकि Emacs में ऐसी एकरूप operability नहीं है

    • मैं 25 साल से ज़्यादा समय से Emacs इस्तेमाल कर रहा हूँ, इसलिए अब यह पूरी तरह स्वाभाविक लगता है

  • Turbo Pascal सचमुच अद्भुत था। शुरुआत में यह non-standard Pascal implementation होने के कारण मैं इसे इस्तेमाल करने में हिचक रहा था, लेकिन competing tools बहुत महंगे और कम शक्तिशाली थे। खुद इस्तेमाल करके मैं पूरी तरह प्रभावित हो गया। IBM PC पर इतना तेज़ और intuitive IDE अनुभव हुआ। modern IDEs में Intellij 25 साल से भी ज़्यादा समय से competitors से बहुत आगे है। Microsoft products मैं बहुत पहले से इस्तेमाल नहीं करता, इसलिए VSCode का अनुभव नहीं है। Eclipse धीमा, कम intuitive और bugs से भरा हुआ था। JetBrains उन विरले companies में है जो अपने mission पर कायम रहते हुए उत्कृष्टता बनाए रखती हैं। अलग-अलग languages, standards और tools को लगातार support करते हुए भी बेहतरीन quality बनाए रखना प्रभावशाली है

    • Visual Studio अभी भी WinForms और graphical form designer को support करता है, इसलिए यह 90 के दशक के आखिर वाले Delphi अनुभव से बहुत मिलता-जुलता है। WinForms ने VCL की खुली नकल की थी

    • लेकिन resource usage एक बड़ी समस्या है। cloud desktop पर neovim नहीं चला सकता, इसलिए ideavim इस्तेमाल करना पड़ा, लेकिन 4-core, 16GB RAM होने के बावजूद कुछ projects खोलते ही lag होने लगता है। शायद company security software का भी असर हो, लेकिन VSCode उतना परेशान नहीं करता

  • Turbo Pascal IDE अपने समय से बहुत आगे था, और CP/M (खासतौर पर Z-80) पर भी जादू की तरह शानदार था। उस दौर की किसी भी चीज़ से बेहतर था

  • लेख 2023 का है, इसलिए title का साल 32 साल पहले करना ज़्यादा सही होगा। आजकल TUI में सबसे निराशाजनक बात यह है कि asynchronous frameworks अक्सर key input को अनदेखा कर देते हैं। 2000 से पहले के TUI, system तैयार न होने पर भी key input को wait में रखते थे। इसके उलट, आधुनिक "web-based" TUI frameworks में अगर event listener register होने से पहले key दबा दी जाए, तो वह पूरी तरह ignore हो जाती है। इन समस्याओं को छोड़ दें तो TUI अभी भी अच्छी तरह काम कर रहा है। Neovim, LSP और plugins की वजह से अब तक के सर्वश्रेष्ठ features देता है। यह mouse-based TUI नहीं है, लेकिन productivity के लिहाज़ से बेहद शक्तिशाली है

    • DOS के दिनों में असली terminals में key input buffer होता था, और interface से परिचित लोग कई keys पहले ही दबाकर UI से आगे निकल जाते थे। input buffer में जमा हो जाता था और फिर स्क्रीन पर झट से दिखकर गायब हो जाता था। आधुनिक frameworks में भी यह संरचना बनाई जा सकती है, लेकिन बहुत सावधानी चाहिए

    • 1984 में भी ऐसा अनुभव था, इसलिए इसे 41 साल पहले तक ले जा सकते हैं। Visual Studio 1.0 या NetBeans जैसे GUI products आने तक शुरुआती projects ही मुख्यधारा थे। यह vim (1991) से पहले की बात है, लेकिन अहसास ऐसा था जैसे ncurses की जगह floating windows चाहिए हों

    • key input का इस तरह ignore होना पागल कर देने वाला है। पहले तेज़ shortcut combinations से कंप्यूटर को अविश्वसनीय गति से चलाया जा सकता था, लेकिन अब लगता है जैसे चिपचिपे शीरे के भीतर चल रहे हों

    • मुझे ठीक से समझ नहीं आया कि 30 साल पहले से उनका आशय किस समय से है, लेकिन मैं GUI Smalltalk system browser की उम्मीद कर रहा था और DOS TUI देखकर थोड़ा निराश हुआ। फिर भी Turbo C/Pascal, MS C 4.0 और CodeView की यादें ताज़ा होकर अच्छा लगा। ये tools 43-line और 50-line modes में भी इस्तेमाल किए जा सकते थे

    • मुझे लगता है कि किसी खास IDE पर अत्यधिक निर्भरता आपकी प्रतिस्पर्धात्मक क्षमता और आपके code, दोनों के लिए नुकसानदेह हो सकती है। अगर terminal IDE की बात करें, तो GNU/Linux terminal ही सबसे बेहतरीन app है। tiling window manager में कई terminals खोलकर इस्तेमाल करने से productivity अधिकतम हो जाती है। बड़े displays पर modern scaling developer ergonomics के लिहाज़ से भी शानदार है

  • मैं अभी भी अपने हाथ से बनाए गए text-based editor/IDE (https://github.com/alefore/edge) को विकसित और इस्तेमाल कर रहा हूँ। 10 साल के development से निकले निष्कर्ष हाल में लिखे हैं (https://github.com/alefore/weblog/blob/master/edge/README.md)

    • मैंने भी खुद बनाया है। लगभग 4 महीने develop किया, और यह बहुत आनंददायक अनुभव था (https://github.com/ivanjermakov/hat)

  • DOS के स्वर्णकाल में characters को byte array के रूप में और attributes (background, foreground color आदि) को अलग array में manage किया जाता था। अगर किसी खास जगह 'A' लिखना हो, तो memory address पर सिर्फ 0x41 लिखना काफी था। कुछ wait states होते थे, लेकिन 9600 baud terminal पर ANSI commands से output भेजने की तुलना में यह बहुत तेज़ था। Emacs धीमे serial terminals या Sun workstations के terminal emulator पर इस्तेमाल किया जा सकता था, लेकिन shell-based TUI के गायब होने की यही एक बड़ी वजह थी

    • पुराना तरीका तो उल्टा ज़्यादा श्रेष्ठ लगता है। screen size बदलने पर इसे कैसे handle किया जाता था, यह जानने की जिज्ञासा है

  • यह लेख text-based IDE पर केंद्रित है, लेकिन मुझे लगता है कि यह Visual Basic या Delphi जैसे पारंपरिक IDE पर भी लागू होता है। beginners के लिए Python का एक IDE सचमुच ज़रूरी है। text-based नहीं, बल्कि Visual Basic शैली का, जिसमें सब कुछ integrated हो और चीज़ें आसानी से discover की जा सकें (यह बहुत ज़रूरी है!)। अगर उसमें GUI builder और debugger भी built-in हों तो और अच्छा। code editor में syntax highlighting, autocomplete और आसान code navigation हो तो काफी होगा। उदाहरण के लिए, window पर button रखें और GUI editor में उस पर double-click करते ही सीधे उसके handler code पर पहुँच जाएँ। पहले कभी लोग इसी तरह के विचार पर साथ आए थे, लेकिन किस GUI framework का इस्तेमाल हो (Pyside, Dear PyGui, web-based आदि) इस पर मतभेद इतने बड़े थे कि चर्चा ठंडी पड़ गई। Free Pascal की बात आई है, तो Delphi की नकल करने वाले Lazarus (https://www.lazarus-ide.org/) का ज़िक्र भी होना चाहिए। यह बहुत शानदार है और सक्रिय रूप से विकसित हो रहा है। हालांकि Object Pascal आजकल ज़्यादा इस्तेमाल नहीं होता, इसलिए थोड़ा पुराना महसूस होता है

    • मैं पूरी तरह सहमत हूँ कि beginners के लिए Python का integrated IDE, Visual Basic शैली, GUI builder और built-in debugger के साथ होना चाहिए। 2000 में Boa Constructor (https://boa-constructor.sourceforge.net/) नाम का एक Python IDE था, लेकिन वह लोकप्रिय नहीं हो पाया

    • मैंने भी हाल ही में Windows 3.11 पर VB3 से toy app बनाने की प्रक्रिया का वीडियो रिकॉर्ड किया, और वह tweet “viral” हो गया। आखिर में असली बात TUI नहीं, बल्कि integrated user experience है

    • मेरे लिए Lazarus ही असली IDE का मानक है। Lazarus, Lazarus से ही बनाया गया है, और लेखक खुद अपने product का गहराई से इस्तेमाल करते हुए examples और tutorials भी देता है। बच्चों को programming सिखाने में भी यह उत्कृष्ट है। इसमें Microsoft Visual Studio की तरह tagging, search, help, API docs, widget examples, libraries आदि integrated हैं। दूसरे IDEs में ऐसी integration नहीं है, और Xcode खुद को IDE कहता तो है, लेकिन Lazarus की तुलना में कमज़ोर लगता है। मैं इतना ज़िद्दी हूँ कि पिछले 6 महीनों से JS की जगह Go में अपना UI frontend framework खुद बना रहा हूँ, और आशा है कि कभी IDE भी बना सकूँ

  • Borland का IDE सचमुच आनंद का स्रोत था। आज भी मुझे कोई modern tool नहीं मिला जो वैसा अनुभव दे सके। हाँ, थोड़ी nostalgia ज़रूर है, लेकिन Free Pascal इस्तेमाल करने का बहाना बनाकर भी उस interface को फिर से बुलाना सुखद लगता है। Pascal भी मुझे पसंद है। मैं Plan 9 का Sam और Acme भी इस्तेमाल करता हूँ, लेकिन वे IDE नहीं, editor हैं। मुझे ऐसे tools पसंद हैं जो मुझे बाधित न करें और सोचने दें। पुराने TUI से सीखने लायक बहुत कुछ है। उदाहरण के लिए, File menu से shell खोलकर कुछ चलाना और फिर वापस लौट आना पूरी तरह स्वीकार्य, बल्कि heroic व्यवहार था। और keybindings! पुराने TUI अक्सर WordStar के shortcut patterns अपनाते थे, और वे इतने शरीर में बस गए हैं कि Emacs मुझे ऐसा लगता है जैसे oven gloves पहनकर typing कर रहा हूँ। लंबे समय तक joe (jstar alias) का उपयोग किया। अब समय है Dr. DOS VM boot करने का, Advent of Code भी आज़माने का, और जानबूझकर अक्षम तरीके से nostalgia party मनाने का

    • DOS युग का “professional” software (जैसे Emacs) इस तरह डिज़ाइन किया गया था कि user पूरी तरह उसी software के भीतर जी सके। मशीन के साथ एकाकार होकर, organ player की तरह shortcuts को स्वाभाविक ढंग से चलाया जा सकता था। Fry’s Electronics के कर्मचारियों को TUI इतने तेज़ी से चलाते देखा है कि स्क्रीन पूरा बनने से पहले ही काम खत्म हो जाता था और printout निकल आता था

    • WordStar bindings क्या हैं और उनमें ऐसा क्या अच्छा है, यह जानने की उत्सुकता है। मुझे इन patterns के इतिहास और अलग-अलग तरीकों के फायदे का अध्ययन करने में रुचि है

    • शानदार लेख से सहमत हूँ। मैं भी अपने personal time में Turbo Pascal शैली का एक tui code editor बना रहा हूँ। आगे चलकर make और lldb भी built-in करने की योजना है

    • Plan 9 की कई बातें पसंद हैं, लेकिन Acme के mouse-केंद्रित UI की आदत मैं कभी नहीं डाल पाया। जिस UI में सटीक mouse aim की ज़रूरत हो, वह लंबे समय तक इस्तेमाल करने पर या disability की स्थिति में बेहद असुविधाजनक होगा

    • djgpp और vi for dos 1991 का संयोजन सबसे बेहतरीन था

  • मैंने Visix Vibe नाम का Java IDE और Delphi, दोनों इस्तेमाल किए हैं, और दोनों products ने productivity को जबरदस्त ढंग से बढ़ाया। clients के लिए UI development, logic wiring और deployment readiness तक का schedule आसानी से अनुमानित किया जा सकता था। खास तौर पर, दोनों IDE की integration सबसे ज़्यादा याद आती है। database जोड़कर form बनाते ही तुरंत data entry और validation संभव हो जाती थी, और कुछ ही दिनों में project requirements के अनुरूप UI विकसित किया जा सकता था। आजकल इस पर ज़्यादा सावधानी से design और सोच-विचार करना पड़ता है कि UI, API और backend सही तरह जुड़े भी या नहीं। लगता है कि AI सिर्फ UI code generate करने तक सीमित न रहे; अभी भी ऐसे tools की ज़रूरत है जिनमें code को सीधे visual तरीके से रचा जाए और UI के माध्यम से program बनाया जाए। अगर कोई JUCE के लिए एक ढंग का WYSIWYG tool बना दे, तो शायद फिर से स्वर्णयुग लौट आए

    • सुनने में मज़ेदार लगे, लेकिन आजकल html forms को लोग कुछ इसी तरह इस्तेमाल करते हैं। सरल और प्रभावी है

  • DOS के दौर में characters दिखाने के लिए byte array और color attributes की array होती थी, और hardware इन्हें सीधे render करता था। memory address में value लिखते ही वह स्क्रीन पर दिख जाती थी, इसलिए यह धीमे serial terminal या ANSI command-आधारित rendering से कहीं तेज़ था। Sun workstation के terminal पर Emacs इस्तेमाल करते समय वह स्वाभाविक रूप से धीमा ही हो सकता था, और TUI के गायब होने की यही वजह थी

    • उस समय की संरचना उल्टा ज़्यादा सुविधाजनक लगती है। screen size को लचीले ढंग से कैसे बदला जाता था, यह जानना चाहूँगा