magiblot

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....

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

Thank you very much!

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.

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.

Could you please expand on that?

Show them this, too:

https://github.com/magiblot/turbo

Applications like tvedit were designed for MS-DOS, which offered full interaction with the mouse and keyboard, and many of them were commercial products aimed at a general audience. TUI applications from the Unix tradition, however, were designed for use in terminals with limited capabilities, and were aimed at more technical users (or were created by the users themselves).

User-friendly TUI applications in MS-DOS were succeeded by Windows applications, while the largest revolution in the last 20 years in Unix TUIs has been the widespread support of 256/24-bit colors and UTF-8. Hence the gap in usability between the two worlds.

A port happened before didn't it? I remember setedit and rhide about twenty years ago.

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.

Damn. That "lib/system.cc" in Sigala's port is such a mess. You must have had a tough time tweaking it.

I was not aware of your project, thanks for sharing it.

Thanks for sharing! Don't hesitate to submit an issue if you need help using it or if you want to share any suggestions.

I recently added Unicode support into Turbo Vision: https://github.com/magiblot/tvision