[HN Gopher] Win16 Retro Development
___________________________________________________________________
Win16 Retro Development
Author : naetius
Score : 93 points
Date : 2022-12-24 18:37 UTC (4 hours ago)
(HTM) web link (www.os2museum.com)
(TXT) w3m dump (www.os2museum.com)
| ComputerGuru wrote:
| Nice read. I wouldn't have minded more technical details about
| the implementation and challenges, but that's probably because
| I've had to write generic SVGA drivers to support generic
| graphics cards before. (I'm not clear on what was the more
| convenient alternative to VMs that the author ended up using,
| though?)
|
| Side-bar but still on-topic: It _really_ irks me to no end that
| Windows 3.x and Windows 95 could get a fairly hardware-agnostic
| (fallback) software-rendered GUI fully up and running and exposed
| to user space in the early 90s and even today Linux /BSD can't
| manage that (even just in SVGA mode) without vendor specific
| drivers. Xfree86 and then Xorg with the fb driver were attempts
| at doing the same but I can attest they never achieved that same
| universality. I had hoped EFI fb could finally give us the same
| for modern PCs but the chances of open source efifb drivers _in
| userland_ working on a chipset /implementation they haven't been
| tested against are a real crapshoot.
|
| I had "success" (compared to the status quo, not compared to the
| situation on Windows) writing X drivers that wrote to the kernel
| framebuffer but that broke when everything was rewritten or
| deprecated in order to support EFI. Even then, the support for
| listing supported modes and changing to them was very poor (which
| make sense given how little serious use the kernel frame buffer
| sees), never mind figuring out what modes intersected with those
| the display supported. Laptops with integrated plus discrete
| graphics cards (or desktop motherboards with the same) were also
| problematic for various reasons.
| fredoralive wrote:
| Wasn't Windows back then dependent on vendor supplied device
| specific display drivers for anything above basic VGA? There
| wasn't a real standard for "SVGA", and the VBE stuff wasn't
| that well supported early on?
|
| The Windows fallback until circa Windows XP was good old
| 640x480x16.
| tomcam wrote:
| > Wasn't Windows back then dependent on vendor supplied
| device specific display drivers for anything above basic VGA?
|
| In theory, yes, but the reality was starkly different as I
| recall (I worked there in the late 90s). In my experience,
| Microsoft was doing a ton of heavy lifting helping vendors
| with device drivers.
| mjg59 wrote:
| Historically you wanted the -vesa Xorg driver, today
| -modesetting should work fine on the firmware-provided
| framebuffer using simpledrm. But the EFI spec provides no way
| to change screenmode at runtime, so you're going to need a
| native driver for that under all circumstances.
| ComputerGuru wrote:
| IIRC in real-world testing on actual consumer hardware in the
| field (sample size in the hundreds of thousands), we found
| fbdev was better supported than vesa (with more restrictions,
| of course).
|
| Inability to change EFI resolution is OK except with high-res
| (4k) discrete GPUs running without scaling. But that's ok
| because you can do fake DPI scaling in software - the actual
| tissue is performance at 4k sucks if not hardware
| accelerated.
|
| Bigger problem today is that EFI fb support is still in its
| nascence both manufacturer- and software-side. Manufacturers
| ship crap that's not up to spec while some EFI FB handlers
| are too strict in what they expect or haven't added quirks
| for some of the very common hardware you might run across.
| mjg59 wrote:
| fbdev would only work on BIOS systems if you were using
| vesafb or had a hardware-specific framebuffer driver
| loaded. Vesafb would tend to cause problems with
| suspend/resume and needed to be configured with bootloader
| arguments (the kernel had no support for transitioning to
| real mode and the protected mode entry point for VBE
| basically never worked, so either the bootloader or the
| 16-bit kernel entry code needed to be used to do the mode
| setting). The -vesa ddx either ran in vm86 mode or used x86
| emulation code so could do more setting at runtime. I don't
| know of any cases where vesafb would work and -vesa
| wouldn't. I did a bunch of the hardware enablement work for
| Ubuntu back in 2004/2005, so real world deployment
| experience here is in the millions.
|
| I've no idea what you're talking about as far as EFI fb
| support goes. The spec literally does not provide a
| mechanism for a running OS to get anything other than a
| pointer to a linear framebuffer and the metadata you need
| to use it. There's nothing more to support. What quirks are
| you talking about?
| Teknoman117 wrote:
| I remember using Xvesa in the 00's on 90's hardware with
| great success. Damn Small Linux, etc.
|
| iirc, -vesa got kinda bad after the advent of the "GPU".
| Cards didn't natively support VBE and emulated a subset of it
| just for compatibility purposes.
|
| It's gotten worse these days. I don't know if I'd call it a
| bad thing though - with the push for hardware accelerated
| rendering to help with battery life on portable devices, many
| of the desktop environments have lost support for "software"
| graphics. They instead depend on software OpenGL support via
| llvmpipe and chug hard even on modern devices (if you don't
| have a driver installed) and VMs.
| ComputerGuru wrote:
| While it's true that having a better proliferation of
| hardware accelerated displays in use is a net win, you
| can't discount the need to be able to bring up a GUI on
| generic hardware without knowing the underlying stack in
| advance.
|
| While under X it was possible to install a dozen drivers
| and - mostly - be able to cycle through them (auto
| detection sucked and continues to suck at matching drivers
| to hardware via manufacturer/device ids), DRM/KMS drivers
| are unfortunately another story. You often cannot bring up
| a KMS driver for one hardware on another and expect to be
| able to gracefully unload if it's not supported. There KMS
| drivers that can't be installed in parallel (you have to
| choose which set of cards to support over the other a
| priori), and there is a _ton_ of legacy hardware that will
| never get KMS drivers working, ever.
| mjg59 wrote:
| What KMS driver will attempt to bind to unsupported
| hardware, and which other KMS driver would you be
| attempting to replace it with in that scenario?
| mjg59 wrote:
| Some degree of VBE is required for Windows to boot in BIOS
| mode (and even in EFI mode before Windows 8 for really
| tedious reasons). I'd expect it to be fine for basic mode
| setting, but you're still stuck with the modes the card
| firmware provides which means it's probably 4:3 ratios.
| kevin_thibedeau wrote:
| I recently installed FreeDOS on a Ryzen system to get a
| parallel port device working. It boots fine but anything that
| uses graphics modes is flaky and will often hang the machine
| hard where Ctrl+Alt+Del doesn't work. SB16 compatibility is out
| of the question.
|
| Curiously I got it into a weird mode where artifacts from a
| corrupted framebuffer in DOS were persistent on screen as a
| faint ghost image after booting into Linux even when cycling
| the power for a short duration. I have no idea how that could
| happen.
| ok123456 wrote:
| CMake macros for cross compiling Win16 binaries with Openwatcom
| were just added to CMake earlier this month.
| kybernetyk wrote:
| Man, I'm a sucker for the Win 3.11 UI. I wish there was an option
| to use this style of UI on modern systems.
| jmclnx wrote:
| [flagged]
| msla wrote:
| Is ShieldSecurity a problem on your end or the site's end?
| jmclnx wrote:
| Yes, with my VPN source IP, many sites work fine (like
| hackernews).
|
| But if sites that does not need to know personal information
| cares about my source IP, then I say "too bad". The only
| sites that should care where I am from are sites like
| banking, credit card, etc.
| blueflow wrote:
| Avoid using low-reputation addresses for surfing. If you
| fail to differentiate yourself from the spammers, website
| hosters can say "too bad" to you, too.
| [deleted]
___________________________________________________________________
(page generated 2022-12-24 23:00 UTC)