Eh, the Borland Grahics Interface (BGI) style TUIs were kind of awful. I hated the Borland Turbo C IDE in no small part because of that style TUI. It just wasted so much precious character space on TUI frames and other decorations.
More of my fond TUI memories from that era were the bespoke ones in the demo/art/music/bbs scenes. Those in many cases were still character based but seemed to make better use of the screen space and at least more aesthetically pleasing character sets.
Scream Tracker / Impulse Tracker comes to mind as one example:
For anyone searching for the Borland style text interface, it was actually called TurboVision, not BGI (which was a generic graphics library). TurboVision (and many GUIs of the time) largely followed the Common User Interface (CUI) spec by IBM for its interactions in text mode.
It is fair to say there was a lot of screen space devoted to borders and such, especially in 80x25 mode, but that helped make everything super clear and usable.
I remember that I loved the Turbo Vision TUI's so much that I dreamed to have a copy of it as a kid. My family wasn't very well off, but I got Borland C++ 2.0 for Christmas. The compiler came with BGI graphics but they were NOT text mode. The library was also awfully slow (drawing a picture by repeatedly calling drawPixel() took minutes)
I don't remember the price of Turbo Vision, but I remember it was obscenely expensive in my third-world eyes. It was sold separately until it was finally bundled with BC++ 3.1 (1992).
Altought I liked Borland IDE's, did't liked their UIs neither. For me the best text UI's ever created were Symantec's, which used some custom icons (ie arrows, buttons), and nicer tech colors:
The DOSSHELL included in MS-DOS itself also used some custom graphics, but that was totally optional. The interface was still based around the usual hardware text mode.
You might have disliked them but they were far from awful. They were some of the cleanest TUIs ever designed.
The other screenshot you shared isn’t a TUI by the way. It’s a GUI. It just happens it runs atop of DOS (much like early versions of Windows did). So it’s not really comparable to TurboVision.
Regarding TurboVision, I suspect you might be in the minority with your dislike for them too. Which I guess just goes to prove that everyone will have different preferences and thus you can’t please everyone all of the time.
It has bevels made up of 3 colours, so I can’t see how it’s pure text mode. It’s certainly text heavy so they could have drawn the GUI int a frame buffer and then just used text mode for screen updates. But that’s a little disingenuous from being a TUI.
You guys are still missing my point that it’s not a TUI because non-text elements have been drawn to the frame buffer. This is actually a lot easier to do in DOS than it is in UNIX too by virtue of the fact that DOSs text mode isn’t a pseudo-teletype. In fact this is a trick I used to do all the time when writing software back in the 80s: draw a UI then fallback to printing characters for UI updates.
For that tracker to be a proper TUI it would have to use text characters for all of the UI elements, bevels included. You simply couldn’t do those 3-tone bevels with any alt character sets, let alone an 8-bit one from the era of DOS.
What frame buffer? There is no frame buffer. It runs in text mode, thus it's a TUI. Would you consider Norton's text-mode interfaces not TUIs because they would redefine some characters for window chrome and a mouse pointer?
Are you sure? It seems to me that they were probably replacing some text characters with their own sprites instead. They could still be text characters, just redefined for their purposes.
I remember back then my editor of choice in DOS was QEdit. I think it used up less space with its menus, although it's funny to think I enjoy using vim today whereas back then in my youth it may have been too much for me.
I do miss the simple UI offered by some BBSes (as well as their message editors, like in Renegade BBS). A lot of that is just nostalgia, of course.
Compared with modern UIs where you don't know where an UI element begins or ends or with gray font on gray background (or like this text field on my phone where the cursor does not advances when i press space) those UIs were a blessing.
Impulse Tracker, which was intended as an advanced Screamtracker clone also features character map graphics to show sample data. It was kind of mind-blowing back in the day to have a text-mode DOS tool with pseudo graphics.
Totally! However, even with the proper fonts (that also have to be aspect ratio corrected, the usual VGA text mode did not have square pixels), I struggle to recreate this to the point that it's really recognizable.
CRTs with that text mode (and including scanlines, but not only that) just seem very hard to reproduce on modern displays.
The fact that your photo does evoke the same feeling while I'm seeing it on a modern 5k display shows that it's possible, but the amount of tricks needed might be so much that it becomes whimsical somehow (or at least in contrast to just changing the font)...
I once wrote a web front-end for a DOS-era web application that was used at over 2,000 locations by hundreds of thousands of people. It was virtually identical to the original layout and functionality, but it had basic-yet-functional HTML look to it. Think Google search.
On the 1st of April it would instead switch to a "DOS skin" using the fixedsys font and the original colour theme and box-drawing character layout. Virtually identical to the original, except that some things were centred and you could scroll with a mouse.
I wonder if it would be possible to extend a terminal multiplexer to the point of providing such an intuitive interface to existing TUI software on modern *ix systems. I'm sure the effort would be quite non-trivial, but it would help a number of workflows. Adding support for the additional features that are found in these TUI environments (consider e.g. menubars) could then be done via custom terminal extensions.
Check out the VTM project[1]! It feels like that's the direction they're heading. No direct affiliation; they've filed some bugs on Windows Terminal, however. :)
Well, that's a terminal multiplexer but not very TUI like. I don't think it would be directly usable over a low-bandwidth SSH connection, which is the kind of use case people often have in mind for TUI's.
Oh, great! Happy to help. I've been using it for years now -- it's becoming a faithful friend, to the bafflement of my colleagues who are mostly Vi(m) or Emacs fans.
The one thing it doesn't do for me is pick up Git commit templates, so for that I have to have my default set to `mc`. I don't know why that one thing doesn't function.
I liked Turbo Vision but I thought Microsoft’s text UI (the one used in products like QuickC, QBasic etc — not sure what it’s called) was actually cleaner and more aesthetically pleasing.
Never tried that, however. Ncurses is what is used under Linux and other UNIX like systems to draw terminal based GUIs, and allows some pretty good graphics.
I absolutely do. I'm 100% aware that it's the nostalgia talking, but I don't care, I unapologetically love them.
For context, the first computer we got at home was a PC at some point in '94 or '95. We had MS-DOS 6.22 and Windows 3.11. Some years later we moved into Windows 95. While I didn't really use these kind of GUIs (DOSShell and so on) as often as I would like, I always thought they were very pleasant to use. There is something about that DOS font that makes me happy each time I see it, and there is a certain feeling of being a stereotypical movie-style hacker when you use these instead of modern, actually graphical UIs. And yes, the reminiscence of simpler times with simple software, way before the surveillance capitalism and the brutal omnipresence of ads, is easy to appreciate.
The nice thing is that early versions of Windows supported these GUIs as well. So, a few years later, during my degree in Computer Engineering, I learned some x86 assembly (using Turbo Assembler as a compiler); this was during the early 00s, and we still used EDIT.com as the main text editor, although there were some others available. I loved it since the first day, both in concept (super low level programming with direct access to the hardware, managing interruptions and so on) and in execution (everything was in that text mode I loved, since modern Windows and their restrictions didn't play nicely with such low-level programming). I learned a lot from Ralf Brown's Interrup.lst, and wrote a few simple GUIs of my own, using box drawing characters and all that. Aside from those I wrote for academic work, I mostly spent a lot of time creating a silly GUI that allowed you to modify the look of the console. There were a few resolutions available, from 40x25 to 132x60, and you could change the colours of the text, the background and the border (yes, there is a border, which you can set to a different colour than the background. And my program could get 2^18=262144 colours available, not just 16! Although 16 was the max simultaneous on-screen limit IIRC), plus the font (I was able to add an edition screen where you could see the aspect of all 256 characters, yet I could use box drawing and so on for the interface in this screen. Did you know that DOS allowed two different sets of characters in screen at the same time?). There were some other additions like pixel-level scroll as opposed to the usual line-level scroll, and background "music" using the PC speaker. It didn't have any practical purpose aside from these silly customisations (which, in the case of Windows, went away when you closed the windows, and some times, also when you moved from full screen to a window), but man, did I have fun coding it. It's still one of my best memories of programming, nearly 15 years later.
Then, in 2009, my last Windows 98-capable computer stopped working, and current hardware only supported Windows XP and newer, so all of this fun basically stopped being possible (especially considering that basically all state of the art hardware was already 64 bits, and 16-bit applications like EDIT.com weren't supported any more). With emulators it's not the same, because I know I'm not really accessing the low-level hardware registers. By that time I already had a job and there was less time for this kind of hobbies, so I eventually stopped. Currently my recreational programming is mostly oriented towards math (Project Euler and so on), which is very different, but I still remember those days very fondly. I still have all that code somewhere.
Yeah, it's all nostalgia, but that doesn't mean it doesn't hit hard.
OH GOD NO. Man, I hated all that stuff at the time. If you're stuck in text mode, just be text. Don't try to mimic a GUI; it just looks weird and generally works poorly.
A web site that imposed this sort of interface would be a site I visited ONCE.
I suggest that you need to look at the historical context of it.
When DOS was the uncontested king of business computing, user interfaces were all over the place. Every app had its own UI, its own keystrokes, its own everything.
To steal some text I wrote for Wikipedia:
In WordPerfect, the command to open a file was F7, 3.
In Lotus 1-2-3, a file was opened with / (to open the menus), F (for File), R (for Retrieve).
In Microsoft Word, a file was opened with Esc (to open the menus), T (for Transfer), L (for Load).
It was a mess and a significant effort to learn multiple apps.
Then classic MacOS and MS Windows started to introduce the idea of uniform UIs, where programs had the same menu bar with the same core menus with the same commands on them, opened and navigated with the same keystrokes.
It made life so much easier. A lot of apps came across, even big-name ones -- for instance MS Word (v5.0, proprietary 2-line menus at the bottom of the screen; v5.5, CUA menu bar); WordPerfect (added CUA menus in v5); Borland Quattro; etc.
And if you have a standard menu bar, then you more or less need to have dialog boxes as part of the UI.
Once you go that far, you may as well apply it to multiple documents support and so on.
And so you end up with a familiar, more-or-less harmonious UI across different apps from different vendors, and for the first time it became possible to operate a program you'd never seen before first time.
This was a huge win for usability, accessibility, and it saved time, effort and stress for millions of people.
It was a triumph. That UI persists today in most modern FOSS apps and desktops, except for intentional rebels like GNOME 3, who want to make us all use phones with big screens.
If I am going to use a text editor, say, in the shell sometimes, then YES I want it to use the same UI I have in my GUI session, with the same keystrokes and menu options. Life is much to short to learn some crappy half-assed UI from the 1970s because a bunch of old dudes with beards have loved it ever since.
I'm 51. I lived the era you're describing, so yeah, I understand the historical context quite well.
But you're crossing the streams a little here.
Yes, it was a net win for the shift to GUIs to include a shift to very, very consistent interfaces.
HOWEVER, it doesn't follow that goofy, hamfisted attempts to mimic those interfaces in text mode was a good idea. If you want that, just go use Windows (or the Mac).
Word for DOS 5.0 was a fantastic program that I could move around in VERY VERY VERY quickly. It was powerful, stable, and extremely usable once you learned its interface.
Word 5.5 for DOS ripped out the ESC menus for a crappy text-mode UI, and basically killed the product. (For my part, I immediately uninstalled it and reinstalled 5.0 so I could get work done.)
But I _strongly_ disagree. In fact I think I could reasonably say that I couldn't disagree more.
I thought it was a huge win when DOS and console-mode apps adopted the general Windows-like UI.
I worked in support back then. I had to learn many dozens of apps to support them.
For instance...
In word processors, on DOS alone I worked with MS Word, WordPerfect, DisplayWrite, MultiMate, WordStar (classic, 1512 (i.e. Express), & 2000 — all different), Samna Executive, PC-Write, VolksWriter, XyWrite, Protext, PFS:Write, and also LocoScript (from the Amstrad PCW, later on DOS). Probably others.
Spreadsheets: Lotus 1-2-3, Lotus Symphony, AsEasyAs, SuperCalc, Quattro, MS Multiplan. Probably more.
I had to learn all of them, all separately, either at least the basics (I think Samna is the only one that defeated me there), or in multiple cases, pretty much inside-out.
I mean, as an example, I didn't consider myself a guru, but I interviewed for https://www.newtonim.com/ in about 1992 and I got a record-best score (about 98%) in their test of my WordPerfect and 1-2-3 skills. Neither was even my favourite program of its type!
It was a massive pain.
I mean, yes, you're right, some of them were highly efficient interfaces. I didn't hate 1-2-3 or MS Word for their idiosyncratic 2-line menus. You had to memorize them to be fast and efficient, but it wasn't that hard and once you had, it was as you say very quick.
Unlike, say, WordPerfect with its wretched Ctrl-F3, Alt-F6, Shift-F2, Alt-Shift-F8 workflow. Horrible and basically impossible to discover. If you didn't have that little cardboard keyboard template, you were doomed.
But I didn't have the luxury of picking 1 app of each type and using only those. At work I used PCs with PC DOS, at home I used CP/M and Locoscript, later Acorn RISC OS, later still OS/2 2. I did charts and DTP on classic MacOS.
All totally different, and my job meant knowing _all_ of the leading contenders in all categories.
Sure it was possible to write attractive, efficient, DOS menuing systems. Novell's DOS menuing system on Netware clients and on the server itself was fast, easy, efficient, and attractive.
So was 3Com 3+Share -- probably last seen by most people in the config tool for the classic 3C509 NIC.
But they were totally different from one another.
So if you only used MS Word, good for you. I envy you the simplicity that may have lent.
But for those of us who changed apps considerably more than every day -- more like ever hour of every day -- no, the profusion of DOS UIs was a complete pain in the neck and made my job 10× more difficult.
So when they all went away, replaced by a text-only version of the Windows/CUA guidelines, I celebrated. It made my life so very much easier.
Which is why now, 3 decades later, I absolutely refuse to learn the horrid 1970s BS UIs of Emacs or Vim. I don't care how powerful they are. I'm not interested. I gave that rubbish up in about 1990-1991 and for me all those proprietary UIs died once the next-gen ones came along.
You're still litigating the idea of interface standardization, which isn't the thing I was saying was a terrible idea.
Your background is not normal. Most people doing actual work in that era used the word processor they had, not seven word processors.
In a limited environment -- text mode -- efficiency and speed > cuddly GUIs. If you wanted the common interface, install Windows; don't fuck up the existing interfaces of tools people were VERY VERY good at to graft some horribly ugly faux-GUI on them.
>I absolutely refuse to learn the horrid 1970s BS UIs of Emacs or Vim
Given the longevity and popularity of these tools, coupled with their broad availability on so many platforms, this sentence reads more like "I'm proudly ignorant!" than anything else.
Believe me, tech support is actual work. Without it, all those writers and accountants wouldn't get much done.
The CUA interface is perfectly efficient and works very well. It doesn't need a mouse, although you can use one if it's there.
As I said: I was a skilled user of a bunch of the leading pre-CUA DOS apps, and I can navigate a CUA interface using hotkeys very quickly and efficiently without a pointing device. Occasionally, over the years, astounded onlookers have asked how it's possible that I can operate Windows so quickly. The answer is that I don't use the mouse much, and the reason is that in my first job, my employers didn't own a PC mouse. They sold Macs; if you wanted to do graphical pointy-clicky stuff, you bought a Mac.
I decided that Windows looked like it was useful and could be big one day, so I installed Windows 2.01 and learned to use it... without a mouse. The same keystrokes mostly still work today, from obvious ones like Ctrl+S to save, Ctrl+X/C/V for Cut/Copy/Paste, to less-known ones like Ctrl-W for Close Window and Alt-F4 for Close Program. Alt-Space for the window control menu, then X to maXimise, etc.
It's a common but spurious argument to claim that because one knows one particular program well and can operate it very quickly, that this fact in some way indicates that the program's UI is particularly efficient or well-designed or something. It isn't. It just means that that individual knows it well.
The basic concepts of the desktop GUI were nicknamed WIMP: Windows, Icons, Menus, Pointer. Well, each of those works fine in isolation. Icons are a useful abstraction all on their own; for instance, iOS and Android make very extensive use of the "I" part without the "W," "M" or "P".
By the same token, the W and M parts -- windows and menus -- work very well without a GUI. It's very handy that the same keystrokes that let me drive Geany or Mousepad or Notepad also work fine in Tilde or MS-DOS Edit.
They're no less efficient. Ctrl+S Ctrl-W to Save then Close is just as quick as ^KS ^KD, or !wq, or C-s C-x, or Shift+F3, Ctrl+F4.
But what's a huge boon to my or anyone's efficiency is that once I've learned Ctrl+S, say, it works in thousands of programs on multiple OSes. C-s C-x or Shift-F3 don't work in anything except the one particular app they were designed for.
I used poor wording. Support is definitely work. I just mean that MOST people doing day-to-day work USING tools (vs supporting them) only deal with one at a time.
A UI's utility isn't determined by whether or not it's shared with other tools. It's determined by *how well users can get work done with it* which is why a host of non-CUA interfaces persist today.
Text-mode CUA was and remains horribly ugly and clunky. If you want that, go use a GUI.
What I am saying is that in this case, I put it to you that this is more than simply a matter of opinion and personal preference.
There are demonstrable, measurable advantages to this approach. Knowledgeable users can work on unfamiliar programs immediately by using standard keystrokes and via prior knowledge of how the menus will work.
Unskilled users, so long as the machine has a mouse configured, can simply use the console/terminal app in the same way as they're used to, by point-and-click.
I get that you hate it. What I am trying to tell you is that I _really_ like it. It is a _strong_ preference of mine, I find it asthetically pleasing as well as convenient, and I hate and refuse to fight with non-compliant apps that don't use it. Including _both_ of the xNix world's favourite editors, Vim and Emacs -- I hate both -- *and* all the alternatives people recommend: Joe, Pico, Nano, etc.
I get that you have a preference. That is your choice. But you are trying to make out that it's a universal truth, that your opinion is an objective fact, and it's not.
Whether you, or anyone, likes it is neither here nor there. It helps. It works. It's useful. It makes life easier.
And if the price of that is that some people's aesthetic sensibilities are offended, well... sorry dude, tough.
Lmao I like how saying "no" got you downvoted. Express an opinion about a purely subjective thing that others don't like and you get downvoted. Come on HN, you can do better.
Still don’t quite get the DOS nostalgia. Individual games were good, but the whole ecosystem was finicky and crash-prone by the early- to mid-90s, not to mention deeply ugly (ALL CAPS console, lousy inconsistent GUIs, unnaturally short filenames, etc.). My friends and I couldn’t wait to run Unix, NeXTSTEP, hell even classic MacOS. We only ran DOS/Windows because that’s all we had. Though don’t get me wrong, we still had tons of fun and learned a lot.
The irrelevancy is the appeal. It's become something mostly disconnected from everything else.
A world of computing that's not focused around networking or communications where the relationship is between the user and the machine as opposed to the machine being a vessel for a relationship with others.
It is inherently a different kind of computing with a different kind of performance expected between the participants. It's like how people who restore classic cars don't do so because they need a way to get groceries and drive to the office. Anyone with their head on straight would admit modern cars are cheaper to maintain, safer, and have better fuel economy. Doesn't matter, it's not the point.
You nailed it. My attraction to retro-computing is a mixture of nostalgia and a desire to unplug and go "off the grid". Early computers (DOS, Mac, C64, Apple II, BBC Micro, etc.) had a much more intimate feel than today's omni-connected communications devices. It's kind of like reading a book vs watching a live stream (with busy chat scrolling by).
Another aspect to it is the low latency you get when using a machine with very few layers of abstraction between the software and the (usually CRT) display. Using something like WordPerfect for DOS is a dramatically different experience than modern MS Word or Google Docs. Vastly fewer visual distractions as well.
The OS itself was very basic. Learning to program things like TSRs, dealing with HIGHMEM, BASIC and BASIC assemblers vs C and other tools. It was a complicated environment by the restrictions, but those restrictions when explored taught one a lot about programming.
It was a great environment to learn in. I spent time there, on the Amiga, and other systems. I honestly love how easy and powerful systems are now, but miss swap meets and the like for meeting up, talking hardware, software, etc.
I thought DESQview was pretty cool. But none of my nerd friends appreciated it that much. Until I showed them they could hide _Bards_Tale_ or _Sopwith_ from the game-hating highschool librarian with a simple hot key.
I was a brief DOS user for several months (in between C64 and discovering UNIX) around the early 90's, and my opinions of it from the time mostly align with yours. I think the early 90's was an especially rough period for DOS users, because people were trying to push it way beyond what it was originally meant to be.
However, while I certainly don't have nostalgia for DOS in general, there were some positive things about the platform and ecosystem. Some subset of applications had TUI interfaces that were very nice (e.g. Borland C++), and while I'm a die-hard Linux terminal user, I find myself occasionally missing some of the tightness of those interfaces. (I think the UNIX terminal heritage, such as the "alt" key translating to ESC+key, no key-down/key-up events, etc., can limit our modern TUI interfaces.)
I sometimes tinker with some 8086 emulator code for fun, which can lead me to diving into the internals of DOS. Looking at its API (and how the API evolved through the 80's), I can appreciate the simplicity that was necessary to run on machines with as little as 64KB of memory. So I may not have nostalgia for it -- there was certainly plenty of pain -- but it can still be very interesting to explore from an objective historical perspective. There may even be a few things we can learn from it.
There were entire communities based around specific DOS games and applications. Notably: ZZT, MegaZeux, a slew of abandonware games, QBASIC, and so on.
A lot of people discovered just how limited DOS was because they were fascinated by computers, but DOS (and likely Windows on top of it) was the only thing they had at the time. Yet they wanted to push the boundaries and ended up finding the ceiling. At least that's been my experience.
For creative pursuits, limitations can counter-intuitively be good to have. Not only do you learn a lot (and have fun) when you're forced to understand a system well to work around its limitations, but it removes a lot of the distraction of choice ("option paralysis"), so you make creative decisions instead of technical ones.
That's why it was all so much fun. I had so much fun that I'm still actively maintaining one of those originally DOS QuickBasic game engines -- it was ported to FreeBASIC and modern OSes long ago, but it's still got that DOS look and various limitations.
MS-DOS filenames were too short to be useful, but the systems once up and running, tended to run until they were obsoleted. MS-DOS itself is mostly just a program loader, with a bit of file system API to make programming easier. The nice thing was that it was simple, could be backed up easily, and stuff worked as expected, for decades, if necessary.
The other thing is we didn't have to worry about security (much). Because everything could be backed up, and a known safe system state was achievable, and you could even write protect non-hard drive based machines, you could run ANYTHING, and there was nowhere in the hardware for malware to hide if things got squirrely and you rebooted.
You could always just reboot from a write protected system disk, and get back to work. This is a level of security that hasn't been matched since, except for mainframes with their fixed assignment of resources.
I wrote a system that recorded inspections of equipment, involved hand held computers, and a weird Emulex serial card to talk to them. The code was all in Turbo Pascal, with PL/N running on the handhelds. I supported it for a decade until Windows and Networking made things obsolete. It was a great job.
I was a big fan of 80x50 or 80x43 character screen mode.
WAT?! You didn't enjoy running QEMM, running the optimizer to figure out the best order to load things. Configuring EMS and XMS memory? Editing your config.sys and autoexec.bat. Manually setting dip switches and setting pins to try to get your cards to each have a unique IRQ
I certainly have some fond memories but I'm pretty happy with modern UIs
On the surface of it, I look back fondly at those times. It was certainly a good environment to learn about computer basics.
But realistically, I also recall getting pretty frustrated at times. Such as when I just wanted to play Wing Commander: Privateer, but had to spend hours messing with memory settings in `autoexec.bat`/`config.sys` and rebooting just to get it to run. And then I had to spend hours more fiddling with the memory settings, IRQs and the like, just so I could get sound from my Gravis Ultrasound/Soundblaster instead of the PC speaker.
>Manually setting dip switches and setting pins to try to get your cards to each have a unique IRQ
Also, thinking about which IRQs are available when buying a hardware device and how that maps with possibilities for existing devices.
Even more fun - realizing that the solution is to swap network cards amongst a couple of computers because the other network card has more options. So you do the swap (and update the software to use the new ports) and then hope that both computers will even load afterward.
Had to do the planning by hand since this was before I was on the Internet and I don't remember seeing web apps that help with this.
I feel like most of the folks on the DOS nostalgia train are people who didn't actually live through that era trying to make all those things work. As you note, it was finicky, crash prone, and very very annoying to work with.
We did have fun, but we would've had more fun on a more capable, less slapdash OS. Which is why so many of us abandoned Win/DOS at our first opportunity -- either on (likely university-owned) Unix or BSD hardware, or on early Linux, or for some to the Mac or Amiga or even Atari, all of which were empirically better platforms than DOS/Windows at the time EXCEPT for gaming.
I wouldn't paint with such a broad brush. I've recently gotten way into retrocomputing, DOS included, I absolutely lived through that era. I spent my formative computing years in the early to mid 90s deep in DOS, mostly playing games, watching demos, listening to and writing tracker music, and doing pretty rudimentary C/C++ programming.
At the beginning of this year, I built an AMD K6 machine, got my Gravis Ultrasound card working again (which involved ordering a replacement mixer chip from China), and have had an absolutely wonderful time reliving my early computing experiences. And yes, that also includes fiddling with IRQ settings, maximizing low DOS memory, etc. Would I do day-to-day work in this kind of environment? Hell no! But it's a really fun distraction.
What still blows my mind is that there were vastly better technologies at the time.
Back in 1992 or so, I was an Amiga user. I was blessed with both advanced GUIs and advanced shells. AmigaOS wasn't quite Unix, but the shell had similar power. I had friends who used Apple Macintosh computers, and they also bragged about the stuff they could do. (And of course you had other things like NeXT, Acorn's RISC OS, SCO UNIX, and OS/2, all of which had pre-emptive multitasking, but weren't on my radar at the time.)
But the PC was everywhere, and the Amiga was fading, so I got a PC, even though it was ridiculously primitive. While building PCs was fun, everything was a struggle. DOS was crappy, you had to fiddle with memory managers, no multitasking, a terrible file system, and so on. Windows 3.0 was not the dominant player that it would become with Windows 95, and you still did many things in DOS, such as programming. On the positive side, the gaming situation was pretty much as good as it had been on the Amiga. The 1990s was a great time for games.
But it's insane that so much superior tech existed at the time, yet we lost of all that to MS-DOS. It wasn't really until Windows 2000 that we had something decent again, even then it was quickly derailed. I really appreciate that Apple came back and MacOS X became an alternative.
The transition from ANSI graphics to the ugliness of Windows 3.1 or even Desqview was pretty rough. I spent a ton of time in terminal emulators and BBS programs that I found much more intuitive and "pretty". Their graphical counterparts were hideous by comparison. I think I still carry some of that bias with me.
I did have to do a quick check to see if this library required me to configure expanded memory, however.
One of my first jobs involved writing a modern (for the time) GUI app to replace some ancient services that involved logging in a mainframe to use. They needed to updated for a host of technical reasons, but there was also hope that more user-friendly versions would decrease the onboarding time for new employees.
The first version was a fairly literal replacement of the workflows. The users were pissed. They demanded the checkboxes be replaced with "Y" and "N" options to mimic what they were used to. It was interesting to see the reluctance to any change at all.
> The users were pissed. They demanded the checkboxes be replaced with "Y" and "N" options to mimic what they were used to.
If you removed my keyboard workflow, I'd be pissed too. Muscle memory means you don't have to think about it; with the mouse, you always have to think about what you're doing, and can't think of other things (e.g. why you're doing it) while you're doing the rote bits.
Is there a particular reason you couldn't've supported the Y/N workflow? (i.e. “Y” is like “set, tab” and “N” is like “clear, tab”)
> They were pissed we replaced the Y/N text items with a checkbox.
At this point, I'd probably factor out the UI, hand them the client-side source code and tell them to get on with it. If they want to customise the UI, then so long as you're not supporting it…
… but yeah; that's a less reasonable objection than I thought it was. (Still a change to their workflow, and still understandable, but there were legitimate business reasons that the workflow needed to be changed.)
The Github doesn't have much besides the source, this is probably the better link: https://mattiasgustavsson.itch.io/dos-like Includes some sample code and screenshots.
It looks pretty much identical to the Turbo Pascal IDE for anyone that's feeling nostalgic and wants to write some yellow on dark blue code.
Even better - Free Pascal comes with Free Vision, which is mostly compatible with Turbo Vision. Turbo Vision was the toolkit Borland provided that would let you write your own text-mode GUI apps using the same widgets used to build the Turbo Pascal IDE.
I don't think the Free Pascal IDE is related to this
If you check the website demos and the "dos.h" source on GitHub, this is a library for making GUI apps whose UI has the appearance of being made with MS-DOS.
Unless I am misunderstanding the connection you're trying to make, which is also possible
I like these and the other examples. However they all tend to use 16 colors while improving other aspects such as unicode and resizable large cell count terminals. Please use more colors, 256 at least. I’d like to see a turbovision style CUA TUI (haha) in a theme like Win 95 or 2k etc.
Oooh, I didn't know that technique was called vowel space rendering. I love the look of it, but, more importantly, it seems like a fairly trivial way to encode multidimensional information and make it navigable by humans. (I'm having loose ideas for e.g. representing the health state of software systems this way, letting the operators "fly" around and get an intuition for what things are like. Coupled with sound it could get fairly immersive.
I wish there was DOS EMULATOR type of framework that renders to the web
The latest talk python to me podcast has an episode on Textual and Rich that looks interesting.
https://github.com/willmcgugan/textual
Microsoft Defender is really bad at false positives. I think especially the "!ml" ones – I believe that means it is using heuristics rather than a direct signature match.
I have my own parental control software I wrote. (Maybe one of these days I will open source it, but not in its current state.) I wanted to use text-to-speech to send audio messages to our son ("Your time is up in five minutes!" kind of thing). Windows has a bunch of different APIs for this – there is an older COM API (which supports IDispatch so you can use it from VBScript etc), a newer .Net API, an even newer WinRT one. I decided, for my purposes, the easiest thing to do was just call the .Net API from PowerShell. So, I embedded a PowerShell script in my executable.
All works – except suddenly Microsoft Defender says it is a Trojan. (Forget which one, it was one of those !ml ones, so it could have even been the same one.) Only when it sees the embedded Powershell script in the executable, took it out and it doesn't.
I found a trick – I gzipped the PowerShell script, and embedded the gzipped PowerShell script in the executable instead. I included in the executable a zlib decompressor library so it could decompress it at runtime. Suddenly, no more false positive, Defender thinks my executable is fine.
I also found it gets upset if a Windows service runs PowerShell as a subprocess with certain command line arguments (passing the PowerShell code to run on the command line)–it will block the PowerShell subprocess from starting. Again, various tricks – such as Base64-ing the code to be run, and having PowerShell decode it and then evaluate it dynamically – and it no longer complains. I suppose other approaches, such as putting the code to run in a temporary file, or passing it to PowerShell over a named pipe, might also do the trick.
Makes me think the whole thing is pretty stupid – if I can use these simple tricks to get around their false positives, why can't malware authors use the same tricks to turn true positives into false negatives?
I can't speak to every situation, but all computer/video game/whatever time limits did for me was make me resent my parents and do nothing with the remaining time out of spite. I don't think I'd ever do it to my own kids.
Our son is 8. If we let him, he would stay up until 1am using the computer. We've tried other approaches, such as reasoning with him, or positive reinforcement, but this is the only thing that has worked.
I have been using Linux my whole life. Some years ago I tried distributing some of my tools to windows users. The main feedback I got was hate because I appearantly packaged a virus. It worked on my VMs but not on some others. Most tools have been packaged ruby interpreters with attached scripts. Nothing to weird either.
I have not tried releasing anything for Windows ever again.
About 20 years ago I remember it was semi-common for binaries compiled with anything other than MSVC to be flagged as false positives by other AVs (I suspect if MS had its own AV at the time, it would definitely raise antitrust allegations...) Lots of beginners using GCC (MinGW and the like) complained why their freshly-compiled Hello World executable would disappear without doing anything as soon as they ran it.
Installing Linux and seeing if it even starts is already a lot of effort, and then you've only "seen if it starts" and are very far from anything considered "tested".
Eh. Sure it's takes a bit of effort but installing a Linux distro in a virtual machine and pulling and compiling some C code isn't exactly a massive project. It would have been a much bigger deal before the widespread use of virtual machines. Or, I guess, if you don't have experience with building things on Linux.
I completely understand that if someone doesn't use a platform themselves, there might be little motivation to test things on it. No hard feelings if someone doesn't care to do that. But it's not that much effort.
https://img.itch.zone/aW1hZ2UvMTIyODU3OC83MTY0MTEyLnBuZw==/o...
They have such a cozy feel, reminds me of simpler times.
It would be cool if there were a CSS framework where you could make webpages like that.