Alexandre Julliard wrote:
Shachar Shemesh <[EMAIL PROTECTED]> writes:
Alexandre Julliard wrote:
That's why we don't use malloc in Wine...
http://source.winehq.org/source/dlls/ntdll/virtual.c#L373 says otherwise.
Yes there are a few exceptions, because we obviously can't allocate
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> Alexandre Julliard wrote:
>
>>That's why we don't use malloc in Wine...
>>
> http://source.winehq.org/source/dlls/ntdll/virtual.c#L373 says otherwise.
Yes there are a few exceptions, because we obviously can't allocate
from the process heap in the cod
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> I think there is one zero too many here. Did you mean 078?
No, 7800. Check loader/Makefile.in.
> So, effectively, in order to use this area, we'll need to manage it
> ourselves. Is that a correct assertion? Is there any reason we use
> malloc
Alexandre Julliard wrote:
Shachar Shemesh <[EMAIL PROTECTED]> writes:
I think there is one zero too many here. Did you mean 078?
No, 7800. Check loader/Makefile.in.
Saw it. Didn't understand it, but that will have to wait until tomorrow,
I guess. Half past midnight is too late t
Alexandre Julliard wrote:
Shachar Shemesh <[EMAIL PROTECTED]> writes:
When actually run (through strace), one can see the mmaps being
carried out and successful, and then the mmap that fails (no
memory). Then malloc is attempted, which tries mmap, then brk, and
then mmap again. All fail. This is
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> When actually run (through strace), one can see the mmaps being
> carried out and successful, and then the mmap that fails (no
> memory). Then malloc is attempted, which tries mmap, then brk, and
> then mmap again. All fail. This is the point where I s
