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

[Stefan Dösinger]

Hi,

I am not directly involved in any of those, but here are my best guesses:

> Am 03.07.2022 um 21:33 schrieb Jinoh Kang <jinoh.kang.kr at gmail.com>:
> 
> 1. Accurate emulation of Windows userspace. As kernel drivers run in kernel
> mode, a syscall interface does not make sense at all.

Not all of them. See e.g. winspool.drv, which is something applications can link against. Might have inherited the "wrong" file ending somewhere, but it is mostly a regular DLL otherwise.

> 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.

I think there are two things affecting this:

*) Application-provided drivers (DRM etc) still need a Windows-ish environment. They run in the same space our .drv's run. Afaics those drivers can also link against our .sys modules, e.g. the dinput tests contain a driver that links against hidclass.sys.

*) aarch64 and x86_64 (on mac) still need a non-trivial syscall thunk for TLS registers. I am not sure if there is any kind of TLS support in a .drv in the Windows kernel though.

*) We might want to run 32 bit DRM drivers on 64 bit even if Windows doesn't support that. We can currently load old 32 bit safedisk 2 drivers and want to retain that. Windows solved this problem by providing a rewrite of the safedisk drivers. I don't know how they handle kernel DRM modules on aarch64.

I think it is the combination of those points why we want to have a windows-y kernel environment and not take the host environment 1:1.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20220703/ef0a4a97/attachment.sig>