I've been working on a simple OS for tinkering and running bare metal apps on vintage PCs.
Since I couldn't quite decide whether to target pure 16-bit, or slightly more capable 32-bit machines, I ended up with two separate versions:
- GentleOS/32 (https://github.com/luke8086/gentleos32) works on i386+, requires 4MB of RAM and VGA display supporting 640x480x16 mode or any 256-color VESA mode.
- GentleOS/16 (https://github.com/luke8086/gentleos) works on 80186+, requires less than 192KB of RAM and a CGA display supporting 320x200x4 mode.
You can find more details in the repos.
Seeing the screenshots I was kind of expecting this was a pre-emptive multi-tasking OS (forgetting what I read in the submission).
Things that thus surprised me on a cursory look:
- noticed krn_main() ends with `while (1);` [1]. I would've expected a "schedule" call or something. I assume there's no real busy loop burning CPU, maybe it's never meant to reach this code?
- I'm reminded of the "bare metal OS" when I see one of the apps call `krn_\*` functions directly [2].
[2]: https://github.com/luke8086/gentleos32/blob/ea691f14635c023d...
I had 2 different Librex 386SX laptops, with 4MB of RAM, on long-term loan from work around 1992. One was quite chunky, the 2nd was a slimline thing with an off-centre hinge.
I ran OS/2 2.0 on them both.
So I could run multiple DOS apps, and a WinOS2 VM containing Windows 3.0, meaning I could run Win16 apps as well. And native OS/2 apps, although I didn't have many.
Here's a pic of the original Librex:
https://books.google.im/books?id=tDwEAAAAMBAJ&pg=PA27&redir_...
And the 2nd model:
https://www.reddit.com/r/vintagecomputing/comments/10gepdd/l...
TL;DR
A 386 with 4MB is small now but at the time this was a fairly serious workstation-level PC. At the time my work desktop was a 386DX but it had only 1MB of RAM.
In its time a 4MB 386 could run any one of multiple multitasking 32-bit protected-mode OSes, including OS/2 2.x, SCO Xenix, Coherent 3 or 4, DR Concurrent DOS/386, and so on.
This was a high-end bit of kit and with one of these OSes, or even with Quarterdeck DESQview, it could multitask half a dozen large and demanding DOS apps, or maybe a couple of the still fairly new Windows apps such as WinWord 1, or Excel 2.
Its wild to me to think of how much old computers could do relative to new. WordPerfect for DOS was always responsive and quick wheb I used it. I've seen ms word cludge up machines that should have plenty of power to run a word processor.
OMG yes please. :-)
Yep, WP for DOS was quick. Rather clunky UI compared to MS Word for DOS, IMHO, but fast. A friend of mine used a simple method to demo its speed: on his cheap monochrome 286 home computer, he loaded the book he was working on -- one big file, a few hundred pages -- and just held down the cursor key to scroll through the whole thing. It kept the entire doc in RAM and the text just blurred as it zoomed through the entire book in under a minute.
Compared then (early 1990s) to Windows where a similar text took tens of minutes, as my faster computer struggled to load in pages of text from disk, render the fonts, etc.
In the late 1980s, Amstrad introduced new CP/M machines, the PCW range:
https://www.cpcwiki.eu/index.php/PCW
They sold for over a decade and shifted about 8 million units. A CP/M computer, in the early Windows era.
Maybe it's time to do that again: a very low-spec machine, but with a crisp e-ink screen and a great premium-grade mechanical keyboard, shipping with a modern FOSS DOS, a compilation of free DOS apps, and some nice friendly graphical launcher. Wrapped up as an easy appliance that doesn't do Internet stuff at all, but makes it trivially easy to save your work on USB media or zap it to modern devices wirelessly.
Form factor of a big late-20th-century laptop, with a massive battery so it can double as a power bank for your phone or something.
I attached a couple of big SCSI drives and ran Windows NT 3.51 Server on it. When not logged in, it only used a couple of megs of RAM for the OS so file serving performance was tolerable -- and the hardware was literally bulletproof. I dropped one down a flight of stairs in my first job. The computer survived but it knocked lumps out of the concrete stairs on the way down.
You may get some interest from others in the retrocomputing/permacomputing sphere if you implement an Uxn emulator; it is extremely simple and can run on very limited hardware. https://100r.co/site/uxn.html
Vintage hardware would be a great host for Uxn programs, so I suspect this would generate some excitement.
Now I feel like integrating that into various things....
Also, there's an emulator for PS/1 machines at https://www.ibmulator.org/
Unusuable because of how small the keys are
example how one looks like irl https://allegrolokalnie.pl/oferta/laptop-toshiba-t1800 https://www.youtube.com/watch?v=sxIc_UVKxvc
- Letting it warm for a while
- Putting windows in the right places, because each one generates its own artifacts
- Setting background to dark with the white pattern
- Fiddling with the contrast knob and matching it with the right viewing angle
- Using 2x zoom
To be fair, the default photo app of iPhone 16 automatically reduced some of the artifacts. The only post-processing done myself in GIMP was very basic stuff like adjusting white balance, exposure and contrast.
Here you can see a few very quick-n-dirty photos I just took for comparison - https://imgur.com/a/6Xz6vc8
Btw. the QEMU screenshots are still in the repo in https://github.com/luke8086/gentleos32/tree/main/doc/appimg
Will be digging out some old hardware to test it out very soon, this is exciting!
Computer programs are tools. It doesnt do anyone any good if they're unusable in the name of chasing moronic trends.
Old interfaces were far more practical for getting work done, and therefore obviously boring.
For me, as someone who is supposed to use technology as a tool and not as a source of amusement, the new interfaces of the major OSes feel unacceptable. But the other billion people chatting and scrolling are the real consumers, not me — and as a result, we now have the interfaces we have.
All that said, I truly miss the days when we had interface skinning. There was a skin for OS X called UNO that was absolute perfection in my eyes, and it was ported to an old version of Android back when skinning was a thing. There's nothing like it available now. Even GNOME is highly against theming and skinning now, apparently because they like breaking with every single release rather than maintaining an API/ABI and skinning support. The themes that were available for Windows XP were so much fun, even if you had to swap out DLLs to get them working.
Focus-group based and UX research was a lot more intense in the 1990s compared to today, and late 1990s UIs are still among the best available.
Material is what made me hate google. It makes everything so difficult. It doesnt even look good. It's a low contrast sea of modern bullshit.
I sincerely hope that the material designers go to hell when they die and are forced to use their own garbage designs for all eternity while those of us who dont suck can use properly designed software.
I am all in favour of great projects, but why a differentiation between 32-bits or 64-bits? I don't understand that. Is a computer that is 32 bit or 64 bit, either way which, not worthy?
Edit: I understand a motivation if it is on simplicity choosing one or the other, but other than that I don't see why that should ever be a goal worthy to be pursued. Software should really "just work" no matter the number of bits and bytes.
It only won't work on modern pure-UEFI systems because that would require writing full stack of USB drivers for keyboard and mouse, and that would be a huge task.
> Edit: I understand a motivation if it is on simplicity choosing one or the other, but other than that I don't see why that should ever be a goal worthy to be pursued. Software should really "just work" no matter the number of bits and bytes.
Not really how software works.
Just sold my SGI Indigo 2 for 900 $ ! Vintage 64 bit is absolutely a thing. :-)
The last step (32-bit to 64-bit) can a bit of a can of worms especially on older platforms where 64-bit implementations can differ greatly and 32-bit "just works tm". 32-bit is quite well supported and has enough resources to make some interesting programs work without much hassle.
I think the author has made the decision not to support 64-bit mode due to needing to balance the complexity and usability of the project. It is a hobby project after all.
Since the author maintains a 16-bit and 32-bit for this project I suppose if you wanted you can always fork and maintain a 64-bit version if you wanted to.
Perfect. Nice to see a platform target stability instead of constantly reinventing itself and its APIs. Definitely want to give it a go!