4 ms·

This is amazing. Has there been anything like this before?

by smusamashah 6y ago

GrumpyNl 6y ago
Yep, around 1990
- Stratoscope 6y ago
  1985. https://en.wikipedia.org/wiki/IBM_TopView https://en.wikipedia.org/wiki/IBM_TopView I had just started working at Gupta Technologies at the time, and for a short while we seriously considered developing for TopView instead of Windows.
  - reaperducer 6y ago
    Ashton-Tate did it with Framework in 1984. Though my memory is that it goes back a few years earlier to Valdocs on CP/M machines, but I can’t find any pictures on the intarwebs.
    - Stratoscope 6y ago
      Framework was pretty great! My partner and I were working on some similar ideas at the time, and we got together with the Framework team to compare notes and brainstorm. The thing that stuck in my mind when Robert Carr took us on a tour of their office was the printer lab. It was a full size conference room with floor-to-ceiling shelves on every wall stacked with printers. Because back in those days, if you wanted to sell a DOS application that could print anything more than plain text, you had to write your own drivers for every printer you wanted to support. Ouch! I've sometimes thought that the real innovation in Windows 1.0 was having systemwide printer drivers so every app didn't have to provide their own.
mightybyte 6y ago
Oh yeah. I'm going to date myself here, but I was just going to say this reminds me a lot of Borland Turbo C++ way back in the day. They had this thing called Turbo Vision for building text UIs. It seemed super cool back then. https://en.wikipedia.org/wiki/Turbo_Vision https://en.wikipedia.org/wiki/Turbo_Vision
- dewlinedew 6y ago
  It had been open sourced i made a project using it: https://github.com/ivans5/BitMediaCentre https://github.com/ivans5/BitMediaCentre
- Phil-bitplex 6y ago
  It was super cool!!! I had so much fun emulating it drawing single and double line text borders, with shadows. Oh ASCII chart how I miss thee.
- Minor49er 6y ago
  It definitely was super cool. The windows had types, could be resized, had titles, dropdown menus, and form controls. The editor had syntax highlighting. And most importantly (at least for me at the time), there was a language reference included with the help system which had hyperlinking, so you could click through pages about the supported syntax and various topics, gleaning a wealth of information. All on DOS!
  - makapuf 6y ago
    Hypertext integrated help has been available earlier than turbo vision even. It has been available from turbo pascal 3 at least. For a young like me who ... copied it on two disks, it was awesome what you could learn.
    - badsectoracula 6y ago
      Turbo Pascal 3 didn't have integrated help (hypertext or not), it was introduced in Turbo Pascal 4 (which itself was AFAIK in general a big rewrite of the compiler and IDE). Though the integrated help really improved with version 6 (when Turbo Vision was also introduced) since you could move a cursor freely inside the help window as if it was an editor, select and copy text, the help text was much more detailed and more organized and every function/procedure also had a small example showing its use (version 5.5 also had examples but the overall help was much more terse).
      - 6y ago
guerrilla 6y ago
There are many tiling window managers for UNIXes and similar such things. There's also Plan9 which is in a sense text based.
derefr 6y ago
Windows 1.0, while having a framebuffer-based layout engine, clearly evolved from a pure TUI, and retains elements (title bars, scroll bars, etc.) whose drawing algorithm emulates a TUI within the framebuffer, by just drawing DOS-like lines or grids of box-drawing characters. In fact, it’s only window content that is arbitrarily graphical in Windows 1.0; if you only have DOS VMM windows open, you’re essentially seeing a TUI, just with extra steps.
- Stratoscope 6y ago
  Windows 1.0 didn't actually use box-drawing characters for any of this, of course. For example, the System menu in the top left corner of each window was three horizontal lines, just like a hamburger menu of today. Scrollbar buttons did not look like any box-drawing character. The Maximize button in the top right did look like a box-drawing character, but that's really about the only resemblance I see. (I developed a DOS GUI for email, Transend PC, in the early '80s that used box-drawing characters, and soon after started writing SQLWindows for Windows 1.0, so pretty familiar with both.)
  - derefr 6y ago
    Right, I'm not saying that the GUI was rendered using the DOS box-drawing characters, i.e. the monitor's built-in codepage 437 text mode; nor were they using a monospace bitmap font of codepage 437. What I'm saying, is that I'm pretty sure that a lot of the Windows 1.0 GUI was drawn by emulating the "technique" TUIs use to draw box-drawing characters, but on a framebuffer and with a custom (monospace) bitmap font: 1. create any-and-all graphical detail you need on screen, by repurposing the "leftover" parts of the bitmap font you're using to draw control-label text to the screen, adding a set of additional, custom symbol-drawing elements, which are all 'characters' of that bitmap font, and so all stuck being the same size+shape as the label text; 2. create a graphical "monospace text" drawing primitive, that takes as input a pair of buffers representing the text itself, and its hardware-text-mode-alike per-character drawing attributes (i.e. FG + BG color); 3. implement your OS widget library almost entirely in terms of calls into that graphical "monospace text" drawing primitive, passing a static data-section buffer holding the positional+attribute data for your box-drawing character. (For example, look at the drive icons in the File Manager. Those are just clearly just "text" composed of four drawing-element characters from the bitmap font, like this: [-=-]. So the whole drive-chooser area can be drawn with a single text-draw command, passing a string like "A[-=-] C[-=-] C: \WINDOWS".) ----- You might say "but look at any screenshot of Windows 1.0 — the first thing you'll notice is that the menu-item labels in each window's menu bar are offset by a half-character-width horizontally! And modal dialogs are, in their entirety, offset by a half-character horizontally and vertically! How's that possible?" Well, the GUI "monospace text"-drawing primitive might be drawing a grid of characters to the framebuffer; but it's not drawing them to an imaginary grid on the framebuffer. It accepts an arbitrary pixel offset for where it should start to draw the block of monospace text. So, with that in mind, the algorithm for drawing the menu bar very likely has two passes: 1. render some box-drawing characters representing the "background" of the menu (i.e. yellow with a black border) 2. render a layer of regular non-box-drawing characters on top, offset by +4px on the X axis, in "black on transparent", representing the menu-item labels. It's pretty clear (to me, at least) how a drawing algorithm like this could be a natural evolution and outgrowth of a TUI: first, replace the TUI's backing text buffer with a framebuffer, and the character-plotting calls with draw calls to a "draw monospace text character at emulated-grid position on framebuffer" primitive; then refactoring the draw calls to use a window-local coordinate basis; and only then adding the ability to draw anything other than monospace characters—but gradually, starting only with defined grid-snapped "rich graphical content" regions within windows (sort of like how Windows today has "Direct3D drawing surface" regions); and then going back and gradually enhancing the GUI widgets with little flourishes like draw offsets. Within the Windows 1.0 codebase, I would bet money that—at least in some previous revision in early development—there was probably a #define flag for whether the "framebuffer driver" was enabled; and that all these windowing-system and common-controls drawing algorithms were written in a "hybrid" way where, instead of one TUI-based and an entirely-distinct framebuffer-based implementation, the framebuffer-based implementation is just #ifdef'ed ornamentation on top of the base TUI implementation.
DenisM 6y ago
Norton Commander / FAR commander. The latter is still in use and actively developed: https://www.farmanager.com/screenshots.php?l=en https://www.farmanager.com/screenshots.php?l=en

This is amazing. Has there been anything like this before?

GrumpyNl 6y ago

Yep, around 1990

Stratoscope 6y ago
1985. https://en.wikipedia.org/wiki/IBM_TopView https://en.wikipedia.org/wiki/IBM_TopView I had just started working at Gupta Technologies at the time, and for a short while we seriously considered developing for TopView instead of Windows.
- reaperducer 6y ago
  Ashton-Tate did it with Framework in 1984. Though my memory is that it goes back a few years earlier to Valdocs on CP/M machines, but I can’t find any pictures on the intarwebs.
  - Stratoscope 6y ago
    Framework was pretty great! My partner and I were working on some similar ideas at the time, and we got together with the Framework team to compare notes and brainstorm. The thing that stuck in my mind when Robert Carr took us on a tour of their office was the printer lab. It was a full size conference room with floor-to-ceiling shelves on every wall stacked with printers. Because back in those days, if you wanted to sell a DOS application that could print anything more than plain text, you had to write your own drivers for every printer you wanted to support. Ouch! I've sometimes thought that the real innovation in Windows 1.0 was having systemwide printer drivers so every app didn't have to provide their own.

mightybyte 6y ago

Oh yeah. I'm going to date myself here, but I was just going to say this reminds me a lot of Borland Turbo C++ way back in the day. They had this thing called Turbo Vision for building text UIs. It seemed super cool back then. https://en.wikipedia.org/wiki/Turbo_Vision https://en.wikipedia.org/wiki/Turbo_Vision

dewlinedew 6y ago
It had been open sourced i made a project using it: https://github.com/ivans5/BitMediaCentre https://github.com/ivans5/BitMediaCentre
Phil-bitplex 6y ago
It was super cool!!! I had so much fun emulating it drawing single and double line text borders, with shadows. Oh ASCII chart how I miss thee.
Minor49er 6y ago
It definitely was super cool. The windows had types, could be resized, had titles, dropdown menus, and form controls. The editor had syntax highlighting. And most importantly (at least for me at the time), there was a language reference included with the help system which had hyperlinking, so you could click through pages about the supported syntax and various topics, gleaning a wealth of information. All on DOS!
- makapuf 6y ago
  Hypertext integrated help has been available earlier than turbo vision even. It has been available from turbo pascal 3 at least. For a young like me who ... copied it on two disks, it was awesome what you could learn.
  - badsectoracula 6y ago
    Turbo Pascal 3 didn't have integrated help (hypertext or not), it was introduced in Turbo Pascal 4 (which itself was AFAIK in general a big rewrite of the compiler and IDE). Though the integrated help really improved with version 6 (when Turbo Vision was also introduced) since you could move a cursor freely inside the help window as if it was an editor, select and copy text, the help text was much more detailed and more organized and every function/procedure also had a small example showing its use (version 5.5 also had examples but the overall help was much more terse).
    - 6y ago

guerrilla 6y ago

There are many tiling window managers for UNIXes and similar such things. There's also Plan9 which is in a sense text based.

derefr 6y ago

Windows 1.0, while having a framebuffer-based layout engine, clearly evolved from a pure TUI, and retains elements (title bars, scroll bars, etc.) whose drawing algorithm emulates a TUI within the framebuffer, by just drawing DOS-like lines or grids of box-drawing characters. In fact, it’s only window content that is arbitrarily graphical in Windows 1.0; if you only have DOS VMM windows open, you’re essentially seeing a TUI, just with extra steps.

Stratoscope 6y ago
Windows 1.0 didn't actually use box-drawing characters for any of this, of course. For example, the System menu in the top left corner of each window was three horizontal lines, just like a hamburger menu of today. Scrollbar buttons did not look like any box-drawing character. The Maximize button in the top right did look like a box-drawing character, but that's really about the only resemblance I see. (I developed a DOS GUI for email, Transend PC, in the early '80s that used box-drawing characters, and soon after started writing SQLWindows for Windows 1.0, so pretty familiar with both.)
- derefr 6y ago
  Right, I'm not saying that the GUI was rendered using the DOS box-drawing characters, i.e. the monitor's built-in codepage 437 text mode; nor were they using a monospace bitmap font of codepage 437. What I'm saying, is that I'm pretty sure that a lot of the Windows 1.0 GUI was drawn by emulating the "technique" TUIs use to draw box-drawing characters, but on a framebuffer and with a custom (monospace) bitmap font: 1. create any-and-all graphical detail you need on screen, by repurposing the "leftover" parts of the bitmap font you're using to draw control-label text to the screen, adding a set of additional, custom symbol-drawing elements, which are all 'characters' of that bitmap font, and so all stuck being the same size+shape as the label text; 2. create a graphical "monospace text" drawing primitive, that takes as input a pair of buffers representing the text itself, and its hardware-text-mode-alike per-character drawing attributes (i.e. FG + BG color); 3. implement your OS widget library almost entirely in terms of calls into that graphical "monospace text" drawing primitive, passing a static data-section buffer holding the positional+attribute data for your box-drawing character. (For example, look at the drive icons in the File Manager. Those are just clearly just "text" composed of four drawing-element characters from the bitmap font, like this: [-=-]. So the whole drive-chooser area can be drawn with a single text-draw command, passing a string like "A[-=-] C[-=-] C: \WINDOWS".) ----- You might say "but look at any screenshot of Windows 1.0 — the first thing you'll notice is that the menu-item labels in each window's menu bar are offset by a half-character-width horizontally! And modal dialogs are, in their entirety, offset by a half-character horizontally and vertically! How's that possible?" Well, the GUI "monospace text"-drawing primitive might be drawing a grid of characters to the framebuffer; but it's not drawing them to an imaginary grid on the framebuffer. It accepts an arbitrary pixel offset for where it should start to draw the block of monospace text. So, with that in mind, the algorithm for drawing the menu bar very likely has two passes: 1. render some box-drawing characters representing the "background" of the menu (i.e. yellow with a black border) 2. render a layer of regular non-box-drawing characters on top, offset by +4px on the X axis, in "black on transparent", representing the menu-item labels. It's pretty clear (to me, at least) how a drawing algorithm like this could be a natural evolution and outgrowth of a TUI: first, replace the TUI's backing text buffer with a framebuffer, and the character-plotting calls with draw calls to a "draw monospace text character at emulated-grid position on framebuffer" primitive; then refactoring the draw calls to use a window-local coordinate basis; and only then adding the ability to draw anything other than monospace characters—but gradually, starting only with defined grid-snapped "rich graphical content" regions within windows (sort of like how Windows today has "Direct3D drawing surface" regions); and then going back and gradually enhancing the GUI widgets with little flourishes like draw offsets. Within the Windows 1.0 codebase, I would bet money that—at least in some previous revision in early development—there was probably a #define flag for whether the "framebuffer driver" was enabled; and that all these windowing-system and common-controls drawing algorithms were written in a "hybrid" way where, instead of one TUI-based and an entirely-distinct framebuffer-based implementation, the framebuffer-based implementation is just #ifdef'ed ornamentation on top of the base TUI implementation.

DenisM 6y ago

Norton Commander / FAR commander. The latter is still in use and actively developed: https://www.farmanager.com/screenshots.php?l=en https://www.farmanager.com/screenshots.php?l=en