sorry, just saw the note on WWN. I did hope that there would be someone
to point to the gcc visibility stuff already - but it seems that people are
more concerned to exchange their believes and politics rather showing
off some engineering stuff.
* preface:
it's not in the file format - it's in the
On Sun, 16 May 2004 22:30:09 +0800, Jonathan Wilson wrote:
> Is anyone working on getting sutable-to-use-in-wine versions of these?
Nyef was working on this up until a few months ago.
> Would having these benefit OLE apps?
Yes, stdole32.tlb is essential for InstallShield to perform interface
mar
On Sun, 2004-05-16 at 11:25 -0700, Alexandre Julliard wrote:
> The process heap can be placed anywhere, this isn't the cause of the
> problem. You are confusing it with the shared heap.
Oops, so I am :(
Maurizio, try a +heap trace - that section of code doesn't have much
tracing in so you may ne
Mike Hearn <[EMAIL PROTECTED]> writes:
> Put code which dumps the maps list when the process heap can't be
> created, ie something like:
>
> {
> char buffer[100];
> sprintf(buffer, "cat /proc/%d/maps", getpid();
> system(buffer);
> }
>
> and see what is sitting at the place we're
..]
> > wine: failed to create the process heap
> >
> > The same wine executable was running ok on my 32bits distro.
> > I read that this happens on fedora2 too because of nx stack, and
> > i think that, even if i do not have SeLinux installed, the stack
> > is not executable by default on amd64...
Is anyone working on getting sutable-to-use-in-wine versions of these?
Would having these benifit OLE apps?
On Sun, 2004-05-16 at 15:40 +0200, Maurizio Monge wrote:
> Mh, i'm not convinced :-)
> I do not have execshield (kernel 2.6.4-rc2 with only supermount and reiser4
> patches) or prelink. The strange thing is that it MUST be a kernel problem
> because:
Put code which dumps the maps list when the pr
