Builtin DLL View

[Keno Fischer]

Hello everyone,

out of curiosity, I was tracking down why a piece of code in julia [1]
threw an assertion when running under wine, but
not on windows proper. The problem in this piece of code turned out to be
that VirtualQuery is claiming a region of
memory is free, when it is actually occupied by part of one of the builtin
dlls.

If I understand correctly what's happening here is that builtin dlls are
regular shared objects on the host system, and
get loaded as such, but contain the respective windows dll inside of them
(modulo header, which gets created in
`map_dll` by mapping over a couple of pages in the middle). Later, after
going through the load callback,
`virtual_create_builtin_view` records the appropriate information in the
view map. However, it only records what
it knows about the inner dll, not the shared object wrapper around it.

I was thinking of preparing a patch, but I am not sure how to go about it.
Options I could see:

- Expand the mapping in `virtual_create_builtin_view`. This seems most
straightforward, but I don't quite
 know what the proper way to pass this information through to here is. Or
maybe we can parse the wrapper's
header right in the function, if we assume that it's base will always be
64K before the PE header base?

- Unmap the parts of the shared library that do not constitute the inner
dll. I would imagine that at some
point wine stops relying on the native dynamic linker, at which point it
would probably be safe to just unmap
the extra pages such that view agrees with what is actually mapped.

I'd be happy to put together a patch, but I'll need some guidance on how
best to do this, since I haven't looked
at the Wine codebase before today.

[1]
https://github.com/JuliaLang/julia/blob/01dd5ec0b25fc5fa8cf1fbae6bb00ef5874700d3/ui/repl.c#L598
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20160312/969abcf4/attachment.html>