Possibly crazy idea to deal with memory layout problems once and for all

[Dan Kegel]

On 2/18/06, Mike McCormack <mike at codeweavers.com> wrote:
> Dan Kegel wrote:
> > You can override mmap() in wine by just changing all
> > the places it's called.  (Having control over the source is
> > a wonderful thing.)  But if you want mmap to behave
> > truly differently, you'd probably need to change the
> > kernel.
>
> You can do that easily after glibc has loaded, but you won't know where
> glibc itself was loaded into the address space.
>
> I discussed something like what Troy proposed with Vitaliy on IRC, but
> with the preloader looking up and overriding the mmap/munmap symbols in
> glibc.  That would hopefully give Wine control over most mmaps and
> munmaps, possible save us from having to reserve memory in the
> preloader, and allow more control of the address space.
>
> It has a few problems though.  Firstly, we'd miss mmaps done with system
> calls.  Secondly, we'd have to make assumptions about what areas of
> memory the kernel would let us map, and what areas of memory were
> already used in the address map.
>
> > I seem to recall somebody was working on a linux
> > kernel module for wine that just dealt with
> > program loading, but I can't recall who.
> > Perhaps he'll surface and comment on this.
>
> I had a go at creating a kernel based PE loader for Linux 2.6 by forward
> porting parts of David Howell's Wine kernel module.  It currently
> compiles, but that's about all.
>
> Haven't had much time to spend on it lately, because I've been busy with
> work ... ;)

I was thinking about the WinePluginApi SoC proposals, and how it
really boils down to "make win32 and nptl threads compatible,
and somehow make the regular dynamic loader handle PE files".
Is there a good brain dump somewhere about what you were working
on, maybe on the wine wiki somewhere?
- Dan