1

Current state :

There are more and more computers like mine which are 64 bits uefi only and thus unable to boot 32 bits based Windows.
And as Windows 11 is 64 bits only this means in a few years (ends of support for Windows 10 in 2025) there won’t be a network trusted way to run 32 bits based Windows.

In the 90’s many hardware got rereleased from isa into a pci variant. And as Windows 98 supported the Windows Driver model of later nt based Windows, this meant many hardware of the time was still usable which is how you can use a SoundBlaster 16 on Windows xp. While Vista introduced a new binary format for drivers, it is still possible to use wdm based drivers (in theory) on Windows. And Windows 10 still offer a mode for using unsigned official drivers.

Though a new problem arises : In addition to the legacy of the end of the 90’s, many manufacturers didn’t produce 64 bits drivers for their hardware until the late 2000’s (understandable as I remember being offered a 32 bits computer in 2010 for my birthday in the name a 64 bits laptop was too costly).

This means many hardware will no longer be able to run with current software and as newer Visual Studio drop support for older versions of Windows, not longer be able to be used safely with files coming from the Internet.

Ironically, stripped‑down drivers in functionality for mainline Linux (compared to their closed source Windows variant) risk becoming the only way to get modern ᴏꜱ being able to use bare functionality from old hardware.

With proper hypervisor emulation, it should be possible to do it technically as the first x86 OsX have supported loading 64 bits .kext from a 32 bits kernel. And the Ndiswrapper, allows to wrap wdm Windows binary driver using the linux ndis driver api to the Alsa/oss api of Linux. Whereas in my case it’s almost purely functions along entry points along Driver Objects which needs to be wrapped and rebuilt.

But let’s talk about my specific case :

my computer doesn’t have any Internal sound card so I thought it was the time to use my old ess’s es1938 solo1/AudioDrive®.
Besides being able to play ᴘᴄᴍ sound like any sound card, it contains an ᴇꜱꜰᴍ module not supported by the Linux driver, offering Adlib opl3 in hardware compatibility (which might be a partial solution but I failed to find a 64 bits Adlib driver) and more importantly an advanced non compatibility mode : in the non compatible mode with additional registers, it is still 4‑op per voice, and thus inferior to a Yamaha dx7, but unlike the opl3 it offers 72 op for full midi compatibility and the possibility to control pitch per op instead of per op pair.
This allow getting a good fm based synth hard to emulate very accurately in terms of performance on modern hardware while still being cheaper and smaller than a Yamaha fs1r.

Of course, with being less successful than Creative products, those native capabilities found very little use beside tomb rider and other dos games requiring to run on real hardware which used the miles sound system library .
But what interest me is the hardware midi synth exposed by the official drivers of the time and which based on what I understand isn’t possible to use in Linux because of lack of tools and driver support. It uses the advandced registers for providing better per voice compatibility along the ability to play all the maximum 16 midi channels for polyphony.

This means any .mid can be used to use the advandced the fm synth style of the chip. There is no sound bank, and instead the sound bank is provided as hardcoded blob inside the kernel’s driver executable.

So is there a community Windows driver ? I only found https://github.com/pachuco/ESSPlayMid and that the card is identified as VEN_125D&DEV_1969&SUBSYS_8888125D&REV_01. Or a way to use Linux drivers on Windows for at least getting ᴘᴄᴍ playback or 32 bits Windows drivers on 64 bits ?

Improve this question
15
  • The underlying point is some form of hardware synth is required for supporting ᴡᴅᴍ audio drivers. So it wasn’t completely removed by Microsoft and since Windows Vista, there are programs still working which allow to select and use of hardware ᴍɪᴅɪ synthesisers instead of the Roland based Microsoft software Synthesizer existing since Windows 98.
    – user2284570
    Jul 27, 2022 at 5:49
  • 1
    What is this modern computer that runs Windows 11 but which doesn't have sound? That seems unusual.
    – another-dave
    Jul 27, 2022 at 12:08
  • @another-dave no I m using Windows 10 but it can boot 64 bits uefi only. The model is a R2308WFTZSR.
    – user2284570
    Jul 27, 2022 at 12:29
  • I think this could be edited into an on-topic new-hardware-adaptation question.
    – wizzwizz4 ♦
    Jul 27, 2022 at 14:54
  • 4
    These FM synthesizers are programmed using port I/O (and at least the OPL3 registers are well documented), which means you should be able to access it on 64-bit Windows using the generic WinRing0 driver, in combination with a custom user-mode program. I expect that would be easier than developing a 64-bit driver to replace or wrap the 32-bit driver.
    – DamageX
    Jul 28, 2022 at 22:06

3 Answers 3

Reset to default
5

The difficulty seems to be that Windows Driver Model device drivers aren't stand-alone chunks of code. They consist of two layers: the bus driver, PCI in this example, which is provided with Windows, and the function driver, provided by the device manufacturer.

Running a 32-bit function driver in a 64-bit OS requires both the OS kernel and the PCI bus driver to be able to cope with both 32-bit and 64-bit function drivers. Since the PCI bus driver has to be able to cope with the quirks of different PCI implementations, I can see why Microsoft didn't want the extra complexity of 32-bit handling in a low-level driver that can readily crash the whole machine if it malfunctions.

Microsoft tried quite hard to persuade the device manufacturers to provide both 32-bit and 64-bit device drivers, but with limited success. As of Windows Vista, they required device manufacturers to provide both drivers to qualify for the "Designed for use with Microsoft Windows" logo. That was one of the few things about Vista that was managed well, IMHO. If manufacturers didn't care about that, what more could Microsoft do? As a company with a near-monopoly in consumer operating systems, they'd have serious trouble with the US courts if they tried to force add-on manufacturers to do things.

Device manufacturers have always been reluctant to provide new drivers for hardware they're no longer selling. They'd far rather sell you a new device, for obvious reasons.

After some thought, I can see a theoretical way to do this, but it isn't practical. You write a 64-bit device driver that does all the memory marshalling (copying data from above the 4GB line to below it, changing the sizes of pointers, etc.) and then invokes the 32-bit driver it has loaded. It then needs to intercept calls coming out of the 32-bit driver and translate them to 64-bit form before they hit the PCI bus driver.

This driver needs to have a very complete implementation of all the driver interfaces, because you don't know in detail how your soundcard driver works, which makes it capable of hosting more than just that driver. It could, in theory, host many kinds of drivers.

Writing this wonderful driver would be quite hard. Anyone doing it would need unusual expertise in Windows device drivers, both 32-bit and 64-bit. I'm also suspicious that Microsoft would refuse to sign it, even if it was bundled with a specific 32-bit driver and was thus (in theory) testable, simply because it has so many extra ways that it can go wrong.

Improve this answer
17
  • While the majority of hardware devices are commodities, which could be easily replaced by superior ones if old drivers stop working, it's hardly rare for computer-controlled equipment to have needed specialized drivers because of Microsoft's early failure to provide "generic USB device" drivers which could exchange data faster than HID devices could.
    – supercat
    Aug 27, 2022 at 18:18
  • @JohnDallman and in my case the said device remains too powerful to be emulated accurately. Back in the time, the successor devices were sampling based which was also supposed to ditch analog audio like Vynyle at the same time. Though I do remember running the card with more than 4Gib of ram before Windows sp2 disabled the ability to use more than 4Gib because some drivers were crashing the system with the additional memory. Do you have any ideas on how memory handling worked for allowing 32 bits drivers accessing data above the 4Gib limit ?
    – user2284570
    Aug 27, 2022 at 23:50
  • @JohnDallman beside memory, This doesn’t change the aim is still to convert calling conventions along structures. In the case of wdmaudio, you know Microsoft tried to do thing Alsa like so it works with communating bus. Everything is a single .sys file without user space components.
    – user2284570
    Aug 28, 2022 at 0:03
  • 1
    @user2284570: If a driver makes use of hardware features such as a DMA controller which expects to have 32-bit registers written into it, recompiling isn't going to cause the code to magically generate the correct sequence of configuration steps necessary to use a 64-bit DMA controller.
    – supercat
    Aug 28, 2022 at 21:30
  • 1
    @user2284570: That's all well and good if a peripheral uses a DMA controller the OS knows about. There was a time when I/O devices did their own address generation, which meant the only really safe way of handling things was to permanently allocate regions of RAM address space to such devices--something which would have been annoying given RAM prices at the time, but would nowadays not be so bad.
    – supercat
    Aug 30, 2022 at 14:38
1

Can't be done. See this article by Raymond Chen:

Why can’t you thunk between 32-bit and 64-bit Windows?

https://devblogs.microsoft.com/oldnewthing/20081020-00/?p=20523

Improve this answer
17
  • 5
    All that really means is that it would be much more complex, not that it can’t be done (in all cases). As long as appropriate memory can be mapped into the 32-bit driver’s address space, or if double-buffering can be used, it would be possible to convert data structures from their 64-bit variant to their 32-bit variant, and back.
    – Stephen Kitt
    Jul 27, 2022 at 10:36
  • 1
    Which means in turn that it would take a high degree of motivation to write a driver, rather than simply buying more modern sound hardware.
    – another-dave
    Jul 27, 2022 at 11:57
  • 2
    @rgos It is so much impossible that wow6432.dll along Wow64Cpu.dll included with almost every installation of 64‒bits Windows does just what your article state is architecturally impossible to do in order to allow 32‒bits programs to run. Unlike ᴏꜱ like Linux Microsoft didn’t change the kernel to support 32‑bits system calls along the required ᴄᴘᴜ mode.
    – user2284570
    Jul 28, 2022 at 2:57
  • 1
    If MacOS can run x64 code on an ARM processor using a runtime translator, Windows can run x32 code on an x64 processor too even if the CPU does not support it natively. It can be done. It is a political decision, or even an excuse to use this to cut off supporting legacy software.
    – Thorbjørn Ravn Andersen
    Jul 29, 2022 at 16:28
  • 2
    @user2284570 the point was that if Microsoft had wanted to, Old software would still be supported. They took the opportunity to cut lose (like apple does all the time).
    – Thorbjørn Ravn Andersen
    Jul 30, 2022 at 23:23
0

There actually is a very good reason why you can't do this. Interrupt handlers are always in machine bitness.

Under normal application code you could simulate everything up to and including an entire machine if need be, but to handle the hardware interrupts you actually need to be in machine bitness, because they're entered from everywhere.

It seems that switching to protected mode ought to work; but mind what you are doing. You cannot enter the normal 32 bit compatibility mode because you are in an interrupt handler but only the true ring 0 protected mode, which means none of the emulation around the driver will exist. If the driver's expecting to access anything outside itself (including the IO buffers) it just won't be able to. So it can't actually do anything unless the entire driver were written from the ground up to run in this mode; which if you could do tht you could have ported it to long mode in the first place.

Improve this answer
2
  • @user2284570: I used to use ndiswrapper; it needs a driver bitness that matches the kernel bitness.
    – Joshua
    Dec 6, 2022 at 15:14
  • And how .kext acheives mixing bitness at ring 0 on Apple ?
    – user2284570
    Dec 6, 2022 at 15:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .