A modern port of Turbo Vision 2.0, the classical framework for text-based user interfaces. Now cross-platform and with Unicode support.

Overview

Turbo Vision

A modern port of Turbo Vision 2.0, the classical framework for text-based user interfaces. Now cross-platform and with Unicode support.

tvedit on Konsole

I started this as a personal project at the very end of 2018. By May 2020 I considered it was very close to feature parity with the original, and decided to make it open.

The original goals of this project were:

  • Making Turbo Vision work on Linux by altering the legacy codebase as little as possible.
  • Keeping it functional on DOS/Windows.
  • Being as compatible as possible at the source code level with old Turbo Vision applications. This led me to implement some of the Borland C++ RTL functions, as explained below.

At one point I considered I had done enough, and that any attempts at revamping the library and overcoming its original limitations would require either extending the API or breaking backward compatibility, and that a major rewrite would be most likely necessary.

However, between July and August 2020 I found the way to integrate full-fledged Unicode support into the existing arquitecture, wrote the Turbo text editor and also made the new features available on Windows. So I am confident that Turbo Vision can now meet many of the expectations of modern users and programmers.

The original location of this project is https://github.com/magiblot/tvision.

Table of contents

What is Turbo Vision good for?

A lot has changed since Borland created Turbo Vision in the early 90's. Many GUI tools today separate appearance specification from behaviour specification, use safer or dynamic languages which do not segfault on error, and support either parallel or asynchronous programming, or both.

Turbo Vision does not excel at any of those, but it certainly overcomes many of the issues programmers still face today when writing terminal applications:

  1. Forget about terminal capabilities and direct terminal I/O. When writing a Turbo Vision application, all you have to care about is what you want your application to behave and look like—there is no need to add workarounds in your code. Turbo Vision tries its best to produce the same results on all environments. For example: in order to get a bright background color on the Linux console, the blink attribute has to be set. Turbo Vision does this for you.

  2. Reuse what has already been done. Turbo Vision provides many widget classes (also known as views), including resizable, overlapping windows, pull-down menus, dialog boxes, buttons, scroll bars, input boxes, check boxes and radio buttons. You may use and extend these; but even if you prefer creating your own, Turbo Vision already handles event dispatching, display of fullwidth Unicode characters, etc.: you do not need to waste time rewriting any of that.

  3. Can you imagine writing a text-based interface that works both on Linux and Windows (and thus is cross-platform) out-of-the-box, with no #ifdefs? Turbo Vision makes this possible. First: Turbo Vision keeps on using char arrays instead of relying on the implementation-defined and platform-dependent wchar_t or TCHAR. Second: thanks to UTF-8 support in setlocale in recent versions of Microsoft's RTL, code like the following will work as intended:

    std::ifstream f("コンピュータ.txt"); // On Windows, the RTL converts this to the system encoding on-the-fly.

How do I use Turbo Vision?

You can get started with the Turbo Vision For C++ User's Guide, and look at the sample applications hello, tvdemo and tvedit. Once you grasp the basics, I suggest you take a look at the Turbo Vision 2.0 Programming Guide, which is, in my opinion, more intuitive and easier to understand, despite using Pascal. By then you will probably be interested in the palette example, which contains a detailed description of how palettes are used.

Don't forget to check out the features and API changes sections as well.

Releases and downloads

This project has no stable releases for the time being. If you are a developer, try to stick to the latest commit and report any issues you find while upgrading.

If you just want to test the demo applications:

  • Unix systems: you'll have to build Turbo Vision yourself. You may follow the build instructions below.
  • Windows: you can find up-to-date binaries in the Actions section. Click on the first successful workflow (with a green tick) in the list. At the bottom of the workflow page, as long as you have logged in to GitHub, you'll find an Artifacts section with the following files:
    • examples-dos32.zip: 32-bit executables built with Borland C++. No Unicode support.
    • examples-x86.zip: 32-bit executables built with MSVC. Windows Vista or later required.
    • examples-x64.zip: 64-bit executables built with MSVC. x64 Windows Vista or later required.

Build environment

Linux

Turbo Vision can be built as an static library with CMake and GCC/Clang.

cmake . -B ./build -DCMAKE_BUILD_TYPE=Release && # Could also be 'Debug', 'MinSizeRel' or 'RelWithDebInfo'.
cmake --build ./build # or `cd ./build; make`

CMake versions older than 3.13 may not support the -B option. You can try the following instead:

mkdir -p build; cd build
cmake .. -DCMAKE_BUILD_TYPE=Release &&
cmake --build .

The above produces the following files:

  • libtvision.a, which is the Turbo Vision library.
  • The demo applications hello, tvdemo, tvedit, tvdir, which were bundled with the original Turbo Vision (although some of them have a few improvements).
  • The demo applications mmenu and palette from Borland's Technical Support.
  • tvhc, the Turbo Vision Help Compiler.

The library and executables can be found in ./build.

The build requirements are:

  • A compiler supporting C++14.
  • libncursesw (note the 'w').
  • libgpm (for mouse support on the Linux console) (optional).

If your distribution provides separate devel packages (e.g. libncurses-dev, libgpm-dev in Debian-based distros), install these too.

The minimal command line required to build a Turbo Vision application (e.g. hello.cpp with GCC) from this project's root is:

g++ -std=c++14 -o hello hello.cpp ./build/libtvision.a -Iinclude -lncursesw -lgpm

You may also need:

  • -Iinclude/tvision if your application uses Turbo Vision 1.x includes (#include <tv.h> instead of #include <tvision/tv.h>).

  • -Iinclude/tvision/compat if your application includes Borland headers (dir.h, iostream.h, etc.).

  • On Gentoo (and possibly others): -ltinfow if both libtinfo.so and libtinfow.so are available in your system. Otherwise, you may get a segmentation fault when running Turbo Vision applications (#11). Note that tinfo is bundled with ncurses.

-lgpm is only necessary if Turbo Vision was built with libgpm support.

The backward-compatibility headers in include/tvision/compat emulate the Borland C++ RTL. Turbo Vision's source code still depends on them, and they could be useful if porting old applications. This also means that including tvision/tv.h will bring several std names to the global namespace.

Windows (MSVC)

The build process with MSVC is slightly more complex, as there are more options to choose from. Note that you will need different build directories for different target architectures. For instance, to generate optimized binaries:

cmake . -B ./build && # Add '-A x64' (64-bit) or '-A Win32' (32-bit) to override the default platform.
cmake --build ./build --config Release # Could also be 'Debug', 'MinSizeRel' or 'RelWithDebInfo'.

In the example above, tvision.lib and the example applications will be placed at ./build/Release.

If you wish to link Turbo Vision statically against Microsofts's run-time library (/MT instead of /MD), enable the TV_USE_STATIC_RTL option (-DTV_USE_STATIC_RTL=ON when calling cmake).

If you wish to link an application against Turbo Vision, note that MSVC won't allow you to mix /MT with /MD or debug with non-debug binaries. All components have to be linked against the RTL in the same way.

If you develop your own Turbo Vision application make sure to enable the following compiler flags, or else you will get compilation errors when including <tvision/tv.h>:

/permissive-
/Zc:__cplusplus

If you use Turbo Vision as a CMake submodule, these flags will be enabled automatically.

Note: Turbo Vision uses setlocale to set the RTL functions in UTF-8 mode. This won't work if you use an old version of the RTL.

With the RTL statically linked in, and if UTF-8 is supported in setlocale, Turbo Vision applications are portable and work by default on Windows Vista and later.

Windows (MinGW)

Once your MinGW environment is properly set up, build is done in a similar way to Linux:

cmake . -B ./build -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release &&
cmake --build ./build

In the example above, libtvision.a and all examples are in ./build if TV_BUILD_EXAMPLES option is ON (the default).

If you wish to link an application against Turbo Vision, simply add -L./build/lib -ltvision to your linker and -I./include to your compiler

Windows/DOS (Borland C++)

Turbo Vision can still be built either as a DOS or Windows library with Borland C++. Obviously, there is no Unicode support here.

I can confirm the build process works with:

  • Borland C++ 4.52 with the Borland PowerPack for DOS.
  • Turbo Assembler 4.0.

You may face different problems depending on your build environment. For instance, Turbo Assembler needs a patch to work under Windows 95. On Windows XP everything seems to work fine. On Windows 10, MAKE may emit the error Fatal: Command arguments too long, which can be fixed by upgrading MAKE to the one bundled with Borland C++ 5.x.

Yes, this works on 64-bit Windows 10. What won't work is the Borland C++ installer, which is a 16-bit application. You will have to run it on another environment or try your luck with winevdm.

A Borland Makefile can be found in the project directory. Build can be done by doing:

cd project
make.exe <options>

Where <options> can be:

  • -DDOS32 for 32-bit DPMI applications (which still work on 64-bit Windows).
  • -DWIN32 for 32-bit native Win32 applications (not possible for TVDEMO, which relies on farcoreleft() and other antiquities).
  • -DDEBUG to build debug versions of the application and the library.
  • -DTVDEBUG to link the applications with the debug version of the library.
  • -DOVERLAY, -DALIGNMENT={2,4}, -DEXCEPTION, -DNO_STREAMABLE, -DNOTASM for things I have nave never used but appeared in the original makefiles.

This will compile the library into a LIB directory next to project, and will compile executables for the demo applications in their respective examples/* directories.

I'm sorry, the root makefile assumes it is executed from the project directory. You can still run the original makefiles directly (in source/tvision and examples/*) if you want to use different settings.

Turbo Vision as a CMake dependency (not Borland C++)

If you choose the CMake build system for your application, there are two main ways to link against Turbo Vision:

  • Installing Turbo Vision and importing it with find_package. Installation depends on the generator type:

    • First, decide an install prefix. The default one will work out-of-the-box, but usually requires admin privileges. On Unix systems, you can use $HOME/.local instead. On Windows, you can use any custom path you want but you'll have to add it to the CMAKE_PREFIX_PATH environment variable when building your application.

    • For mono-config generators (Unix Makefiles, Ninja...), you only have to build and install once:

      cmake . -B ./build # '-DCMAKE_INSTALL_PREFIX=...' to override the install prefix.
      cmake --build ./build
      cmake --install ./build
    • For multi-config generators (Visual Studio, Ninja Multi-Config...) you should build and install all configurations:

      cmake . -B ./build # '-DCMAKE_INSTALL_PREFIX=...' to override the install prefix.
      cmake --build ./build --config Release
      cmake --build ./build --config Debug --target tvision
      cmake --build ./build --config RelWithDebInfo --target tvision
      cmake --build ./build --config MinSizeRel --target tvision
      cmake --install ./build --config Release
      cmake --install ./build --config Debug --component library
      cmake --install ./build --config RelWithDebInfo --component library
      cmake --install ./build --config MinSizeRel --component library

    Then, in your application's CMakeLists.txt, you may import it like this:

    find_package(tvision CONFIG)
    target_link_libraries(my_application tvision::tvision)
  • Have Turbo Vision in a submodule in your repository and import it with add_subdirectory:

    add_subdirectory(tvision) # Assuming Turbo Vision is in the 'tvision' directory.
    target_link_libraries(my_application tvision)

In either case, <tvision/tv.h> will be available in your application's include path during compilation, and your application will be linked against the necessary libraries (Ncurses, GPM...) automatically.

Features

Modern platforms (not Borland C++)

  • UTF-8 support. You can try it out in the tvedit application.
  • 24-bit color support (up from the original 16 colors).
  • 'Open File' dialogs accepts both Unix and Windows-style file paths and can expand ~/ into $HOME.
  • Redirection of stdin/stdout/stderr does not interfere with terminal I/O.
  • Compatibility with 32-bit help files.

There are a few environment variables that affect the behaviour of all Turbo Vision applications:

  • TVISION_MAX_FPS: maximum refresh rate, default 60. This can help keep smoothness in terminal emulators with unefficient handling of box-drawing characters. Special values for this option are 0, to disable refresh rate limiting, and -1, to actually draw to the terminal in every call to THardwareInfo::screenWrite (useful when debugging).

  • TVISION_CODEPAGE: the character set used internally by Turbo Vision to translate extended ASCII into Unicode. Valid values at the moment are 437 and 850, with 437 being the default, although adding more takes very little effort.

Unix

  • Ncurses-based terminal support.
  • Extensive mouse and keyboard support:
    • Support for X10 and SGR mouse encodings.
    • Support for Xterm's modifyOtherKeys.
    • Support for Paul Evans' fixterms and Kitty's keyboard protocol.
    • Support for key modifiers (via TIOCLINUX) and mouse (via GPM) in the Linux console.
  • Custom signal handler that restores the terminal state before the program crashes.

The following environment variables are also taken into account:

  • TERM: Ncurses uses it to determine terminal capabilities. It is set automatically by the terminal emulator.

  • COLORTERM: when set to truecolor or 24bit, Turbo Vision will assume the terminal emulator supports 24-bit color. It is set automatically by terminal emulators that support it.

  • TVISION_ESCDELAY: the number of milliseconds to wait after receiving an ESC key press, default 10. If another key is pressed during this delay, it will be interpreted as an Alt+Key combination. Using a larger value is useful when the terminal doesn't support the Alt key.

  • TVISION_USE_STDIO: when not empty, terminal I/O is performed through stdin/stdout, so that it can be redirected from the shell. By default, Turbo Vision performs terminal I/O through /dev/tty, allowing the user to redirect stdin, stdout and stderr for their needs, without affecting the application's stability.

    For example, the following will leave out.txt empty:

    tvdemo | tee out.txt

    While the following will dump all the escape sequences and text printed by the application into out.txt:

    TVISION_USE_STDIO=1 tvdemo | tee out.txt
  • TVISION_DISPLAY: strategy for drawing to screen. Valid values are ansi and ncurses, with ansi being the default. The Ncurses library is used in either case, with the difference that ncurses uses Ncurses' own draw methods and is limited to 16 colors, while ansi supports 24-bit color and avoids redundant buffering and UTF-8 to wide char conversions.

Windows

  • Only compatible with the Win32 Console API. On terminal emulators that don't support this, Turbo Vision will automatically pop up a separate console window.
  • Applications fit the console window size instead of the buffer size (no scrollbars are visible) and the console buffer is restored when exiting or suspending Turbo Vision.

The following are not available when compiling with Borland C++:

  • The console's codepage is set to UTF-8 on startup and restored on exit.
  • Microsoft's C runtime functions are set automatically to UTF-8 mode, so you as a developer don't need to use the wchar_t variants.
  • If the console crashes, a new one is allocated automatically.

Note: Turbo Vision writes UTF-8 text directly to the Windows console. If the console is set in legacy mode and the bitmap font is being used, Unicode characters will not be displayed properly (photo). To avoid this, Turbo Vision detects this situation and tries to change the console font to Consolas or Lucida Console.

All platforms

The following are new features not available in Borland's release of Turbo Vision or in previous open source ports (Sigala, SET):

  • Middle mouse button and mouse wheel support.
  • Arbitrary screen size support (up to 32767 rows or columns) and graceful handling of screen resize events.
  • Windows can be resized from their bottom left corner.
  • Windows can be dragged from empty areas with the middle mouse button.
  • Improved usability of menus: they can be closed by clicking again on the parent menu item.
  • Improved usability of scrollbars: dragging them also scrolls the page. Clicking on an empty area of the scrollbar moves the thumb right under the cursor. They respond by default to mouse wheel events.
  • TInputLines no longer scroll the text display on focus/unfocus, allowing relevant text to stay visible.
  • Support for LF line endings in TFileViewer (tvdemo) and TEditor (tvedit). TEditor preserves the line ending on file save but all newly created files use CRLF by default.
  • TEditor: context menu on right click.
  • TEditor: drag scroll with middle mouse button.
  • TEditor: delete whole words with kbAltBack, kbCtrlBack and kbCtrlDel.
  • TEditor: the Home key toggles between beginning of line and beginning of indented text.
  • TEditor: support for files bigger than 64 KiB on 32-bit or 64-bit builds.
  • tvdemo: event viewer applet useful for event debugging.
  • tvdemo: option to change the background pattern.

API changes

  • Screen writes are buffered and are usually sent to the terminal once for every iteration of the active event loop (see also TVISION_MAX_FPS). If you need to update the screen during a busy loop, you may use TScreen::flushScreen().
  • TDrawBuffer is no longer a fixed-length array. The equivalent of sizeof(TDrawBuffer)/sizeof(ushort) is the .length() method.
  • TTextDevice is now buffered, so if you were using otstream you may have to send std::flush or std::endl through it for do_sputn to be invoked.
  • TApplication now provides dosShell(), cascade() and tile(), and handles cmDosShell, cmCascade and cmTile by default. These functions can be customized by overriding getTileRect() and writeShellMsg(). This is the same behaviour as in the Pascal version.
  • Mouse wheel support: new mouse event evMouseWheel. The wheel direction is specified in the new field event.mouse.wheel, whose possible values are mwUp, mwDown, mwLeft or mwRight.
  • Middle mouse button support: new mouse button flag mbMiddleButton.
  • The buttons field in evMouseUp events is no longer empty. It now indicates which button was released.
  • Triple-click support: new mouse event flag meTripleClick.
  • TRect methods move, grow, intersect and Union now return TRect& instead of being void so that they can be chained.
  • TOutlineViewer now allows the root node to have siblings.
  • New function ushort popupMenu(TPoint where, TMenuItem &aMenu, TGroup *receiver=0) which spawns a TMenuPopup on the desktop. See source/tvision/popupmnu.cpp.
  • New virtual method TMenuItem& TEditor::initContextMenu(TPoint p) that determines the entries of the right-click context menu in TEditor.
  • fexpand can now take a second parameter relativeTo.
  • New class TStringView, inspired by std::string_view.
    • Many functions which originally had null-terminated string parameters now receive TStringView instead. TStringView is compatible with std::string_view, std::string and const char * (even nullptr).
  • New class TSpan<T>, inspired by std::span.
  • New classes TDrawSurface and TSurfaceView, see <tvision/surface.h>.
  • New method TVMemMgr::reallocateDiscardable() which can be used along allocateDiscardable and freeDiscardable.
  • New method TView::textEvent() which allows receiving text in an efficient manner, see Clipboard interaction.
  • Unicode support, see Unicode.
  • True Color support, see extended colors.
  • New method static void TEvent::waitEvent(int timeoutMs) which may block for up to timeoutMs milliseconds waiting for input events. If it blocks, it has the side effect of flushing screen updates. It is invoked by TProgram::getEvent() with static int TProgram::appEventTimeout (default 20) as argument so that the event loop doesn't consume 100% CPU.
  • New method static void TEvent::putNothing() which puts an evNothing event into the event queue and causes TEvent::waitEvent() not to block until an evNothing is returned by TEvent::getKeyEvent(). This will usually cause the main thread to wake up from TEvent::waitEvent() and to invoke TApplication::idle() immediately. This method is thread-safe, so it can be used to unblock the event loop from any other thread.

Screenshots

You will find some screenshots here. Feel free to add your own!

Contributing

If you know of any Turbo Vision applications whose source code has not been lost and that could benefit from this, let me know.

Applications using Turbo Vision

If your application is based on this project and you'd like it to appear in the following list, just let me know.

Unicode support

The Turbo Vision API has been extended to allow receiving Unicode input and displaying Unicode text. The supported encoding is UTF-8, for a number of reasons:

  • It is compatible with already present data types (char *), so it does not require intrusive modifications to existing code.
  • It is the same encoding used for terminal I/O, so redundant conversions are avoided.
  • Conformance to the UTF-8 Everywhere Manifesto, which exposes many other advantages.

Note that when built with Borland C++, Turbo Vision does not support Unicode. However, this does not affect the way Turbo Vision applications are written, since the API extensions are designed to allow for encoding-agnostic code.

Reading Unicode input

The traditional way to get text from a key press event is as follows:

// 'ev' is a TEvent, and 'ev.what' equals 'evKeyDown'.
switch (ev.keyDown.keyCode) {
    // Key shortcuts are usually checked first.
    // ...
    default: {
        // The character is encoded in the current codepage
        // (CP437 by default).
        char c = ev.keyDown.charScan.charCode;
        // ...
    }
}

Some of the existing Turbo Vision classes that deal with text input still depend on this methodology, which has not changed. Single-byte characters, when representable in the current codepage, continue to be available in ev.keyDown.charScan.charCode.

Unicode support consists in two new fields in ev.keyDown (which is a struct KeyDownEvent):

  • char text[4], which may contain whatever was read from the terminal: usually a UTF-8 sequence, but possibly any kind of raw data.
  • uchar textLength, which is the number of bytes of data available in text, from 0 to 4.

Note that the text field may contain garbage or uninitialized data from position textLength on.

You can also get a TStringView out of a KeyDownEvent with the getText() method.

So a Unicode character can be retrieved from TEvent in the following way:

switch (ev.keyDown.keyCode) {
    // ...
    default: {
        std::string_view sv = ev.keyDown.getText();
        processText(sv);
    }
}

Let's see it from another perspective. If the user types ñ, a TEvent is generated with the following keyDown struct:

KeyDownEvent {
    union {
        .keyCode = 0xA4,
        .charScan = CharScanType {
            .charCode = 164 ('ñ'), // In CP437
            .scanCode = 0
        }
    },
    .controlKeyState = 0x200 (kbInsState),
    .text = {'\xC3', '\xB1'}, // In UTF-8
    .textLength = 2
}

However, if they type the following will happen:

KeyDownEvent {
    union {
        .keyCode = 0x0 (kbNoKey), // '€' not part of CP437
        .charScan = CharScanType {
            .charCode = 0,
            .scanCode = 0
        }
    },
    .controlKeyState = 0x200 (kbInsState),
    .text = {'\xE2', '\x82', '\xAC'}, // In UTF-8
    .textLength = 3
}

If a key shortcut is pressed instead, text is empty:

KeyDownEvent {
    union {
        .keyCode = 0xB (kbCtrlK),
        .charScan = CharScanType {
            .charCode = 11 (''),
            .scanCode = 0
        }
    },
    .controlKeyState = 0x20C (kbCtrlShift | kbInsState),
    .text = {},
    .textLength = 0
}

So, in short: views designed without Unicode input in mind will continue to work exactly as they did before, and views which want to be Unicode-aware will have no issues in being so.

Displaying Unicode text

The original design of Turbo Vision uses 16 bits to represent a screen cell—8 bit for a character and 8 bit for BIOS color attributes.

A new TScreenCell type is defined in <tvision/scrncell.h> which is capable of holding a limited number of UTF-8 codepoints in addition to extended attributes (bold, underline, italic...). However, you should not write text into a TScreenCell directly but make use of Unicode-aware API functions instead.

Text display rules

A character provided as argument to any of the Turbo Vision API functions that deal with displaying text is interpreted as follows:

  • Non-printable characters in the range 0x00 to 0xFF are interpreted as characters in the active codepage. For instance, 0x7F is displayed as and 0xF0 as if using CP437. As an exception, 0x00 is always displayed as a regular space. These characters are all one column wide.
  • Character sequences which are not valid UTF-8 are interpreted as sequences of characters in the current codepage, as in the case above.
  • Valid UTF-8 sequences with a display width other than one are taken care of in a special way, see below.

For example, the string "╔[\xFE]╗" may be displayed as ╔[■]╗. This means that box-drawing characters can be mixed with UTF-8 in general, which is useful for backward compatibility. If you rely on this behaviour, though, you may get unexpected results: for instance, "\xC4\xBF" is a valid UTF-8 sequence and is displayed as Ŀ instead of ─┐.

One of the issues of Unicode support is the existence of multi-width characters and combining characters. This conflicts with Turbo Vision's original assumption that the screen is a grid of cells occupied by a single character each. Nevertheless, these cases are handled in the following way:

  • Multi-width characters can be drawn anywhere on the screen and nothing bad happens if they overlap partially with other characters.

  • Zero-width characters overlay the previous character. For example, the sequence में consists of the single-width character and the combining characters and . In this case, three Unicode codepoints are fit into the same cell.

    The ZERO WIDTH JOINER (U+200D) is always omitted, as it complicates things too much. For example, it can turn a string like "👩👦" (4 columns wide) into "👩‍👦" (2 columns wide). Not all terminal emulators respect the ZWJ, so, in order to produce predictable results, Turbo Vision will print both "👩👦" and "👩‍👦" as 👩👦.

  • No notable graphical glitches will occur as long as your terminal emulator respects character widths as measured by wcwidth.

Here is an example of such characters in the Turbo text editor: Wide character display

Unicode-aware API functions

The usual way of writing to the screen is by using TDrawBuffer. A few methods have been added and others have changed their meaning:

void TDrawBuffer::moveChar(ushort indent, char c, TColorAttr attr, ushort count);
void TDrawBuffer::putChar(ushort indent, char c);

c is always interpreted as a character in the active codepage.

ushort TDrawBuffer::moveStr(ushort indent, TStringView str, TColorAttr attr);
ushort TDrawBuffer::moveCStr(ushort indent, TStringView str, TAttrPair attrs);

str is interpreted according to the rules exposed previously.

ushort TDrawBuffer::moveStr(ushort indent, TStringView str, TColorAttr attr, ushort width, ushort begin=0); // New

str is interpreted according to the rules exposed previously. However:

  • width specifies the maximum number of display columns that should be read from str.
  • begin specifies the number of display columns that should be skipped at the beginning of str. This is useful for horizontal scrolling. If begin is in the middle of a multi-width character, the remaining positions in that character are filled with spaces.

The return values are the number of display columns that were actually filled with text.

void TDrawBuffer::moveBuf(ushort indent, const void *source, TColorAttr attr, ushort count);

The name of this function is misleading. Even in its original implementation, source is treated as a string. So it is equivalent to moveStr(indent, TStringView((const char*) source, count), attr).

There are other useful Unicode-aware functions:

int cstrlen(TStringView s);

Returns the displayed length of s according to the aforementioned rules, discarding ~ characters.

int strwidth(TStringView s); // New

Returns the displayed length of s.

On Borland C++, these methods assume a single-byte encoding and all characters being one column wide. This makes it possible to write encoding-agnostic draw() and handleEvent() methods that work on both platforms without a single #ifdef.

The functions above are implemented using the functions from the TText namespace, another API extension. You will have to use them directly if you want to fill TScreenCell objects with text manually. To give an example, below are some of the TText functions. You can find all of them with complete descriptions in <tvision/ttext.h>.

size_t TText::next(TStringView text);
size_t TText::prev(TStringView text, size_t index);
void TText::drawChar(TSpan<TScreenCell> cells, char c);
size_t TText::drawStr(TSpan<TScreenCell> cells, size_t indent, TStringView text, int textIndent);
bool TText::drawOne(TSpan<TScreenCell> cells, size_t &i, TStringView text, size_t &j);

For drawing TScreenCell buffers into a view, the following methods are available:

void TView::writeBuf(short x, short y, short w, short h, const TScreenCell *b); // New
void TView::writeLine(short x, short y, short w, short h, const TScreenCell *b); // New

Example: Unicode text in menus and status bars

It's as simple as it can be. Let's modify hello.cpp as follows:

TMenuBar *THelloApp::initMenuBar( TRect r )
{
    r.b.y = r.a.y+1;
    return new TMenuBar( r,
      *new TSubMenu( "~Ñ~ello", kbAltH ) +
        *new TMenuItem( "階~毎~料入報最...", GreetThemCmd, kbAltG ) +
        *new TMenuItem( "五劫~の~擦り切れ", cmYes, kbNoKey, hcNoContext ) +
        *new TMenuItem( "העברית ~א~ינטרנט", cmNo, kbNoKey, hcNoContext ) +
         newLine() +
        *new TMenuItem( "E~x~it", cmQuit, cmQuit, hcNoContext, "Alt-X" )
        );
}

TStatusLine *THelloApp::initStatusLine( TRect r )
{
    r.a.y = r.b.y-1;
    return new TStatusLine( r,
        *new TStatusDef( 0, 0xFFFF ) +
            *new TStatusItem( "~Alt-Ç~ Exit", kbAltX, cmQuit ) +
            *new TStatusItem( 0, kbF10, cmMenu )
            );
}

Here is what it looks like:

Unicode Hello

Example: writing Unicode-aware draw() methods

The following is an excerpt from an old implementation of TFileViewer::draw() (part of the tvdemo application), which does not draw Unicode text properly:

if (delta.y + i < fileLines->getCount()) {
    char s[maxLineLength+1];
    p = (char *)(fileLines->at(delta.y+i));
    if (p == 0 || strlen(p) < delta.x)
        s[0] = EOS;
    else
        strnzcpy(s, p+delta.x, maxLineLength+1);
    b.moveStr(0, s, c);
}
writeBuf( 0, i, size.x, 1, b );

All it does is move part of a string in fileLines into b, which is a TDrawBuffer. delta is a TPoint representing the scroll offset in the text view, and i is the index of the visible line being processed. c is the text color. A few issues are present:

  • TDrawBuffer::moveStr(ushort, const char *, TColorAttr) takes a null-terminated string. In order to pass a substring of the current line, a copy is made into the array s, at the risk of a buffer overrun. The case where the line does not fit into s is not handled, so at most maxLineLenght characters will be copied. What's more, a multibyte character near position maxLineLength could be copied incompletely and be displayed as garbage.
  • delta.x is the first visible column. With multibyte-encoded text, it is no longer true that such column begins at position delta.x in the string.

Below is a corrected version of the code above that handles Unicode properly:

if (delta.y + i < fileLines->getCount()) {
    p = (char *)(fileLines->at(delta.y+i));
    if (p)
        b.moveStr(0, p, c, size.x, delta.x);
}
writeBuf( 0, i, size.x, 1, b );

The overload of moveStr used here is TDrawBuffer::moveStr(ushort indent, TStringView str, TColorAttr attr, ushort width, ushort begin). This function not only provides Unicode support, but also helps us write cleaner code and overcome some of the limitations previously present:

  • The intermediary copy is avoided, so the displayed text is not limited to maxLineLength bytes.
  • moveStr takes care of printing the string starting at column delta.x. We do not even need to worry about how many bytes correspond to delta.x columns.
  • Similarly, moveStr is instructed to copy at most size.x columns of text without us having to care about how many bytes that is nor dealing with edge cases. The code is written in an encoding-agnostic way and will work whether multibyte characters are being considered or not.
  • In case you hadn't realized yet, the intermediary copy in the previous version was completely unnecessary. It would have been necessary only if we had needed to trim the end of the line, but that was not the case: text occupies all of the view's width, and TView::writeBuf already takes care of not writing beyond it. Yet it is interesting to see how an unnecessary step not only was limiting functionality but also was prone to bugs.

Unicode support across standard views

Support for creating Unicode-aware views is in place, and most views in the original Turbo Vision library have been adapted to handle Unicode.

The following views can display Unicode text properly. Some of them also do horizontal scrolling or word wrapping; all of that should work fine.

The following views can, in addition, process Unicode text or user input:

  • TInputLine (81066ee5, cb489d42).
  • TEditor (702114dc). Instances are in UTF-8 mode by default. You may switch back to single-byte mode by pressing Ctrl+P. This only changes how the document is displayed and the encoding of user input; it does not alter the document. This class is used in the tvedit application; you may test it there.

Views not in this list may not have needed any corrections or I simply forgot to fix them. Please submit an issue if you notice anything not working as expected.

Use cases where Unicode is not supported (not an exhaustive list):

  • Highlighted key shortcuts, in general (e.g. TMenuBox, TStatusLine, TButton...).

Clipboard interaction

The Turbo Vision API offers no integration with the system clipboard. As a developer you can still access it by other means (e.g. via libclipboard). But unless you do that, the only way for a user to paste text into your application is to do so through the terminal emulator.

Unfortunately, each character is processed as a separate evKeyDown event. If the user pastes 5000 characters, the application will execute the same operations as if the user pressed the keyboard 5000 times. This involves drawing views, completing the event loop, updating the screen, etcetera. As you can imagine, this is far from optimal.

For the purpose of dealing with this situation, the Turbo Vision API has been extended with the following function:

Boolean TView::textEvent(TEvent &event, TSpan<char> dest, size_t &length);

TEditor takes advantage of this function to provide a good user experience when pasting text through the terminal. You can check it out in the tvedit application. As a developer, you may be interested in using it if you are implementing a text editing component. Otherwise, you don't need to care about it.

Just for the record, here is a more detailed explanation:

textEvent() tries to read text from standard input and stores it in a user-provided buffer dest. It returns False when no more events are available in the program's input queue or if a non-text event is found, in which case this event is saved with putEvent() so that it can be processed in the next iteration of the event loop.

The exact number of bytes read is stored in the output parameter length, which can never be greater than dest.size().

It is intended to be used as follows:

// 'ev' is a TEvent, and 'ev.what' equals 'evKeyDown'.
// If the event contains text...
if (ev.keyDown.textLength) {
    char buf[512];
    size_t length;
    // Fill 'buf' with text from the input queue,
    // including the text in 'ev'.
    while (textEvent(ev, buf, length)) {
        // Process 'length' bytes of text in 'buf'.
        // ...
    }
    // 'textEvent()' clears 'ev' after reading it the first time
    // (by this point, 'ev.what' is 'evNothing').
}

Extended color support

The Turbo Vision API has been extended to allow more than the original 16 colors.

Colors can be specified using any of the following formats:

  • BIOS color attributes (4-bit), the format used originally on MS-DOS.
  • RGB (24-bit).
  • xterm-256color palette indices (8-bit).
  • The terminal default color. This is the color used by terminal emulators when no display attributes (bold, color...) are enabled (usually white for foreground and black for background).

Although Turbo Vision applications are likely to be ran in a terminal emulator, the API makes no assumptions about the display device. That is, the complexity of dealing with terminal emulators is hidden from the programmer and managed by Turbo Vision itself.

For example: color support varies among terminals. If the programmer uses a color format not supported by the terminal emulator, Turbo Vision will quantize it to what the terminal can display. The following images represent the quantization of a 24-bit RGB picture to 256, 16 and 8 color palettes:

24-bit color (original) 256 colors
mpv-shot0005 mpv-shot0002
16 colors 8 colors (bold as bright)
mpv-shot0003 mpv-shot0004

Extended color support basically comes down to the following:

  • Turbo Vision has originally used BIOS color attributes stored in an uchar. ushort is used to represent attribute pairs. This is still the case when using Borland C++.
  • In modern platforms a new type TColorAttr has been added which replaces uchar. It specifies a foreground and background color and a style. Colors can be specified in different formats (BIOS color attributes, 24-bit RGB...). Styles are the typical ones (bold, italic, underline...). There's also TAttrPair, which replaces ushort.
  • TDrawBuffer's methods, which used to take uchar or ushort parameters to specify color attributes, now take TColorAttr or TAttrPair.
  • TPalette, which used to contain an array of uchar, now contains an array of TColorAttr. The TView::mapColor method also returns TColorAttr instead of uchar.
  • TView::mapColor has been made virtual so that the palette system can be bypassed without having to rewrite any draw methods.
  • TColorAttr and TAttrPair can be initialized with and casted into uchar and ushort in a way such that legacy code still compiles out-of-the-box without any change in functionality.

Below is a more detailed explanation aimed at developers.

API reference of extended color support (click to expand).

Data Types

In the first place we will explain the data types the programmer needs to know in order to take advantage of the extended color suport.

To get access to them, define the macro Uses_TColorAttr before including <tvision/tv.h>. You may not need to do this because other classes like TView or TDrawBuffer already depend on it.

All the types described in this section are trivial. This means that they can be memset'd and memcpy'd. But variables of these types are uninitialized when declared without initializer, just like primitive types. So make sure you don't manipulate them before initializing them.

Color format types

Several types are defined which represent different color formats. The reason why these types exist is to allow distinguishing color formats using the type system. Some of them also have public fields which make it easier to manipulate individual bits.

  • TColorBIOS represents a BIOS color. It behaves the same as uint8_t, but allows accessing the r, g, b and bright bits individually.

    The memory layout is:

    • Bit 0: Blue (field b).
    • Bit 1: Green (field g).
    • Bit 2: Red (field r).
    • Bit 3: Bright (field bright).
    • Bits 4-7: unused.
    TColorBIOS bios = 0x4;  // 0x4: red.
    bios.bright = 1;        // 0xC: light red.
    bios.b = bios.r;        // 0xD: light magenta.
    bios = bios ^ 3;        // 0xE: yellow.
    uint8_t c = bios;       // Implicit conversion to integer types.

    In terminal emulators, BIOS colors are mapped to the basic 16 ANSI colors.

  • TColorRGB represents a color in 24-bit RGB. It behaves the same as uint32_t but allows accessing the r, g and b bit fields individually.

    The memory layout is:

    • Bits 0-7: Blue (field b).
    • Bits 8-15: Green (field g).
    • Bits 16-23: Red (field r).
    • Bits 24-31: unused.
    TColorRGB rgb = 0x9370DB;   // 0xRRGGBB.
    rgb = {0x93, 0x70, 0xDB};   // {R, G, B}.
    rgb = rgb ^ 0xFFFFFF;       // Negated.
    rgb.g = rgb.r & 0x88;       // Access to individual components.
    uint32_t c = rgb;           // Implicit conversion to integer types.
  • TColorXTerm represents an index into the xterm-256color color palette. It behaves the same as uint8_t.

TColorDesired

TColorDesired represents a color which the programmer intends to show on screen, encoded in any of the supported color types.

A TColorDesired can be initialized in the following ways:

  • As a BIOS color: with a char literal or a TColorBIOS object:

    TColorDesired bios1 = '\xF';
    TColorDesired bios2 = TColorBIOS(0xF);
  • As a RGB color: with an int literal or a TColorRGB object:

    TColorDesired rgb1 = 0xFF7700; // 0xRRGGBB.
    TColorDesired rgb2 = TColorRGB(0xFF, 0x77, 0x00); // {R, G, B}.
    TColorDesired rgb3 = TColorRGB(0xFF7700); // 0xRRGGBB.
  • As an XTerm palette index: with a TColorXTerm object.

  • As the terminal default color: through zero-initialization:

    TColorDesired def1 {};
    // Or with 'memset':
    TColorDesired def2;
    memset(&def2, 0, sizeof(def2));

TColorDesired has methods to query the contained color, but you will usually not need to use them. See the struct definition in <tvision/colors.h> for more information.

Trivia: the name is inspired by Scintilla's ColourDesired.

TColorAttr

TColorAttr describes the color attributes of a screen cell. This is the type you are most likely to interact with if you intend to change the colors in a view.

A TColorAttr is composed of:

  • A foreground color, of type TColorDesired.

  • A background color, of type TColorDesired.

  • A style bitmask containing a combination of the following flags:

    • slBold.
    • slItalic.
    • slUnderline.
    • slBlink.
    • slReverse.
    • slStrike.

    These flags are based on the basic display attributes selectable through ANSI escape codes. The results may vary between terminal emulators. slReverse is probably the least reliable of them: prefer using the TColorAttr reverseAttribute(TColorAttr attr) free function over setting this flag.

The most straight-forward way to create a TColorAttr is by means of the TColorAttr(TColorDesired fg, TColorDesired bg, ushort style=0) and TColorAttr(int bios) constructors:

// Foreground: RGB 0x892312
// Background: RGB 0x7F00BB
// Style: Normal.
TColorAttr a1 = {TColorRGB(0x89, 0x23, 0x12), TColorRGB(0x7F, 0x00, 0xBB)};

// Foreground: BIOS 0x7.
// Background: RGB 0x7F00BB.
// Style: Bold, Italic.
TColorAttr a2 = {'\x7', 0x7F00BB, slBold | slItalic};

// Foreground: Terminal default.
// Background: BIOS 0xF.
// Style: Normal.
TColorAttr a3 = {{}, TColorBIOS(0xF)};

// Foreground: Terminal default.
// Background: Terminal default.
// Style: Normal.
TColorAttr a4 = {};

// Foreground: BIOS 0x0
// Background: BIOS 0x7
// Style: Normal
TColorAttr a5 = 0x70;

The fields of a TColorAttr can be accessed with the following free functions:

TColorDesired getFore(const TColorAttr &attr);
TColorDesired getBack(const TColorAttr &attr);
ushort getStyle(const TColorAttr &attr);
void setFore(TColorAttr &attr, TColorDesired fg);
void setBack(TColorAttr &attr, TColorDesired bg);
void setStyle(TColorAttr &attr, ushort style);

TAttrPair

TAttrPair is a pair of TColorAttr, used by some API functions to pass two attributes at once.

You may initialize a TAttrPair with the TAttrPair(const TColorAttrs &lo, const TColorAttrs &hi) constructor:

TColorAttr cNormal = {0x234983, 0x267232};
TColorAttr cHigh = {0x309283, 0x127844};
TAttrPair attrs = {cNormal, cHigh};
TDrawBuffer b;
b.moveCStr(0, "Normal text, ~Highlighted text~", attrs);

The attributes can be accessed with the [0] and [1] subindices:

TColorAttr lo = {0x892343, 0x271274};
TColorAttr hi = '\x93';
TAttrPair attrs = {lo, hi};
assert(lo == attrs[0]);
assert(hi == attrs[1]);

Changing the appearance of a TView

Views are commonly drawn by means of a TDrawBuffer. Most TDrawBuffer member functions take color attributes by parameter. For example:

ushort TDrawBuffer::moveStr(ushort indent, TStringView str, TColorAttr attr);
ushort TDrawBuffer::moveCStr(ushort indent, TStringView str, TAttrPair attrs);
void TDrawBuffer::putAttribute(ushort indent, TColorAttr attr);

However, the views provided with Turbo Vision usually store their color information in palettes. A view's palette can be queried with the following member functions:

TColorAttr TView::mapColor(uchar index);
TAttrPair TView::getColor(ushort indices);
  • mapColor looks up a single color attribute in the view's palette, given an index into the palette. Remember that the palette indices for each view class can be found in the Turbo Vision headers. For example, <tvision/views.h> says the following about TScrollBar:

    /* ---------------------------------------------------------------------- */
    /*      class TScrollBar                                                  */
    /*                                                                        */
    /*      Palette layout                                                    */
    /*        1 = Page areas                                                  */
    /*        2 = Arrows                                                      */
    /*        3 = Indicator                                                   */
    /* ---------------------------------------------------------------------- */
  • getColor is a helper function that allows querying two cell attributes at once. Each byte in the indices parameter contains an index into the palette. The TAttrPair result contains the two cell attributes.

    For example, the following can be found in the draw method of TMenuBar:

    TAttrPair cNormal = getColor(0x0301);
    TAttrPair cSelect = getColor(0x0604);

    Which would be equivalent to this:

    TAttrPair cNormal = {mapColor(1), mapColor(3)};
    TAttrPair cSelect = {mapColor(4), mapColor(6)};

As an API extension, the mapColor method has been made virtual. This makes it possible to override Turbo Vision's hierarchical palette system with a custom solution without having to rewrite the draw() method.

So, in general, there are three ways to use extended colors in views:

  1. By providing extended color attributes directly to TDrawBuffer methods, if the palette system is not being used. For example:

    // The 'TMyView' class inherits from 'TView' and overrides 'TView::draw'.
    void TMyView::draw()
    {
        TDrawBuffer b;
        TColorAttr color {0x1F1C1B, 0xFAFAFA, slBold};
        b.moveStr(0, "This is bold black text over a white background", color);
        /* ... */
    }
  2. By modifying the palettes. There are two ways to do this:

    1. By modifying the application palette after it has been built. Note that the palette elements are TColorAttr. For example:
    void updateAppPalette()
    {
        TPalette &pal = TProgram::application->getPalete();
        pal[1] = {0x762892, 0x828712};              // TBackground.
        pal[2] = {0x874832, 0x249838, slBold};      // TMenuView normal text.
        pal[3] = {{}, {}, slItalic | slUnderline};  // TMenuView disabled text.
        /* ... */
    }
    1. By using extended color attributes in the application palette definition:
    static const TColorAttr cpMyApp[] =
    {
        {0x762892, 0x828712},               // TBackground.
        {0x874832, 0x249838, slBold},       // TMenuView normal text.
        {{}, {}, slItalic | slUnderline},   // TMenuView disabled text.
        /* ... */
    };
    
    // The 'TMyApp' class inherits from 'TApplication' and overrides 'TView::getPalette'.
    TPalette &TMyApp::getPalette() const
    {
        static TPalette palette(cpMyApp);
        return palette;
    }
  3. By returning extended color attributes from an overriden mapColor method:

// The 'TMyScrollBar' class inherits from 'TScrollBar' and overrides 'TView::mapColor'.
TColorAttr TMyScrollBar::mapColor(uchar index) noexcept
{
    // In this example the values are hardcoded,
    // but they could be stored elsewhere if desired.
    switch (index)
    {
        case 1:     return {0x492983, 0x826124}; // Page areas.
        case 2:     return {0x438939, 0x091297}; // Arrows.
        case 3:     return {0x123783, 0x329812}; // Indicator.
        default:    return errorAttr;
    }
}

Display capabilities

TScreen::screenMode exposes some information about the display's color support:

  • If (TScreen::screenMode & 0xFF) == TDisplay::smMono, the display is monocolor (only relevant in DOS).
  • If (TScreen::screenMode & 0xFF) == TDisplay::smBW80, the display is grayscale (only relevant in DOS).
  • If (TScreen::screenMode & 0xFF) == TDisplay::smCO80, the display supports at least 16 colors.
    • If TScreen::screenMode & TDisplay::smColor256, the display supports at least 256 colors.
    • If TScreen::screenMode & TDisplay::smColorHigh, the display supports even more colors (e.g. 24-bit color). TDisplay::smColor256 is also set in this case.

Backward-compatibility

The types defined previously represent concepts that are also important when developing for Borland C++:

Concept Layout in Borland C++ Layout in modern platforms
Color Attribute uchar. A BIOS color attribute. struct TColorAttr.
Color A 4-bit number. struct TColorDesired.
Attribute Pair ushort. An attribute in each byte. struct TAttrPair.

One of this project's key principles is that the API should be used in the same way both in Borland C++ and modern platforms, that is, without the need for #ifdefs. Another principle is that legacy code should compile out-of-the-box, and adapting it to the new features should increase complexity as little as possible.

Backward-compatibility is accomplished in the following way:

  • In Borland C++, TColorAttr and TAttrPair are typedef'd to uchar and ushort, respectively.

  • In modern platforms, TColorAttr and TAttrPair can be used in place of uchar and ushort, respectively. That is, the assertions in the following code won't fail:

    // Any value which fits into a 'uchar' can be
    // losslessly passed through TColorAttr.
    uchar c = 0;
    do {
        assert(uchar(TColorAttr {c}) == c);
    } while (c++ < UCHAR_MAX);
    
    // Any value which fits into a 'ushort' can be
    // losslessly passed through TAttrPair.
    ushort s = 0;
    do {
        assert(ushort(TAttrPair {s}) == s);
    } while (s++ < USHRT_MAX);

    A TColorAttr initialized with uchar represents a BIOS color attribute. When converting back to uchar, the following happens:

    • If fg and bg are BIOS colors, and style is cleared, the resulting uchar represents the same BIOS color attribute contained in the TColorAttr (as in the code above).
    • Otherwise, the conversion results in a color attribute that stands out, i.e. white on magenta, meaning that the programmer should consider replacing uchar/ushort with TColorAttr/TAttrPair if they intend to support the extended color attributes.

    The same goes for TAttrPair and ushort, considering that it is composed of two TColorAttr.

A use case of backward-compatibility within Turbo Vision itself is the TPalette class, core of the palette system. In its original design, it used a single data type (uchar) to represent different things: array length, palette indices or color attributes.

The new design simply replaces uchar with TColorAttr. This means there are no changes in the way TPalette is used, yet TPalette is now able to store extended color attributes.

TColorDialog hasn't been remodeled yet, and thus it can't be used to pick extended color attributes at runtime.

Example: adding extended color support to legacy code

The following pattern of code is common across draw methods of views:

void TMyView::draw()
{
    ushort cFrame, cTitle;
    if (state & sfDragging)
    {
        cFrame = 0x0505;
        cTitle = 0x0005;
    }
    else
    {
        cFrame = 0x0503;
        cTitle = 0x0004;
    }
    cFrame = getColor(cFrame);
    cTitle = getColor(cTitle);
    /* ... */
}

In this case, ushort is used both as a pair of palette indices and as a pair of color attributes. getColor now returns a TAttrPair, so even though this compiles out-of-the-box, extended attributes will be lost in the implicit conversion to ushort.

The code above still works just like it did originally. It's only non-BIOS color attributes that don't produce the expected result. Because of the compatibility between TAttrPair and ushort, the following is enough to enable support for extended color attributes:

-    ushort cFrame, cTitle;
+    TAttrPair cFrame, cTitle;

Nothing prevents you from using different variables for palette indices and color attributes, which is what should actually be done. The point of backward-compatibility is the ability to support new features without changing the program's logic, that is, minimizing the risk of increasing code complexity or introducing bugs.


Comments
  • help: compiling a project

    help: compiling a project

    Hello everybody

    I try to compile old source code I found somewhere. Some info I know already about it

    • original source code

    https://gitlab.com/twilight-cd.com/sourcecode-menu-twilight-9

    • From the readme: It's written in Borland Turbo C, assembler and some pascal. It contains several artifacts of earlier releases and several helper tools such as THF, TLDIAGS, TLMAKE, TLSETUP and HELPAPP.

    • It makes the following ms-dos program: https://gitlab.com/twilight-cd.com/menu-binaries/-/tree/master/TWILIGHT009/MENU

    Run menu.exe in DOSBox (https://www.dosbox.com/) to see this:

    afbeelding

    The screenshot is the program that I want to compile by using Tvision (if possible).

    Is there anybody who can look at it and tell me if there is a way to compile it by using Tvision? I'm a complete beginner... So my question: is somebody interested to look at the code and try to compile it using Visual Studio and Tvision in order to get a modern code and executable that's doing the same as the original code? If the user interface is displayed, that would be already great. I don't know if the old code even uses Tvision (i'm a beginner)

    Thanks for the help! Lisa

    opened by ghost 39
  • use modern target based commands on CMakeLists.txt

    use modern target based commands on CMakeLists.txt

    almost rewrite everything, and because target based commands are location independent, so I just used default location to put all generate lib and binaries. when run cmake --install . it will install correct place.

    opened by asanoic 27
  • The build of demo applications are broken on FC32

    The build of demo applications are broken on FC32

    There are some problems in linking stage:

    [ 95%] Building CXX object CMakeFiles/tvdemo.dir/examples/tvdemo/puzzle.cpp.o
    In file included from /usr/include/c++/10/backward/strstream:50,
                     from /home/pavel/src/tvision/include/override/strstrea.h:4,
                     from /home/pavel/src/tvision/examples/tvdemo/puzzle.cpp:29:
    /usr/include/c++/10/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp]
       32 | #warning \
          |  ^~~~~~~
    [ 95%] Building CXX object CMakeFiles/tvdemo.dir/examples/tvdemo/tvdemo1.cpp.o
    [ 96%] Building CXX object CMakeFiles/tvdemo.dir/examples/tvdemo/tvdemo2.cpp.o
    [ 96%] Building CXX object CMakeFiles/tvdemo.dir/examples/tvdemo/tvdemo3.cpp.o
    [ 97%] Linking CXX executable tvdemo
    /usr/bin/ld: /tmp/tvdemo.ecc3yZ.ltrans0.ltrans.o: in function `TWindow::streamableName() const':
    :(.text+0x3): undefined reference to `TWindow::name'
    /usr/bin/ld: /tmp/tvdemo.ecc3yZ.ltrans0.ltrans.o: in function `non-virtual thunk to TWindow::streamableName() const':
    :(.text+0x13): undefined reference to `TWindow::name'
    /usr/bin/ld: /tmp/tvdemo.ecc3yZ.ltrans0.ltrans.o: in function `TDialog::streamableName() const':
    :(.text+0x83): undefined reference to `TDialog::name'
    /usr/bin/ld: /tmp/tvdemo.ecc3yZ.ltrans0.ltrans.o: in function `non-virtual thunk to TDialog::streamableName() const':
    :(.text+0x93): undefined reference to `TDialog::name'
    /usr/bin/ld: /tmp/tvdemo.ecc3yZ.ltrans0.ltrans.o: in function `TCollection::streamableName() const':
    :(.text+0x123): undefined reference to `TCollection::name'
    /usr/bin/ld: /tmp/tvdemo.ecc3yZ.ltrans0.ltrans.o: in function `TView::streamableName() const':
    :(.text+0x183): undefined reference to `TView::name'
    /usr/bin/ld: /tmp/tvdemo.ecc3yZ.ltrans0.ltrans.o: in function `non-virtual thunk to TView::streamableName() const':
    :(.text+0x193): undefined reference to `TView::name'
    /usr/bin/ld: /tmp/tvdemo.ecc3yZ.ltrans0.ltrans.o: in function `TStaticText::streamableName() const':
    :(.text+0x1a3): undefined reference to `TStaticText::name'
    /usr/bin/ld: /tmp/tvdemo.ecc3yZ.ltrans0.ltrans.o: in function `non-virtual thunk to TStaticText::streamableName() const':
    :(.text+0x1b3): undefined reference to `TStaticText::name'
    /usr/bin/ld: /tmp/tvdemo.ecc3yZ.ltrans0.ltrans.o: in function `TGroup::streamableName() const':
    :(.text+0x203): undefined reference to `TGroup::name'
    /usr/bin/ld: /tmp/tvdemo.ecc3yZ.ltrans0.ltrans.o: in function `non-virtual thunk to TGroup::streamableName() const':
    :(.text+0x213): undefined reference to `TGroup::name'
    /usr/bin/ld: /tmp/tvdemo.ecc3yZ.ltrans0.ltrans.o: in function `TAsciiChart::read(ipstream&)':
    :(.text+0x2b6): undefined reference to `TWindow::read(ipstream&)'
    /usr/bin/ld: /tmp/tvdemo.ecc3yZ.ltrans0.ltrans.o: in function `non-virtual thunk to TAsciiChart::read(ipstream&)':
    :(.text+0x2ca): undefined reference to `TWindow::read(ipstream&)'
    /usr/bin/ld: /tmp/tvdemo.ecc3yZ.ltrans0.ltrans.o: in function `TCalendarWindow::read(ipstream&)':
    :(.text+0x2e6): undefined reference to `TWindow::read(ipstream&)'
    /usr/bin/ld: /tmp/tvdemo.ecc3yZ.ltrans0.ltrans.o: in function `non-virtual thunk to TCalendarWindow::read(ipstream&)':
    :(.text+0x2fa): undefined reference to `TWindow::read(ipstream&)'
    /usr/bin/ld: /tmp/tvdemo.ecc3yZ.ltrans0.ltrans.o: in function `TPuzzleWindow::read(ipstream&)':
    :(.text+0x316): undefined reference to `TWindow::read(ipstream&)'
    /usr/bin/ld: /tmp/tvdemo.ecc3yZ.ltrans0.ltrans.o::(.text+0x32a): more undefined references to `TWindow::read(ipstream&)' follow
    /usr/bin/ld: /tmp/tvdemo.ecc3yZ.ltrans0.ltrans.o: in function `TTable::read(ipstream&)':
    :(.text+0x366): undefined reference to `TView::read(ipstream&)'
    /usr/bin/ld: /tmp/tvdemo.ecc3yZ.ltrans0.ltrans.o: in function `non-virtual thunk to TTable::read(ipstream&)':
    :(.text+0x37a): undefined reference to `TView::read(ipstream&)'
    /usr/bin/ld: /tmp/tvdemo.ecc3yZ.ltrans0.ltrans.o: in function `TTable::build()':
    :(.text+0x3aa): undefined reference to `TView::TView(StreamableInit)'
    /usr/bin/ld: /tmp/tvdemo.ecc3yZ.ltrans0.ltrans.o: in function `TReport::build()':
    
    opened by okbob 27
  • Cannot compile under BCPP 5.02 with TASM 5.0 (Win 98 SE)

    Cannot compile under BCPP 5.02 with TASM 5.0 (Win 98 SE)

    Trying to compile geninc gives several errors related to missing files (which are in fact missing from source) and geninc32 simply states "Invalid target->/Ts" I'm banging my head against the wall here as my co-worker on this project, Sduensin, tells me he's managed to compile it fine in his build environment under windows 3.1 I've followed the instructions in build.txt until now, can anyone tell me what I'm doing wrong here?

    opened by Maxwelldoug 18
  • Help system fixes

    Help system fixes

    • tvhc: Increase the buffer size for the help file path. It was crashing on longer but still valid paths.
    • tvhc: Increase the buffer size for topics. Converting to dynamic memory allocation would have been nice but I didn't want to delve deeply into the code. tmbasic needed this in order to stick the various third-party licenses into help topics.
    • THelpFile: Allow in-memory streams instead of requiring the help file to come from a file. tmbasic uses this to link the help file directly into the executable instead of shipping a separate file.
    opened by electroly 14
  • A few thoughts about the library...

    A few thoughts about the library...

    Greetings again! Thank you for the work done to adapt the library. I will allow myself a few remarks, which I ask you not to take as a reproach.

    1. I think that maintaining compatibility with compilers that have died is unnecessary. With all due respect to Borland, their compiler is a corpse. Therefore, I think the compatibility code with it can be removed, leaving only a link to the copyright.
    2. TurboVision itself, with all its advantages, has a lot of disadvantages, such as a very poor palette of control elements, the absence of some obvious functions (for example, window centering), etc. I think it's worth creatively expanding the functionality of the library with existing code.
    3. When compiling to MSVC, a warning occurs, which may lead to errors in the future. I am sending a message:

    ...>cmake . -B ./build -A x64 -- Building for: Visual Studio 16 2019 -- Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.18363. -- The C compiler identification is MSVC 19.26.28805.0 -- The CXX compiler identification is MSVC 19.26.28805.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/MSVC/14.26.28801/bin/Hostx64/x64/cl.exe - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/MSVC/14.26.28801/bin/Hostx64/x64/cl.exe - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Performing Test SUPPORTS_COUNTER_MACRO -- Performing Test SUPPORTS_COUNTER_MACRO - Success -- Install path: C:/Program Files/tvision -- Build Examples: ON -- Link w/static RTL: OFF -- Configuring done -- Generating done -- Build files have been written to: D:/Design/tv_prj/tv/build

    ...>cmake --build ./build --config Release Microsoft (R) Build Engine версии 16.6.0+5ff7b0c9e для .NET Framework (C) Корпорация Майкрософт (Microsoft Corporation). Все права защищены.

    Checking Build System Building Custom Rule D:/Design/tv_prj/tv/source/CMakeLists.txt cmake_pch.cxx .... help.cpp helpbase.cpp histlist.cpp D:\Design\tv_prj\tv\source\tvision\histlist.cpp(189,39): warning C4291: void *HistRec::operator new(size_t,HistRec *) noexcept: the corresponding delete operator was not found; if an exception occurs during initialization, the memory will not be freed [D:\Design\tv_prj\tv\build\source\tvision.vcxproj] D:\Design\tv_prj\tv\source\tvision\histlist.cpp(55): message : см. объявление "HistRec::operator new" [D:\Design\tv_prj\tv\build\source\tvision.vcxproj] mapcolor.cpp menu.cpp .... I'm sorry if my English is not very clear. My native language is Russian, I read normally, but I don't really speak and write))) - I use an automatic translator.

    opened by IngvarRiga 13
  • Konsole: overly wide Unicode characters mess up intended layouts

    Konsole: overly wide Unicode characters mess up intended layouts

    I'm trying to find a solution to this rendering issue in Konsole.

    konsole

    This is a TEditor example showing how the line formatting gets shifted around due to those ❺ symbols. Also, the title of this window is clipped (there's no close parenthesis). These symbols are rendered slightly wider than a single cell, leading to the rest of the printed line being shifted out of alignment. Other terminals show this symbol in a single terminal cell, but Konsole is painting the line with variable character widths with chaotic effects.

    image

    Here's my evolution of the ASCII table from tvdemo. On the right you can see some extra-wide characters that mess up the whole line. ⑪-⑯ and ❽-❿ are clipped. When you click on one, it selects the "wrong" character due to the rendering discrepancy.

    Open to suggestions on this. Konsole is the only terminal I've tested so far with this issue.

    opened by electroly 11
  • Query terminal color capabilities

    Query terminal color capabilities

    In my RGB color picker, I find it would be helpful to know what the terminal supports. There are two related situations I'm concerned about:

    1. The user's terminal only supports 16 colors, and I'm showing a 256 color palette. Swaths of colors in the palette look the same to the user, but they really have different RGB values. If the user clicks a color from the palette, they don't know what color they've actually selected and if their work is later displayed on a 256 color terminal, the colors won't be what they had intended. It seems better to show a 16 color palette to users who can't see 256 colors.

    2. The user has TERM=vt100. In this case I'd hide the palette entirely and make the user enter R/G/B numbers.

    image image

    opened by electroly 10
  • TDesktop with fixed Window

    TDesktop with fixed Window

    Main Desktop Customize Goal

    I was wondering if somebody manage to create a Window/Dialog to fill all the desktop and block the CLOSE/RESIZE actions.

    I'm considering use the TV to create a terminal menu app, to show a custom menu to operator.

    Only a few fixed menus will be displayed and the main actions would be show in a window, occuipied all the desktop area.

    As the actions will be a few, I'm thinking about use buttons for the action and a static text for long description.

    I going through TV source code, but nothing by now!

    So, the premisses are:

    • Fill the free desktop area;
    • Disable the close dialog option;
    • Disable the resize option;
    • May be, it could hide the borders;
    • Even, detect the button focus event, to give user hints;
    opened by WillianBR 8
  • Very slow under Windows Console

    Very slow under Windows Console

    I use the pre-built Turbo editor (TVedit.exe) to check if Turbo Vision is suitable for my need. Every time the cursor is moved (point-and-click with mouse, by Backspace, Left Arrow, Right Arrow, Ctrl+one of those, or simply by typing an alphanum key) the cursor disappears for almost 1 second, which is terribly slow.

    opened by zingchen 7
  • Mouse wheel not working on ubuntu 18.04

    Mouse wheel not working on ubuntu 18.04

    Hello ! Compiling on my machine with lubuntu 18.04 the mouse click works but not the mouse wheel, see the cmake output bellow:

    cmake .
    -- The C compiler identification is GNU 9.3.0
    -- The CXX compiler identification is GNU 9.3.0
    -- Check for working C compiler: /usr/bin/cc
    -- Check for working C compiler: /usr/bin/cc - works
    -- Detecting C compiler ABI info
    -- Detecting C compiler ABI info - done
    -- Detecting C compile features
    -- Detecting C compile features - done
    -- Check for working CXX compiler: /usr/bin/c++
    -- Check for working CXX compiler: /usr/bin/c++ - works
    -- Detecting CXX compiler ABI info
    -- Detecting CXX compiler ABI info - done
    -- Detecting CXX compile features
    -- Detecting CXX compile features - done
    -- Library output: xxx/tvision/lib
    -- Binary output : xxx/tvision/bin
    -- Install path  : /usr/local
    -- Build Examples: ON
    -- Build w/GPM   : ON
    -- gpm library requested
    -- gpm library found
    -- Configuring done
    -- Generating done
    -- Build files have been written to: xxx/tvision
    

    And here is tvedit link parameters:

    /usr/bin/c++     CMakeFiles/tvedit.dir/examples/tvedit/tvedit1.cpp.o CMakeFiles/tvedit.dir/examples/tvedit/tvedit2.cpp.o CMakeFiles/tvedit.dir/examples/tvedit/tvedit3.cpp.o  -o bin/tvedit  lib/libtvision.a -lncursesw /usr/lib/x86_64-linux-gnu/libgpm.so
    

    Cheers !

    opened by mingodad 7
  • 2 bugs....

    2 bugs....

    Good day! Found 2 errors:

    1. If there is an incomplete submenu in the program menu that does not contain items, then when you double-click on Esc and close the active dialog (the second press after closing), the program crashes in the function that searches for short menu keys. It turns out that it requests a list of sub-items that is null_ptr and tries to scan it

    2. If in the file saving dialog box you immediately specify the file name without jokers (*), then double-click on the link to the top directory .. (and possibly the lower one, I didn't check it) leads to automatic confirmation of saving and as a result saving the file in the top-level directory, although the dialog should just go to that directory.

    opened by IngvarRiga 11
  • [Feacture Request] Customize the look and feel by widget

    [Feacture Request] Customize the look and feel by widget

    Is possible make api to do something like "skins"?. I mean to change the look and feel by widget not only the color.

    Maybe a setter where you can set to the widget witch char use to draw the border, the shadow. In the window widget can be nice you can set the position of the buttons. For example move the close button from the left to the right. Aside right from maximize button and change the icon to X.

    O even better define custom button to attach to upper left, upper right, lower left, lower right to the window widget.

    You can change from "Turbo Vision Style" to "Ubuntu Style":

    image

    O maybe to "Ubuntu Server Setup Style":

    image

    Thanks!!!.

    opened by sirlordt 5
  • Layout/resizing console window in Windows - will become broken

    Layout/resizing console window in Windows - will become broken

    First of all thank you for this project. It was always something what I wanted (to have TVISION enabled in PC again) and you actually overachieved this with Unicode support and Linux portability. Great job!

    One thing which I’m seeing is that if you run app in Windows console (E.g. tvdemo.exe with some window open in app) and you do resize of console with Alt+Enter or resizing with dragging right corner of Windows console, the layout will become broken. Not sure if this can be fixed somehow or if this is known limitation but would be nice to have this working properly.

    opened by jbinko 10
  • Terminal widget?

    Terminal widget?

    Hello @magiblot ! I just became aware of this active Turbo Vision project recently over on the notcurses thread.

    Besides "hello!" :-) I wanted to mention something I had done with SET's rhtvision a long time ago: qterminal . This was a port of Qodem's VT100/102/220/Linux terminal to Turbo Vision (screenshot1 screenshot2 screenshot3):

    • I discovered that rhtvision had the wrong mappings for Unicode codepoints 0x2264 and 0x2265 (≤ and ≥); they were swapped. Just wanted to mention that, I don't know if you had started from there or are added your own Unicode awareness to a fresh branch off the Borland TV sources.
    • If you don't yet have a terminal widget and are interested, I would be happy to get it running again and provide a bug-fixed public domain licensed version of it for you. Just let me know.
    • If you do have your own terminal widget, how could I test it out?

    Very nice to see your project here! 💗

    Also I love your Turbo editor screenshots. Very cool!

    opened by ghost 2
  • Add recommendation for Windows Terminal to readme?

    Add recommendation for Windows Terminal to readme?

    I'm sure you saw this as I see you commented on the issue, but https://github.com/microsoft/terminal/issues/376 was finally fixed. It's shipping right now in "Windows Terminal Preview". I tested it and the mouse now works with TMBASIC. At long last, we have 256 color support, full Unicode with fallback, and mouse support on Windows. I'm going to make the explicit recommendation for TMBASIC that people use Windows Terminal.

    opened by electroly 11
  • Can't compile example in Visual Studio 2019

    Can't compile example in Visual Studio 2019

    Hello there,

    I have managed to build the project using cmake and MSVC, I could open the examples and even make small changes. However, when I create a new project, copy the hello.cpp to my project, set the include path and the lib path it fails to compile giving me these errors:

    1>Tvision3.cpp 1>C:\Users\%username%\source\tvision-master\include\tvision\tv.h(35,9): warning C4068: unknown pragma 'option' 1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29910\include\limits(44,67): error C2864: 'std::_Num_base::has_denorm': a static data member with an in-class initializer must have non-volatile const integral type or be specified as 'inline' 1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29910\include\limits(44,67): message : type is 'std::float_denorm_style' 1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29910\include\limits(45,59): error C2864: etc. etc.

    I would really like to use this library as I love CLI interfaces, I am currently working on a project for my university to create a unified interface for all our vacuum gauges. So far I have managed to do it well on Labview but I would like to build everything using Turbo Vision. Not only would it mean a great relief or resources compared to the bloat that is Labview, but CLI may also be used via SSL.

    Any advice on how to overcome this issue would be greatly appreciated.

    opened by purpledan 4
Releases(r586)
  • r586(Sep 2, 2020)

    NOTE: The downloads in this page are outdated. Please see the Releases and downloads section of the README.

    Windows/DOS binary release

    Below are 64-bit and 32-bit binaries built with MSVC, and DPMI32 binaries built with Borland C++.

    Changelog

    Turbo Vision

    • The 'Cancel' button in messageBox can now be toggled with the C key (https://github.com/magiblot/tvision/commit/22e366c0f253e690fa1620e4a74230946c545035).
    • Windows can now be dragged from their empty area with the middle mouse button (https://github.com/magiblot/tvision/commit/73762a28905ee5f76b147ca4e31c535a7688b81a).
    • Text selection with arrow keys in TInputLine now behaves as expected (https://github.com/magiblot/tvision/commit/25183ab762c40e79ddb17fc3ca04cc96e379d5c6).
    • The size of messageBox is now calculated according to character width and not byte count (https://github.com/magiblot/tvision/commit/dfe2c019dd3d40dfb0b18a470c06640e719ea398).
    • Fixed a bug in the 'resize windows from bottom left corner' feature (https://github.com/magiblot/tvision/commit/21377a5240e25886932f5c5c12fe2f09826cfb38).
    • Fixed a bug in the string search algorithm in TEditor (https://github.com/magiblot/tvision/commit/b5ee0463b8d9ed647ec5e07a63777ce21474ed7c).
    • Fixed buffer overruns in TChDirDialog, TFileDialog (https://github.com/magiblot/tvision/commit/552af8dfedbf3985d9e489318e829052078740c5), fnmerge and fexpand (https://github.com/magiblot/tvision/commit/67895c52ccf57fa9042e73f9a7be2ecd110f8d2a).

    MSVC builds only

    This is the first release supporting MSVC; this brings the formerly Linux-exclusive features to Windows.

    • Most views do now display unicode text properly.
    • TInputLine and TEditor do now handle unicode input.
    • TEditor: press Ctrl+P to toggle between unicode and single-byte mode (https://github.com/magiblot/tvision/commit/702114dc03a13ebce2b52504eb122c97f9892de9).
    • Recovery on console crash.

    tvedit

    • Context menu on right-click.

    tvdemo

    • TTextDevice is no longer buffered on Borland C++, which fixes the event viewer (https://github.com/magiblot/tvision/commit/597c801eeb19a76cc4e6df58b63339520bedfd55).
    • Line length in the file viewer is no longer limited to a fixed amount (https://github.com/magiblot/tvision/commit/068bbf7a0a13482bda91f9f3411ec614f9a1e6ff).
    • The file viewer now displays null characters as spaces instead of truncating the line (https://github.com/magiblot/tvision/commit/1157d1c0cb14314d541f912314c061c919edf91f).
    • Fixed another buffer overrun (https://github.com/magiblot/tvision/commit/7804b7c6e0ab0d9d738ddadc9f6dd73ac00ffa93).
    Source code(tar.gz)
    Source code(zip)
    tvdemo-dos32.zip(114.49 KB)
    tvdemo-x64.zip(367.35 KB)
    tvdemo-x86.zip(316.97 KB)
    tvedit-dos32.zip(92.41 KB)
    tvedit-x64.zip(339.42 KB)
    tvedit-x86.zip(289.98 KB)
  • r415(Jul 26, 2020)

    Windows/DOS binary release

    Below are the DOS and DPMI32 binaries for the tvdemo and tvedit applications. DPMI32 binaries still work on 64-bit Windows 10.

    Changelog

    Turbo Vision

    New features

    • The default size of TFileDialog has been increased (5a29fef26d0dba925156c939d945e4b2d42dfe8f) and some elements in TInfoPane are now left-aligned (c866692c9f8b61c0ac61d0ae78784e1ff1b29cff).
    • Ability to resize windows from their bottom left corner (4b6650c0ed25feca6672bf9bcfd447e157a3bd77).

    Performance improvements

    • Use alloca instead of heap allocations in certain cases (dab41bd364c2ca349cba1236338d6a41c172c3a9).

    Memory safety

    • TFileEditor: fix use-after-free on buffer resize (3327879414034052906e775375ff3ab24a96a365, 5a378c4228dc8c358ed9a6781ec9b0723deed279).
    • Fix an out-of-bounds access in TParagraph::text (41a6f424ca35254aeff7e5d046af6087402bab5c).
    • Fix several out-of-bounds acesses in TDrawBuffer (da117497123527c95d57cdd55dcc295adf056f6a, c37b8f7d757793cb75df7d06dcf957c4d5b880d2).
    • Fix views being resized beyond limits in extreme resolutions (d4a114cd7e67675487fa39d454a36fde4b095a2c, 8b7bac21b4980e802f87bbfe3fa74ad00fbd3403).
    • Fix read beyond null terminator in TListViewer (4acda91ee9834d87136df4e185acbefe7dd62661).
    Source code(tar.gz)
    Source code(zip)
    tvdemo-dos.zip(132.03 KB)
    tvdemo-dos32.zip(113.65 KB)
    tvedit-dos.zip(102.58 KB)
    tvedit-dos32.zip(90.63 KB)
  • r346(May 10, 2020)

    Windows/DOS binary release

    Below are the DOS and DPMI32 binaries for the tvdemo and tvedit applications.

    Changelog

    Turbo Vision

    • Applications fit the console window size instead of the buffer size.
    • The console buffer is restored when exiting or suspending Turbo Vision.
    • kbCtrlC, Shift+Arrow, kbShiftTab and AltGr key combinations work properly on Windows.
    • No busy polling for events on Windows.
    • Middle mouse button support (mbMiddleButton), even on DOS.
    • Horizontal and vertical mouse wheel support (evMouseWheel), even on DOS.
    • Arbitrary screen size support (with up to 65535 rows or columns).
    • Graceful handling of screen resize events.
    • Support for kbCtrlUp and kbCtrlDown key codes. They can be used to move windows faster with the keyboard (as kbCtrlLeft and kbCtrlRight already did).
    • Improved usability of menus: they can be closed by clicking twice on them, even in submenus.
    • Improved usability of scrollbars: dragging them also scrolls the page. Clicking on an empty area of the scrollbar moves the thumb right under the cursor. They are responsive by default to mouse wheel events.
    • Views don't lose their sizes when extremely resized.

    tvdemo

    • Support for LF line ending in File Viewer.
    • Event Viewer applet useful for event debugging (available in the menu or with kbAlt0).
    • Option to change the background pattern in Options > Background....

    tvedit

    • Support for files bigger than 64 KiB on 32-bit builds.
    • Support for LF line ending. New files use CRLF but existing LF files are kept that way.
    • Drag scroll with middle mouse button in the text editor.
    • Delete whole word with kbCtrlBack and kbCtrlDel.
    • Select all text with kbCtrlA.
    • Smart Home key (toggles between beggining of line and beggining of indentation).
    • Create new document with kbCtrlN, close window with kbCtrlW.
    Source code(tar.gz)
    Source code(zip)
    tvdemo-dos.zip(131.15 KB)
    tvdemo-dos32.zip(112.17 KB)
    tvedit-dos.zip(101.77 KB)
    tvedit-dos32.zip(89.42 KB)
Owner
null
Repository of some great classical and Advanced cryptosystems

CryptoSystems ?? Repository of some great classical and Advanced cryptosystems Every C file here contains one of the most popular Cryptosystem in hist

Abhilash Datta 3 Nov 8, 2022
Fix some extrinsic parameter importing problems. 6-axis IMU works now. Lidar without ring works now.

LVI-SAM-MODIFIED This repository is a modified version of LVI-SAM. Modification Add function to get extrinsic parameters.The original code assumes the

null 88 Dec 9, 2022
Neo - Simulates the digital rain from "The Matrix" (cmatrix clone with 32-bit color and Unicode support)

neo WARNING: neo may cause discomfort and seizures in people with photosensitive epilepsy. User discretion is advised. neo recreates the digital rain

Stew Reive 470 Dec 28, 2022
Header-only library providing unicode aware string support for C++

CsString Introduction CsString is a standalone library which provides unicode aware string support. The CsBasicString class is a templated class which

CopperSpice 91 Dec 8, 2022
A cross-platform,lightweight,scalable game server framework written in C++, and support Lua Script

Current building status Moon Moon is a lightweight online game server framework implement with multithread and multi-luaVM. One thread may have 1-N lu

Bruce 467 Dec 29, 2022
A cross-platform,lightweight,scalable game server framework written in C++, and support Lua Script

hive Distributed game server framework based on CPP 17 && LUA 5.4 框架(hive)+逻辑(server) 支持跨平台开发(windows,linux,mac) oop模式的lua开发,支持lua热更新 protobuf协议 pbc修改

toney 82 Jan 1, 2023
Cross-platform tool to extract wavetables and draw envelopes from sample files, exporting the wavetable and generating the appropriate SFZ text to use in a suitable player.

wextract Cross-platform tool to extract wavetables and draw envelopes from sample files, exporting the wavetable and generating the appropriate SFZ te

Paul Ferrand 9 Jan 5, 2022
Cross-OS library for implementing USB device-mode interfaces

libusbd Cross-OS library for implementing USB device-mode interfaces. WIP. I'm currently working out most of the API details with the programs in exam

Max Thomas 46 Dec 13, 2022
libu8ident - Follow unicode security guidelines for identifiers

libu8ident - Follow unicode security guidelines for identifiers without adding the full Unicode database. This library does the unicode identifier sec

Reini Urban 9 Dec 23, 2022
Simdutf - Unicode routines (UTF8, UTF16): billions of characters per second.

simdutf: Unicode validation and transcoding at billions of characters per second Most modern software relies on the Unicode standard. In memory, Unico

simdutf: Unicode at gigabytes per second 535 Jan 3, 2023
Typewriter Effect with Rich Text + *Correct* Text Wrapping

Typewriter Effect with Rich Text + Correct Text Wrapping I've spent way too long getting this right. This is meant as a base class for a UMG dialogue

Sam Bloomberg 30 Nov 29, 2022
Cross-platform, Serial Port library written in C++

Serial Communication Library (Linux and OS X) (Windows) This is a cross-platform library for interfacing with rs-232 serial like ports written in C++.

William Woodall 1.7k Dec 30, 2022
KeePassXC is a cross-platform community-driven port of the Windows application “Keepass Password Safe”.

KeePassXC KeePassXC is a modern, secure, and open-source password manager that stores and manages your most sensitive information. You can run KeePass

KeePassXC 14.7k Jan 2, 2023
Project is to port original Zmodem for Unix to CP/M and provide binaries and source code for platform specific modification as needed. Based on 1986 C source code by Chuck Forsberg

Zmodem-CP-M This repository is intended to foster a RetroBrewComputers community effort to port the original Zmodem source code for Unix to CP/M so ev

null 11 Aug 31, 2022
Project is to port original Zmodem for Unix to CP/M and provide binaries and source code for platform specific modification as needed. Based on 1986 C source code by Chuck Forsberg

Zmodem4CPM This repository is intended to foster a RetroBrewComputers community effort to port the original Zmodem source code for Unix to CP/M so eve

null 11 Aug 31, 2022
A Walkie-Talkie based around the ESP32 using UDP broadcast or ESP-NOW

Overview We've made a Walkie-Talkie using the ESP32. Explanatory video Audio data is transmitted over either UDP broadcast or ESP-NOW. So the Walkie-T

atomic14 259 Dec 31, 2022
The Leap Motion cross-format, cross-platform declarative serialization library

Introduction to LeapSerial LeapSerial is a cross-format, declarative, serialization and deserialization library written and maintained by Leap Motion.

Leap Motion (Ultraleap) 15 Jan 17, 2022
Lingo - Text encoding for modern C++

Lingo Lingo is an encoding aware string library for C++11 and up. It aims to be a drop in replacement for the standard library strings by defining new

Rick de Water 29 Oct 18, 2022
A cross-platform framework for developing spatial audio algorithms and software in C/C++

git: https://github.com/leomccormack/Spatial_Audio_Framework doxygen: https://leomccormack.github.io/Spatial_Audio_Framework/ About The Spatial_Audio_

Leo McCormack 396 Dec 23, 2022