Bootloader developers used to be particularly fond of Forth.
For example, for many years the FreeBSD's 3rd-stage loader used FICL (Forth Inspired Command Language) for scripting [1]. It's still supported, although in the recent years it was deprecated in favor of Lua [2].
This was also my first thought, but looks like it's already designed to be toolkit-agnostic, like NetSurf. So it should be easy to port to fltk or anything else.
$ ls -1 fixgui_\*.c
fixgui_cocoa.c
fixgui_gtk.c
fixgui_haiku.c
fixgui_win32.c
> NetBSD might have some "bloatware" but _the user must enable it_ first
> Everything is off by default. That is one of the things that makes NetBSD great IMHO
I mean, it gets pretty close to that, and I don't even mind syslogd and powerd, but I'm confused why they enable stuff like postfix, inetd and makemandb without asking. Especially makemandb is pretty intensive on slow machines.
> "I was able to fix it by adding usermod disable wss to the bootloader line."
Ah, sysinst. I do not use it. This explains the enabling of programs in the configuration. Apologies I should have guessed that's where these settings were coming from.
I usually installboot and disklabel manually, download and extract sets manually, use makefs or mdsetimage and vnconfig to create/edit images.
On the other hand, note it only shows 133MB of total mem, rather than 160MB that is installed. I believe the missing 27MB is used by the kernel (the kernel file itself is 23MB) and its data structures.
That being said, I suspect 64MB could be enough for console-mode work, and if you recompiled the kernel without any unused drivers, perhaps you could make it under 32MB.
To be honest, I wouldn't notice this issue at all, if it wasn't for FreeBSD which refused to boot right off the bat. It has a more advanced bootloader though, so perhaps it does some extra sanity checks.
Actually one of the reasons for writing the app was to reduce my compulsive browsing of social media. A feature like this would go in the opposite direction :) But if you really want it, feel free to tinker with the code, it should be pretty straightforward.
To be precise, it only assumed 80x25 terminals with 16 colors, which I think fits into some definitions of retro, but I see your point :)
I've just added support for ascii & monochrome modes, and reduced the required screen size to 80x12, which I think is a reasonable minimum for readability.
Would you mind sharing what kind of hardware did you try it on?
You're almost there. But 80x12 is still a bit big for truly retro hardware.
Remember that 80 column screens were not the majority of computers in what we now consider the retro age. 40, 36, and even 32 columns screens were common.
Also, terminals would often have status bars, reducing the amount of vertical real estate. 12 sounds small, but with status indicators active, you're looking at 10 or even 8 usable lines.
What commonly used UNIX terminals had less than 80 columns? VT100 had 80 columns, IBM PCs had 80 columns. I remember some 8 bit computers having text modes where you could choose to display less columns in return for getting more colors, but those computers never ran UNIX and getting on usenet was surely a pipe dream.
I agree, any terminal I ever used to access a shared unix host had 80 columns. Typically a VT100 or ADM-3a or something like that.
TRS-80, TI-99, Commodore, Apple etc. home computers had 32, 40, maybe 64 columns and you could get terminal emulator programs for them but most people would use them for CompuServ or America Online, or maybe BBS logins. I think I tried using my TI-99 terminal emulator with a unix host and it wasn't very successful. The host had no idea what my terminal was and operated in a very limited "dumb tty" mode.
Eh, to do it properly, 40 cols and less would require adjusting the whole layout and I just want to keep the code simple.
I'm also not sure if the code would be fast enough to run on so old machines, I mean it's Python and not optimized at all.
But feel free to fork and tinker if you're interested, at this point it's not really far off.
For example, for many years the FreeBSD's 3rd-stage loader used FICL (Forth Inspired Command Language) for scripting [1]. It's still supported, although in the recent years it was deprecated in favor of Lua [2].
[1] https://github.com/freebsd/freebsd-src/tree/main/stand/forth
[2] https://github.com/freebsd/freebsd-src/tree/main/stand/lua