Haha nice! I also have been hacking transparency and limited utf8 into the turbo vision source code for my weird kodi like project, but your work seems way better !
How nice! It has been a few years since I started thinking of doing something similar. I have used Turbo Vision a lot in the past, both within Turbo Pascal and Turbo C++. This project seems very solid: I enjoyed reading how much care was spent in dealing with UTF8 encoding!
A port happened before didn't it? I remember setedit and rhide about twenty years ago. At that time I was desperate for a CUA editor under Linux. So, I stripped down setedit and made my own simple editor in the tradition of dos edit and nano. That worked for a number of years but the tvision? lib was removed from Debian and I couldn't build the editor any longer.
Couple of years later I found the ne editor and that was decent, and two or so years ago found micro, which is better than I could do myself. But these others are all missing that special something, the final polish of having a complete widget set like turbo vision.
Looks like this port got a lot farther on Unicode, awesome! However, 16 colors? Don't think I can handle that any longer, just too spoiled. And C++, am too lazy, haha. Unlikely anyone is using DOS any longer, maybe freedos but still. Also, windows console is in maintenance only these days. Everyone is moving to Windows terminal and for good reason. Focus on win console instead of full ansi support may be suboptimal, not sure yet.
All in all my dream would be to perhaps port Qt to a TUI or make a wxTerminal so we could write apps in Python as well. Without funding though will probably never happen.
This is not a design choice of mine. It's what the original Turbo Vision supported and I still haven't gotten around to extend it.
> Also, windows console is in maintenance only these days. Everyone is moving to Windows terminal and for good reason.
Using the Win32 Console API doesn't imply that applications will only work in the legacy Windows console. Windows Terminal supports this, as well as any terminal taking advantage of the Windows Pseudo Console (ConPTY) API (i.e. Git Bash).
From a programmer's perspective, using ANSI escape sequences to display text is fairly simple (and is what Turbo Vision does). But processing input is a pain in the ass, as it requires a complex VT sequence parser. So I stuck with the Console API for input. Anyway, there would be no problem in replacing the current console I/O strategy with something entirely different or even having many of them and picking one at runtime.
> Unlikely anyone is using DOS any longer, maybe freedos but still.
But still, I don't see the point in removing features that are already there if they are not a deterrent for further development. So DOS support is staying for now.
back then I used Turbo Pascal first and dabble in its Turbo Vision before knowing the C++ counterpart. For me, the C++ version looks like a port of the Pascal one. IIRC, it even has "uses" like construct. So, for me, the "true" TV is the Pascal one.
I was worried this would be like some other "modern ports" using electron or some other overkill-to-made-coding-easier framework but was pleasantly surprised. Even retained DOS support, excellent!
Borland C++ and Turbo Vision were a killer combo back in the DOS times. Borland's decline over the years was painful to watch. I guess that what happens to the engineering driven companies that get overtaken by the MBA types.
18 comments
[ 4.3 ms ] story [ 61.9 ms ] threadhttps://github.com/magiblot/tvision#applications
https://github.com/ivans5/BitMediaCentre
I was not aware of your project, thanks for sharing it.
A port happened before didn't it? I remember setedit and rhide about twenty years ago. At that time I was desperate for a CUA editor under Linux. So, I stripped down setedit and made my own simple editor in the tradition of dos edit and nano. That worked for a number of years but the tvision? lib was removed from Debian and I couldn't build the editor any longer.
Couple of years later I found the ne editor and that was decent, and two or so years ago found micro, which is better than I could do myself. But these others are all missing that special something, the final polish of having a complete widget set like turbo vision.
Looks like this port got a lot farther on Unicode, awesome! However, 16 colors? Don't think I can handle that any longer, just too spoiled. And C++, am too lazy, haha. Unlikely anyone is using DOS any longer, maybe freedos but still. Also, windows console is in maintenance only these days. Everyone is moving to Windows terminal and for good reason. Focus on win console instead of full ansi support may be suboptimal, not sure yet.
All in all my dream would be to perhaps port Qt to a TUI or make a wxTerminal so we could write apps in Python as well. Without funding though will probably never happen.
Yeah. SET published their port on GitHub a few months ago:
https://github.com/set-soft/tvision
One of the motivations to undertake this project was when I realized SET's Turbo Vision didn't support UTF-8 (https://github.com/windoze/tvision/issues/5).
> However, 16 colors?
This is not a design choice of mine. It's what the original Turbo Vision supported and I still haven't gotten around to extend it.
> Also, windows console is in maintenance only these days. Everyone is moving to Windows terminal and for good reason.
Using the Win32 Console API doesn't imply that applications will only work in the legacy Windows console. Windows Terminal supports this, as well as any terminal taking advantage of the Windows Pseudo Console (ConPTY) API (i.e. Git Bash).
From a programmer's perspective, using ANSI escape sequences to display text is fairly simple (and is what Turbo Vision does). But processing input is a pain in the ass, as it requires a complex VT sequence parser. So I stuck with the Console API for input. Anyway, there would be no problem in replacing the current console I/O strategy with something entirely different or even having many of them and picking one at runtime.
> Unlikely anyone is using DOS any longer, maybe freedos but still.
That's what I thought, until someone opened an issue and explained they were building for DOS... (https://github.com/magiblot/tvision/issues/20).
But still, I don't see the point in removing features that are already there if they are not a deterrent for further development. So DOS support is staying for now.
The culture at Borland, and subsequent renamings, was always Object Pascal first and C++ would built on top of it.
Still I keep waiting for the day that Visual C++ actually deserves the Visual moniker by offering a C++ Builder like tooling experience.