6

I'm looking for a UI library that offers a similar "experience" to that provided by Microsoft's infamous, Visual Basic for DOS RAD environment.

I mean, it's such a compelling environment, and there's really nothing "like" it. Anything even remotely similar would be in the Borland or Watcom C++ family of languages. I mean, does such a library even exist to recreate the "look and feel" of VBDOS?

Sure there's QB64, but that's about replicating the look and feel of QUICK basic, not VISUAL basic.

[

Anyway, thanks for your time and consideration!

4
  • 1
    Turbo Vision may look similar.
    – filo
    Apr 12 '20 at 16:02
  • 1
    Yes, though I'm looking for something easy enough to make changes to so that it basically looks exactly like VBDOS. Thank you! :D Apr 12 '20 at 16:12
  • Answerers might like to see how much of groups.google.com/d/msg/comp.os.msdos.programmer/qwba0biZIM0/… can be turned into a useful answer. People remember Turbo Vision and forget all of the other shareware and commercial stuff.
    – JdeBP
    Apr 14 '20 at 11:38
  • I always love the look of the shaded gray on these. When you scroll it makes the screen look like it's flashing.
    – S.S. Anne
    Apr 14 '20 at 17:28
6

Turbo Vision is probably your best bet.

  1. Borland released the C++ port of it into the public domain and there's a GPLed descendant of that public domain release on SourceForge or a less advanced BSD-licensed one on Sergio Sigala's website.
  2. The GPLed version is listed as compatible with "DOS, FreeBSD, Linux, QNX, Solaris and Win32" via the Borland C++, GCC, DJGPP (see also Win/Mac/Lin cross-compiling DJGPP), and MinGW (cross-compiler in Debian/Ubuntu repos as mingw-w64) compilers.
  3. It's the framework Borland used for their own Turbo C++ and Turbo Pascal IDEs and, as far as I know, it is flexible enough to replicate VBDOS 1.0's IDE. (The screenshots of the "Turbo ..." IDEs don't show it, but it does have dialogs and widget classes such as buttons, text-entry fields, etc.)
  4. It's open-source so, if it turns out to have some subtle shortcoming (eg. not quite able to match the exact visual style), you can patch it.

It's also got various helper classes including a standardized system for streaming persistent state between GUI widgets and the disk. The best comparison I can make is "Qt for the MS-DOS era".

Sergio Sigala's version includes some API documentation, though the best documentation, language syntax aside, is probably still the Turbo Vision 2.0 print manual that came with Turbo Pascal 7. I believe Bitsavers has uploaded scans of that to the Internet Archive.

I don't have a DOS compiler set up at the moment, but here's a screenshot of one of the example programs, built for Linux, to show off some of the widgets it comes with in their default look.

enter image description here

4
  • Actually, Turbo Vision had some quite unsubtle differences from VBDOS.
    – JdeBP
    Apr 14 '20 at 11:23
  • @JdeBP Yes, but a 100% perfect match is unlikely to exist and, if it does, is likely to be greatly inferior to Turbo Vision in other aspects. I recommended it because "patch this open-source code to tweak the visual rendering" is likely to be the best option. (In fact, I say this as someone who has, at times, considered cloning VBDOS and just didn't have the time.)
    – ssokolow
    Apr 15 '20 at 18:15
  • Also, Turbo Vision is difficult to customize, in order to achieve my desired outcome. Apr 19 '20 at 10:10
  • Sometimes tv also behaves strangely outside the 80x25 text modes. May 2 at 21:44
1

The combination of functions to move the cursor, select text color, and read a key made most parts of a UI sufficiently easy to design and implement that there was far less need for automated tools than when designing a windowed application. About the only thing missing would have been a good function to accept an input line with cursor editing, but there were plenty of those around and they were generally agnostic to the design of the application using them, so a programmer who had a line-input library he liked could simply use it.

One might use a screen-layout-design program to do mockups of a screen, though a text editor could also suffice if one didn't need color. Once one identified the positions of prompts input fields, it wasn't that hard to write code to handle it.

An essential feature of text-mode user interfaces compared with windowed ones is that operational flows were much more linear. If one didn't mind using "goto", a typical user interface would essentially be:

GetField1:
  ...
GetField2:
  ExitKey := ReadInputLine( { parameters for a particular input operation } );
  If { exit key indicates premature exit } Then Goto Exit;
  If { exit key indicates go back to previous field } then Goto GetField1;
GetField3:
  ...

etc. While windowed applications needed to handle many more kinds of things that could happen while editing a text field, text-mode apps without mouse support generally didn't. Further, if one had a working app without mouse support, it may have been practical to tweak ReadInputLine to add mouse support with relatively minimal change to the surrounding application(*), whereas using an application framework with mouse support built in would have required major rewrites.

(*) If an application was designed so that pushing tab would cycle through fields in wrapping fashion, a ReadInputLine function could respond to a mouse click by latching the coordinates of an unacknowledged mouse click and the identity of the field that was active when it occurred. It could then, while an unacknowledged mouse click remained pending, check to see whether it was within the current input field and, if not, hit tab and notice if the field that became active was the one that had been active when the mouse was clicked. If so, call a user "Unacknowledged mouse click here" function with the coordinates of the click, and clear the pending click, leaving the field selection back where it started, without the underlying application having to know or care about what was happening.

3
  • lol ah, I think I see, but at first glance, your answer is like "...what?" Apr 12 '20 at 21:27
  • @RobertButler: My point was that back in the day, once one knew where UI components belonged on a text-based UI, writing code to put them there was sufficiently easy that there wasn't much benefit to the kind of automated design tools that are far more essential when dealing with a graphical UI.
    – supercat
    Apr 12 '20 at 21:56
  • … and yet such libraries existed in relative abundance, from TurboVision and workalikes such as TVGraphic, through D-Flat and D-Flat++, to C/WinDOS Toolchest from Mix Software.
    – JdeBP
    Apr 14 '20 at 11:36
0

I have not used it, but one option appears to be TCL/TK for DOS. It is available at https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&ved=2ahUKEwjI3MKCzuPoAhVqmeAKHTnED_YQFjACegQIAxAB&url=ftp%3A%2F%2Fftp.tcl.tk%2Fpub%2Ftcl%2Fmirror%2Fftp.procplace.com%2Falcatel%2Fdistrib%2Fmstcl73.README&usg=AOvVaw2nLrFFlM6vWftbBdojybJI

(Gotta love machine-generated URLs! Sorry about the Google pre-linkage, but I can't get StackExchange to recognize an FTP link.) This could be great or it could be unusable. I know Tcl/Tk is a pretty powerful cross-platform development system. How good the overall development environment is ranges from writing text files to full GUI front end. I would suspect this is closer to the former. Sorry for not checking it out myself, but I do think Tcl/Tk does provide a decent UI library. It's not that popular nowadays, but then neither is DOS.

Tk is the actual GUI-generation "toolkit". Tcl is the "Tool Command Language". There are also other backends to drive Tk; it is not solely dependent on Tcl. Also see: https://www.tcl.tk/

2
  • So, how would I use Tk from C? Apr 12 '20 at 21:26
  • 1
    @RobertButler I believe there are C bindings available. AC3D (3D CAD program) for example uses TK for its frontend on X11 (plus Windows & Mac IIRC) with the backend being compiled so it´s likely possible to do so on DOS as well. Apr 12 '20 at 22:05
0

There exists FLTK for DOS, which is the most modern option. It's hardly a surprise, as fltk is simple and hence easy to port anywhere.

Note that djgpp supports the latest c++ standard, so you can do modern c++ gui programming under DOS.

2
  • Yes, but FLTK us GUI. I'm looking for a TUI for DOS, strictly that feels like VBDOS. May 3 at 3:54
  • You may need to change your question then, as you only mention needing an UI library, which does not exclude GUI libraries. May 3 at 6:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.