[HN Gopher] One Dog vs. the Windows 3.1 Graphics Stack
___________________________________________________________________
One Dog vs. the Windows 3.1 Graphics Stack
Author : todsacerdoti
Score : 138 points
Date : 2025-01-04 11:10 UTC (11 hours ago)
(HTM) web link (wuffs.org)
(TXT) w3m dump (wuffs.org)
| drooopy wrote:
| That title was... slightly confusing. That said, I will always
| feel a sense of awe when I read about how those old, DOS-based
| versions of Windows worked behind the scenes. Everything is held
| together by software duct tape, yet somehow it works.
| jsheard wrote:
| > That title was... slightly confusing.
|
| There's nothing in the rules that says a dog can't use Ghidra.
| geon wrote:
| Finally an Air Bud movie I'd watch.
| rezmason wrote:
| "Hey look! It didn't crash!" "I guess Toonces _can_ write a
| driver! " "Yeah! Just not very well!"
|
| https://www.youtube.com/watch?v=5fvsItXYgzk
| donatj wrote:
| I was expecting something about the dog from Microsoft Bob,
| like a war story from an MS veteran about making the characters
| work on Windows 3.1
| KMnO4 wrote:
| Alright; I'll bite. Where's the dog? I'm still confused.
| amenhotep wrote:
| The author is a furry, and the dog being referred to is
| himself
|
| (Do other kink subcultures do this stuff??)
| Kye wrote:
| It's not a kink subculture. There are kink subcultures
| within it, but the only common factor among all the
| subcultures inside it is an appreciation for
| anthropomorphism.
| qdot76367 wrote:
| Hi fox.
| wolfgang42 wrote:
| Furries do tend to be more open about kink (as part of the
| community's general culture of acceptance), but to describe
| furry as a "kink subculture" is misleadingly reductive at
| best.
| vzqx wrote:
| The author has a fursona, so I think the author himself is
| the dog.
| Kye wrote:
| Famed for the "when you like my post, it's like you're
| putting a treat in my mouth" tweet and pictures of lonely
| abandoned objects.
| cmgbhm wrote:
| It's the author.
| immibis wrote:
| Go listen to Casey Muratori talk. We've created a giant pile of
| abstractions but we don't actually need them and all they is
| make performance worse.
| bmicraft wrote:
| Now I'm interested, which talk do you mean?
|
| Edit: I might have read that wrong, but I'm interested in
| specific recommendations nonetheless.
| ComputerGuru wrote:
| SVGA support aside, it will never cease to astound me that you
| can load Windows 3.x on a modern standards-supporting PC _and get
| basic VGA working out-of-the-box_ but you cannot do the same on
| modern Linux /BSD to get a basic software-accelerated VGA
| framebuffer supported by Xorg/Wayland if you don't have the right
| drivers installed (and the correct configuration files manually
| set up).
|
| (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)
| kevin_thibedeau wrote:
| Xorg is Xfree86 with a cleaned up build system.
| immibis wrote:
| Xorg is a fork of XFree86 with many, many changes. Some
| XFree86 code is retained as one possible backend.
| asveikau wrote:
| One of the most user visible things they did, though, was
| make it work better if you didn't have a config file.
| immibis wrote:
| It's specialization. Windows 3.x runs with a GUI on an IBM PC.
| XFree86-era Linux runs with any UI on an IBM PC. Xorg-era Linux
| runs with any UI on any computer. Therefore you have to specify
| what kind of configuration you require, and don't get it out of
| the box. But note that every distribution that runs on IBM PCs
| with a VGA GUI does come with that configuration out of the
| box, because they are re-specialized for that system.
|
| 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.
| heeen2 wrote:
| Wayland does not require a GPU and the baseline protocol is
| just shared memory buffers. The protocol requires file
| descriptor for said buffers and getting gpu drivers to
| support mapping gpu memory to file descriptors is what
| allowed Wayland to become efficient through zero copy and
| just passing handles from clients to compositors
| devit wrote:
| Linux supports vgafb/vesafb so this is possible if the
| distribution is configured appropriately.
|
| 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.
| mjg59 wrote:
| Xfree86 never did anything different to Xorg here. If you boot
| via CSM on a modern PC (which is really not something you
| should do, but, well) you should get Xorg running with the VBE
| backend using x86emu to execute the video BIOS, and if you boot
| via EFI you should get modesetting running on top of efifb
| using whatever mode your firmware and bootloader left you in.
|
| 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.
| int_19h wrote:
| It's been a very long time, but I recall X having a generic VGA
| driver that "just worked". Are you saying that's not there
| anymore?
| marcodiego wrote:
| Not only that, I remember X.org source tree had a bult-in x86
| emulator so VGA bios of some PCI video cards could be run on
| Solaris.
| mjg59 wrote:
| Technically not related to Solaris, since Solaris x86
| existed and you wouldn't need it there, but yes, this was
| used on Sparc and any other CPU unable to run the card BIOS
| (including 64-bit x86 Linux, since virtual 8086 mode goes
| away when you're on long mode)
| ok123456 wrote:
| I remember the "generic" VGA driver having horrible default
| settings that resulted in 300x200 at 16 colors.
| kijiki wrote:
| 320x200 at 256 colors. X doesn't support any depth lower
| than 8bit, so VGA 640x480 wouldn't work.
| Zardoz84 wrote:
| I remember that Xfree86 allowed 1 bit (B&W) modes
| mjg59 wrote:
| X does, modern X apps may not.
| bayindirh wrote:
| X11 has a "VESA" driver since forever, however its performance
| scales badly since number of pixels to process grows rapidly
| with the resolution.
|
| 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/).
| shakna wrote:
| > it can't even run most up-to-date Linux distros due to its lack
| of x86_64 support
|
| 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.
| cout wrote:
| I totally agree on having a computer with minimum distractions
| when writing -- for that I use a PS/2 386SX running WordPerfect
| 5.1.
|
| I loved my EEE, super portable, but the keyboard is too small
| for serious typing IMO.
| duneisagoodbook wrote:
| was that a machine you had lying around, or did you seek it
| out?
| pavlov wrote:
| Is that a PS/2 55SX?
|
| That was the computer I had between ages 9 and 14. I wish I
| had one now.
| cout wrote:
| No, it's a PS/2 50Z, which comes with a 10MHz 286. It was
| my first computer, second hand from my dad. When I got it,
| I saved up and bought the 386SX/Now!, a 25Mhz 386SX that
| fits into a 286 slot.
| Narishma wrote:
| Debian is removing support for 32-bit x86 in the next release I
| think.
| 101008 wrote:
| Unrelated to the actual article, but so refreshing seeing a
| website with a design/structure that reminded me of the best
| years of internet. How I miss left sidebars, tables and more!
| zerkten wrote:
| I appreciated this too. First time I've seen a dark/light
| selector on the right side which also highlighted how you can
| blend old and new very effectively.
| a1o wrote:
| That is fun, I have an EEEPC 207g, those smaller ones. It still
| works, but I never thought about retro gaming with it - mine is
| just "collecting dust", it would be fun to try these things on
| it!
| nosrepa wrote:
| You mean the 701? 207g isn't a model of eeepc.
| copper_think wrote:
| The author mentions the screen being corrupted when a DOS prompt
| is opened in windowed mode. This can happen because the DOS
| prompt runs in a separate VM (in V86 mode), and makes calls into
| the VGA ROM BIOS via INT 10h. The VGA ROM BIOS on this machine is
| probably a wrapper over VBE; that is, it probably contains IN and
| OUT instructions that talk to the VBE I/O ports, 0x1CE and 0x1CF.
| These reads and writes from the DOS VM will, by default, be
| allowed to reach the physical hardware if they are not
| virtualized by the VMM.
|
| 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.
___________________________________________________________________
(page generated 2025-01-04 23:00 UTC)