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! -- Sincerely, Jinoh Kang