wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

an odd focus problem
by Paul R Streitman 02 Jun '04

02 Jun '04

I have an odd focus problem to report. This problem is a regression, some time since 4/26 (which does not exhibit the problem). I have not had time to pull interative CVS levels to find out exactly when it appeared, but it was definitely failing last week (at first, I thought that it might be a window manager problem). The problem has to do with virtual desktop focus. If I switch to a different virtual desktop and back, my wine application disappears! There are no error messages or anything (including when running winedbg without any options), its just become totally invisible. It also disappears from the window manager task list. I believe that the application is still running, based on terminal output and the fact that the various wine processes still show up in top. In fact, with Lotus Notes (6.5.1), you have to kill off those processes to restart a 'disappeared' Notes. This problem is readily reproducable. Just define virtual desktops in Afterstep (1.8.11) or Enlightenment (the 0.65 snapshot of 16.7, for example), and run 'wine notepad'. Switch focus to another virtual desktop and back - the notepad is gone! I am running Mandrake cooker, kernel 2.6.7-rc1-mm1, and a May 17th CVS snapshot of x.org. Thanks, Paul z/OS core components development Internet: prs(a)us.ibm.com

1 0

CVS compile failure
by Paul R Streitman 02 Jun '04

02 Jun '04

When compiling CVS, I get: ... gcc -c -I. -I. -I../include -I../include -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o pthread.o pthread.c gcc -o wine-pthread -Wl,--export-dynamic -Wl,--section-start,.interp=0x77f00400 pthread.o main.o -L../libs/wine -lwine -L../libs/port -lwine_port -lpthread gcc -c -I. -I. -I../include -I../include -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o preloader.o preloader.c gcc -o wine-preloader -static -nostartfiles -Wl,-Ttext=0x78000000 preloader.o -L../libs/port -lwine_port /usr/bin/ld: cannot find -lc collect2: ld returned 1 exit status make[1]: *** [wine-preloader] Error 1 make[1]: Leaving directory `/home/wine0601/loader' make: *** [loader] Error 2 This is on Mandrake cooker, gcc 3.3.2. Thanks, Paul z/OS core components development Internet: prs(a)us.ibm.com

2 1

winemaker /configuration file
by Ahmed Abdel Aal 02 Jun '04

02 Jun '04

Hi, I installed new version of wine -20040505 but when I tried to use winemaker to gnerate configuration file. it is not generated and generate Makefile direct. is it and error in winemaker or updates in new version. thanks aallabs

2 1

Re: [OLEAUT32] Resend: Typelibs, Better handling of References
by Mike Hearn 02 Jun '04

02 Jun '04

On Tue, 2004-06-01 at 09:33 +0200, Raphael wrote: > Now we go further on many InstallShields (i'm using Prince Of Persia and > SplinterCell Demo) but InstallShield seems to freeze after creating the > "desktop/background" window (i only see Window messaging traces). > Any expert to help me ? > helpppp, i want a lot to use SplinterCell Demo :( Are you sure it's frozen, or is it actually that the big blue window was created as override-redirect so is placed always-on-top by your window manager? What happens if you use desktop mode? thanks -mike

3 3

Re: RSABase: Created Needed Registry Key in DllRegisterServer (Try 2)
by Robert Shearman 02 Jun '04

02 Jun '04

On Wed, 2004-06-02 at 01:39, Raphael wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wednesday 02 June 2004 00:51, Robert Shearman wrote: > > On Tue, 2004-06-01 at 22:53, Robert Shearman wrote: > > > Hi, > > > > > > The second registry key added by this patch is needed for rsabase to be > > > used properly. > > > > > > Rob > > > > Now with correct registry key. > > > > Changelog: > > Created needed registry key in DllRegisterServer. > > More Complete Patch Again :) Too late :) Alexandre has already committed the patch. You'll have to re-diff. Rob

1 0

CVS Wine doesn't build on NVidia system (2004-05-01)
by Saulius Krasuckas 01 Jun '04

01 Jun '04

Am I the only NVidia owner who has this problem? I did 'make clean' and 'cvs -PAd' and now am getting following: make[2]: Entering directory `/mnt/antras/usr/src/wine-cvs/wine/dlls/uuid' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/mnt/antras/usr/src/wine-cvs/wine/dlls/uuid' make[2]: Entering directory `/mnt/antras/usr/src/wine-cvs/wine/dlls/glu32' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/mnt/antras/usr/src/wine-cvs/wine/dlls/glu32' make[2]: Entering directory `/mnt/antras/usr/src/wine-cvs/wine/dlls/d3d8' gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o utils.o utils.c utils.c: In function `set_tex_op': utils.c:1605: `GL_MODULATE_ADD_ATI_EXT' undeclared (first use in this function) utils.c:1605: (Each undeclared identifier is reported only once utils.c:1605: for each function it appears in.) make[2]: *** [utils.o] Error 1 make[2]: Leaving directory `/mnt/antras/usr/src/wine-cvs/wine/dlls/d3d8' make[1]: *** [d3d8] Error 2 make[1]: Leaving directory `/mnt/antras/usr/src/wine-cvs/wine/dlls' make: *** [dlls] Error 2 Patch of cause is http://cvs.winehq.org/patch.py?id=12484 . Nothing changed in my NVidia drivers setup, nor in GL headers on my system AFAIK. # lsmod | grep nv nvidia 2123744 6 (autoclean) # strings /lib/modules/`uname -r`/kernel/drivers/video/nvidia.o | grep id: nvidia id: NVIDIA Linux x86 NVIDIA Kernel Module 1.0-5336 Wed Jan 14 18:29:26 PST 2004 Help :)

4 4

Re: Minor logging improvements to freetype.c
by Huw D M Davies 01 Jun '04

01 Jun '04

On Mon, May 31, 2004 at 09:47:35PM +0100, Mike Hearn wrote: > Mike Hearn <mh(a)codeweavers.com> > Change some TRACEs into WARNs, WARN on skipping font due to wrong format. > > Index: dlls/gdi/freetype.c > =================================================================== > RCS file: /home/wine/wine/dlls/gdi/freetype.c,v > retrieving revision 1.60 > diff -u -r1.60 freetype.c > --- dlls/gdi/freetype.c 20 Apr 2004 01:12:18 -0000 1.60 > +++ dlls/gdi/freetype.c 31 May 2004 20:47:29 -0000 > @@ -316,20 +316,21 @@ > } > > if(!FT_IS_SFNT(ft_face)) { /* for now we'll skip everything but TT/OT */ > + WARN("skipping font file %s, not TrueType/OpenType font\n", debugstr_a(file)); > pFT_Done_Face(ft_face); > return FALSE; > } > if(!pFT_Get_Sfnt_Table(ft_face, ft_sfnt_os2) || > !pFT_Get_Sfnt_Table(ft_face, ft_sfnt_hhea) || > !(pHeader = pFT_Get_Sfnt_Table(ft_face, ft_sfnt_head))) { > - TRACE("Font file %s lacks either an OS2, HHEA or HEAD table.\n" > + WARN("Font file %s lacks either an OS2, HHEA or HEAD table.\n" > "Skipping this font.\n", debugstr_a(file)); > pFT_Done_Face(ft_face); > return FALSE; > } > > if(!ft_face->family_name || !ft_face->style_name) { > - TRACE("Font file %s lacks either a family or style name\n", debugstr_a(file)); > + WARN("Font file %s lacks either a family or style name\n", debugstr_a(file)); > pFT_Done_Face(ft_face); > return FALSE; > } You could argue that these three should really be FIXMEs > @@ -369,13 +370,13 @@ > (*insertface)->font_version, pHeader->Font_Revision); > > if(fake_family) { > - TRACE("This font is a replacement but the original really exists, so we'll skip the replacement\n"); > + WARN("This font is a replacement but the original really exists, so we'll skip the replacement\n"); > HeapFree(GetProcessHeap(), 0, StyleW); > pFT_Done_Face(ft_face); > return FALSE; > } > if(pHeader->Font_Revision <= (*insertface)->font_version) { > - TRACE("Original font is newer so skipping this one\n"); > + WARN("Original font is newer so skipping this one\n"); > HeapFree(GetProcessHeap(), 0, StyleW); > pFT_Done_Face(ft_face); > return FALSE; > I don't think these two should be warnings. It's perfectly possible to have two copies of the same font installed and you don't want to confuse users by issuing warnings about something where we actually do the right thing. Huw. -- Huw Davies huw(a)codeweavers.com

2 3

wine
by Mike 01 Jun '04

01 Jun '04

m tring to play a game using wine does anybody no why i receive this message and if so how to fix? Thanks Mike > Exception at EIP=0081F2B4: ACCESS VIOLATION > While attempting to read memory at 00000000 > ----------------------------------------------------- > EAX=00000000 EBX=00000001 ECX=0000013C EDX=41796208 > ESI=000006D7 EDI=407CFD7C EBP=00000000 ESP=407CFC30 >

2 1

DCOM (was Re: Fix CoMarshalInterThreadInterfaceInStream)
by Robert Shearman 01 Jun '04

01 Jun '04

On Sat, 2004-05-29 at 00:44, Mike Hearn wrote: > Of course calling CoMarshalInterface in this case doesn't actually do > much, but if it helps InstallShield OK. Actually, it does. It appears as though the interface marshaling functions are all compatible with each other on Windows (even though MSDN says that they aren't and then says they use the same code as the others). Presumably InstallShield was quite understandably passing the IStream from on the two functions that were fixed into one of the other (supposedly compatible) functions and then that function failed because it wasn't the right format. Even on Wine, those other functions, such as CoMarshalInterface do actually attempt to get a marshaller or just use the standard one and > If you are interested in this > stuff I'd say trying to merge the TransGaming patch would be a good > start. I assume you mean this: http://www.winehq.com/hypermail/wine-devel/2003/07/att-0179/01-ole.diff__ch… I've had a look at what is in there. The way I interpret it, there are a couple of sections: o Auto-generated marshaling code -- this is fine to be included in Wine and could probably be done so at any point o Converting COM (ole32) to using RPC -- as you can see by the comments in the code, this isn't really done through the correct interfaces yet (and this is stuff that you only want implement once) and hence I'm not confident that the related stuff is done correctly. There are useful bits, but I doubt I will use all of that code. o Rewriting the Type Library marshaller -- this isn't much better than the code we have at the moment. Again, this isn't done through the correct interfaces - I would prefer to use the stubless RPC to do the same, but it would probably mean writing half of MIDL into RPCRT4. o Miscellaneous header and bug fixes -- I'll check whether they are included in Wine already and check whether they are correct or workarounds for something in the patch > This includes a lot of what you've done lately such as proper > apartments, proper inter-thread marshalling and so on. Otherwise the > codebase drift is going to get even worse :( I would prefer it if we could all work on the same codebase, but as you know the licensing restrictions largely prevent that. I hope (wish?) that Transgaming will use more and more LGPL modules from Wine and only develop separately the ones that are core to their business. They have been kind of informally doing that by submitting their RPC / OLE patches back to Wine, but they are working from the ReWind codebase, not Wine and they are not in sync. Rob P.S. I am currently putting together a plan for tackling RPC / DCOM and will present it to wine-devel soon.

2 4

Re: Various MDI children activation fixes
by Dmitry Timoshkov 01 Jun '04

01 Jun '04

"Dmitry Timoshkov" <dmitry(a)baikal.ru> wrote: > I'm also attaching latest cersion of my MDI tool which I'm using > for all MDI related investigations, perhaps it will be useful for > somebody else. Here it is. -- Dmitry.

1 0

Current Wine CVS status
by Dmitry Timoshkov 01 Jun '04

01 Jun '04

Hello all (mostly Alexandre :-)), running today's ~/wine/wine under an old RH 6.2 install I get the following: Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...] You have invoked `ld.so', the helper program for shared library executables. This program usually lives in the file `/lib/ld.so', and special directives in executable files using ELF shared libraries tell the system's program loader to load the helper program from this file. This helper program loads the shared libraries needed by the program executable, prepares the program to run, and runs it. You may invoke this helper program directly from the command line to load and run an ELF executable file; this is like executing that file itself, but always uses this helper program from the file you specified, instead of the helper program file specified in the executable file you run. This is mostly of use for maintainers to test new versions of this helper program; chances are you did not intend to run this program. --list list all dependencies and how they are resolved --verify verify that given object really is a dynamically linked object we get handle --library-path PATH use given PATH instead of content of the environment variable LD_LIBRARY_PATH --inhibit-rpath LIST ignore RPATH information in object names in LIST -- Dmitry.

2 2

Re: Wine bug with delphi Menus
by Robert van Herk 01 Jun '04

01 Jun '04

Dan Kegel wrote: > Please do put the source and executable of your demo > app online at some web page, and post the URL on wine-devel. Okay, please feel free to grab it from http://www.students.cs.uu.nl/people/rherk/DelphiMenuTest.tar.gz . Greetings, Robert P.S. Hope I got the bonus :-P

1 0

broken mingw build
by Kevin Koltzau 01 Jun '04

01 Jun '04

This patch http://cvs.winehq.org/patch.py?id=12495 seems to have broken the mingw build, currently getting i386-mingw32msvc-gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -Wall -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o interlocked.o interlocked.c {standard input}: Assembler messages: {standard input}:124: Error: unknown pseudo-op: `.previous' {standard input}:135: Error: unknown pseudo-op: `.previous' {standard input}:145: Error: unknown pseudo-op: `.previous' {standard input}:155: Error: unknown pseudo-op: `.previous' {standard input}:165: Error: unknown pseudo-op: `.previous' make[2]: *** [interlocked.o] Error 1

3 2

Re: Use TRACE rather than FIXME for check_resource_write
by Dmitry Timoshkov 01 Jun '04

01 Jun '04

[forgot to cc wine-devel] "Mike Hearn" <mh(a)codeweavers.com> wrote: > No need for this to be a fixme, we can't fix broken apps anyway and it > just confuses people. > > Mike Hearn <mh(a)codeweavers.com> > Use TRACE rather than FIXME for check_resource_write I have found and fixed at least one bug in Wine itself thanks to this fixme message. -- Dmitry.

1 0

Re: [DInput] Fix RailroadTycoon
by Christian Costa 31 May '04

31 May '04

Lionel Ulmer wrote: >Sorry for the huge diff, but I got sick when I saw my previous 2-space >indenting style, so I had to re-indent everything... For people who want to >do a code review, I could send them a 'diff -w' version :-) > Now, you're proposing, that would be cool. :-) > >And before anyone complains, yeah, I should have sent two patches (one >cosmetic, one with the real meat in it) :-) > > Lionel > >Changelog: > - some TRACEing improvements > - fix mouse Acquire which switched right and middle buttons > - reset the mouse cursor at its original location on Unacquiring the device > > > > > Bye, Christian

2 2

Making a system DLL unavailable (problem with COMMCTRL)
by Samuel Audet 31 May '04

31 May '04

Hello, I have a Windows 3.1 application here that uses the OWL library. I have problems running it properly, and I have found the following: http://www.xploiter.com/programming/c/borland/3031.html Looking at what wine outputs when I use "WINEDEBUG=dll" or loaddll, I see that my program tries to load commctrl.dll and always succeeds. The problem is, I want it not to succeed, since AFAIK, 16 bit COMMCTRL functionality is not implemented in WINE, and the OWL library has a backup plan where it emulates some of the controls (like described on the site above) when it can't find COMMCTRL, which is what it does in Windows 2000 or XP for example. I have confirmed that the COMMCTRL is at the source of the problem by using one from a Windows 98 installation. Dialogs that are not showing using WINE's builtin COMMCTRL are now showing (although they are having sizing problems... anybody might know why?). Is there like a "disable" option in the [DllOverrides] section? Or some other way to disable a system DLL? I can't seem to just be able to "remove" commctrl.dll since even 32 bits builtin DLL (in this case comctl32.dll) require the 16 bit counterpart. In this case, when comdlg32 tries to load, it loads comctl32 and fails because it can't load commctrl. I don't think it's a good idea to make 32 bits DLL be dependent of their 16 bit counterpart. Thank for any input! -- Samuel Audet <guardia(a)step.polymtl.ca> http://www.step.polymtl.ca/~guardia/

3 5

Using objdump
by James Courtier-Dutton 31 May '04

31 May '04

I have used objdump in the past to disassemble and check the code that is generated in a .so or .o file. How do I modify objdump so I can get it do the same with win32 .exe and .dll files ? Cheers James

4 4

Crash due to _fini
by Rajeev Bansal 31 May '04

31 May '04

Hi i am trying to link wine library(msvcrt.dll.so) with my code but i getting segv in _fini call of msvcrt library Please tell me a way so that i can use wine libraries directly without winegcc or specs file on using winegcc for code which contains new and delete operator it gives undefined reference to following symbols operator new(unsigned) operator delete[](void*) _Unwind_Resume __gxx_personality_v0 please help me to resolve above symbols waiting for response Thanks Rajeev Test Program : #include <dlfcn.h> #include <direct.h> #include <math.h> #include <stdio.h> main() { char *a; char *b; double d; void *mod, *ker; const char *error; mod=dlopen("msvcrt.dll.so",RTLD_LAZY); ker=dlopen("kernel32.dll.so",RTLD_LAZY); if(mod) { if ((error = dlerror())) { printf("Couldn't find getcwd: %s\n", error); } if(dlsym(mod, "getcwd")){ printf("found"); b=getcwd(a,20); } dlclose(mod); dlclose(ker); } //end if return (0); } //end main Build command : g++ -g -Wall -c -I/home/timex/wine/wine-20040505/include -I. -I/home/timex/wine/wine-20040505/include/msvcrt test.cpp g++ -g -ldl /home/timex/wine/wine-20040505/dlls/msvcrt.dll.so test.o Debugger output [me@cvs TUCP]$ gdb -n GNU gdb Red Hat Linux (5.2.1-4) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux". (gdb) file ./a.out Reading symbols from ./a.out...done. (gdb) break test.cpp:10 Breakpoint 1 at 0x80486cc: file test.cpp, line 10. (gdb) run Starting program: /home/a.out Breakpoint 1, main () at test.cpp:14 14 mod=dlopen("msvcrt.dll.so",RTLD_LAZY); (gdb) next 15 ker=dlopen("kernel32.dll.so",RTLD_LAZY); (gdb) disp mod 1: mod = (void *) 0x40013578 (gdb) disp ker 2: ker = (void *) 0x4026cc40 (gdb) next 16 if(mod) 2: ker = (void *) 0x8049b60 1: mod = (void *) 0x40013578 (gdb) next 19 if(dlsym(mod, "getcwd")) 2: ker = (void *) 0x8049b60 1: mod = (void *) 0x40013578 (gdb) next 20 {printf("found"); 2: ker = (void *) 0x8049b60 1: mod = (void *) 0x40013578 (gdb) next 21 b=getcwd(a,20); 2: ker = (void *) 0x8049b60 1: mod = (void *) 0x40013578 (gdb) step getcwd (buf=0x4026cc40 "T\v\022", size=20) at direct.h:73 73 static inline char* getcwd(char * buf, int size) { return _getcwd(buf, size); } (gdb) step _getcwd (buf=0x4026cc40 "T\v\022", size=20) at dir.c:424 424 int dir_len = GetCurrentDirectoryA(MAX_PATH,dir); Current language: auto; currently c (gdb) step 422 { (gdb) step 424 int dir_len = GetCurrentDirectoryA(MAX_PATH,dir); (gdb) step 422 { (gdb) step 424 int dir_len = GetCurrentDirectoryA(MAX_PATH,dir); (gdb) step Program received signal SIGTRAP, Trace/breakpoint trap. 0x40062179 in _fini () from /home/timex/wine/wine-20040505/dlls/msvcrt.dll.so (gdb) bt #0 0x40062179 in _fini () from /home/timex/wine/wine-20040505/dlls/msvcrt.dll.so #1 0x08048790 in getcwd (buf=0x4026cc40 "T\v\022", size=20) at direct.h:73 #2 0x08048730 in main () at test.cpp:21 #3 0x40161b84 in __libc_start_main () from /lib/libc.so.6 (gdb) --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.642 / Virus Database: 410 - Release Date: 3/24/2004

2 1

segfault fault at startup
by Florian Goth 31 May '04

31 May '04

H! I have the same Problem. I get a segfault, when I do "wine myapp" and when I do "wine-pthread" I'm using a SuSE System ( ~ 9.0 ) with kernel 2.6.6 and gcc 3.4.0 this is the gdb output: (gdb) set follow-fork-mode child (gdb) r Starting program: /usr/local/bin/wine [New Thread 16384 (LWP 5206)] [New Thread 32769 (LWP 5209)] [New Thread 16386 (LWP 5210)] Cannot find user-level thread for LWP 5206: generic error (gdb) this is some of the last strace output I get: t_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 writev(4, [{"$\0\0\0002\0\0\0\0\0\0\0\0\0\0\200\0\0\0\0\1\0\0\0\1\0"..., 64}, {"/home/sifff/.wine/dosdevices/c:/"..., 50}], 2) = 114 read(5, "\0\0\0\0\0\0\0\0000\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 write(4, "G\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0A\0\0\0\5\0\17\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0004\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 write(4, "I\0\0\0\0\0\0\0\0\0\0\0004\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0000M\0A\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 write(4, "&\0\0\0\0\0\0\0\0\0\0\0004\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\377\377\377\377\1\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"4\0\0\0", 4}], msg_controllen=16, msg_control=0xbfffab68, , msg_flags=0}, 0) = 4 fcntl64(9, F_SETFD, FD_CLOEXEC) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 write(4, "\26\0\0\0\0\0\0\0\0\0\0\0004\0\0\0\0\0\0\0\0\0\0\0\t\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\t\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 dup(9) = 10 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 write(4, "&\0\0\0\0\0\0\0\0\0\0\0004\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\t\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 dup(9) = 11 fstat64(11, {st_mode=S_IFREG|0755, st_size=5054496, ...}) = 0 fstatfs(11, {f_type="MSDOS_SUPER_MAGIC", f_bsize=4096, f_blocks=358741, f_bfree=57991, f_files=0, f_ffree=0, f_namelen=260}) = 0 close(11) = 0 mmap2(NULL, 5124096, PROT_READ, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40860000 munmap(0x40d33000, 65536) = 0 mmap2(0x40860000, 5058560, PROT_READ, MAP_PRIVATE|MAP_FIXED, 10, 0) = 0x40860000 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 write(4, "\27\0\0\0\0\0\0\0\0\0\0\0\377\377\377\3774\0\0\0\377\377"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0008\0\0\0\377\377\377\377\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 close(10) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 write(4, "\25\0\0\0\0\0\0\0\0\0\0\0004\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\t\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 close(9) = 0 getpid() = 5154 open("/tmp/reg14220000.tmp", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0666) = 9 fcntl64(9, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE) fstat64(9, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40d33000 _llseek(9, 0, [0], SEEK_CUR) = 0 brk(0) = 0x7800a000 brk(0x7800b000) = 0x7800b000 write(9, "WINE REGISTRY Version 2\n[MIME\\\\D"..., 131072) = 131072 write(9, "trolSet\\\\Control\\\\DeviceClasses\\"..., 131072) = 131072 write(9, "&PID_0095&INST_0\"\n\"RefCount\"=dwo"..., 131072) = 131072 write(9, "ixer f\\xfcr Aureon 5.1 Fun\"\n\n[Sy"..., 131072) = 131072 write(9, "0,00,00,00,00,00,00,00,00,00,00,"..., 131072) = 131072 write(9, "stem\\\\CurrentControlSet\\\\Service"..., 131072) = 131072 brk(0) = 0x7800b000 brk(0x7800c000) = 0x7800c000 brk(0) = 0x7800c000 brk(0x7800d000) = 0x7800d000 brk(0) = 0x7800d000 brk(0x7800e000) = 0x7800e000 brk(0) = 0x7800e000 brk(0x7800f000) = 0x7800f000 brk(0) = 0x7800f000 brk(0x78010000) = 0x78010000 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Thanks, Flo

1 0

segfault fault at startup
by terra＠gnome.org 31 May '04

31 May '04

A newly built wine segfaults for me. No args: welinder@anemone:~/wine> ./wine Segmentation fault No core. gdb just reports: welinder@anemone:~/wine> LD_LIBRARY_PATH=/home/welinder/wine/libs/wine gdb loader/wine ... (gdb) r Starting program: /home/welinder/wine/loader/wine [New Thread 16384 (LWP 28622)] [New Thread 32769 (LWP 28624)] [New Thread 16386 (LWP 28625)] Cannot find user-level thread for LWP 28622: generic error This is with a suse 9.0 system. Ideas? Morten

4 4

Re: segfault fault at startup
by terra＠gnome.org 31 May '04

31 May '04

No change with 'set follow-fork-mode child', or even '... ask'. With strace, I get... strace -i $WINELOADER [...] [40113d71] close(9) = 0 [400f0c37] getpid() = 30133 [40113ce3] open("/tmp/reg75b50000.tmp", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0666) = 9 [401140b8] fcntl64(9, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE) [40112dcb] fstat64(9, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 [4011e6ed] old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40032000 [40121ce7] _llseek(9, 0, [0], SEEK_CUR) = 0 [400b7fdc] --- SIGSEGV (Segmentation fault) @ 0 (0) --- upeek: ptrace(PTRACE_PEEKUSER,30133,48,0): No such process [????????] +++ killed by SIGSEGV +++ Hmm... welinder@anemone:~/wine> printenv | grep WINE WINESERVER=/home/welinder/wine/server/wineserver WINELOADER=/home/welinder/wine/loader/wine WINEDLLPATH=/home/welinder/wine/dlls:/home/welinder/wine/programs:/home/welinder/wine/dlls:/home/welinder/wine/programs welinder@anemone:~/wine> gdb $WINELOADER GNU gdb 5.3.92 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-suse-linux"... (gdb) tb main Breakpoint 1 at 0x8048857: file glibc.c, line 76. (gdb) r Starting program: /home/welinder/wine/loader/wine [New Thread 16384 (LWP 30150)] [Switching to Thread 16384 (LWP 30150)] main (argc=1, argv=0xbffff414) at glibc.c:76 76 const char *loader = getenv( "WINELOADER" ); (gdb) info symbol 0x400b7fdc nl_langinfo + 60 in section .text (I'm not sure I believe that) Morten

1 0

Help with winedbg
by Shachar Shemesh 30 May '04

30 May '04

Hi, I'm trying to get a Visual C compiled program to run on Wine. I have the sources and full debug info for the PE part of the program. Obviously, however, it was not compiled on the same machine on which it is running. To make things even more interesting, I would rather use some GUI frontend for the debugger. As far as I can tell, I have two options to go about this: 1. Use Visual Studio's remote debugging 2. Use winedbg as a gdb backend for ddd Option 1 fails miserably. I suspect the project is just too complex for Visual Studio to handle over the wire. When I try to do that, the Visual Studio front end (the one running on a Windows machine) crashes. This leaves me with just option 2. When I try to run it like that (winedbg --gdb --no-start), winedbg starts ok. When I hook ddd to it, however, winedbg complains about a missing source file (one that is not in the Windows source, btw). In the mean while, ddd claims to time out on the connection, and closes down. Am I missing something? Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/

2 7

Tainted code in User32?
by Steven Edwards 30 May '04

30 May '04

Hello this line: "However, disassembling NT implementation (WIN32K.SYS) reveals that........." in http://source.winehq.org/source/windows/win.c#L845 was introduced in to winehq by the following patch: http://cvs.winehq.com/cvsweb/wine/windows/win.c.diff?r1=1.61&r2=1.62 Does this not violate a clean rooming the implementation? The ReactOS code is a derived work of the Wine code in the case and if soon then we have to remove it. Thanks Steven __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

4 3

Re: EnumDateFormats patch
by Alexandre Julliard 29 May '04

29 May '04

Wililam <computerman413(a)ezrs.com> writes: > Here is the ChangeLog entry: > > * dlls/kernel/lcformat.c > William Lahti <computerman413(a)ezrs.com> > > - Implemented the EnumDateFormatsW function and vastly improved upon the > EnumDateFormatsA function. This stuff clearly needs to be stored as data in the nls resource files, not in the code. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [Fwd: winetest: copy and submit manually]
by Dimitrie O. Paun 29 May '04

29 May '04

On Fri, May 28, 2004 at 07:42:54AM -0400, Robert Reif wrote: > It appears that the locale.c test on line 1866 and 1867 fail a lot > (0xffff?). Can you try to see why this happens on your box? > File too big (# > 1 MB), copy and submit manually > > where # is around 8 meg. Yeah, there's no point in submitting such a large file, it will be rejected by the server. The message about submitting manually is confusing, it should be 'this is a problem, please report (and investigate, if at all possible :))' -- Dimi.

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