wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

testsuite patch - please run on windows
by Marcus Meissner 01 Oct '05

01 Oct '05

Hi, Can one of the Windows testers please try this testsuite patch? The second test fails on WINE, but I have a Bugzilla where the reporter said it should not. (http://bugs.winehq.org/show_bug.cgi?id=1847) Ciao, Marcus Index: dlls/user/tests/win.c =================================================================== RCS file: /home/wine/wine/dlls/user/tests/win.c,v retrieving revision 1.71 diff -u -r1.71 win.c --- dlls/user/tests/win.c 29 Sep 2005 13:36:14 -0000 1.71 +++ dlls/user/tests/win.c 1 Oct 2005 15:18:35 -0000 @@ -2173,6 +2173,8 @@ static void test_capture_3(HWND hwnd1, HWND hwnd2) { + BOOL ret; + ShowWindow(hwnd1, SW_HIDE); ShowWindow(hwnd2, SW_HIDE); @@ -2188,7 +2190,10 @@ ShowWindow(hwnd1, SW_SHOW); check_wnd_state(hwnd1, hwnd1, hwnd1, hwnd2); - ReleaseCapture(); + ret = ReleaseCapture(); + ok (ret, "releasecapture did not return TRUE.\n"); + ret = ReleaseCapture(); + ok (ret, "releasecapture did not return TRUE after second try.\n"); } static void test_keyboard_input(HWND hwnd)

2 1

Bug Triage: Infinite loop in painting.c / winpos.c (2658)
by Molle Bestefich 01 Oct '05

01 Oct '05

Hello I'd like to take a stab at helping clear out bugzilla. I've chosen this particular entry: http://bugs.winehq.org/show_bug.cgi?id=2658 A trial version can be downloaded here: http://www.download.com/Trillian/3000-2150-10047473.html The installer runs the setup wizard, which will crash and misbehave. Ignore that, and continue onwards with running "wine trillian.exe". In today's CVS, the application behaves as explained in the Bugzilla. The app goes into an infinite loop somewhere around user/painting.c and user/winpos.c. The visual effect is that: 1. The splash screen pops up in the middle of the screen, 2. It moves a notch (3 by 3 pixels) down and to the right, 3. Step 2.) repeats almost ad infinitum. That is, until the window is at the bottom edge of the screen and halfway to the right edge. 4. The application then waits for a very short while before finally starting over from step 1. Google gives us a few hints, so I'll take you on a short tour: http://bugs.winehq.org/show_bug.cgi?id=2658 "With previous versions, at least the splash window worked [...] but 20050111 makes the splash screen go crazy [...]! It shows up in the middle of the screen, but then goes down until the bottom of the screen." http://article.gmane.org/gmane.comp.emulators.wine.user/3048 "I've been running Trillian Pro quite successfully on wine-20030508 since, well, May 8th." http://article.gmane.org/gmane.comp.emulators.wine.user/6 "CodeWeavers Crossover Plugin works 100% with Trillian, no window move issues." http://www.desktoplinux.com/news/NS4813802007.html "Jan. 23, 2003 [...] CodeWeavers, Inc. today announced the release of CrossOver Plugin Version 1.2, [...] the new release also [... has] improved support for [...] Trillian." http://www.codeweavers.com/site/compatibility/browse/name?app_id=251;forum=1 "Has anyone tested the new version 3.0 already with Crossover?" "Yes. It works somewhat okay - there are bugs that need to be ironed out (i.e. new windows don't pop up well, dragging windows causes artsd to lock up on KDE)." Also slightly interesting: http://www.codeweavers.com/site/compatibility/browse/name?app_id=251;issues… So, it seems it works with CrossOver, but not vanilla Wine. Something fishy seems to be going on in Wine's USER32. I've run with +win, which gives an infinitely repeating list consisting of RedrawWindow, BeginPaint, GetWindowRect, SetWindowPos, MoveWindow, WINPOS_GetMinMaxInfo and others. Here's the infinitely looping part of a +win run: win:RedrawWindow 0x10028 whole window flags: RDW_ALLCHILDREN RDW_UPDATENOW win:BeginPaint hdc = 0xbb4 box = (0,0 - 177,368), fErase = 0 win:GetWindowRect hwnd 0x10028 (741,1244)-(924,1634) win:GetWindowRect hwnd 0x10028 (741,1244)-(924,1634) win:SetWindowPos hwnd 0x10028, after (nil), 549,317 (183x390), flags 80000015 win:dump_winpos_flags flags: SWP_NOSIZE SWP_NOZORDER SWP_NOACTIVATE 80000000 [ notice the block below.. ] win:RedrawWindow 0x10028 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME win:GetWindowRect hwnd 0x10028 (549,317)-(732,707) win:RedrawWindow 0x10028 whole window flags: RDW_INVALIDATE RDW_ERASE RDW_FRAME win:GetWindowRect hwnd 0x10028 (549,317)-(732,707) win:MoveWindow 0x10028 552,336 183x390 0 win:SetWindowPos hwnd 0x10028, after (nil), 552,336 (183x390), flags 0000001c win:dump_winpos_flags flags: SWP_NOZORDER SWP_NOREDRAW SWP_NOACTIVATE win:GetWindowRect hwnd 0x10028 (549,317)-(732,707) win:WINPOS_GetMinMaxInfo 183 390 / 552 336 / 183 390 / 183 390 [ it's repeated now, below.. ] win:RedrawWindow 0x10028 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME win:GetWindowRect hwnd 0x10028 (552,336)-(735,726) win:RedrawWindow 0x10028 whole window flags: RDW_INVALIDATE RDW_ERASE RDW_FRAME win:GetWindowRect hwnd 0x10028 (552,336)-(735,726) win:MoveWindow 0x10028 555,355 183x390 0 win:SetWindowPos hwnd 0x10028, after (nil), 555,355 (183x390), flags 0000001c win:dump_winpos_flags flags: SWP_NOZORDER SWP_NOREDRAW SWP_NOACTIVATE win:GetWindowRect hwnd 0x10028 (552,336)-(735,726) win:WINPOS_GetMinMaxInfo 183 390 / 555 355 / 183 390 / 183 390 [ above block repeats 10 more times, only coordinates changing. ] [ then poof happens the below. Almost a repeat, except for the GetMinMaxInfo params: ] win:RedrawWindow 0x10028 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME win:GetWindowRect hwnd 0x10028 (642,906)-(825,1296) win:RedrawWindow 0x10028 whole window flags: RDW_INVALIDATE RDW_ERASE RDW_FRAME win:GetWindowRect hwnd 0x10028 (642,906)-(825,1296) win:MoveWindow 0x10028 645,925 183x390 0 win:SetWindowPos hwnd 0x10028, after (nil), 645,925 (183x390), flags 0000001c win:dump_winpos_flags flags: SWP_NOZORDER SWP_NOREDRAW SWP_NOACTIVATE win:GetWindowRect hwnd 0x10028 (642,906)-(825,1296) win:WINPOS_GetMinMaxInfo 1282 1026 / -1 -1 / 1288 1032 / 112 27 win:RedrawWindow 0x10028 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME win:GetWindowRect hwnd 0x10028 (645,925)-(828,1315) win:RedrawWindow 0x10020 region 0x192c box (642,906)-(825,1296) flags: RDW_INVALIDATE RDW_ALLCHILDREN win:RedrawWindow 0x10028 whole window flags: RDW_INVALIDATE RDW_ERASE win:RedrawWindow 0x10020 region 0x1934 box (639,887)-(822,1277) flags: RDW_INVALIDATE RDW_ALLCHILDREN win:RedrawWindow 0x10028 whole window flags: RDW_INVALIDATE RDW_ERASE [ above repeats 30 times, albeit with new coordinates etc. ] After this, the trace "wraps around" and repeats itself from the beginning. Coordinates change slightly though, it's a few pixels off from the first run. Please help me understand why the above infinite loop occurs! I also did a +relay trace and ran it through examine-relay. The resulting call stack is awe inspiring - it's as deep as the Mariana Trench. See the attached snippet. Does it not seem "wrong"? I also did a +all trace, which instantly got very big and confusing. I tried grepping to get rid of parts of it, which went OK, but then examine-relay wouldn't indent half of the lines in it, and in the end it complained about a bunch of leftover calls. So I patched Wine (attached) to output only toplevel calls, which gave me this listing: Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGING,wp=00000000,lp=4069e7b0) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGING,wp=00000000,lp=4069e7b0) retval=00000000 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_NCPAINT,wp=00000001,lp=00000000) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_NCPAINT,wp=00000001,lp=00000000) retval=00000000 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_ERASEBKGND,wp=00000bb4,lp=00000000) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_ERASEBKGND,wp=00000bb4,lp=00000000) retval=00000001 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGED,wp=00000000,lp=4069e7b0) [ window moves a lot now ] Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGED,wp=00000000,lp=4069e7b0) retval=00000000 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGING,wp=00000000,lp=4069e7b0) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGING,wp=00000000,lp=4069e7b0) retval=00000000 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_NCPAINT,wp=00000001,lp=00000000) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_NCPAINT,wp=00000001,lp=00000000) retval=00000000 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_ERASEBKGND,wp=00000bb4,lp=00000000) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_ERASEBKGND,wp=00000bb4,lp=00000000) retval=00000001 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGED,wp=00000000,lp=4069e7b0) [ window moves a lot now ] Etc. ad infinitum. The above should be the stuff that Trillian actually calls in Wine, but my patch might be wrong. Seems odd that the WM_blah calls do not show up in +relay mode. Please help me understand: Why is that? Thank You for Paying Attention. And Please Help Me Fix This Bug! :-)

1 0

WSACleanup() again?
by JustFillBug 01 Oct '05

01 Oct '05

I saw the bug described in: http://winehq.com/hypermail/wine-users/2001/01/0516.html happened again to a program I was trying to use. At least the behavior is the same. I have no access to the source code. It seems the problem was fixed in revision 1.42 of socket.c. But now at 1.139, WSACleanup again return 0 forever on repeating calls.

2 4

Documentation on DIBENG.DLL exported functions
by Alex Villacís Lasso 30 Sep '05

30 Sep '05

Could somebody please point me to an online documentation on the functions exported by DIBENG.DLL and how an userspace application could use them? I want to evaluate whether a possible DIB engine for Wine could use the DIBENG.DLL API. I googled and all I find are reports of GPFs involving DIBENG.DLL. Same issue when searching MSDN. Of course, DIBENG.DLL might not be the best model to implement for a DIB engine, so I wait for suggestions. I was planning on writing a C program that would load DIBENG.DLL via LoadLibrary() and call its functions in order to build tests for it. Alex Villacís Lasso

1 0

Re: OLEAUT32: add additional condition for creation of interface
by Steven Edwards 30 Sep '05

30 Sep '05

On 9/30/05, Alex Villacís Lasso <a_villacis(a)palosanto.com> wrote: > This patch is required in order to run any application that embeds > DBGRID32.OCX from MS VisualBasic 5 or 6 > > Changelog: > * Add additional condition for creation of interface A patch would be nice =) Thanks Steven

1 0

WWN: Rpm's for Fedora Core 4
by Dieter Komendera 30 Sep '05

30 Sep '05

Hi people, I read in the today's Wine Weekly News something about rpms for Fedora Core 4. In august I begann building some for FC 4. I built rpm's for the july and the august version. The rpm's were based on Vincent Beron's. They were downloaded about 700 times from my server. There is also a mirrorserver that also hosts my rpms. In fedoraforums.org just one guy reported a problem with the rpm. They can be downloaded here: http://komi.bluezones.org/wine/fc4/ I'll build also rpms for the coming cvs drop out. In this, I will take care of things I read in the WWN. Any comments, improvements, suggestions are very welcome! Regards, Dieter Komendera

2 1

freedce-win32 - progress!
by Luke Kenneth Casson Leighton 30 Sep '05

30 Sep '05

i am making the "amateur" version of progress: i just had echo_server.exe run for the first time on win32: echo_client.exe has been running successfully since this morning. rpcd.exe - the endpoint mapper - just crashed :) hmmm... recv_state_timer is indicating Ping timeout, sending "Orphan timeout", and then bombing out... hmmm... this despite echo_server.exe happily running. i don't really know enough to say what's going on here - other than to consider quite cheerfully disabling the ping rpc timer code with a _huge_ manic grin on my face :) i have had to disable TCP (ncacn_ip_tcp) for now, and will try that next. i've refrained from notifying wine-devel of status reports until i actually had something working. for your benefit: * i am using pthreads-win32, from sourceware.org, with pthread_self.c patched to set sp->implicit = 0 instead of 1. this gets the dcethreads test programs to work: whether this is a good thing remains to be seen... * i have removed the awfulness that is linux-specific (system call wrapping) which previously made dcethreads non-portable to win32: instead, you now must #define sys_pthread_create pthd4_create because dcethreads provides pthd4_xxx. * the dcethreads exception emulation library still uses setjmp and longjmp and to my surprise and horror it actually works. * i have tracked down an implementation of gettimeofday, and liberally sprinkled it across the code, statically, instead of providing a nice library routine * i have provided a win32_winsock.c "wrapper" set of code to divorce the #including of <windows.h> and <winsock.h> from everything else. no, it is _not_ appropriate to put #include <windows.h> in the freedce header files. there are too many conflicts for that to be suitable. HANDLE, handle_t, UUID, uuid_t rpc_binding_t ain't the half of it. * i could not be arsed to write yet another version of uuid_create() and the uuid_create() function in freedce conforms to the RFC - grabs networking MAC address etc. etc. therefore, rather than rip wine code from UuidCreate(), i decided to call UuidCreate() - via a wrapper function. this _could_ therefore get interesting, if someone decides to make rpcrt4.dll utilise uuid_create() ... :) * i have NOT done any proper file locking stuff - yet - in rpcd.exe. there's a database that really needs to be locked: i aim to grab APR's apr_open(), apr_flock() etc. etc. and utilise those because i _so_ cannot be bothered to reinvent the wheel. wine-devel team: you now have a partially-working and therefore proof-of-concept port of freedce to win32. there are many next steps that can be taken from here. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

2 2

Subject: Re: Newsleecher Installer Failing
by josephblack 30 Sep '05

30 Sep '05

For information on debugging, these official docs may help http://www.winehq.org/site/docs/wine-devel/debugging http://www.winehq.org/site/docs/wine-devel/index http://wiki.winehq.org/DebuggingTutorials there is an unofficial list of examples from the mailing lists, here. http://wine-wiki.org/index.php/Debugging_Wine if you see or think of something that could be added to the official documents - please send a suggestion to the wine-devel list. -- Joseph Black

1 0

MS VisualBasic apps have no minimize/maximise buttons, no taskbar button - RFC, help debugging
by Alex Villacís Lasso 29 Sep '05

29 Sep '05

The following is a problem I have been having with every single VisualBasic application for some time, and I ask for your help now: Every single VisualBasic application I have tried lacks the minimize and maximize buttons, even when the application is supposed to have them. In addition, the taskbar button is missing (on Gnome 1.4.x/Metacity 2.10.3 under Fedora 4), so there is no way to recall the application once the window is obscured by another application, except by clearing the desktop. The applications show the buttons on the virtual desktop, and the problem arises only when the application uses the window manager for its own window. This problem was confirmed on Metacity and MWM. As far as I can tell, this affects Visual Basic apps only. The applications from Wine (regedit, for example) show correct decorations, and so do some tools from MS Visual Studio. I modified x11drv/window.c to display the Windows attributes before setting hints for the window manager. Here is what I got: Tested regedit (wine), depends.exe (native, MS Visual Studio), windiff.exe (native, MS Visual Studio), dbgridtest.exe (native, VisualBasic app), pruebatransparency.exe (native, VisualBasic app). Entries with asterisks lack min/max buttons as explained. regedit wine fixme:x11drv:X11DRV_set_wm_hints hwnd = 0x00010022 style = 0x04cf0200 ex_style = 0x00000100 fixme:x11drv:displayStyles style = 0x04cf0200 WS_CLIPSIBLINGS WS_CAPTION WS_BORDER WS_DLGFRAME WS_SYSMENU WS_THICKFRAME WS_GROUP WS_TABSTOP WS_MINIMIZEBOX WS_MAXIMIZEBOX fixme:x11drv:displayStyles ex_style = 0x00000100 WS_EX_WINDOWEDGE fixme:x11drv:X11DRV_set_wm_hints hwnd = 0x00010028 style = 0x04c00000 ex_style = 0x00000100 fixme:x11drv:displayStyles style = 0x04c00000 WS_CLIPSIBLINGS WS_CAPTION WS_BORDER WS_DLGFRAME fixme:x11drv:displayStyles ex_style = 0x00000100 WS_EX_WINDOWEDGE fixme:x11drv:X11DRV_set_wm_hints hwnd = 0x00010022 style = 0x14cf0200 ex_style = 0x00000100 fixme:x11drv:displayStyles style = 0x14cf0200 WS_VISIBLE WS_CLIPSIBLINGS WS_CAPTION WS_BORDER WS_DLGFRAME WS_SYSMENU WS_THICKFRAME WS_GROUP WS_TABSTOP WS_MINIMIZEBOX WS_MAXIMIZEBOX fixme:x11drv:displayStyles ex_style = 0x00000100 WS_EX_WINDOWEDGE depends.exe native fixme:x11drv:X11DRV_set_wm_hints hwnd = 0x00010026 style = 0x04cf8000 ex_style = 0x00000100 fixme:x11drv:displayStyles style = 0x04cf8000 WS_CLIPSIBLINGS WS_CAPTION WS_BORDER WS_DLGFRAME WS_SYSMENU WS_THICKFRAME WS_GROUP WS_TABSTOP WS_MINIMIZEBOX WS_MAXIMIZEBOX fixme:x11drv:displayStyles ex_style = 0x00000100 WS_EX_WINDOWEDGE fixme:x11drv:X11DRV_set_wm_hints hwnd = 0x00010026 style = 0x14cf8000 ex_style = 0x00000110 fixme:x11drv:displayStyles style = 0x14cf8000 WS_VISIBLE WS_CLIPSIBLINGS WS_CAPTION WS_BORDER WS_DLGFRAME WS_SYSMENU WS_THICKFRAME WS_GROUP WS_TABSTOP WS_MINIMIZEBOX WS_MAXIMIZEBOX fixme:x11drv:displayStyles ex_style = 0x00000110 WS_EX_ACCEPTFILES WS_EX_WINDOWEDGE windiff.exe native fixme:x11drv:X11DRV_set_wm_hints hwnd = 0x00010022 style = 0x04cf0000 ex_style = 0x00000100 fixme:x11drv:displayStyles style = 0x04cf0000 WS_CLIPSIBLINGS WS_CAPTION WS_BORDER WS_DLGFRAME WS_SYSMENU WS_THICKFRAME WS_GROUP WS_TABSTOP WS_MINIMIZEBOX WS_MAXIMIZEBOX fixme:x11drv:displayStyles ex_style = 0x00000100 WS_EX_WINDOWEDGE fixme:x11drv:X11DRV_set_wm_hints hwnd = 0x00010022 style = 0x14cf0000 ex_style = 0x00000100 fixme:x11drv:displayStyles style = 0x14cf0000 WS_VISIBLE WS_CLIPSIBLINGS WS_CAPTION WS_BORDER WS_DLGFRAME WS_SYSMENU WS_THICKFRAME WS_GROUP WS_TABSTOP WS_MINIMIZEBOX WS_MAXIMIZEBOX fixme:x11drv:displayStyles ex_style = 0x00000100 WS_EX_WINDOWEDGE **** dbgridtest.exe native fixme:x11drv:X11DRV_set_wm_hints hwnd = 0x00010022 style = 0x04c00000 ex_style = 0x00000100 fixme:x11drv:displayStyles style = 0x04c00000 WS_CLIPSIBLINGS WS_CAPTION WS_BORDER WS_DLGFRAME fixme:x11drv:displayStyles ex_style = 0x00000100 WS_EX_WINDOWEDGE fixme:x11drv:X11DRV_set_wm_hints hwnd = 0x00010024 style = 0x84090000 ex_style = 0x00000080 fixme:x11drv:displayStyles style = 0x84090000 WS_POPUP WS_CLIPSIBLINGS WS_SYSMENU WS_TABSTOP WS_MAXIMIZEBOX fixme:x11drv:displayStyles ex_style = 0x00000080 WS_EX_TOOLWINDOW fixme:x11drv:X11DRV_set_wm_hints hwnd = 0x00010028 style = 0x84000000 ex_style = 0x00000000 fixme:x11drv:displayStyles style = 0x84000000 WS_POPUP WS_CLIPSIBLINGS fixme:x11drv:displayStyles ex_style = 0x00000000 fixme:x11drv:X11DRV_set_wm_hints hwnd = 0x0001002c style = 0x06cf0000 ex_style = 0x00040100 fixme:x11drv:displayStyles style = 0x06cf0000 WS_CLIPSIBLINGS WS_CLIPCHILDREN WS_CAPTION WS_BORDER WS_DLGFRAME WS_SYSMENU WS_THICKFRAME WS_GROUP WS_TABSTOP WS_MINIMIZEBOX WS_MAXIMIZEBOX fixme:x11drv:displayStyles ex_style = 0x00040100 WS_EX_WINDOWEDGE WS_EX_APPWINDOW fixme:x11drv:X11DRV_set_wm_hints hwnd = 0x0001002c style = 0x16cf0000 ex_style = 0x00040100 fixme:x11drv:displayStyles style = 0x16cf0000 WS_VISIBLE WS_CLIPSIBLINGS WS_CLIPCHILDREN WS_CAPTION WS_BORDER WS_DLGFRAME WS_SYSMENU WS_THICKFRAME WS_GROUP WS_TABSTOP WS_MINIMIZEBOX WS_MAXIMIZEBOX fixme:x11drv:displayStyles ex_style = 0x00040100 WS_EX_WINDOWEDGE WS_EX_APPWINDOW **** pruebatransparency.exe native fixme:x11drv:X11DRV_set_wm_hints hwnd = 0x00010022 style = 0x04c00000 ex_style = 0x00000100 fixme:x11drv:displayStyles style = 0x04c00000 WS_CLIPSIBLINGS WS_CAPTION WS_BORDER WS_DLGFRAME fixme:x11drv:displayStyles ex_style = 0x00000100 WS_EX_WINDOWEDGE fixme:x11drv:X11DRV_set_wm_hints hwnd = 0x00010024 style = 0x84090000 ex_style = 0x00000080 fixme:x11drv:displayStyles style = 0x84090000 WS_POPUP WS_CLIPSIBLINGS WS_SYSMENU WS_TABSTOP WS_MAXIMIZEBOX fixme:x11drv:displayStyles ex_style = 0x00000080 WS_EX_TOOLWINDOW fixme:x11drv:X11DRV_set_wm_hints hwnd = 0x00010028 style = 0x84000000 ex_style = 0x00000000 fixme:x11drv:displayStyles style = 0x84000000 WS_POPUP WS_CLIPSIBLINGS fixme:x11drv:displayStyles ex_style = 0x00000000 fixme:x11drv:X11DRV_set_wm_hints hwnd = 0x0001002c style = 0x06cf0000 ex_style = 0x00040100 fixme:x11drv:displayStyles style = 0x06cf0000 WS_CLIPSIBLINGS WS_CLIPCHILDREN WS_CAPTION WS_BORDER WS_DLGFRAME WS_SYSMENU WS_THICKFRAME WS_GROUP WS_TABSTOP WS_MINIMIZEBOX WS_MAXIMIZEBOX fixme:x11drv:displayStyles ex_style = 0x00040100 WS_EX_WINDOWEDGE WS_EX_APPWINDOW fixme:x11drv:X11DRV_set_wm_hints hwnd = 0x0001002c style = 0x16cf0000 ex_style = 0x00040100 fixme:x11drv:displayStyles style = 0x16cf0000 WS_VISIBLE WS_CLIPSIBLINGS WS_CLIPCHILDREN WS_CAPTION WS_BORDER WS_DLGFRAME WS_SYSMENU WS_THICKFRAME WS_GROUP WS_TABSTOP WS_MINIMIZEBOX WS_MAXIMIZEBOX fixme:x11drv:displayStyles ex_style = 0x00040100 WS_EX_WINDOWEDGE WS_EX_APPWINDOW From what I can tell, VisualBasic apps have an odd pattern of window initialization. The very first window in the other C/C++ apps is also the one to be set with a WS_VISIBLE style, but this is not the case for VisualBasic apps. However, I am unable to tell if this is relevant to the issue. Thanks for your attention. Alex Villacís Lasso

2 2

Re: wine/ programs/Makeprog.rules.in include/wine/ ...
by Dimi Paun 29 Sep '05

29 Sep '05

> Declare debug channels as static variables so that we > don't need to generate an external .dbg.c file to define them. Way cool, thanks for fixing this, it was really bothering me that we had that additional pass over the source... I think our toolchain looks pretty good now! -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

Re: Unused function in regedit/treeview.c
by Krzysztof Foltman 29 Sep '05

29 Sep '05

> If that function is supposed to be useful, then scream or re-add it > later. Re-adding would be a good idea. I thought it will be useful for finding an item in the tree, but then managed to do the same without using it. --- Krzysztof

1 0

FW: Help debugging a problem!
by Ann & Jason Edmeades 29 Sep '05

29 Sep '05

Ok, more information... The routine (slightly modified to allow code before the return) is ATOM WINAPI RegisterClass16( const WNDCLASS16 *wc ) { WNDCLASSEX16 wcex; ATOM fred; wcex.cbSize = sizeof(wcex); : fred = RegisterClassEx16( &wcex ); return fred; } This fails for the application as it stands. Adding in char temp[8]; before the WNDCLASSEX16 and it still fails Adding in char temp[9]; and the program starts working... Adding in char temp[9]; after the WNDCLASSEX16 and it still fails (Yes, temp is unused...) So that would agree heap corruption of some sort Next question... how to pin this down. I've tried the following 1. Use DebugBreak before and after the RegisterClassEx16 call with no temp defined - Stacks are identical as far as winedbg traces (0x60 bytes) - registers are nearly identical, only difference is ESI after 2. Initialize temp to 0x00's (still works @ 9 and fails @ 8). Then adding an 'if' statement before the return to query the bytes... a. If I put a stream of if statements it always works b. If I put a single statement it works@9 / fails@8. Manually, I have confirmed chars 0->11 are not touched (3 longs). c. I changed temp to be 8192 in size, memset it to 0x00 and then post call checked each byte to see if it had changed - it hadn't, they were all still 0x00 => I don't think the actual values are important, size matters (so they say!) 3. I recompiled user.c with -O0 and got different results. With char temp; in it works, with it removed it fails! 4. I compared the assembler output produced with temp[8] and temp[9] and as expected they are identical except for some offsets in that routine. ARGH... Advice please.... Anyone... Jason

4 3

Re: winspool/tests: New Testsuite
by Detlef Riekenberg 29 Sep '05

29 Sep '05

Changelog: - New Testsuite for winspool.drv for GetPrinterDriverDirectoryA and GetDefaultPrinterA The "W" - Versions and more Functions will follow. BTW: I'm offline / disconected from the mailing-lists for a week. -- By By ... ... Detlef

2 1

Problem with D3D9 CreateDevice
by Mark Hatsell 29 Sep '05

29 Sep '05

Hello I am trying to get an application I have written working under Wine. My application uses Direct3D v.9 which is causing a problem. I am using the latest CVS version of Wine under Mandriva Linux 10.2. The problem I have is that when I try to create the 3D device using CreateDevice, it fails and I get the following output from Wine debugging: fixme:d3d:IWineD3DImpl_GetDeviceCaps Caps support for directx9 is nonexistent at the moment! fixme:d3d:IWineD3DImpl_CheckDeviceMultiSampleType Quality levels unsupported at present trace:d3d:IWineD3DImpl_CreateDevice Created WineD3DDevice object @ 0x79b7ec78 trace:d3d:IWineD3DImpl_AddRef (0x7bcb1890) : AddRef increasing from 1 trace:d3d:IWineD3DImpl_CreateDevice (0x7bcb1890)->(Adptr:0, DevType: 1, FocusHwnd: 0x50060, BehFlags: 42, PresParms: 0x7baeb0ec, RetDevInt: 0x78d56ea8) trace:d3d:IWineD3DImpl_CreateDevice (0x7bcb1890)->(DepthStencil:(80,WINED3DFMT_D16), BackBufferFormat:(23,WINED3DFMT_R5G6B5)) trace:d3d:IWineD3DImpl_CreateDevice (0x7bcb1890) : Creating stateblock trace:d3d:IWineD3DImpl_CreateDevice (0x7bcb1890) : Created stateblock (0x79bbf6a0) trace:d3d:IWineD3DStateBlockImpl_AddRef (0x79bbf6a0) : AddRef increasing from 1 trace:d3d:IWineD3DImpl_CreateDevice Creating implicit swapchain trace:d3d:IWineD3DDeviceImpl_CreateAdditionalSwapChain (0x79b7ec78) : Created Aditional Swap Chain trace:d3d:IWineD3DDeviceImpl_CreateAdditionalSwapChain Using a display of 0x7c017628 0x4284 warn:d3d:IWineD3DDeviceImpl_CreateAdditionalSwapChain Failed to get a valid XVisuial ID for the window 0x50060 fixme:d3d9:IDirect3DDevice9Impl_CreateAdditionalSwapChain (0x78d56ea0) call to IWineD3DDevice_CreateAdditionalSwapChainfailed warn:d3d:IWineD3DImpl_CreateDevice Failed to create implicit swapchain trace:d3d:IWineD3DStateBlockImpl_Release (0x79bbf6a0) : Releasing from 2 trace:d3d:IWineD3DStateBlockImpl_Release (0x79bbf6a0) : Releasing from 1 fixme:d3d:IWineD3DStateBlockImpl_Release Releasing primary stateblock I have located the source of the error in device.c which seems to be something to do with it not having a valid X11 window. However, at this point my lack of Wine knowledge prevents me from getting any further. Has anyone any idea what might be causing this problem and what I can do to fix it? Any help much appreciated. Mark

3 7

Re: wine/ programs/winedbg/info.c programs/taskmgr ...
by Vincent Béron 29 Sep '05

29 Sep '05

Le mer 28/09/2005 à 11:21, Alexandre Julliard a écrit : > ChangeSet ID: 20474 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)winehq.org 2005/09/28 10:21:48 > > Modified files: > programs/winedbg: info.c > programs/taskmgr: dbgchnl.c > libs/wine : wine.map wine.def loader.c debug.c > include/wine : debug.h > > Log message: > New scheme for keeping track of debug channels that doesn't require > maintaining a list of all loaded dlls. This patch causes compilation with gcc 3.2 to issue some warnings about null format strings whenever a TRACE_ON() (or other) is used. I know there's a check in wine_dbg_log() for !format, but the warning is still annoying. I guess you don't want an empty line (except for type and class) to be printed everytime TRACE_ON is tested, so changing the 0 for "" wouldn't work out ok... Vincent

2 1

xcursor and wine
by Vijay Kiran Kamuju 29 Sep '05

29 Sep '05

Hi all, I any body wants tp implement Xcursor support in wine, for loading color cursors. What should be implemented, how it should be implemented? any details regarding this would be helpful. Thanks, Vijay

1 1

winehq at the CIA Open Source Notification System
by Detlef Riekenberg 28 Sep '05

28 Sep '05

Hi. There are no updates listed for wine at the CIA Open Source Notification System: http://cia.navi.cx/stats/project/winehq Is this our fault? -- By By ... ... Detlef

2 1

Re: fixme:win:LockWindowUpdate
by James Hawkins 28 Sep '05

28 Sep '05

On 9/28/05, Esko Woudenberg <wanderbored(a)yahoo.com> wrote: > > > fixme:win:LockWindowUpdate (0x2002a), partial > > stub! > > > > > Stubbed functions aren't usually the cause of > > crashes. > I take it that wine would just "ignore" the request to > not update the window...?? > I'm not really sure what functionality is missing from LockWindowUpdate. Maybe someone on wine-devel will know. > > There are a > > couple pieces of information that can help us spot > > the problem. What > > version of wine are you using? > 20050830 on SuSe 9.2 under vmWare 5.0.0 > Could you update to CVS and see if the problem still exists? > > Can you provide the > > output of the > > crash and the stack backtrace? > Is running with WINEDEBUG=+relay enough to provide > that? > We might need that information later, but the most important piece we need is the crash and backtrace. This information everything after the following: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8. > > You said it was an app you are working on; can you > > provide the source? > I have full access to source. I would most likely > only be able to provide relevant portions of the app > source. > Having access to the source will help figure out what is going wrong. We won't know what we need until we know where it's crashing. > > Just knowing that stubs are not supposed to result in > a wine crash is already helpful... > No problem, a good bug report helps Wine the most. P.S. Make sure to use 'Reply to All' or cc wine-devel so others can be a part of the process. -- James Hawkins

1 0

riched20.dll asserts
by Aric Stewart 28 Sep '05

28 Sep '05

Hello, So looking into an issue with IE6 i found the following problem. If I install IE6, and then go to a japanese web site. (for example http://www.mainichi.co.jp) I get given the option to download and install the Japanese Text Display Support. However if i click Download then the download reports as a failure (a message about having to set your security settings from High to Medium, but that is a red herring) The issue is that the assert in riched20/run.c line 115 is being hit during a call to RichEditANSIWndProc for the message EM_LINELENGTH. If i change the assert to instead to return 0, then the certificate dialog is displayed and the download progresses without issue. (there is still an issue with the install but that is not richedit related) Does someone with richedit experience want to help figure out what to do with that assert beyond just changing it to an error trace and returning 0? thanks -aric

3 2

Help debugging a problem!
by Ann & Jason Edmeades 28 Sep '05

28 Sep '05

Hiya, I've got a weird issue and was wondering if anyone could advise on how to resolve. (Comes from a 16bit windows app, but is a more general debugging issue). The problem is ... 1) If I run the application, it just hangs - no overly helpful information at all. 2) If I add WINEDEBUG +relay trace, it runs ok :-) (Workaround...!) 3) If I add anything else on WINEDEBUG other than relay, it fails 4) Running under winedbg didn't help at all - I could code to stop it before the hang but it wouldn't step through to the failure 5) Attaching to the hung process shows code in 16 bit user app, and winedbg didn't overly help there either So - I've (painstakingly) got to the point of failure with the add of debug tracepoints and comparing the relay with the debug statements. Now the odd bit! If you look at dlls\user\wnd16.c, routine RegisterClass16 the final line is: return RegisterClassEx16( &wcex ); If I change this to fred = RegisterClassEx16( &wcex ); TRACE("Here... %d\n", fred); return fred; it all works.....! How can I debug this further? I was thinking about trying to dump the registers before and after the trace statement, but I really can't think of what could be causing the problem! Does windows guarantee any of the registers across a win16 call which we don't honour? What about i386 flags? Any suggestions please? Jason

3 3

Crash in printer setup dialog if no printers in list
by Dan Kegel 28 Sep '05

28 Sep '05

I just filed http://bugs.winehq.org/show_bug.cgi?id=3415 describing a repeatable crash in Printer Setup when you have no printers. Affects all apps that have a Printer Setup menu item, I bet.

1 0

Trying to track down a failure in a native, non-MS DLL for which I have no source
by David D. Hagood 28 Sep '05

28 Sep '05

I'm trying to get the Delorme packages (AAA MapNGo, Street Atlas) running under the latest Wine. They used to work back when Wine used the MS DLLs for DCOM, but then they stopped working when Wine started supplying their own DCOM DLLS. Now, they show an inclination to work but for one thing. Both packages use a DLL supplied with the package, mapsys32.dll, which appears to be the main map drawing code. This DLL appears to attempt to load a file FONT.FNT, which appears to be an ASCII file describing certain vector objects used to draw maps. This DLL is failing to load the FONT.FNT file - and that's pretty much a show-stopper. So, I'd like to try to track down the problem and see if I can fix it. Now, I don't work for Delorme, I don't have the source for the DLL, and I am really not a Windows programmer (fortunately I work on embedded systems and Linux). So, I'd like a few pointers - how can I commence to begin to start on this? I know the following things: The FONT.FNT file is being opened (strace shows it being opened). The mapsys32.dll file is being loaded (WINEDEBUG=+relay shows it) The mapsys32.dll does not implement DllRegisterServer (regsvr32 says so). The problem exists even though I've blown away my entire .wine directory and recreated it from scratch. The problem has been in the code for several months, and as of 19 Sept 2005's CVS it still is. So, how can I see what is going on with mapsys32.dll?

2 1

Problem with Magellan DataSend and COM ports
by David D. Hagood 28 Sep '05

28 Sep '05

I recently tried to install the Magellan DataSend tool to talk to my GPS, and it almost works. However, I did find one funny with it - the program did not "see" the COM ports until I added the following entries into the registry: [HKEY_LOCAL_MACHINE\hardware\devicemap\serialcomm] "COM2"="COM2" "COM1"="COM1" (these were found via a file on the Magellan install CD named win95com.reg). Perhaps these should be added to the Wine registry? Once added, then the program would run - at least right up to the point where I told it to download the data to the GPS, at which point it threw and exception and died.

1 0

fixme:win:LockWindowUpdate
by Esko Woudenberg 28 Sep '05

28 Sep '05

There are several parts of a C++ Builder app I am working on that try to call the LockWindowUpdate() WIN32 api call it appears to result in a wine crash with the following error: fixme:win:LockWindowUpdate (0x2002a), partial stub! Where do I go to find out who (if anyone) is working on support for that? (Would this be a horrible place for someone COMPLETELY new to wine to start trying to contribute?) Esko __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

2 1

CopyEnhMetaFile() on big endian arch
by Phil Krylov 27 Sep '05

27 Sep '05

Hi, My problem is: CopyEnhMetaFile() creates a .wmf file from a HENHMETAFILE by simple dumping of data to the file. On big-endian platforms (in my case - PowerPC) the resulting file is not a valid WMF. To make it valid, we need to convert all binary data to little-endian. I'd like to make it work. Can someone suggest where the byte order should be reversed? Should it be done in the HENHMETAFILE stored in memory, or should rather CopyEnhMetaFile parse the whole metafile and byte-reverse all data that should be dumped to disk? In any case, it seems to be a huge task. If someone is also interested, probably we should cooperate with each other? -- Ph.

1 0

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