I don't have any nostalgia it, I just appreciate how thoughtfully it was designed for data-input efficiency. I actually ported the official UNIX version of 1-2-3 to Linux a few years ago, I still use it regularly. It uses some tricks to get the original UNIX binaries working on Linux: https://github.com/taviso/123elf
I had been thinking about how to add UTF-8 support, it only supports LMBCS (Lotus Multi-Byte Character Set) by default. It's actually worse than that, it stores everything internally as LMBCS but in a lot of cases can only display ASCII, so it transliterates a lot of characters (e.g. é -> e).
It's also possible to run the real DOS version in dosemu - in terminal mode it's basically indistinguishable from an ncurses application, although dosemu is just cleverly sampling the framebuffer and translating it on-the-fly.
A regression here and there would be normal before, major features breaking in this stable 25 year old software is simply unheard of.
This is not exciting cutting-edge software, it's a boring financial app. My instinct is people want stability and confidence that the output won't change and that their records will still parse.
If you hear a rumor that sounds too crazy to be true on social media, maybe don't repeat it as fact. Imagine how you would feel reading something like that.
I think those are all basic features that all major debuggers support, certainly gdb can do those including moving backwards (gdb calls it reverse debugging).
- Conditional breakpoints, break main.c:26 if a > 6
- Move instruction pointer, jump main.c:84
- Jump between threads, thread 123
- etc, etc.
I've barely used Visual Studio, but I'm very familiar with windbg which uses the same debugger engine with a different UI.
I remember TotalView releasing a product years and years ago called Memscape - Like Netscape, but for Memory. It looked like a browser, but was a sort of graphical heap profiler/leak detector.
I think it wasn't as powerful as Valgrind, but you've got to give them credit for an interesting UX concept.
I don't think I have any of gdb, but I was just talking about a hobby project using frida! Frida is a tool that lets you inject v8 into any process, then exposes a javascript debugging api, I find it incredibly useful.
I use vanilla gdb, the secret to the arrow-key problem the author had is they needed to switch window focus. The keybinding is Ctrl-X O, but if you don't want to remember that - and who could blame you - you can use the focus command, e.g. `focus cmd` will get you back to the command window, or `focus src` will get you back to the source window.
The display isn't really buggy, it's just the debugee output messed up the terminal. You can redraw it with ^L, or disable the tui while it's running. You can toggle it with Ctrl-X A, or just `tui enable` or `tui disable`.
I quite like the tui, the windows are configurable (use `show tui` and `show style`), and you can display more than just source, there's also registers and disassembly mode, e.g. `tui reg general`.
I don't have any nostalgia it, I just appreciate how thoughtfully it was designed for data-input efficiency. I actually ported the official UNIX version of 1-2-3 to Linux a few years ago, I still use it regularly. It uses some tricks to get the original UNIX binaries working on Linux: https://github.com/taviso/123elf
I had been thinking about how to add UTF-8 support, it only supports LMBCS (Lotus Multi-Byte Character Set) by default. It's actually worse than that, it stores everything internally as LMBCS but in a lot of cases can only display ASCII, so it transliterates a lot of characters (e.g. é -> e).
It's also possible to run the real DOS version in dosemu - in terminal mode it's basically indistinguishable from an ncurses application, although dosemu is just cleverly sampling the framebuffer and translating it on-the-fly.
I wrote a display driver to make that work a little better: https://github.com/taviso/lotusdrv