Dan Kegel wrote:
I don't think this is good for an SoC project, because the changes are
small, and you'll spend more time arguing with Alexandre about the right
way to do it than doing actual coding.
The changes may sound small to you, but they're probably a
month's work for a newbie. The st
On 5/10/06, Mike McCormack <[EMAIL PROTECTED]> wrote:
I think win32 and NPTL threads are compatible already.
Golly.
The issues I see for are reserving the right memory areas, setting up
the large stack, establishing a connection to the Wine server and
setting up the segment registers (%fs) so
Dan Kegel wrote:
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 wi
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
Troy Rollo wrote:
It has a few problems though. Firstly, we'd miss mmaps done with system
calls.
Yes, but how many apps actually do this?
We wouldn't care about applications, only libraries that use their own
mmap system call (eg. Wine).
Secondly, we'd have to make assumptions about wha
On Saturday 18 February 2006 22:47, Mike McCormack wrote:
> It has a few problems though. Firstly, we'd miss mmaps done with system
> calls.
Yes, but how many apps actually do this?
> Secondly, we'd have to make assumptions about what areas of
> memory the kernel would let us map, and what are
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
> it seemed that the only way to resolve it would be to
> get in between the application and any libraries, and the kernel.
>
> If wine_preloader were extended to have its own implementation of all the
> friends of mmap(), and to have its own implementation of the dynamic linker,
> then in principl
On Saturday 18 February 2006 15:21, Vitaliy Margolen wrote:
> more specific about what is the real problem here? From what I know this
> patch is to fix WoW (Blizard's bad assumption about place where memory
> will be allocated). And possible few other games (that make the same
> exact assumption).
Friday, February 17, 2006, 8:57:06 PM, Troy Rollo wrote:
> I have been looking at a problem that has arisen in recent versions,
> particularly when using some D3D games, in which the virtual address space
> above TASK_UNMAPPED_BASE becomes fragmented to the extent that eventually you
> get an out
I have been looking at a problem that has arisen in recent versions,
particularly when using some D3D games, in which the virtual address space
above TASK_UNMAPPED_BASE becomes fragmented to the extent that eventually you
get an out of memory condition, even though you still have well over a
gi
11 matches
Mail list logo
