Disclaimer: I know precisely zero of the details here nor
if the PE loader can support any of the below features.
On Fri, 2021-09-10 at 09:23 +0000, Bastien ROUCARIES wrote:
> The problem is that windows apps particularly games try to check if
> mapped ram exec pages are from dll from disk and not modified in
> memory.
The fake dlopen could presumably be provided by an on-disk DLL?
The PE loader would just load the fake dlopen DLL first, like
glibc does when you set the LD_PRELOAD environment variable.
> You propose:
I'm not proposing any on-disk symlinks, renaming DLLs or any other
changes to any PE DLLs, just loading into memory like dlmopen.
The solution I'm thinking of looks something like this:
src:libpng -> libpng16-16:$winarch -> /usr/lib/$wintriplet/libpng16.dll
(requires Debian to support cross-only, partial and Windows arch types)
PE loader sets up in-memory Wine namespace.
PE loader loads into Wine namespace: /usr/lib/$windowstriplet/wine/fake-dlopen.dll
PE loader loads Wine dependencies into Wine namespace.
Some of the Wine dependencies call the Windows equivalent of dlopen,
which resolves to the fake dlopen equivalent within the namespace,
which calls the Windows equivalent of dlmopen("Wine", dll), which makes
the PE loader load those libraries into the Wine namespace.
PE loader finishes loading Wine dependencies and proceeds loading the
PE file and its dependencies into the default namespace.
Windows apps check mapped RAM pages and they show up correctly.
The main issue would be that apps could check they run in Wine.
OTOH the PE loader could also just hide the pages somehow?
--
bye,
pabs
https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part