What is the purpose of PE conversion of *.sys drivers?

[Jinoh Kang]

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