As the Wine PE conversion process marches toward the finish line, a question of mine has stuck around for a long time:
Why is the *.sys modules, which emulate the Windows kernel drivers, being converted to PE?
As lots of efforts have been put into the process so far, I asume there is a valid reason for it; however, I'm yet to find any explanations on the list. Here are the best explanations I found so far:
- "PE Conversion", Giovanni Mascellani, https://www.winehq.org/pipermail/wine-devel/2021-August/193127.html - "wine modules", Eric Pouech, https://www.winehq.org/pipermail/wine-devel/2022-April/213677.html
To begin with, the rationale of the conversion process *in general* is twofold:
1. Accurate emulation of Windows userspace. This includes the system call interface. Such effort is necessary to appease some DRM and anti-cheat technologies.
2. Wow64 support. Some platforms (e.g. macOS) are either planning to drop, or have already dropped support for 32-bit binaries. To work around this, Wine adopts a "32-on-64" model where 32-bit code is run on 64-bit processes thanks to CPU and operating system support.
Now, here's the reasons I think that both of the above do not necessarily apply to drivers:
1. Accurate emulation of Windows userspace. As kernel drivers run in kernel mode, a syscall interface does not make sense at all.
2. Wow64 support. Note that 64-bit Windows does not support running 32-bit drivers. I don't necessary see a significant value in supporting 32-bit binaries on a Wow64 wineprefix, but others may have different opinion.
Also, drivers tend to interface with the host platform *a lot*, so it's much more difficult than, say, purely native modules whose PE conversion is only a matter of getting rid of "-mcygwin".
Looking forward for your input. Thanks a lot!