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