wine-devel July 2004

wine-devel@winehq.org

122 participants
251 discussions

Error building CVS
by wine-devel＠kievinfo.com 04 Jul '04

04 Jul '04

preloader.o(.text+0x219): In function `wld_printf': /usr/local/src/wine/loader/preloader.c:338: undefined reference to `strlen' preloader.o(.text+0x260): In function `fatal_error': /usr/local/src/wine/loader/preloader.c:349: undefined reference to `strlen' collect2: ld returned 1 exit status make[1]: *** [wine-preloader] Error 1 make: *** [loader] Error 2 Here is offending patch: http://cvs.winehq.org/patch.py?id=12698 This part: Index: wine/loader/Makefile.in diff -u wine/loader/Makefile.in:1.15 wine/loader/Makefile.in:1.16 --- wine/loader/Makefile.in:1.15 Sun Jul 4 16:02:15 2004 +++ wine/loader/Makefile.in Sun Jul 4 16:02:15 2004 @@ -28,7 +28,7 @@ $(CC) -o $@ glibc.o $(LIBWINE) $(LIBPORT) $(LIBPTHREAD) $(EXTRALIBS) $(LDFLAGS) wine-preloader: preloader.o Makefile.in - $(CC) -o $@ -static -nostartfiles -Wl,-Ttext=0x78000000 preloader.o $(LIBPORT) $(LDFLAGS) + $(CC) -o $@ -static -nostartfiles -nodefaultlibs -Wl,-Ttext=0x78000000 preloader.o $(LIBPORT) $(LDFLAGS) wine-kthread: $(KTHREAD_OBJS) Makefile.in $(CC) -o $@ $(LDEXECFLAGS) $(KTHREAD_OBJS) $(LIBWINE) $(LIBPORT) $(EXTRALIBS) $(LDFLAGS) Any ideas? -- Best regards, Vitaliy

1 0

Wierd wine threading crash
by Andrei Barbu 04 Jul '04

04 Jul '04

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=c0000005 flags=0 addr=0x4fb13f 0011:trace:seh:EXC_RtlRaiseException info[0]=00000000 0011:trace:seh:EXC_RtlRaiseException info[1]=00a63834 0011:trace:seh:EXC_RtlRaiseException eax=000362a2 ebx=00000001 ecx=00000001 edx=00000000 esi=00000000 edi=00000320 0011:trace:seh:EXC_RtlRaiseException ebp=4073a920 esp=40738a98 cs=0073 ds=007b es=007b fs=0033 gs=0007 flags=00010246 First chance exception: page fault on read access to 0x00a63834 in 32-bit code (0x004fb13f). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:0007 EIP:004fb13f ESP:40738a98 EBP:4073a920 EFLAGS:00010246( - 00 -RIZP1) EAX:000362a2 EBX:00000001 ECX:00000001 EDX:00000000 ESI:00000000 EDI:00000320 Stack dump: 0x00000000: 00000000 00000000 00000000 00000000 0x00000010: 00000000 00000000 00000000 00000000 0x00000020: 00000000 00000000 00000000 00000000 0x00000030: 00000000 00000000 00000000 00000000 0x00000040: 00000000 00000000 00000000 00000000 0x00000050: 00000000 00000000 00000000 00000000 0x00000060: Backtrace: =>1 0x004fb13f (0x4073a920) 2 0x004e5cd0 (0x4073a94c) 3 0x004ef883 (0x4073fda4) 4 0x004f5ae1 (0x4073fdc0) 5 0x005206d8 (0x4073fde0) 6 0x0052091f (0x4073fe00) 7 0x00520d07 (0x4073fe1c) 8 0x00522a1b (0x4073fe90) 9 0x0064dd06 (0x4073ff20) 10 0x4057f352 start_process+0xf2(arg=0x0) [process.c:980] in kernel32 (0x4073fff4) 11 0x40044091 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) 0x004fb13f: movb 0x98adac(,%eax,4),%dl The error happens regularly every time the 1st turn is ended (it's turn based, which makes things simpler in this case) Any ideas? By the way, the above only happens once in a while, it's more common for the stack to be full of ??s or winedbg failing to get any backtraces.

2 1

16-bit application fails due to regression in NE-module handling
by Saulius Krasuckas 03 Jul '04

03 Jul '04

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: [s2@katleriai wine]$ cat include/winerror.h | grep ' \+32$' #define ERROR_SHARING_VIOLATION 32 The quick analysis of the patch [1] revealed me two points: + handle = FILE_CreateFile( full_name.long_name, GENERIC_READ|GENERIC_WRITE, 0, + NULL, OPEN_EXISTING, 0, 0, TRUE, + GetDriveTypeW( full_name.short_name ) ); ... /* Open file */ - if ((hFile = OpenFile16( name, &ofs, OF_READ )) == HFILE_ERROR16) + if ((hFile = OpenFile16( name, &ofs, OF_READ|OF_SHARE_DENY_WRITE )) == HFILE_ERROR16) return (HMODULE16)2; /* File not found */ which confused me a bit. By doing some wild guess I tried to revert last mentioned change. Heh, reversing this line really lets the app to succeed. My discovery may imply I should write some additional wine-tests, but I'd like to ask in such case: do I need the test (for example of OpenFile16() function) to be 16-bit style? I mean doing some NE-module-over-ELF and compiling 16-bit app within Wine(lib). If yes, then how it should be done? If no, then what should I do else to make Wine happy or even to submit the correct patch? Yes, I was a bit too lazy to RSFM. TIA.

1 1

Pango for BiDi
by Mike Hearn 03 Jul '04

03 Jul '04

Hi Shachar, I am reading your interview and a few words jumped out at me, mostly "BiDi", "shaping" and "unicode" - very vague I know, but if I understand correctly Pango is a library with advanced support for shaping and laying out all kinds of different scripts. Only stopper I can think of would be that it uses UTF-8 not UTF-16. Have you looked at this, or am I talking smack? thanks -mike

2 5

Assertion in dlls/ntdll/loader.c
by Jon Griffiths 03 Jul '04

03 Jul '04

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 native dll at all (since this is the only native dll I'm using). Using all builtins does not hit this assert. I don't really grok what this function is doing, but commenting it out allows the app the start up with no ill efects. Any ideas? Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

1 0

Re: Pango for BiDi
by Shachar Shemesh 03 Jul '04

03 Jul '04

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.com/cvs/icu/~checkout~/icu/license.html and it > appears to be under the X11 licence which is GPL compatible. > > IANAL but unless there is something I missed, I see no reason why > debian couldnt include ICU (and hence WINE with ICU support) in the > debian package system. > The problem is not a legal one. The problem is a technological one. ICU is mangling the library's version into the symbols, making it impossible to dynamically link the library. As a result, most distros don't carry ICU as a package. Shachar

1 0

Re: [Mono-winforms-list] Fw: [Mono-list] System.Windows.Forms plans.
by Peter Dennis Bartok 03 Jul '04

03 Jul '04

May I remind you that this thread was started by you, asking why we are abandoning Wine, not by me complaining about Wine. All I did was give you the reasons why we are no longer using Wine. You may not like them, you may disagree with them, but the decision has been made. And there is really nothing to be gained in nitpicking or pointing fingers. I don't understand the comment about managed Quake, but we don't have to create managed Wine. We simply have to create the SWF controls in managed code and the underlying SWF framework. Wine doesn't have anything to do with the framework, anyway, so it's down to the controls. And even by using the Wine controls we still would have to either modify Wine to support the additional functionality required by SWF, or subclass them, basically recreating the drawing code for those controls and just using the WndProc messages from Wine. So, you can see it's really just a small step to then drop Wine and handle the management of Windows ourselves instead of using Wine for it. Not trying to be rude either. You asked, I answered. Peter -----Original Message----- From: "Steven Edwards" <steven_ed4153(a)yahoo.com> To: "Peter Dennis Bartok" <peter(a)novonyx.com>; <mono-winforms-list(a)ximian.com> Cc: <wine-devel(a)winehq.com> Date: Thursday, 01 July, 2004 21:03 Subject: Re: [Mono-winforms-list] Fw: [Mono-list] System.Windows.Forms plans. >Hello Peter, > >I am not trying to be rude but... > >--- Peter Dennis Bartok <peter(a)novonyx.com> wrote: >> >Rather than spending a whole lot of time rewritting things wouldnt >> it >> >be better to help the Wine project get stable and move to the 1.0 >> goal? >> >There is a roadmap and TODO on Winehq of things that are needed for >> >1.0. >> No, it wouldn't. Even if Wine already was 1.0 we still would not have >> the >> portability we're trying to get (ie. run on Solaris Sparc, Mac OS, >> etc) and > >Well Winelib does run on PPC and the port to Sparc is mostly done. 99% >of Wine even compiles on Alpha here for me. See > >http://www.winehq.com/site/status_porting > >> debugging would still be almost impossible (Wine does funky stuff >> with >> register for thread storage, special stuff would be required to setup >> Mono-created threads before they'd be able to call Wine functions, >> etc). >> Also, there doesn't seem to be much interest from the Wine community >> to do >> anything that helps using Wine with SWF/Mono. We've had to resort to >> some >> quite complicated mechanisms to even be able to use Wine as a shared, >> runtime attached library, after Alexandre rejected a patch that only >> touched >> six lines of existing Wine code and added a new library to Wine, to >> allow >> straightforward use of Wine as a library. Having to take instead the >> complicated route it now means that many people are having problems >> getting >> SWF to run at all, with due to strict path dependencies. > >I was there when Miguel came online to ask why the patch was not merged >and I also seem to recall Alexandre proposed a fix the would work and >seemed to make Miguel happy. > >See: >http://www.winehq.org/hypermail/wine-devel/2004/03/0150.html > >> Another problem was that we had to spend way too much time tracking >> what >> changed from one Wine version to the next. For example from April to >> May, >> the wine_get_unix_file_name() function arguments were changed (I'm >> not even >> asking why it was changed instead of introducing a new function with >> different arguments and leaving the old one for those people who >> might use >> it). Since I can't require always the latest Wine version, I have to >> come up >> with code figuring out what Wine version might be running, and write >> code to >> make version dependent Wine calls. I'd rather spend that time >> improving SWF. > >Once again how can you fuss about unstable interfaces on a project that >does not have a stable release? You could work with Winehq to create >those stable interfaces. > >Besides how can you blame the Wine project for tracking changes when >the first patch Mono submitted was this? > >http://primates.ximian.com/~duncan/mono-wine/sources/mono-wine.patch > >A whole bunch of #ifdefs and other kludges that violates Winehq coding >standards. > >> Notice how people complain on this mailing that they're having >> problems >> getting even basic stuff going? The SWF code works, it's the >> interaction >> with Wine that's mostly causing the problems. Again, as I said, it >> will >> become much easier for the regular user once the Wine dependency is >> removed >> and the controls are all in managed code. > >Alright well I am not claiming to know very much about the project. >Like I said I only lurk here because I care about how its going to run >on ReactOS. I guess my final though on the matter is that if Vertigo >Software could make a mananged Quake2, how hard can it be for you to >make a managed Wine? > >Thanks >Steven > > > > >__________________________________ >Do you Yahoo!? >Yahoo! Mail - 50x more storage than other providers! >http://promotions.yahoo.com/new_mail >_______________________________________________ >Mono-winforms-list maillist - Mono-winforms-list(a)lists.ximian.com >http://lists.ximian.com/mailman/listinfo/mono-winforms-list > >

8 9

IE6 installation error. would you please give me a suggession
by Shiva Ram Krishna 03 Jul '04

03 Jul '04

Dear Sir/Madam, I downloaded the latest cvs of wine and compiled it. All went well but it seems that the regsvr32.exe.so file wasn't created properly. If check the dependency o f expand.exe.so, winver.exe.so, winepath.exe.so, I can see all the proper files that it needs but if I do it on regsvr32.exe.so, it says "regsvr32.exe.so: Not a dynamic executable". I have that his problem for the last 3-4 months. I used a text editor and it seems that the header is the regsvr 32.exe.so looks like an msdos .exe file (ex, first 2 characters have "MZ") but e xpand,winver, and winepath start with "^^". The reason I have notified it is when I run ie 5/6, It stops at the point saying "/usr/local/bin/wine: cannot open builtin library for 'C:\windows\system\regsvr32.exe': /usr/local/lib/wine/regsvr32.exe.so: invalid ELF header". would you please suggest me what I have to do ________________________________________________________________________ Yahoo! India Careers: Over 50,000 jobs online Go to: http://yahoo.naukri.com/

4 3

Re: collation tables
by Dmitry Timoshkov 03 Jul '04

03 Jul '04

"Vitaly Lipatov" <lav(a)altlinux.ru> wrote: > > What app is it? In which way it depends on the collation table > > being MS compatible? > It is 1C, an accounting system, widely used in Russia. > It keep a copy "right" collation table in exe file and compare it > with gotten from system. > > > Crossover Office has a patched version > > libs/unicode/collation.c, could you try it with your > > aplication? > If I have not Crossover Office, how I can try it? There is a Wine tar ball somewhere on the Codeweavers site which is used in the CX Office. It's freely available, since Wine is LGPL'ed. > > > Does anyone knows what is the better way to fix this tables, > > > in which place? Can I fix libs/unicode/cpmap.pl for it? > > > > Yes, that was an idea. > I see it idea is implemented in CrossOver Office already? No, nothing has been done yet, just a bit of thoughts. -- Dmitry.

2 4

taskmgs hangs on edit debug channels
by Andrei Barbu 02 Jul '04

02 Jul '04

The taskmanager dies when trying to edit the debug channels of any programs with the newest CVS (checked out 2 days ago) It just sits there with this: 002e:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000102 ret=409cd43c 002e:Call kernel32._ConfirmSysLevel(40a08ac0) ret=409a3f15 002e:Ret kernel32._ConfirmSysLevel() retval=00000000 ret=409a3f15 002e:Call kernel32.GlobalLock16(0000116f) ret=40999b70 002e:Ret kernel32.GlobalLock16() retval=404326d0 ret=40999b70 002e:Call kernel32.ReleaseThunkLock(41625f7c) ret=409cd30f 002e:Ret kernel32.ReleaseThunkLock() retval=00000000 ret=409cd30f 002e:trace:msg:GetMessageW (116f) mask=0000007f, bits=00000000, changed=00000000, waiting 002e:Call kernel32.ReleaseThunkLock(41625fe4) ret=409cd684 002e:Ret kernel32.ReleaseThunkLock() retval=00000000 ret=409cd684 002e:Call x11drv.MsgWaitForMultipleObjectsEx(00000001,404326d4,ffffffff,00000000,00000000) ret=409cd6c6 002e:Call ntdll.RtlEnterCriticalSection(40d76680) ret=40d54902 002e:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=40d54902 002e:Call ntdll.RtlLeaveCriticalSection(40d76680) ret=40d54932 002e:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=40d54932 002e:Call ntdll.RtlEnterCriticalSection(40d76680) ret=40d54902 002e:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=40d54902 002e:Call ntdll.RtlLeaveCriticalSection(40d76680) ret=40d54932 002e:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=40d54932 002e:Call kernel32.WaitForMultipleObjectsEx(00000002,41625dac,00000000,ffffffff,00000000) ret=40d383db 002e:Call ntdll.NtWaitForMultipleObjects(00000002,41625ba0,00000000,00000000,00000000) ret=40591c85 If I move the mouse it spits out the correct mouse messages which indicate that wine itself is running just fine. The taskmanager window doesn't get redrawn (the black backround around it does). The backtrace from that point is: =>1 0x400636a9 (0x41b2be48) 2 0x402335c2 NTDLL_wait_for_multiple_objects+0x122(count=0x1, handles=0x41b2bf38, flags=0x4, timeout=0x0) [sync.c:587] in ntdll (0x41b2beec) 3 0x40233636 NtWaitForMultipleObjects+0x66(count=0x1, handles=0x41b2bf38, wait_all=0x0, alertable=0x0, timeout=0x0) [sync.c:605] in ntdll (0x41b2bf14) 4 0x40591c85 WaitForMultipleObjectsEx+0xb5(count=0x1, handles=0x41b2c06c, wait_all=0x0, timeout=0xffffffff, alertable=0x0) [sync.c:171] in kernel32 (0x41b2c044) 5 0x40591b1a WaitForSingleObject+0x3a(handle=0x6c, timeout=0xffffffff) [sync.c:99] in kernel32 (0x41b2c064) 6 0x40656867 ProcessPageRefreshThread+0x87(lpParameter=0x0) [procpage.c:511] in taskmgr (0x41b2c1a4) 7 0x40598fba THREAD_Start+0x11a(ptr=0x40450220) [thread.c:107] in kernel32 (0x41b2c27c) 8 0x40234fe9 start_thread+0x199(info=0x40450240) [thread.c:198] in ntdll (0x41b2cacc) 9 0x4005df70 (0x41b2cbcc) 10 0x4017e40a (0x00000000) Any ideas? I'm not quite versed enough in wine to know what's happening too well. I realise it's a thread waiting for another that apparently never finishes.. or I think it is, and I'm kind of lost from there. Thanks, Andrei

2 1

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 July 2004