October 2005 - Wine-devel - list.winehq.org

Re: Reality check
by Juan Lang 14 Oct '05

14 Oct '05

> BTW, you might be able to clarify how it can happen that Crossover > (derived from LGPL-ed WINE, if I understand it correctly) doesn't > have one of these bugs, but WINE does? Crossover has a limited set of applications that it supports, whereas Wine tries to support "all" applications. Sometimes a gross, ugly hack ends up in Crossover to support an app, that would break other apps, except that those other apps aren't supported by Crossover. As such the hacks end up remaining in the Crossover tree, and not going into winehq. > I used to think that LGPL requires availability of modified source, > and therefore WINE developers should be able to 'backport' bugfixes > from CrossOver to WINE, shouldn't they? Indeed, yes. Prominently linked from Codeweavers' products page: http://www.codeweavers.com/products/source/ --Juan __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

1 0

[daniel: OpenGL bug in 20050930]
by Daniel 14 Oct '05

14 Oct '05

Hi, some combination of wine and my system seems to be triggering a strange bug: Every program that uses OpenGL or D3D crashes upon trying to initialize the graphics. Attached is a sample log of trying to run Starsiege Tribes. The other attachment is some system info (even though DRI is disabled, enabling ist changes nothing). Other apps have similar logs. If you want to try out Tribes in particular, search the web for 'tribes_fullgame.exe'; Fileplanet for example has it. greets, Daniel

3 4

DefDlgProc* broken for (at least) WM_GETTEXT
by Troy Rollo 14 Oct '05

14 Oct '05

The DefDlgProc16, DefDlgProcA and DefDlgProcW call CallWindowProc16, CallWindowProcA and CallWindowProcW to pass messages to the dialog procedures. The problem with this is that a dialog procedure is not a window procedure, despite having a similar signature. The dialog procedures return a BOOL rather than an LRESULT - the value that would be returned by a window procedure is returned by 'SetWindowLongPtrW( hwnd, DWLP_MSGRESULT, ... );' for a dialog procedure, and the return value of the dialog procedure is a BOOL indicating whether the message was processed. This causes problems for messages like WM_GETTEXT, where the return value of the message is needed for (and modified by) post-processing when calling across a W->A or A->W boundary. It seemed that the tidyest fix would be to create three new routines internal to dlls/user: "call_dialog_proc_a", "call_dialog_proc_w" and "call_dialog_proc16". These three routines would be substantially the same as CallWindowProcA, CallWindowProcW and CallWindowProc16, except that they would pass a flag to the 6 cross-call case handling routines to let the routine know it is calling a dialog procedure and needs to use the value for DWLP_MSGRESULT for its post-processing. The problem with this is that two of the cross-call handling routines (the 16->W and 16->A ones) are exported: __wine_call_wndproc_32A __wine_call_wndproc_32W They do not appear to be used anywhere outside of the file they are defined in, and it seems unlikely an app could ever have a legitimate use for them. Vitaliy suggested maybe they may have been inadvertently missed in a cleanup of cross-DLL calls. So, what I propose to do is: 1. make __wine_call_wndproc_32A and __wine_call_wndproc_32W static (and hence not exported) 2. Add a parameter to each of __wine_call_wndproc_32A, __wine_call_wndproc_32W, WINPROC_CallProc32WTo32A, WINPROC_CallProc32WTo16, WINPROC_CallProc32ATo16 and WINPROC_CallProc32ATo32W to indicate that the cross-call routine should get the LRESULT from (and set it into) the DWLP_MSGRESULT value. 3. Rename the existing CallWindowProc* routines to (static) call_window_proc*, add the flag parameter there as well, and create new CallWindowProc* and call_dialog_proc_* routines to call the renamed routines with the appropriate flag. Any objections?

2 6

dbghelp issue
by Saulius Krasuckas 14 Oct '05

14 Oct '05

I got this while running winedbg over deadlocked Gothic demo (v1.04d): | 7 0x7fd362e5 SuspendThread+0x1d(hthread=0xc0) [/usr/src/wine-cvs/wine/dlls/kernel/thread.c:348] in kernel32 (0x7aa8aaf8) | fixme:dbghelp_msc:codeview_snarf Unsupported symbol id 5 | fixme:dbghelp_msc:dump 00000000: 0a 00 05 00 50 01 00 00 01 00 00 00 ....P....... | err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols | 8 0x005d0d68 in gothic (+0x1d0d68) (0x7aa8ab48) Should I enter new bug?

1 0

[dbghelp] continue dwarf support:try 2
by Raphael 13 Oct '05

13 Oct '05

Hi, On Monday 10 October 2005 09:06, Raphael wrote: > Changelog: > - begin of dwarf debug lines parsing > - better robustness > - support of unamed syms > - better traces > > TODO: > - find a clean way to handle forward declarations > - debug lines parsing > as Eric wanted: without type.c modification I'll try to improve it for next patch Regards, Raphael

1 0

Improve Bugzilla Query page usability by changing default state?
by Dan Kegel 13 Oct '05

13 Oct '05

Hey all, every time I do a Bugzilla query, I find the default value for State on the query page to be an annoyance. It would save me a lot of mouse clicks if the State field could either be totally unselected, or at least include the Unconfirmed state by default. This came up because a QA volunteer complained about how hard it was to start using the Bugzilla query page. This was an annoyance for him, too. Fixing this would simplify the Bugzilla quick start on my 'Wine needs YOU to triage bugs!' page, http://kegel.com/wine/qa/#tools How do people feel about the proposed change? Thanks, Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

9 26

Re: [dbghelp] continue dwarf support
by Eric Pouech 13 Oct '05

13 Oct '05

Raphael wrote: > Hi, > > Changelog: > - begin of dwarf debug lines parsing > - better robustness > - support of unamed syms > - better traces > > TODO: > - find a clean way to handle forward declarations > - debug lines parsing > > Index: type.c > =================================================================== > RCS file: /home/wine/wine/dlls/dbghelp/type.c,v > retrieving revision 1.12 > diff -u -r1.12 type.c > --- type.c 18 Apr 2005 15:34:10 -0000 1.12 > +++ type.c 10 Oct 2005 07:02:25 -0000 > @@ -204,8 +204,8 @@ > * the others (bit fields) > */ > BOOL symt_add_udt_element(struct module* module, struct symt_udt* udt_type, > - const char* name, struct symt* elt_type, > - unsigned offset, unsigned size) > + const char* name, struct symt* elt_type, > + unsigned offset, unsigned size) > { > struct symt_data* m; > struct symt** p; > @@ -220,7 +220,7 @@ > assert(m); > assert(m->symt.tag == SymTagData); > if (m->hash_elt.name[0] == name[0] && strcmp(m->hash_elt.name, name) == 0) > - return TRUE; > + return FALSE; > } > > if ((m = pool_alloc(&module->pool, sizeof(*m))) == NULL) return FALSE; I don't see the reason of changin the returnd value from TRUE to FALSE -- Eric Pouech

2 4

STI on wine: progress + help
by Damjan Jovanovic 13 Oct '05

13 Oct '05

Hi I've been working on an STI implementation for wine, and recently I made some progress. At present I've got a basic STI.DLL and I've made a Linux kernel module replacement of USBSCAN.SYS on Windows. I've only changed CreateFile() and NtDeviceIoControl(). When CreateFile() gets a devicepath "\\.\USBSCAN..." it opens the kernel module's device file using open(), and sends the file descriptor to the wine server using wine_server_fd_to_handle(). NtDeviceIoControl() checks the IOCTL code to see whether it is a scanner code, and if so, does an ioctl() call. The problem seems to be that after running for a couple of seconds, all the file system calls like ioctl() start failing with EBADF (bad file descriptor). Is there something other than wine_server_fd_to_handle() I have to do? The scanning application I am testing uses multiple threads and several processes. Thank you Damjan __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs

2 2

GoogleEarth issues
by Robbert Xerox 13 Oct '05

13 Oct '05

Hi, wouldn't it be great to get Googleearth more or less running before Wine 0.9 comes out. At least i think it would be great as is is top voted application and very popular. I did some investigation and found that GoogleEarth suffers from at least 4 bugs. However 3 of them can be bypassed for now by using native dlls. The bug that really makes it quite unusable is that that the menus are hidden by GoogleEarths's image. GoogleEearth's image is in the lower left corner whereas it should be in the upper right corner. The following patch seems to have caused this issue: http://www.winehq.org/pipermail/wine-cvs/2005-January/013739.html Maybe someone who is familiar with the x11drv code could have a look at it. More info in http://bugs.winehq.org/show_bug.cgi?id=3083 Thanks ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

1 0

How Do I launch a Native Linux application from Within Wine
by Craig macLeod 13 Oct '05

13 Oct '05

As the subject says, I have a Windows application and I wish to run a native linux application from withing it. The main Win32 API calls for running another apllication are ShellExecute WinExec CreateProcess I have tried calling a native linux program with these (nautilus) and it consistently fails. Do I need a fully specified path (nautilus is in the search path mind you)? It either does nothing or hangs Wine when I try calling these applications. I assume Wine is running the application as if it is a Windows app and failing. Thanks for any help in advance.

3 2