[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.