Hacker News new | past | comments | ask | show | jobs | submit login
Modern Turbo Vision 2.0 (github.com/magiblot)
214 points by begoon on March 19, 2022 | hide | past | favorite | 92 comments



Turbo Vision was very fun to use and I made a good bit of money contracting on small projects in grad school in the early 90s using it. It made writing text mode guis a breeze. Borland's later Object Windows Library (OWL) was, in my opinion, much clunkier but it was done in C++ compared to Turbo Vision's Pascal.

Probably the most interesting app I did was a small quality control/stats app for this book: "Quality Control 4th Edition" (https://www.amazon.com/Quality-Control-Dale-H-Besterfield/dp...). All the data entry used Turbo Vison and all the graphs and charts used BGI (Borland Graphics Interface). It was meant for student use but I found out later it was used by Jim Beam on their whiskey distillery production line.


Turbo Vision and OWL started as Turbo Pascal frameworks and were later ported to C++.

Delphi continues this tradition, most VCL components are implemented in Delphi, even those shipped in C++ Builder.


There were Pascal and C++ versions of Turbo Vision. This version is based upon the C++ version Borland released into the public domain in 1997.


I bought a mouse specifically for this. It was a Genius and came with a holder which you could stick to the side of your monitor or to a wall.

So you could store your mouse when not in use. I am not making this up.


It also had a ball that you had to remove every third day or so and then clean the friction rollers inside the mouse which the ball was turning. All the dust the ball picked up transferred onto those rollers and coagulated into dense felt around them until they stopped turning.

Mine had three buttons though!


My standard kit still includes a pair of fine-point forceps from my dad's lab that he gave to me for cleaning mice when I went off to college. It's been a long time since I used them for mice, but they're now really handy for charging ports.


I found that incredibly satisfying to clean though!


Genius GM6000? I had that one and still use the cutting side of the combined mousepad/cutting mat that came with it.


Green. Outstanding quality.


Can confirm. Mine was resting in a drawer for some years, but seven i found it, I immediately started using it again. Great mousepad since 1989.


Mouse holders are still manufactured, believe it or not.


I had the same one :) - https://youtu.be/GiFWLSdFAuA


Now we replace it with fifty million JavaScript libraries for a web interface.



Broadly, love seeing projects like this. Entirely too much wheel reinvention going on, well, everywhere in software. Let's go back, see what worked pretty well for a long while, and just updated or rewrite it to similar specs. Any more things going on like this?


It also worked under certain assumptions.

- No concurrency whatsoever.

- No Unicode support.

- In particular, no wide characters support (Chinese, Japanese, emoji).

Not that these are unsurmountable difficulties. But they need to be addressed before jumping to use the good old ways.


Doesn't his comment about rewriting it answer all those questions though but keep the core of the principles of the software intact?


TUIs | https://news.ycombinator.com/item?id=30704923: ~200 comments 3 days ago.


IIRC C++'s TurboVision is port of Pascal's one. Like the

  #define Uses_TKeys
line is from something like

  uses Tkeys
in Pascal


Yes, Borland was always Turbo Pascal first (then C++), the same was with OWL, VCL and now FireMonkey.

The difference being that with Delphi/C++ Builder that made C++ extensions to interop with Delphi's object model, as such it is even the same code and no longer a port like in TV and OWL predecessors.


Wow, this is a throwback. I'm suddenly sat in front of my Amstrad PC as an early teenager poking around DOS tools I don't understand.


My throwback is reading through sheets and sheets of continuous form paper printed with the Turbo Vision demos and being utterly unable the wrap my head around the object oriented code. Still I learned a lot by annotating that source code.


Hah I was just looking at this recently. I was looking for a C# version. I couldn't find anything nice though. There's this https://github.com/elw00d/consoleframework but it looks like it hasn't been updated in a long time.


C#? Tick.

Console? Tick.

TurboVision theme? Tick. (lol)

https://github.com/jinek/Consolonia

> TUI (Text User Interface) (GUI Framework) implementation for Avalonia UI

> Supports XAML, data bindings, animation, styling and the rest from Avalonia.


Have you tried Miguel de Icaza's gui.cs?

https://github.com/migueldeicaza/gui.cs


I looked at that but it didn't look enough like Turbo Vision for me :)


This looks awesome, but not packaged yet?

For a decade or two I waited for a good CUA editor on Unix. One that took advantage of 1990s PC hardware. Like DOS Edit, but better. Built my own striped-down SET/RHIDE editor in the early 2000s, then hobbled along with "ne" from ~2010, but that niche was fully taken by micro a few years ago. Would love a friendly tvision-like competitor with real menus and dialogs.

But what about the color palette? I see one screenshot with an extended palette, but the main shots that are using the original eight-color palette. Maybe nostalgia shots, ok. Was acceptable to have saturated dark blue and dark green backgrounds in ~1990 I suppose, that's all there was. But no longer. A micro/sublime-like dark grey color theme of at least 256 colors would attract new folks more effectively. Backgrounds should have a low-saturation imho.


Turbo Vision is odd. It's a backport of a graphical UI (Windows 3.0) to text mode. It was exceptionally well done in both end user and developer ease of use and caught on.

But I doubt it's the optimum for a text based UI, at least for most applications. Keep evolving!


IIRC both Windows and TV where modeled after the IBM Common User Access (https://en.wikipedia.org/wiki/IBM_Common_User_Access) interface style, which was a somewhat big theme in the late 80s and early 90s.


Its fun seeing some of the vestigial CUA key bindings in modern apps. The one I probably use the most is F5 in the browser to refresh the page. That is listed in your Wikipedia page:

> If applicable to the page/screen in question F5 provides a refresh function;


I still use the original CUA Ctrl-Ins / Shift-Ins / Shift-Del for Copy / Paste / Cut at least as often as the newfangled Macintosh-copied Ctrl-C/V/X. They still work in (most?) Windows apps even if they aren't advertised as shortcuts in the Edit menu.


Also influenced by the original Mac UI, which influenced Motif, which influenced later toolkits. It was a great time for standard interfaces, which has gotten worse since, imho.


You're not wrong, I remember a lot of turbo vision apps loved to use the MDI, multiple document interface, paradigm where each application was like a mini OS with unique windows you could resize and place as you please. This was fine when you were in DOS and could only run one application at a time, entirely fullscreen. But nowadays MDI on a multitasking OS with multiple things running at once is a weird anachronism, like you're running an OS inside an OS. It's confusing and not good.

You can use turbo vision for good interfaces though. Just have to be careful not to fall into the tropes of 30 year old pre-multitasking OS application design.


MDI is completely optional in TUI apps. It only enters the picture if you have multiple documents open within the same terminal/app session, otherwise you simply get the single document view. This applies to Emacs "windows" as much as any TUI in DOS.


This is usually handled by tabs today... not sure that has been ported back to libs like turbo vision yet. I don't think so.


Tab bars are not very TUI friendly though, since the typical TUI has too little space to display a list of usable tab names at all times. Instead there's simply a hotkey which pops up a "window list" for the user to switch to. (There are exceptions when space is genuinely abundant and a side list of "views" or "tabs" to switch to can be kept permanently visible, but they are exceptions.)

Here the TUI designer profits from being able to assume that the user can navigate using the keyboard, as opposed to implementing "keyboard shortcuts" as a purely additional feature. (The GUI on the other hand can use design 'tweaks' to minimize the wasted space and perhaps distraction that would normally result from showing an always-visible tab list.)


Hmm, I don't agree, with terminals post 2000 or so.

My GUI text editor is currently showing about 8 tabs out of a dozen, with ◂ ▸ at the ends. This is comparable to the number of cells in my terminal now, ~100, i.e.:

    ◂│doc_one.txt ╲ doc_two.txt ╲ doc_three.tx… ╲ doc_four.tx… ╲ doc_five.tx… ╲ │▸
  
This is 78 "characters" wide and has extra spaces. This is enough space for typical needs, and could work even on relatively dumb terms like the linux console, DOS of yesteryear. A vte high-color term with utf8, 120+ cells wide could potentially double capacity, in number of tabs, filename length, or bit of both.


> But I doubt it's the optimum for a text based UI, at least for most applications.

Why do you think so? When I came across the first Newt apps years later (Red Hat installer and tools) I was actually surprised how less user-friendly and intuitive these newer TUIs were wen compared to TV.

One big advantage of TV was that it was consistent: when you learned how to use one app, you more or less knew how to use all other TV-based apps.


There were text mode UIs well before Windows 3.0 - Microsoft had their own TUIs, similar to Turbo Vision but with a subtly different style. They even supported a "monochrome mode" option that wouldn't look out of place on a VT-100 terminal.


Also reminded of the Norton DOS tools, which were interesting in themselves.


Unfortunately, I'm afraid, since this is based on the actual source code of Turbo Vision, it's non-free, so it's unusable for open source projects.


Wikipedia says there was an official Borland public domain release of the source code, which this is probably based on: https://en.wikipedia.org/wiki/Turbo_Vision


Yes, you're right.


I stand corrected, but the license statement should be updated to clearly state the actual license, as it currently only includes the warranty disclaimer.


Man I hope you are wrong.. because I was literally planning to build an IDE for Algorand/Python/PyTEAL with this (I know, mentioning Algorand is an automatic downvote, oh well).

You might be right.. but I am not sure. Could Borland really sue you or something, many years they release the full source code "as is", "provided gratuitously", "no support", "no updates"? I mean it doesn't explicitly say "public domain", but if someone built software using this and then Borland tried to claim ownership of it or something, would that not be some kind of trap? It seems like any reasonable court would not allow that.. I would like to believe anyway.

DISCLAIMER AND LIMITATION OF LIABILITY: Borland does not make or give any representation or warranty with respect to the usefulness or the efficiency of this software, it being understood that the degree of success with which equipment, software, modifications, and other materials can be applied to data processing is dependent upon many factors, many of which are not under Borland's control. ACCORDINGLY, THIS SOFTWARE IS PROVIDED 'AS IS' WITHOUT EXPRESS OR IMPLIED WARRANTIES, INCLUDING NO WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. THIS SOFTWARE IS PROVIDED GRATUITOUSLY AND, ACCORDINGLY, BORLAND SHALL NOT BE LIABLE UNDER ANY THEORY FOR ANY DAMAGES SUFFERED BY YOU OR ANY USER OF THE SOFTWARE. BORLAND WILL NOT SUPPORT THIS SOFTWARE AND IS UNDER NO OBLIGATION TO ISSUE UPDATES TO THIS SOFTWARE.

WITHOUT LIMITING THE GENERALITY OF THE FOREGOING, NEITHER BORLAND NOR ITS SUPPLIERS SHALL BE LIABLE FOR (a) INCIDENTAL, CONSEQUENTIAL, SPECIAL OR INDIRECT DAMAGES OF ANY SORT, WHETHER ARISING IN TORT, CONTRACT OR OTHERWISE, EVEN IF BORLAND HAS BEEN INFORMED OF THE POSSIBILITY OF SUCH DAMAGES, OR (b) FOR ANY CLAIM BY ANY OTHER PARTY. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THIS LIMITATION AND EXCLUSION MAY NOT APPLY TO YOU. Use, duplication or disclosure by the Government is subject to restrictions set forth in subparagraphs (a) through (d) of the Commercial Computer-Restricted Rights clause at FAR 52.227-19 when applicable, or in subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013, and in similar clauses in the NASA AR Supplement. Contractor / manufacturer is Borland International, Inc., 100 Borland Way, Scotts Valley, CA 95066.


I very much doubt you can get into trouble for using Turbo Vision as an external dependency. There are already projects using it, e.g. https://github.com/electroly/tmbasic.


I hope I am wrong. But I don't see anywhere in the text of this license any explicit permission to use it for any purpose, it's basically only a warranty disclaimer, unless some bits were omitted by accident.


Right. The question is, if I made a program, and for some reason they wanted to extract a fee or make me delete it or something, would a court take their side?

Because otherwise what is the utility of releasing the source code of a programming library for free? Could they argue that it was only for educational purposes or something?

Again, seems like a trap if it's supposed to be interpreted otherwise. In which case why should such a trap be legal.


Public domain means it's not (any longer) under copyright and therefore no license is needed for any use.


For anything Python, I recommend you try rich/textual.


Very important point, this.

But of course Borland could fix that quite easily.


Free Vision, with Unicode | https://wiki.lazarus.freepascal.org/Free_Vision#Unicode_vers...

> basically an improved Turbo Vision for Free Pascal

https://news.ycombinator.com/item?id=30704923#30711820


I've already asked the question, but is there a way to embed this in a regular app ? I mean, if I want to have a "retro" like GUI but I don't want to bother my users with opening a terminal/console, can I embed this ?

The thing I'm thinking about would be to extract the alacritty render code and make it a library... But that's sure not easy to do...


IMHO I would pop a web view and load an HTML page with tui.css. It's seriously impressive looking and much easier to integrate in a modern gui system, electron app, etc.: https://github.com/vinibiavatti1/TuiCss


Or you could make a launcher for your app that (attempts to) determine whether it needs to launch a terminal and does the right thing. Something like

  my-beautiful-console-app
  ========================
  #! /bin/bash

  if tty -s; then
    exec my-beautiful-console-app-for-realz "$@"
  else
    exec xterm -e my-beautiful-console-app-for-realz "$@"
  fi
might be a start.


You can use the vte library to embed a terminal in a GTK+ program. QEMU does it for example.


I am confident that Turbo Vision can now meet many of the expectations of modern users and programmers.

Probably needs help with porting to node.js though: https://github.com/magiblot/tvision/issues/27#issuecomment-8...


This is great! A Python wrapper would be awesome!



Can rhide be built with this new tv? If so that will be the only ide I'll use and I'll never leave


No, it can't. RHIDE needs specifically this one: https://github.com/set-soft/tvision. If it may interest you, there's a precompiled RHIDE binary in https://github.com/set-soft/tvision/tree/master/rhide_bin/li....


This is awesome! I would prefer to use it with Pascal though; will give it a try anyways!


If you want Pascal, this might be what you want: https://wiki.freepascal.org/Free_Vision


It reminds me of the great rhide, of djgpp fame. It was a similar project.


RHIDE uses this other Turbo Vision port: https://github.com/set-soft/tvision. It depends on the custom API extensions of that port, so it's not compatible with mine.


This was what I learned c++ on and I'm very nostalgic for those (mostly) care free days in college :)


AIUI, the FreeDOS project still maintains DJGPP and RHIDE.


Fond memories :) great to see it on github!


fun memories -- that + monochrome channel adapter was first dual-monitor setup can actively recall using


Nice work!


Thank you very much!


W o W ! :O


Btw those text based interfaces are better than most gui/web interfaces of today.


Windows 95 was the peak of good UX, like the ancient Greek was the peak of statue crafting. Some things were better in the past.


Personally I'd say MacOS 9 was the peak (ignoring its instability).

Things like:

* the filesystem root being the desktop - so you started navigation from the first thing you saw when you switched the computer on

* the way the finder remembered the exact layout of your folder windows (if you've not experienced it, it's hard to explain why it's better - but Windows Explorer and the current Mac Finder are both file browsers, whereas the old Mac Finder *was* your desktop in whatever state you left it)

* kernel extensions being switched on and off by dragging them in and out of the extensions folder

These things made the GUI match the actual underlying system - whereas I always felt that Windows 95 onwards (and now OSX/macOS) hide the workings under pretty layers).

Having said that I also used Turbo Vision in the olden days and it was fantastic.


Windows 95 was unreliable, NT Workstation 4.0 was better.


Pre-internet windows 95 was fine, as long as your hardware was good. A lot of folks had off-brand CPUs with bad cooling, off-brand RAM with problems, etc. which lead to a lot of instability. But on a plain old Intel pentium with good RAM Windows 95 would run forever.

It was a hermetically sealed little environment--there were no updates or changes unless you popped a floppy disk in and made them. If you didn't do anything different it would boot up the next day just like it did the days prior. It wasn't until we started getting those machines on the internet regularly and started running a lot more background tasks, services, new software, etc. that they really started to degrade.


49.7 days are forever?


Before the internet was on 24/7 with broadband connections everywhere people didn't run their PC all the time. It's not like you had a local wifi network to serve data, etc. to your other devices. You turned the PC on, played a game, did some spreadsheets, dialed in to AOL, and then turned it off. Those PCs pulled 300+ watts of power at idle too and were huge power hogs. Running your windows 95 PC nonstop for days and months at a time was not common at all.


Maybe, maybe not. At the times W95 was usual, I mostly ran NetBSD and later some Gentoo and Debian on my assorted systems. Furthermore, most systems had PSUs rated at 200 to 250 Watt, which they didn't even burn if one used operating systems which knew what to do with the CPUs HLT instruction during idle, or less load, also spinning down disks was a thing.

BTW, there was software which made W95/98 use HLT too. Rain, Waterfall, CPUidle, or something like that. Which became obsolete with W2000 which did that by itself.

Shrug.


We downloaded the 95 betas from the internet to test them before rolling them out.


Well obviously, we're talking about the GUI aspect of it, not the underlying OS. Win95 ran on what was essentially DOS so of course it was unstable compared to a modern (at the time) properly jailed off userland/kernel OS like NT


I kind of agree. I think that while it's getting a little bit bloated that xfce4 still pushes the right buttons for a gui for me. Simple, lots of good shortcuts by default, nice simple launcher, and you can tweak til your heart's content (but I don't really anymore). I love xfce4 combined with the whiskers launcher, it does what I need.


The accountants where I work felt all the GUI interfaces sucked compared to their terminal. This led us to buy a new iSeries. It will probably last the same 15 years as the last one.


I remember one place I worked where we ripped out all of the dumb terminals on a UNIX system and replaced them with Windows 3.1 PC's with terminal emulation. Productivity was noticeably down after the change.


> Productivity was noticeably down after the change.

Can't play much Solitaire or Minesweeper on a UNIX dumb terminal... The most fun you can have is flying around in a 3D-rendered filesystem.


"It's a UNIX system! I know this!"


80x24 is plenty of room for solitaire, and an ok minesweeper (bigger is nice though)

If you've got a graphical terminal, like you'd need for your filesystem viewer, then you can do all sorts of stuff, of course.


MUDs say hello.


They're faster than web based apps that's for sure.


Its amazing how fast they can do things. GUIs just cannot be depended upon to be consistent enough to allow for automatic muscle memory.


Definitely not as good as the web, if only for zero accessibility. With the web you have a DOM of semantic elements that are all carefully marked up by hand to describe the intent and meaning of everything. With turbo vision and TUIs you have a buffer of bytes with text, graphics, background, etc. all using the same character set. Good luck if you're a screen reader trying to make sense of it.

But you can have TUI style on the web, this tui.css project is absolutely amazing IMHO: https://github.com/vinibiavatti1/TuiCss




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: