May 2004 - Wine-Devel - list.winehq.org

text edit box not painting text ( on form startup )
by Doug Herbert March 9, 2005

March 9, 2005

( I have posted a similiar question in wine-users, don't flame me for doing so, just thinking about this some more, perhaps it may be more a developer question ) Ok, I have a windows app, that runs under wine fine - not quite. This app has a form, with many text field edit boxes on. Quite often these edit boxes already have text values, ie. they are not empty - there is a database behind the form. Anyway, the form shows on the screen, but the text within the edit fields is invisible, until you activate each edit box component. When you leave one edit box to the next, the text remains visible. It seems like the repainting is not working, on initial startup of the form. As a way to debug this database app ( I don't have the source code for it ) I wrote a real basic form app in Visual Studio, with two edit boxes, with data in each. Now this basic app shows the text values immediately on startup. So there must be something different that the database app is not doing. I then ran wine using 'wine --debugmsg +edit programname' for both app's. I see both logging 'Creating ANSI edit control, style = xxxxx' but the style reference is different between apps - I am not sure if this the cause or not. The problem app reports style = 54011104 and the basic app shows style = 50010080. Can somebody explain what this style reference means and how do I force an app to use a certain style of edit box ? What other wine class debugmsg types should I use to narrow down the source of this problem ? Is there anyway I can check to see how the database app is repainting text within the text edit components ? Regards Doug Herbert. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

3 4

Wine bug with delphi Menus
by Robert van Herk Sept. 5, 2004

Sept. 5, 2004

Hi people, I think I discovered a wine bug. In a delphi program, changing the visibility of a menuitem (TMenuItem) causes the whole menu of that form to stop working, when the program is run under Wine. Behind the screens, the setVisible of a menu item calls MenuChanged. This seems to put the menu in such a state that, in wine, all menu components stop doing anything. I've written a small application (455 kb EXE) to show what goes wrong. Would anybody be interested to help me in solving this bug? Would a message trace from Winsight (for example) be of any help? Greetings, Robert

2 1

Precompiled headers?
by Shachar Shemesh July 5, 2004

July 5, 2004

Hi, Is anyone considering putting precompiled headers support into the wine build system? http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html#Precompiled%20He… -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/

2 1

General serial communications issues
by David Purucker June 14, 2004

June 14, 2004

Hello, I have tried several terminal programs (Hyperterm and TeraTerm) under several builds of Wine including Wine-20040505 and they seem to have the same generic problem. They all exhibit the same situation, DATA seems to go OUT, but never seems to come IN. Several other people have experienced the same thing, as seen in this bug report: http://bugs.winehq.org/show_bug.cgi?id=2115 By the way, TeraTerm does work fine in TCP/IP mode, so it's definitely a serial problem. It's freeware available here: http://hp.vector.co.jp/authors/VA002416/teraterm.html It appears to be a fundamental problem in the serial/file code, which I understand is now under the ntdll tree. Obviously, I don't know much about it, but there is definitely something wrong. I was wondering if any developers were aware of this problem, as the decreased general usage of serial communications may have caused this to slip under the carpet, so to speak. I look forward to hearing any ideas, work-arounds, or patches. Thanks _________________________________________________________________ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.click-url.com/go/onm00200362ave/direct/01/

7 20

[REGRESSION] Photoshop 7.0 works before wine-cvs-20040130 16:??:?? CST (bug #2017)
by Luca Capello June 13, 2004

June 13, 2004

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, as reported on bug #2017 [1], Adobe Photoshop 7.0 stops working after wine-20031212 (in the majority of cases). This happens on Debian unstable (where I am) as well as on other distro. As suggested by Tony Lambregts, I made a regression testing to find the patch that broke this. The problem is between cvs-20040130-165720 and cvs-20040130-165721. The 'cvs -d ...' command gives me updates for only 3 files: ===== U dlls/kernel/Makefile.in U dlls/kernel/actctx.c U dlls/kernel/kernel32.spec ===== so I think the problem should be in these files, am I right? If it's so, well, the patch that broke Photoshop 7.0 working is the following [2] - - Jon Griffiths <jon_p_griffiths(a)yahoo.com> Add stubs for the Activation Context API (XP+). Please fix this problem, now that you know the cause. Thx, bye, Gismo / Luca [1] http://bugs.winehq.org/show_bug.cgi?id=2017 [2] http://www.winehq.org/hypermail/wine-cvs/2004/01/0394.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFAu1FuVAp7Xm10JmkRAgWIAJ90THCdqfIu6/uLGyurqrLfNNWEkACeIAze ALi4ZeOtMTEEDp8ETWu4G4c= =/pZb -----END PGP SIGNATURE-----

6 25

Request for winetesting volunteers
by Chris Morgan June 3, 2004

June 3, 2004

Thanks to Brian Vincent, Paul Millar, Dimi Paun, Ferenc Wagner and Kevin Koltzau the automated winetest suite is ready for more widespread testing. Kevin and Paul build winetests each night if there were cvs commits since the last time the tests were built. The winetests are published to a script on winehq that Brian and Dimi wrote. The winrash service that I wrote sends its current state to the service and receives a script to process that may direct it to check in later, download a winetest and run it or upgrade itself. Thanks to Ferenc the winetest results are sent back to winehq and can be accessed via http://test.winehq.org/data/ Pretty formatting of the results is coming soon ;-) We need volunteers that are willing to particpate in the winetesting process by running the winrash service on their computers. The winrash installer can be downloaded from: http://prdownloads.sourceforge.net/winrash/winrash-0007-chris-msvc.exe?down… You can find out more about winrash at http://winrash.sf.net The installer will install winrash as a service and run Wine tests as required. It is IMPORTANT that you set the client id correctly. Please use your first and last name WITHOUT spaces, like JohnSmith. Using the default client id will cause your winetest results to be ignored. The service is smart enough to autoupgrade as new versions are released. To uninstall just go to the Add/Remove programs and click 'remove' as you do for many windows programs. There is the ability to restrict the times when winrash runs winetests but this requires manually adding some keys to the registry. I haven't finished testing this feature but if someone wants it I can see about getting it polished up and in a release early this coming week. We currently need testers for the whole range of windows versions, win95/98/me, nt3/4, win2k, xp and 2003. Please reply if you want to help out so that we know what kind of coverage we can expect. The more the merrier, so please sign up even if others have done so for your version of Windows. Chris

3 5

wine
by Mike June 1, 2004

June 1, 2004

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

Current Wine CVS status
by Dmitry Timoshkov June 1, 2004

June 1, 2004

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

broken mingw build
by Kevin Koltzau June 1, 2004

June 1, 2004

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: [DInput] Fix RailroadTycoon
by Christian Costa May 31, 2004

May 31, 2004

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 May 31, 2004

May 31, 2004

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 May 31, 2004

May 31, 2004

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 May 31, 2004

May 31, 2004

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(a)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 May 31, 2004

May 31, 2004

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 May 31, 2004

May 31, 2004

A newly built wine segfaults for me. No args: welinder(a)anemone:~/wine> ./wine Segmentation fault No core. gdb just reports: welinder(a)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 May 30, 2004

May 30, 2004

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(a)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(a)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 May 30, 2004

May 30, 2004

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 May 30, 2004

May 30, 2004

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 May 29, 2004

May 29, 2004

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 May 29, 2004

May 29, 2004

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

Re: Print thread ID in 16-bit snoop traces in the noargs case
by Rein Klazes May 29, 2004

May 29, 2004

On Fri May 28 23:42:14 BST 2004, you wrote: > Mike Hearn <mh(a)codeweavers.com> > Print thread ID in 16-bit snoop traces in the noargs case Too late: http://cvs.winehq.org/patch.py?id=12478 Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 1

Upcoming breakage warning
by Mike Hearn May 29, 2004

May 29, 2004

Hi, On Fedora Core 2, the kernel is compiled with the 4G/4G VM split option enabled, which can prevent us from performing a correct emulation. Win32 apps are apparently built with the assumption that they will not be allocated addresses beyond the 3G boundary. The solution therefore is to perform a similar trick to the preloader and reserve the address space before the emulation starts so mmap will never use addresses in that area. This probably won't be combined with the preloader itself though, as Alexandre says it can be done after Wine gets control (what about DSOs mapped >3gig?) and so it can be done more portably. Up until now this issue has only affected Solaris and therefore nobody fixed it. There is currently no known workaround for this problem short of recompiling your kernel. The error looks like this: wine: unable to create process heap Alexandre diagnosed this problem so I'm sure he'll correct me if this email contains any mistakes. thanks -mike

4 5

Re: wine/ loader/main.c loader/glibc.c loader/Make ...
by Mike Hearn May 29, 2004

May 29, 2004

On Fri, 28 May 2004 15:59:23 -0500, Alexandre Julliard wrote: > Log message: > Initial version of the Wine preloader, used to reserve memory > areas at startup. Based on the work of Mike McCormack. For those who haven't been following the execshield/prelink saga, this commit is the result of the various prototypes and patches that were posted to wine-devel since we got back from WineConf. The result of it should be that we no longer need to switch off execshield nor prelink in order to run Wine reliably, also the huge BSS array hack is also no longer needed. Binaries of every size should work. Combined with the patch Alexandre checked in a few days ago to do an iterative binary search of the upper 2gig of address space, we should now also be functional when the 4G/4G VM split is enabled. It could use some testing! Please update to latest CVS and run wine as you would normally. If you are on a prelink/execshield enabled system, make sure they are both switched on and that prelink is using exec-shield mode (should be by default). If you observe any odd breakage please let us know. keep on truckin' -mike

3 3

Re: Fix CoMarshalInterThreadInterfaceInStream
by Mike Hearn May 28, 2004

May 28, 2004

( again wishing pan respected reply-to fields ... ) On Sat, 29 May 2004 00:33:24 +0100, Robert Shearman wrote: > This patch fixes CoMarshalInterThreadInterfaceInStream and > CoGetInterfaceAndReleaseStream to match what MSDN says - calling > CoMarshalInterface and CoUnmarshalInterface respectively. Without this > patch a particular InstallShield installer would just hang. With this > patch it gets a bit further (to an unimplemented function). Calling CoMarshalInterface in this case doesn't actually do much, but if it helps InstallShield OK. If you are interested in this stuff I'd say trying to merge the TransGaming patch would be a good start. 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 :( thanks -mike

1 0

Re: EnableWindow
by Alexandre Julliard May 28, 2004

May 28, 2004

Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> writes: > ChangeLog: > Ulrich Czekalla <ulrich(a)codeweavers.com> > EnableWindow should not remove the focus of child windows Thanks for providing a test, but could you please merge it with the existing win.c and/or msg.c tests? We can't create a new file for every API being tested. -- Alexandre Julliard julliard(a)winehq.org

1 0