On 2/18/06, Mike McCormack <[EMAIL PROTECTED]> 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


Reply via email to