[visiblink]

On this note, the Royal Bank of Canada used a DOS-like system well into the 2000s. The tellers were amazingly proficient with it, entering data, hitting tab-tab-tab, entering more data, tab-tab-tab, etc.

When they switched to Windows, you could see how much the point-and-click interface slowed them down.

[smackeyacky]

When we first starting writing windows programs back then, one of the main considerations of a desktop / client server CRUD program was getting the tabbing order right.

A lot of those green screen / dos / mini computer CRUD programs were carefully designed around productivity with a keyboard.

[accrual]

I wish tab order was considered more in some applications. One of our in-house apps has had a lot of fields added over time and it's a jumbled mess trying to tab through it, essentially forcing point/click when a keyboard would otherwise be enough.

[jaclaz]

Also, this is a pet peeve of mine, we used until 2017 a DOS program (think invoicing) that could fit ALL needed fields in a single 80x25 screen (navigated via TAB and ENTER or SHIFT TAB/ENTER to go back).

The new windows program, on a decent screen resolution, opens instead a small window where the same fields are scattered on three or four tabs.

Even if within the same window fields can be navigated via TAB, you need to switch to the other tabs/windows and it slows down the input, as you never have a "whole" view of the data, so you have to go back through each tab to check whether you missed a field or mistyped inside a field.

[fuzzfactor]

>A lot of those green screen / dos / mini computer CRUD programs were carefully designed around productivity with a keyboard.

Some of the best late DOS programs did a good job of optimizing for both keyboard & mouse also.

There's a cargo installation around here where they got a high-dollar mainframe in the 1970's and the data could be accessed by the few plant employees having CRT terminals. Even into the early 80's independent contractors had to do their field work by hand, and largely back in the office too since PC's were slowly adopted.

Once desktop IBMs became accepted for bigger companies, the whole shebang was rewritten for DOS by the mid-80's and their people had to get accustomed to that.

Finally with the migration (of the rest of the world) to Windows 3 and 9x, there was another DOS rewrite to handle an alternative database.

Each of these was ungodly expensive and took forever. Nobody wanted to repeat that.

Independent contractors like us were then allowed to have a copy of the key DOS modules on our laptops and the preferred procedure was to reboot to the bare metal DOS underlying the Windows 9x shell, and run the program in DOS.

Since then there really hasn't been much more to get accustomed to, each generation of everyday operators is just fine with doing things as they have always been done.

Fortunately for many hardware configurations it would also run from the command prompt window in Windows, but similarly to DOS games, this didn't work for everybody.

This is probably what has made it possible for geeks to kludge it into functionality until I had to figure it out on Windows 10 a few years ago. They were blown away when I gave them the first mouse they had in years.

Some contractors have never used it and just do without, it's only one marine terminal but it's the one where we happen to have people stationed 24/7.

So next week I have to show an IT guy how to get it to run in the latest 64-bit Windows 10 using vDOS again.

DOS really will still boot on the bare metal in BIOS mode with a CSM enabled as long as you have a well prepared Active FAT32 volume on an MBR layout storage device recognized by BIOS, etc.

And I did find the settings to get the DOS app to run from the 32-bit Windows 10 command prompt last time.

Too bad they have to use 64-bit Windows and GPT layout on the SSD, with UEFI booting.

The good emulator turned out to be vDOS.

[smackeyacky]

You don't see vDOS mentioned much, although my limited understanding is that it's designed to get all those old business oriented DOS apps working (instead of games) i.e. it works with the original version of Wordstar that no longer runs on newer DOSs due to the way file handling works.

It's fascinating to me just how long you can keep old programs going in the modern age. Emulation is such a life saver.

[mormegil]

The Czech taxation authority has the "Automated Tax Information System" as the primary IS. It has been running since 1993, it has a classic DOS text-mode interface and its maintenance cost is huge, which is completely fine with its supplier, IBM, which is the only subject allowed to make any modifications to it (per the contract). Textbook case of vendor lock-in. An official study of what to do with the system from 2016 (including a screenshot): https://www.financnisprava.cz/assets/cs/prilohy/f-novinky/20...

[aforwardslash]

Text interfaces are still quite common in mainframes. If the vendor is IBM, the screenshot is probably a 5270 terminal running a RPG (or COBOL) application. In fact, these kind of systems are still so popular in the financial industry that there are libraries to wrap a modern GUI on top of existing terminal-based applications.

[skissane]

> If the vendor is IBM, the screenshot is probably a 5270 terminal running a RPG (or COBOL) application

From the linked PDF I gather the app is written in Informix 4GL (I can’t read Czech, just guessing based on the smattering of English words-I also think in mentions some modules are written in C?). If that’s right, it is probably a character mode VT100 app running on some Unix box, not 3270 or 5250, not COBOL or RPG

[marttt]

> ... and its maintenance cost is huge ...

Would you mind expanding on this a little?

[mormegil]

There is more detail in the (Czech-language) presentation; the ongoing cost is in hundreds of millions CZK (~millions to tens of millions EUR) every year, the TCO for the whole time was in 2019 estimated over 9 billion CZK (~400M EUR).

[accrual]

It's a stretch of a tangent, but this reminded me of the Therac-25 incident in which experienced operators of the machine could enter commands too quickly and cause it to enter an unexpected state.

> One failure occurred when a particular sequence of keystrokes was entered on the VT-100 terminal which controlled the PDP-11 computer: if the operator were to press "X" to (erroneously) select 25 MeV photon mode, then use "cursor up" to edit the input to "E" to (correctly) select 25 MeV Electron mode, then "Enter", all within eight seconds of the first keypress, well within the capability of an experienced user of the machine. These edits weren't noticed as it would take 8 seconds for startup, so it would go with the default setup.

https://en.wikipedia.org/wiki/Therac-25

[HeckFeck]

The health service in Northern Ireland still used TUI terminals way into 2006, I remember seeing the staff bring up my records with a few taps of the keyboard.

Mouse UIs aren't a universal boon, and I think the recent failures at shoehorning touch screen UIs demonstrate that there isn't 'one HID to rule them all'.

[Gordonjcp]

IBM used a DOS-based OS called "4690" for their point-of-sale systems, which IIRC had 32-bit extensions and various forms of networking including a weird 56kbps "token ring" type system that tills could (s-l-o-o-o-w-l-y) netboot off.

It's still in use, and although it's been replaced by Linux in current products there were bugfix releases at least as recently as late 2020.

[lproven]

4690 OS evolved from Digital Research FlexOS, which replaced Concurrent DOS 286.

The revised license for CP/M from DRDOS, Inc this month covers "CP/M and derivatives".

DRDOS is a derivative of CP/M, as is Concurrent DOS/Multiuser DOS, and arguably the FlexOS line too.