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;
lMenuBar
.Add(lDocumentMenu)
.Add(lViewMenu)
.Add(lDialogsMenu)
.Add(new Menu('~A~pp').AddItem('E~x~it', Commands.Quit));
fApplication.SetMenuBar(lMenuBar);
(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.
For those who aren't familiar[1], it's part of RemObjects' Elements[2] suite, which allows you to use and mix several different popular languages in addition to the Pascal-based Oxygene across Windows, MacOS, Linux, Android etc.
I mean, deploying on Linux is good, but not having an IDE that runs on Linux is a disappointment.
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.
(Joking aside, I actually hope great cooperation, not competition... it's what open source is for. Seeing someone else is making a .Net wrapper as well is just plain awesome and I wish you the best. I really like the different API style.)
As a stretch goal, you might try to integrate https://github.com/magiblot/turbo too. This is a Scintilla-based text editor control implemented in tvision. We worked together to make it embeddable in other programs (because I wanted it in mine). Example usage: https://github.com/tmbasic/tmbasic/blob/master/src/tmbasic/C...
Also, I assume you know about the Turbo Vision Pascal and C++ books. They're really helpful. I transcribed both books to Markdown for easy searching if you want it.
That editor is really impressive. I'll see if I can wrap it too! Can I ask what your editor integration is for, what project?
I know the books exist, but I haven't read them. It's possible I even had a copy as a child - we had many of them but I never wrote Turbo Vision code, just Turbo Pascal in plain text or graphics modes. Then I moved on to Delphi. I would love to find both in MD - are they publicly available?
I realised I never answered your question about P/Invoke: I wrote (as in got an AI to generate) a flat C wrapper using the handle pattern, and then reimplemented classes back in Oxygene Pascal. I'm experimenting with new controls now, eg a tab/page view and others. Each is just a class that has its own view, plus some management extras, such as what max rendering it supports (I'm adding DOS character sets through to Powerline in rendering tabs, borders, etc.) It's all churning quite a bit as I do something, realise it may not be the best approach matching the TV model, rethink - learning a lot about TV's architecture at the time - so no more solid answer than that currently simply because it may be outdated tomorrow :)
Rather than focusing heavily on inheritance, I'm leaning more towards soft interfaces (duck typing) and wrapping via composition. This is just personal preference. But the concept is, if something looks like it is able to hold controls, it is treated as though it can hold controls, for example.
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.
Compiler 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://www.goodreads.com/review/list/21394355-william-adams...
I really wish that there were more, in particular, I'd dearly love to see a graphical QT (or other up-to-date) GUI app as a Literate Program.
It was either the manuals, or getting lucky with magazine articles or local library book selection.
Now I will get to see if that was just a nostalgia. Gonna use this in the next tool. Huge kudos to the authors <3
Turbo BASIC, Turbo Pascal, Turbo C++ for MS-DOS and Windows 3.x, Turbo Vision and OWL.
Got into VC+ on version 5, and MFC always felt so lame compared with Borland offerings.
To this day, they don't have anything that can match C++ Builder RAD capabilities, and even with the historic background, it has taken a few years for .NET to get the low level coding and AOT story straight, Delphi like.
We should give Go, C++ and Rust folks a few copies of Turbo Pascal 7 for MS-DOS, and Delphi current.
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.
History rumor hill goes that originally MFC was just as high level, the origin of Afx prefix, however internal teams were opposed to it and hence how MFC became a very thin layer over Win32.
History repeated itself with C++/CX, finally Microsoft had something comparable to C++ Builder, and internal teams weren't happy until they sabotaged the whole effort with C++/WinRT. Now outside Windows team no one cares.
The development experience with OWL, on Windows 3.1 was great, I never bothered with raw Win16 or Win32 other that learning the foundations, or adding support for missing capabilities, at the TP, Delphi, C++ frameworks.
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.
Not sure what you mean here. Turbo Vision came with extensive high quality documentation. If anything such documentation is what's lacking nowadays.
https://archive.org/details/bitsavers_borlandTurrogrammingGu...
if you work with qt for example so these days you ask google/stackoverflow/qtforum and you have multitude of responses if it's a common problem and sometimes you have whole solutions ready to copy&paste.
when you work with TV and ask google - you usually get... not much. so you have to take the longer route: study the doc/books (you mentioned), study the code, examples... or be friend with the author of this library or those two or three people who actively use this library these days ;)
-- edit: btw those books (there's a c++ one as well) you mention are good, but, sadly, no book is detailed enough when you have very specific problem :)
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.
autotools is horrifying. I'm not claiming that there is an obviously better way to solve the problem that it tries to solve, but it is horrifying.
FTR, I have much more experience with cmake, which is also horrifying. (Maybe there is no non-horrifying way to solve this problem?)
However one important aspect here is that there is no reason for Autotools to be what provides the `./configure && make && make install` UX - the GNU standards (not sure the exact name) describe the UX itself without mentioning anything about Autotools so any other approach to implementing it would be just as valid. However in practice whenever you find a configure script in the wild it is either Autotools or a hand-made one (that more often that not misses some of the GNU standard stuff).
Nowadays we don’t bother supporting dozens of platforms. Even Windows is something we can push aside and suggest WSL if you really need to run it under Windows.
And I even try to make sure my code runs correctly on z/OS (which IS a UNIX).
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
Anyone tested to run this on a high resolution Linux text mode with GPM?
"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.
The main issue is that Free Vision (and Turbo Vision) uses the original "object" types introduced in Turbo Pascal 5.5 instead of "class" types introduced in Delphi which make a lot of things easier (e.g. the "class" RTTI allows for enough reflection to implement automatic serialization of objects, but "object" types do not have that and Free/Turbo Vision require manual serialization with registration of the VMT pointer -accessed via a fixed offset in object pointers- as a means to distinguish at runtime between different types). Free Pascal adds a few of the niceties of "class" types to "object" types (like private/protected/public sections -TP objects are all public- and properties) but Free Vision doesn't use those as it implements the original Turbo Vision API.
[0] https://wiki.lazarus.freepascal.org/images/1/19/Userscreen.p...
I still need a VT-230 or 330.
IDEs we had 30 years ago and lost (2023)
1. [https://en.wikipedia.org/wiki/DOS_Shell#/media/File:DOS_Shel...]
