One Dog vs. the Windows 3.1 Graphics Stack
wuffs.org
wuffs.org
(the dead xfree86 project was probably the closest attempt to making this "just work" though it had a long way to go; this approach was not preserved in the Xorg fork)
Most of the times. On my new Ryzen, it didn't.
And Wayland requires a GPU as far as I know, since the entire protocol is based on passing GPU memory buffers around and compositing then. Deleting the backwards compatibility for software rendering was half the point of creating Wayland.
But you can also just encode the result of your composition to a h264 stream and send that over the network if you so desire. no GPU required in this case.
> The simplest means of getting pixels from client to compositor, and the only one enshrined in wayland.xml, is wl_shm — shared memory. Simply put, it allows you to transfer a file descriptor for the compositor to mmap with MAP_SHARED, then share pixel buffers out of this pool. Add some simple synchronization primitives to keep everyone from fighting over each buffer, and you have a workable — and portable — solution.
https://wayland-book.com/surfaces/shared-memory.html
> [weston] Available back-ends:
> drm – run stand-alone on DRM/KMS and evdev (recommend) (DRM kernel doc)
> wayland – run as a Wayland application, nested in another Wayland compositor instance
> x11 – run as a x11 application, nested in a X11 display server instance
> rdp – run as an RDP server without local input or output
> headless – run without input or output, useful for test suite
> pipewire – run without input, output into a PipeWire node
https://wayland.pages.freedesktop.org/weston/toc/running-wes...
I think some/most distributions might not enable it out of the box because it would generally result in a low performance/quality experience and the user not realizing what the problem is, and nowadays almost all GPUs are supported natively, so nobody has invested in writing code to show a "Using unaccelerated VGA/VESA, you may want to fix this" popup.
But note that this is actually easier for 16 or 32 bit operating systems! Setting VESA modes involves making a real mode 16 bit call (there's nominally a 32 bit entry point for VESA but it was specced late in the standard's life and basically nobody implements a working version), and once you're running in 64-bit mode you've lost the ability to do vm86 so calling 16 bit code from userland becomes impossible. This is why x86emu is required (basically we read the video BIOS code and then run it under an x86 emulator), and it's not always perfect.
I agree it was an engineering marvel, IMO only less impressive than the CPU implemented in JPEG instructions for Pegasus.
And then PCI became ubiquitous and it was much cheaper to plug a PC card into a machine than buy an overpriced one from Sun or DEC or whatever, and people were starting to run Linux or *BSD instead of the vendor OS, and suddenly there was an incentive to be able to run graphics card x86 init code even on other CPU architectures.
I ended up stealing the concept and the code to make Ubuntu's usplash boot splash app work on 64-bit, which is an entirely different story.
It didn’t. The X Windows system (https://en.wikipedia.org/wiki/X_Window_System) started at MIT and is from 1984, PowerPC (https://en.wikipedia.org/wiki/PowerPC) from 1992.
I hadn't thought of 1bpp because it isn't interesting on VGA hardware. But you're absolutely right about 4bpp having been a thing.
Bootable Linux distributions I use at work (GRML and Clonezilla mainly) automatically resize to the native resolution of the screen or virtual KVM during boot with KMS support, and they work really well. Anaconda (RedHat and derivatives' installer) and Debian's installer also scales to native resolution on boot.
GUI installers use VESA over X11 directly.
> xfree86 project was probably the closest attempt to making this "just work"...
XOrg fork has "configless boot" for a long time. I don't maintain a config file for a very long time now, and I'm happier than ever (see https://www.xkcd.com/963/).
https://wuffs.org/user/pages/02.blog/windows-3x-graphics/640...
What would Win11 even look like on a lower-resolution display such as in TFA?
The Win11 Start Menu is borderline unusable beyond typing in a keyword and praying to the circuits. What happened?
Naive hypothesis: Windows NT and 2k hit a sweet spot, then product managers have been working their magic ever since.
KDE and Gnome are looking more and more appealing over time, despite not changing much. :)
Windows Forms got a lot right: I think the one missing symbol was "active but not editable".
Even on desktops that don't have batteries.
As it is you can set a text box read only but active, but it does waste time since it doesn't code that it's not interactable visually (i.e. you have to make up a scheme).
Basically it would've been nice to have a consistent background color or other visual cue which says "this will update, this is live, but you can't type here".
Windows 8 broke everything and Windows never recovered. I blame it on two reason: the rise of mobile platforms, and laziness from Microsoft.
For the first point, we have now what seems like an unsolvable problem. Many apps now come with a desktop version and a mobile version. Completely different user experience. One has a large screen, a keyboard and mouse. The other has a small touchscreen. A good desktop app would be completely different from a good mobile app. However, you don't want that either, as you want your users familiar with one version to feel at ease with the other. It means that even when you do your best, there are compromises.
But Microsoft probably could have done a decent work, but they didn't. They just become lazy. It is evident by looking at the control panel. The new control panel (settings) dates back from Windows 8, 12 years ago, and they still didn't port all the features from the old one to the new one, so you need both. They intended for a complete switch a few months ago, they weren't ready, will they ever be? In addition they regularly remove popular customization options, the style is inconsistent between the bundled apps, etc... This is not just controversial, it is objectively bad.
Another factor, but Microsoft and Windows are not to blame here is that app developers prioritize branding and internal consistency over OS integration. Many modern UIs are just a web page rendered with a browser engine (ex: Electron). They are not using native OS controls, ignore theming, draw their own Windows decorations, etc... Maybe the OS is inconsistent, but app developers don't help.
Notably, the way Steam implements its tenfoot experience is an entirely separate UI instead of a single jack-of-all-trades UI. I've never used it since I don't have that type of setup so I can't say how well it works for people accustomed to the desktop UI.
It does seem that as annoying as it might be to get used to a new UI for mobile and desktop, using the same UI for both is even worse.
Again we see this theme, as in other parts of software engineering, that people try to hard to invent abstractions instead of just grinding out the work (a separate design for each platform).
The Steam Deck UI has also solved a problem that Microsoft appears entirely unable to address: mixed input modes. The entire UI can be accessed through the touch screen or the physical controls. Microsoft has been failing horribly at this since Win8, and apparently operate under the impression that every user has a 40" touch screen on their desktop computer and doesn't know what a mouse is.
Good UI is achievable if your goal is to make useful software. That simply isn't what Microsoft's goal is anymore. They're just broadcom now: completely abandoned the product to focus on squeezing the users for everything they're worth.
They have a large amount of potential resources to throw at any problem they like, they could have done a v1.0 for win8 that provided a complete set of equivalents in the new style when they judged the OS was ready to release. Then iterate from that v1.0 in later releases as they have with other aspects of the OS, if anything MS seem to keep parts more fluid than long term stable now and aren't afraid to make major changes in service packs, win10 reaching EOL is quite different to the initial release and similar for win11.
I can appreciate the UI being 'uneven' in a project with loose coordination as you find in a lot of linux distros, but for windows it could be better than it is like an orchestra playing together
I do agree however - a beta for Win10 was a hybrid of tiles mixed with a Windows 7 list that throws back to Windows 2000 and I set that as my peak - you could have the best of both. The notifications area has always been weak and the settings panel is crap compared to the control panel (though debatable if control panel ever was the best we could have since it's somewhat cluttered and complex)
Instead they have been bringing UWP infrastructure into Win32 execution environment, but hardly anyone cares nowadays, unless there is no way to reach the same functionality with classical Win32/COM APIs.
However due to security issues like last year Crowdstrike, Win32 sandboxing is pretty much part of Windows roadmap.
This is a common problem that authors of Windows 3.x/9x display drivers had to handle, although the specific I/O port numbers to be virtualized vary by graphics adapter. There are samples in the Win95 DDK that show how to use the VMM services Install_IO_Handler and Enable/Disable_Global_Trapping to set up I/O port traps, and VDD_Get_VM_Info from within the trap handler to determine the VM that currently owns the CRTC. This allows the trap handler to reach a decision about whether to allow an I/O to reach the hardware, or to virtualize the access in some way. A good virtualization policy to start with is probably just to drop any writes from non-CRTC-owner VMs. Any additional needed complexity can be added from there.
It's interesting to see others (re)discover this architecture, which IMHO was quite ahead of its time, since it predates modern hypervisors with hardware pass-through. The Windows 3.x GUI itself, including its preemptively-multitasked processes, effectively runs as an extended (protected-mode) DOS process inside a VM running DOS, and the hypervisor kernel, VMM32, is what multiplexes between it and other VMs running DOS processes. Thus one part of the display driver sits under GDI and interacts with the "hardware", while the other part in ring 0 virtualises the hardware and multiplexes it with the other VMs.
This would fix it for DOSBox, but that fix would be tied to whichever video adapter it's emulating. I don't want that, I'm trying to make the generic VBE patch work better!
Having written a Win9x VESA framebuffer driver for the Intel GMA950 as well, and added basic acceleration (blitter and fill commands), and encountering basically the same issue, I realised what may be the reason Win9x never came with a generic VESA driver: the VDD needs to know how to save and restore the GPU state, the details of which are obviously vendor-dependent. I did come up with some ideas on how that could be done generically, i.e. emulate/trace the VBIOS and see which ports/MMIOs it touches on each mode switch, but never got around to implementing it.
While on DOSBox I get text mode with lots of corrupted characters, on the Eee PC I get a broken version of the GUI where some of the colours have disappeared.
That looks like the palette registers didn't get saved and restored correctly. Also, the corruption at the top of the screen can be avoided by moving the high-res display plane up by 256K, so as to leave the first 256K of VRAM for the VGA plane and VGA emulation. Fortunately the Intel GMA has a bunch of publicly available documentation (although not for the 900 nor 950, and only for the 810/815 and 965+ but the majority of the registers and commands have not changed) you can refer to for the details.
My Eee is successfully chugging along with 32bit Debian. Firefox is too heavyweight to do much but lag, but mpv works well enough to stream video. But I mostly use it when I'm running behind on a book and basically need a typewriter that can run pandoc, and fewer distractions.
I loved my EEE, super portable, but the keyboard is too small for serious typing IMO.
Everything still works great, except the original monitor died many years ago. I hope to replace it one day, but $200 for a used 12" monitor is more than I want to spend right now (I have a tractor I am restoring that takes precedence).
That was the computer I had between ages 9 and 14. I wish I had one now.
The second worst error was also getting rid of my Asus EEE also featured in the OP.
Why do you say that? They are great machines (mine has lasted forever) but finding parts was hard even when they were new due to the microchannel architecture.
But as I have an existing install... It should just keep grinding on for a bit longer yet.
[0] https://lists.debian.org/debian-devel-announce/2023/12/msg00...
I tried it on my PC. There is obviously not enough available software to be a real daily driver but it struck me as an OS that would be very enjoyable with low connectivity needs like typewriter and mail.
I loved how coherent it felt : the UI, the base software and even the filesystem. If I understood correctly, the filesystem is a representation of all your data and « files » can have arbitrary metadata and you can do pretty much everything from the file manager. It’s like your whole filesystem is a nosql database and apps are ok with that. Your contacts are « files » in a folder, your mails are « files » in a folder etc …
I never touched BeOS back in the day and I can totally see how this paradigm could have worked well in the 90s with low connectivity. Being able to write a mail « file » without internet, drag and dropping it onto a floppy drive and then on another computer, sending it over the Internet and everything with the file manager. It felt amazingly coherent.
Unfortunately this paradigm ceases to be useful when you need interoperability with other computers that aren’t compatible with BeOS/Haiku filesystem which means statistically _any_ computer.
But on your typewriter machine, that could be interesting.
I use it with a lot of modern things, actually. And across the 'net.
My books are built with a pandoc/lua scripting system, and not an ancient version. I use the latest features. I also synchronise the sources via git, and the built bundles via an SSH pipeline to my beta readers.
I also already mentioned mpv - I use it to stream music, because I tend to listen whilst writing. Often the one song on repeat for three hours, but I do.
It seems the tablets have wiped out the netboooks market segment.
While they still exist as ultraportables and 2-1, that is the other side of price segment.
There's nothing in the rules that says a dog can't use Ghidra.
(Do other kink subcultures do this stuff??)
See also, VTubers, manga artists (who often represent themselves as characters), and our tendency to anthropomorphize computers (“it’s gotta think”)
Edit: I might have read that wrong, but I'm interested in specific recommendations nonetheless.
https://youtube.com/playlist?list=PLEMXAbCVnmY6zCgpCFlgggRkr...
See also this video of his: “Clean” Code, Horrible Performance
Abstractions aren't the problem, rather how they are used nowadays, by plenty of folks that only went through JavaScript bootcamps.
To note they aren't at fault, rather those that teach on those factories.
Best support I've ever had for a pirated product.
MS claims that the driver that supported HiDAC came out the 3rd week of April 1992, which would have been 1-2 weeks after the time period I'm remembering, so it sounds about right.
Functional GUI: M_LIN8 G800x600 > 800x600 @00000+100+Dch4
Functional DOS: M_TEXT T80x25 > 720x400 @00000+050-W
Broken GUI: M_VGA G400x600 > 400x600 @00000+200-Dch4
Broken DOS: M_TEXT T80x25 > 720x400 @00000+250-W
- Broken DOS and Broken GUI are 200 or 250, functional are 100 or 050. What's that address?
- Broken GUI is somehow in M_VGA mode instead of LIN8. How and why did it get like that, and is that related to why it somehow got into 400x600, horizontally half of 800x600 (??). (True "textmode" is actually 720x400, as seen in both DOS modes.)