I'm trying to get Alpha Centauri working on wine.
I've fixed some bugs, but I've hit a wall with this one:
0011:trace:seh:EXC_RtlRaiseException code=c005 flags=0 addr=0x4fb13f
0011:trace:seh:EXC_RtlRaiseException info[0]=
0011:trace:seh:EXC_RtlRaiseException info[1]=00a63834
0011:tr
Hello,
I am currently attempting to build Wine-20040615 on an AMD Athlon 64 system.
When I attempt to actually build the software, I am told that I need to
implement interlocked functions for my CPU - I am not sure how to implement
them myself but am wondering if anyone else has done so. Any help
Hi,
I'm experimenting with native vs builtin comctl32 for an app and
whenever I set this dll to native I hit this assert in
init_system_dir():
assert( mod->Flags & LDR_WINE_INTERNAL );
This happens on a 2.6 and a 2.4 system. I suspect its not related to
comctl32 per-se, but merely loading a nat
Mike Hearn wrote:
To be frank I think that's Debians problem, or to more accurate the
problem of those who insist on using apt-get for everything. If WineHQ
provides high quality tested binaries with ICU included, they can use
that if they want BiDi.
There will *always* be random distros that have
On Sat, 3 Jul 2004, Saulius Krasuckas wrote:
> I've entered new bug #2332 [1] recently, where I've described my problem.
Oh, and the bonus line. ;-)
[1] http://bugs.winehq.org/show_bug.cgi?id=2332
I've entered new bug #2332 [1] recently, where I've described my problem.
I think the application was compiled with some BC compiler for win16
platforms. 32 here at "last error" means some sharing violation, I hope:
[EMAIL PROTECTED] wine]$ cat include/winerror.h | grep ' \+32$'
#define ERROR_SH
On Sat, 2004-07-03 at 11:47 +0300, Shachar Shemesh wrote:
> No, that won't solve the problem. For a package to be included in
> Debian, for example, it needs to be reconstructible by doing "apt-get
> source wine; apt-get build-dep wine"
To be frank I think that's Debians problem, or to more accu
Jonathan Wilson wrote:
Maybe we can get our supplied packages to be BiDi enabled, but so
long as we use ICU, and ICU has this horrible linking policy, we
can't really
What linking policy?
I checked the IBM ICU website (http://oss.software.ibm.com/icu/ and
specifically
http://oss.software.ibm.c
David Lee Lambert wrote:
The smaller said native-interaction API is, the easier it will be to
keep stable.
But aside from init and loading a library, what else do we need?
Shachar
Mike Hearn wrote:
OK. Well, that can be solved by WineHQ providing high quality binary
packages that work anywhere. When I get around to this (maybe in a few
months) I'll let you know and you can kick me if I get ICU
integration wrong :)
thanks -mike
No, that won't solve the problem. For a packa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Jul 02, 2004 at 12:42:02PM -0400, Andrei Barbu wrote:
> Can't the wine installer chmod a-w all of those right when it sets
> things up?
This won't work if the WINDOWS\\SYSTEM directory is on a VFAT partition.
> > solution is to this. Maybe pr
On Fri, Jul 02, 2004 at 10:48:57PM +0800, Jonathan Wilson wrote:
> Bascily, there should be 3 sorts of APIs exported in WINE.
...
> and 3.external WINE apis. There should be a limited set of special APIs
> which are made available to enable projects like mono and others wanting to
> interact wit
12 matches
Mail list logo
