it is still very well usable - i used TV 2.0 year ago to do some prototype. i wanted (and mostly succeeded) to create turbovision front end for LLDB debugger... you know, that would behave like Borland's Turbo Debugger.
few quick notes:
- blimey it was like it where i left it 199x :) you can even compile/run code from 1993 without major issues.
- there's even a better internal TV editor based on scintilla, so with syntax highlighting and such. although i was trying to mod it without success, i'll have to ask author for help, probably.
- there's no documentation (in the sense of common wisdom), so you can't ask stack overflow or AI. you have to do it like in old days: learn from examples (that have bugs in them ;) and read those few books on turbo vision again and again.
- manual 'layouting' is kinda annoying, some auto layout like qt would be handy
- i miss splitters, but that should not be hard to implement
- tbh i am kinda surprised how small and compact TV really is. it felt ginormous in the 90ies :)
overall - the author did very good job modernizing the library and i love it.
My programming career literally started in a dumpster in the ’90s, when I found a Turbo Vision book someone had thrown away. I picked it up and immediately fell in love with the bluish TUIs that anyone could make.
The original version came with Turbo Pascal 6, the C++ port came later.
So this is a modern port of the port. :)
Borland did the same with other frameworks OWL came first in Turbo Pascal for Windows 1.5, and many of C++ Builder tools are actually written in Delphi.
Anyway, Turbo Pascal 5.5 adoption of Object Pascal, followed by Turbo Vision on version 6, was my introduction to OOP, and it I was lucky have gone that path.
Got to learn OOP, and all the goodies that Turbo Vision offered as a framework in an environment like MS-DOS.
A critical part that is somewhat lost when running this in a terminal is how the mouse behaved on a real text mode screen. It was a yellow block that you moved with the mouse not a mouse pointer.
Anyone tested to run this on a high resolution Linux text mode with GPM?
So funny to see all the cmake instructions. Really makes you want to go back in time. Turbo C or Pascal, hit F9 and you're up and running.
It does showcase our incompetence. In this age we should be able to point to some online compiler and run it. Or download it and run it on a folder. That should be the extent of our involvement with tools. But apparently they are not tools, but rituals we insist on.
Hmm this is based on the original turbo vision source code. I wonder if Embarcadero or whoever owns the corpse of Borland this week can find a reason to complain.
How awesome to see this on the front page! I've been writing a wrapper for this repo. Right now I'm running Turbo Vision -- this repo -- under .Net on macOS. It's a magical feeling.
The wrapper gives a higher level API, and solves some of the things like the rather antique palette API (or wraps it), is adding layout, etc.
(This is Oxygene, currently compiling to .Net. Can be used from any .Net language of course, even Go or Swift with our toolchain, but as an assembly, consumed by anything. Using PInvoke for the native TV binaries.)
Heavily in progress :D The repo is still private and I'm working on things like basing palettes on the surfaces controls are placed on today and tomorrow. Todos are cleaning up layouts, adding a few more basic (for today) missing controls, etc.
I had experimented with libraries like Terminal.GUI, which was (still is?) in the middle of a v2 transition and really difficult to get behaving without bugs. And Claude is a great lesson about TUIs and libraries that have been built without real terminal consideration -- lots of what not to do. I found myself missing Turbo Vision and thinking, why not just have a modern version? Then I found this repo, saw it was updated for Unicode, etc... I am very grateful to the author.
I've done some work with this tvision port as well. Every time I use a new TUI framework, I'm disappointed. Invariably, Turbo Vision is better.
I'm actually working on my own .NET wrapper, too. I don't think I'm as far as you, though. I'm mimicking the Windows Forms API as closely as possible and I want to have a drag-and-drop TUI designer.
I did most of the hard integration work on the C++ side: https://github.com/brianluft/terminalforms/tree/main/src/tfc... -- exporting simple C functions that I can call with P/Invoke so that the C# side is mainly about organizing into classes. It took a couple tries to find a design that didn't fall apart when I got into more complicated stuff. Initially I went too hard into "everything that you can do in C++ should be possible in C#"--this was maddeningly complex. I was using placement new to stick the C++ objects into C# buffers, you could effectively subclass the C++ classes from the C# side, it was getting way too involved. I switched to a much more direct and less flexible approach. I decided the flexibility should be on the C# side.
I’m happy it relies on libcursesw for terminal abstraction instead of hard-coding ANSI sequences. This way I can continue using my VT-100 compatible terminal.
How deep does this library reach into the the OS? I’m searching for something I can use from microcontroller code, where there isn’t full POSIX or Win32 support.
21 comments
[ 4.2 ms ] story [ 49.0 ms ] threadCompiler performance was superb and the manuals were a work of art - I just wished I had kept all of mine.
This is a cultural treasure.
https://github.com/gansm/finalcut
few quick notes:
- blimey it was like it where i left it 199x :) you can even compile/run code from 1993 without major issues.
- there's even a better internal TV editor based on scintilla, so with syntax highlighting and such. although i was trying to mod it without success, i'll have to ask author for help, probably.
- there's no documentation (in the sense of common wisdom), so you can't ask stack overflow or AI. you have to do it like in old days: learn from examples (that have bugs in them ;) and read those few books on turbo vision again and again.
- manual 'layouting' is kinda annoying, some auto layout like qt would be handy
- i miss splitters, but that should not be hard to implement
- tbh i am kinda surprised how small and compact TV really is. it felt ginormous in the 90ies :)
overall - the author did very good job modernizing the library and i love it.
"Uses" is keyword in Pascal, for example, so "including" a module by "#define"-ing feels like a "hack"
I guess it doesn't matter, nowadays.
So this is a modern port of the port. :)
Borland did the same with other frameworks OWL came first in Turbo Pascal for Windows 1.5, and many of C++ Builder tools are actually written in Delphi.
Anyway, Turbo Pascal 5.5 adoption of Object Pascal, followed by Turbo Vision on version 6, was my introduction to OOP, and it I was lucky have gone that path.
Got to learn OOP, and all the goodies that Turbo Vision offered as a framework in an environment like MS-DOS.
IDEs we had 30 years ago and lost (2023)
https://news.ycombinator.com/item?id=45626910
Anyone tested to run this on a high resolution Linux text mode with GPM?
It does showcase our incompetence. In this age we should be able to point to some online compiler and run it. Or download it and run it on a folder. That should be the extent of our involvement with tools. But apparently they are not tools, but rituals we insist on.
There's also this one in C++: https://github.com/kloczek/tvision
The one that comes with FreePascal/Lazarus is written in Pascal.
There's even one in Rust, though it might have been vibe-coded: https://github.com/aovestdipaperino/turbo-vision-4-rust
The wrapper gives a higher level API, and solves some of the things like the rather antique palette API (or wraps it), is adding layout, etc.
```
var lMenuBar := new MenuBar;
```(This is Oxygene, currently compiling to .Net. Can be used from any .Net language of course, even Go or Swift with our toolchain, but as an assembly, consumed by anything. Using PInvoke for the native TV binaries.)
Heavily in progress :D The repo is still private and I'm working on things like basing palettes on the surfaces controls are placed on today and tomorrow. Todos are cleaning up layouts, adding a few more basic (for today) missing controls, etc.
I had experimented with libraries like Terminal.GUI, which was (still is?) in the middle of a v2 transition and really difficult to get behaving without bugs. And Claude is a great lesson about TUIs and libraries that have been built without real terminal consideration -- lots of what not to do. I found myself missing Turbo Vision and thinking, why not just have a modern version? Then I found this repo, saw it was updated for Unicode, etc... I am very grateful to the author.
hehe working with this TV library scratches my nostalgia itch :D
it probably saved me from futile efforts like writing apps for GEOS or joining the one person Hurd team.
I'm actually working on my own .NET wrapper, too. I don't think I'm as far as you, though. I'm mimicking the Windows Forms API as closely as possible and I want to have a drag-and-drop TUI designer.
Some examples of my wrapper: https://github.com/brianluft/terminalforms/tree/main/src/Ter...
I did most of the hard integration work on the C++ side: https://github.com/brianluft/terminalforms/tree/main/src/tfc... -- exporting simple C functions that I can call with P/Invoke so that the C# side is mainly about organizing into classes. It took a couple tries to find a design that didn't fall apart when I got into more complicated stuff. Initially I went too hard into "everything that you can do in C++ should be possible in C#"--this was maddeningly complex. I was using placement new to stick the C++ objects into C# buffers, you could effectively subclass the C++ classes from the C# side, it was getting way too involved. I switched to a much more direct and less flexible approach. I decided the flexibility should be on the C# side.
I'm curious how your P/Invoke system works.
I still need a VT-230 or 330.