wine-devel January 2003

wine-devel@winehq.org

151 participants
377 discussions

Unhandled exception in VB app "Yardi Property Management"
by Dan Kegel 25 Jan '03

25 Jan '03

A local company wants to run Yardi Professional Property Management, a VB app that doesn't use Access, under Wine. (See http://www.yardi.com.) I tried it under CVS wine as of a few days ago. Happily, the setup program completes, with just a few warnings and one 'illegal function call' vb dialog box, e.g. err:ddeml:WDML_CreateString Unknown code page 437 err:module:BUILTIN32_LoadLibraryExA loaded .so but dll commdlg.dll still not found - 16-bit dll or version conflict. ... Not bad, I guess; after all, setup did run all the way to the end. Problem came when I tried running the app. It gets an unhandled exception -- and oddly, the wine debugger refused to run. [dank@boogie PMWPROG]$ wine --debugmsg +wc_font Y.EXE err:fixup:NE_LoadSegment No implementation for HEDLG.26, setting to 0xdeadbeef err:fixup:NE_LoadSegment No implementation for HEDLG.27, setting to 0xdeadbeef fixme:hook:SetWindowsHookEx16 System-global hooks (7) broken in Win16 fixme:hook:SetWindowsHookEx16 System-global hooks (2) broken in Win16 wine: Unhandled exception, starting debugger... trace:wc_font:WCUSER_SetFontPmt => L"Misc Fixed" h=13 w=0 trace:wc_font:WCUSER_DumpLogFont InitFamily: truetype lf.lfHeight=99 lf.lfWidth=97 lf.lfEscapement=0 lf.lfOrientation=0 lf.lfWeight=400 lf.lfItalic=0 lf.lfUnderline=0 lf.lfStrikeOut=0 lf.lfCharSet=0 lf.lfOutPrecision=3 lf.lfClipPrecision=2 lf.lfQuality=1 lf->lfPitchAndFamily=18 lf.lfFaceName=L"AdvMICR" err:wineconsole:WINECON_Fatal Couldn't find a decent font, aborting Editing ~/.wine/config and changing UseXTerm to 0 helped there. (And what the hell, I can never get wine debugger copy-and-paste to work properly with that at its default value, so it's just as well.) The error was: Unhandled exception: privileged instruction in 16-bit code (25f7:0ca4). Backtrace: =>0 0x25f7:0x0ca4 (bp=6cd4) 1 0x00f7:0x0000 (bp=6d1c, far call assumed) 2 0x407cf7dd (K32WOWCallback16Ex+0x45(vpfn16=0x25f70c78, dwFlags=0x0, cbArgs=0x18, pArgs=0x40e12b90, pdwRetCode=0x40e12b88) [wowthunk.c:298] in kernel32.dll.so) (ebp=40e12b68) 3 0x412d8005 (StgIsStorageILockBytes16+0x75(plkbyt=0x26ff0042) [storage.c:1716] in ole32.dll.so) (ebp=40e12bbc) 4 0x412b516f (__wine_storage_dll_CallFrom16_p_long_l+0xb(proc=0x412d7f90, args=0x40fdbf5a) [storage.spec.c:169] in ole32.dll.so) (ebp=40e12bc8) 5 0x400c9cd5 (__wine_call_from_16_long+0x8d [relay16.s] in libntdll.dll.so) (ebp=40e12c00) 6 0x25df:0x198f (bp=6d56) 7 0x40086142 (NE_StartTask+0x1e6 [module.c:1234] in libntdll.dll.so) (ebp=40e12f04) 8 0x40081625 (task_start+0x41(pTask=0x40259728) [task.c:444] in libntdll.dll.so) (ebp=40e12f18) 9 0x400b2e54 (THREAD_Start+0x60 [thread.c:269] in libntdll.dll.so) (ebp=40e12f30) 10 0x400b227c (SYSDEPS_StartThread+0x8c(teb=0x40e23000) [sysdeps.c:165] in libntdll.dll.so) (ebp=40e12ff4) 11 0x420da1ca (NTDLL.DLL.memcpy+0x5dd7a) (ebp=00000000) Any suggestions? I'm kind of jazzed it gets this far... Thanks, Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

2 2

Re: Games Swat 3d
by fenix＠club-internet.fr 25 Jan '03

25 Jan '03

----Message d'origine---- >De: "Ronald James" <ronniej(a)metroweb.co.za> >A: <wine-devel(a)winehq.com> >Sujet: Games Swat 3d >Date: Mon, 20 Jan 2003 07:39:52 +0200 > >I am wondering if Swat3d will be added to the list anytime soon for use with wine ?? > what do you mean by "added to the list" ? Regards, Raphael

3 2

build problem with current CVS (20030125 9:45 UTC)
by Stefan Leichter 25 Jan '03

25 Jan '03

Hello compiling the current cvs fails for me with: make[2]: Entering directory `/usr/src/wine/wine-build/dlls/winspool' gcc -shared -Wl,-Bsymbolic,-z,defs winspool.drv.spec.o info.o wspool.o winspool.drv.dbg.o -o winspool.drv.so -L../../dlls -L../../library -lwine -lm -lc info.o: In function `PRINTER_INFO_2AtoW': /home/sle/src/wine/wine-build/dlls/winspool/info.c:554: undefined reference to `HEAP_strdupAtoW' /home/sle/src/wine/wine-build/dlls/winspool/info.c:555: undefined reference to `HEAP_strdupAtoW' /home/sle/src/wine/wine-build/dlls/winspool/info.c:556: undefined reference to `HEAP_strdupAtoW' /home/sle/src/wine/wine-build/dlls/winspool/info.c:557: undefined reference to `HEAP_strdupAtoW' /home/sle/src/wine/wine-build/dlls/winspool/info.c:558: undefined reference to `HEAP_strdupAtoW' info.o:/home/sle/src/wine/wine-build/dlls/winspool/info.c:559: more undefined references to `HEAP_strdupAtoW' follow collect2: ld returned 1 exit status make[2]: *** [winspool.drv.so] Error 1 make[2]: Leaving directory `/usr/src/wine/wine-build/dlls/winspool' make[1]: *** [winspool] Error 2 make[1]: Leaving directory `/usr/src/wine/wine-build/dlls' make: *** [dlls] Error 2 Does someone else have this problem ? For me it looks like the patch http://www.winehq.com/hypermail/wine-patches/2003/01/0320.html or some parts of it did not make it into cvs Bye Stefan

2 1

Re: PATCH: glibc 2.3.x and errno
by Ulrich Weigand 25 Jan '03

25 Jan '03

Hi Marcus, > __errno_location and __h_errno_location are no longer weak symbols > and so can not be overwritten any longer. The internal glibc systemcall > wrappers no longer call the functions by reference, but directly. the real problem is even worse. glibc has switched to using thread-local storage for errno (i.e. it is declared as 'extern __thread int errno') when the tool chain supports the __thread keyword. This means that C source code compiled against the new headers will result in assembler code that *directly* accesses a thread-local variable as defined by the TLS ABI. In the case of errno, this will involve accessing the %gs segment using an offset from the GOT, without any function call being performed. (errno is defined to use the initial-exec TLS storage model.) The __errno_location routine is provided only for backwards compatibility reasons, it is no longer guaranteed that every access to errno calls it. Thus, if you overwrite the implementation of __errno_location, you will only catch *some* errno accesses, not all of them ... Bye, Ulrich (who has just implemented TLS for s390 ;-/) -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

3 2

Re: Re: Games Swat 3d
by fenix＠club-internet.fr 25 Jan '03

25 Jan '03

>De: Greg Turner <gmturner007(a)ameritech.net> >A: fenix(a)club-internet.fr, ronniej(a)metroweb.co.za >Sujet: Re: Games Swat 3d >Date: Mon, 20 Jan 2003 08:48:35 -0600 >Copie à: wine-devel(a)winehq.com > >On Monday 20 January 2003 11:05 am, fenix(a)club-internet.fr wrote: >> ----Message d'origine---- >> >> >De: "Ronald James" <ronniej(a)metroweb.co.za> >> >A: <wine-devel(a)winehq.com> >> >Sujet: Games Swat 3d >> >Date: Mon, 20 Jan 2003 07:39:52 +0200 >> > >> >I am wondering if Swat3d will be added to the list anytime soon for >> > use with wine ?? >> >> what do you mean by "added to the list" ? >> >> Regards, >> Raphael > >Presumably, added to the list of programs that work ;) It's what i have thought first, but "will be added ... for use ..." sound like "will be added to the priority list" for me :) >Swat3d is a great game, and one that I happen to own. Haven't tried it >in wine for a while, maybe I'll give it a try after work today. :) can you report the current working state of the game under wine Dx after ? As d3d<8 not support multi-texturing yet, i think you should have some graphics problems Raphael >-- >gmt > >"Everything that is really great and inspiring is created by >the individual who can labor in freedom." --Albert Einstein > >

3 2

Re: Packagers Guide Update #5
by Andreas Mohr 25 Jan '03

25 Jan '03

On Thu, Jan 23, 2003 at 11:42:31PM -0500, Tom Wickline wrote: > Changelog > > Update the Sample config IMHO this doesn't even have *any* business in the Packaging Guide. The guide should simply contain a pointer to the REAL sample config file, otherwise this exactly leads to the permanent updating mess which you just demonstrated ;-) -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php

4 3

Re: PATCH: glibc 2.3.x and errno
by Alexandre Julliard 25 Jan '03

25 Jan '03

Marcus Meissner <meissner(a)suse.de> writes: > The afore mentioned glibc guru did not have any ideas either. > > There however is a happy but messy end, which appeared to me > yesterday: > Overwrite those 2 functions with a jump to our implementations. I'm afraid that won't be enough. When using thread-local storage, glibc doesn't even call __errno_location any more, it directly stores errno into the thread storage using %gs. It seems the only solution is to make Wine threads work on top of libc threads, but that will be messy. -- Alexandre Julliard julliard(a)winehq.com

4 3

Re: PATCH: glibc 2.3.x and errno
by Andreas Mohr 24 Jan '03

24 Jan '03

Hi ! On Fri, Jan 24, 2003 at 05:20:12PM +0100, Marcus Meissner wrote: > Changelog: > Since glibc 2.3.cvs no longer exports __errno_location, we need > to overwrite the implementation in glibc/libpthread directly. Excuse me, but somehow I think this is p*ss poor. (and yes, I'm now marking you up for the dark side ;-) I mean, both Wine and glibc are successful (?) OSS projects, so they should be able to come up with something much better than this terribly embarassing solution (after all everybody knew that OSS development was a "superiour" approach, didn't they ? ;-). I for one would feel much better if we simply rejected that particular "broken" glibc version and supported a *new* glibc method of properly interfacing errno things in a newer glibc version... (maybe have some "advanced" setting in glibc that enables all sorts of funky interfacing capabilities in case a program needs it) After all if Wine needs this errno support, then there's probably a need for it, so it's glibc's bloody obligation to make sure there's proper support IMHO. BTW: why did they even choose to abandon a public errno_location ? Anyway, thanks for tackling this severe issue ! Andreas Mohr P.S.: Do you really think that Alexandre would commit it like that ? ;-)

2 1

dlls/d3d8/device.c: statement with no effect
by Gerald Pfeifer 24 Jan '03

24 Jan '03

In dlls/d3d8/device.c I am getting the following warning (on FreeBSD): /usr/bin/gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -g -O2 -Wall -Wpointer-arith -mpreferred-stack-boundary=2 -gstabs+ -fPIC -D__WINESRC__ -D_REENTRANT -o device.o device.c device.c: In function `DrawPrimitiveI': device.c:475: warning: statement with no effect Could someone please have a look? (If fixed about half a dozen portability problems last week, but this one I'm having a hard time with.) Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

2 1

Re: Patch for crash caused by XIM and make XIM functions properly
by Dmitry Timoshkov 24 Jan '03

24 Jan '03

"liu spider" <liuspider(a)yahoo.com> wrote: > @@ -1000,8 +1100,11 @@ > > wine_tsx11_lock(); > if (xic) > - ascii_chars = XmbLookupString(xic, event, Str, sizeof(Str), &keysym, NULL); > - else > + { > + if(XIM_KeyEvent(GetFocus(), xic, event)) > + return; > + } > + > ascii_chars = XLookupString(event, Str, sizeof(Str), &keysym, NULL); > wine_tsx11_unlock(); I can't comment on other parts, but in the above chunk the return after a successful XIM_KeyEvent() leaves X11 lock held. -- Dmitry.

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
38
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel January 2003