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 ?