wine-devel February 2005

wine-devel@winehq.org

157 participants
316 discussions

Editbox background regression (bug 2695)
by George Ginden 09 Mar '05

09 Mar '05

*See Bug #2695 for screenshots: http://bugs.winehq.com/show_bug.cgi?id=2695 This regression was introduced within wine 20041019, since wine-20040914 was working just fine. (The latest release is still affected by the problem). The diff between these two versions is 5 megs big so I'm just wondering, which area of the codebase is affected by the bug... edit.c is not the case... Regards. *

3 4

Re: edit control
by Robert Shearman 09 Mar '05

09 Mar '05

Ulrich Czekalla wrote: >Running some tests under WinXP I noticed that if the edit control doesn't >have WS_EX_CLIENTEDGE it looses the WS_BORDER style and it handles painting >the border. This also has the side effect that it's non-client area goes to >zero. > >ChangeLog: > Ulrich Czekalla <ulrich(a)codeweavers.com> > Handle painting the border if WS_EX_CLIENTEDGE is not set > > This changelog doesn't really seem to match the patch. Are you sure it's right? >------------------------------------------------------------------------ > >Index: dlls/user/edit.c >=================================================================== >RCS file: /home/wine/wine/dlls/user/edit.c,v >retrieving revision 1.2 >diff -u -r1.2 edit.c >--- dlls/user/edit.c 9 Sep 2004 19:18:40 -0000 1.2 >+++ dlls/user/edit.c 15 Sep 2004 16:30:50 -0000 >@@ -4423,13 +4423,18 @@ > /* > * In Win95 look and feel, the WS_BORDER style is replaced by the > * WS_EX_CLIENTEDGE style for the edit control. This gives the edit >- * control a non client area. Not always. This coordinates in some >- * way with the window creation code in dialog.c When making >- * modifications please ensure that the code still works for edit >- * controls created directly with style 0x50800000, exStyle 0 ( >- * which should have a single pixel border) >+ * control a nonclient area so we don't need to draw the border. >+ * If WS_BORDER without WS_EX_CLIENTEDGE is specified we shouldn't have >+ * a nonclient area and we should handle painting the border ourselves. >+ * >+ * When making modifications please ensure that the code still works >+ * for edit controls created directly with style 0x50800000, exStyle 0 >+ * (which should have a single pixel border) > */ >- es->style &= ~WS_BORDER; >+ if (lpcs->dwExStyle & WS_EX_CLIENTEDGE) >+ es->style &= ~WS_BORDER; >+ else if (es->style & WS_BORDER) >+ SetWindowLongW(hwnd, GWL_STYLE, es->style & ~WS_BORDER); > > This doesn't seem right at all. The new code should be exactly the same as the old, barring any side effects from SetWindowLong (which shouldn't affect the control anyway since this the function changed is the handler for WM_NCCREATE). Rob

3 3

text edit box not painting text ( on form startup )
by Doug Herbert 09 Mar '05

09 Mar '05

( 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

Any resources about threading problems?
by Bill Medland 05 Mar '05

05 Mar '05

Does anyone know any site or book or something with a decent discussion about the problems of the different threading models and their implementations? In the Developer's Guide in section 8.3 there are references to "the threading chapter". Is this a section that has not yet been written? As I understand it we (in the pthreads version) "override the native pthreads library". What does this mean? I am trying to research the issues associated with threading so that I understand the complications. The fact that Linux has two models and that Wine, FreeDCE and Samba (that I know of) seem to have found it necessary to bypass/hack/modify/override them indicates to me that there is something to understand. -- Bill Medland mailto:billmedland@mercuryspeed.com http://webhome.idirect.com/~kbmed

2 3

ESD sound support in Wine 20050111
by Kumaran Santhanam 04 Mar '05

04 Mar '05

I found a patch for ESD (Enlightenment Sound Daemon) support in Wine from July 2004. I modified this to work with Wine-20050111 and compiled the wineesd.drv.so driver. This driver works in both Wine and CrossOver 4.1. The patch and instructions are attached to this email. I have been using it for a few weeks and it seems to be working well. It would be great if it could be incorporated into the main Wine tree. Please let me know if you have any questions. Best Regards, Kumaran Wine Enlightenment Sound Daemon support --------------------------------------- [Jul 2004] Original driver code by Zhangrong Huang <hzhr(a)users.sourceforge.net> [Feb 2005] Ported to Wine 20050111 and CrossOver Office Professional 4.1 by Kumaran Santhanam <rhapsody(a)users.sourceforge.net> Instructions: 0) Make sure that esound-devel is installed. 1) Untar Wine-20050111.tar.gz 2) cd wine-20050111 3) patch -p1 <wineesd-20050111.patch 4) autoconf configure.ac >configure 5) ./configure 6) make depend 7) make Binary is built as dlls/winmm/wineesd/wineesd.drv.so

3 2

World of Warcraft - crash in game
by Alex Woods 03 Mar '05

03 Mar '05

Hi, World of Warcraft is working beautifully now apart from a crash that occurs seemingly randomly. The application is catching the crash, and giving a message like this: This application has encountered a critical error: ERROR #132 (0x85100084) Program: C:\Program Files\World of Warcraft\WoW.exe Exception: 0xC0000005 (ACCESS_VIOLATION) at 0023:557102CD EAX=00000000 EBX=55BDFCA8 ECX=00000000 EDX=55BDFBB8 ESI=5E320308 EDI=00000000 EBP=55BDFC08 ESP=55BDFB9C EIP=557102CD FLG=00010212 CS =0023 DS =002B ES =002B SS =002B FS =005B GS=0063 I know this isn't really much use on it's own. I've tried turning on +relay logging, but it's proved futile - it seems to end up freezing up my system before a crash occurs. One thing that might be useful is that the access violation always seems to be around the same small area of memory each time, eg: Exception: 0xC0000005 (ACCESS_VIOLATION) at 0023:557103CD Exception: 0xC0000005 (ACCESS_VIOLATION) at 0023:5571025D Over the course of 13 (unlucky for me ;)) crashes, these are the only 3 addresses it has given. My question is what can I do to debug this? +relay logging is probably infeasible, but I'd be happy to hack around to get it to only log certain things - I'm not sure what I'd need to log. Also, the last time it crashed, I was lucky enough to have it leave me in winedbg, which I've left open. Is there anything worth my while poking around with in there while I have the chance? I guess I'll be running memtest on my machine too, but I'd like to do what I can in winedbg first ;) Cheers. -- Alex

4 6

vartest.c - major pain in the build process
by Krzysztof Foltman 02 Mar '05

02 Mar '05

Is there any reason for gcc 3.3.1 to spend several minutes on compiling dlls/oleaut32/tests/vartest.c ? I guess it can be explained by optimization stage going nuts on compiling long functions with many branches (contained in the macros), but there must be a way to speed this up. It's barely tolerable now, and upgrading gcc is not an option for everyone. Krzysztof

9 23

Re: [PATCH] Added 2 functions to shell32
by Jacek Caban 01 Mar '05

01 Mar '05

> I doubt shell32 function on windows does this check, also original windows shell32 > function is a lot more complicated and longer, I've compared the results between > real and my code and they are correct. I wrote a small test for this function showing that your implementation is almost correct. It failes in two cases: 1. If a path ends with '\' and is compared with one that doesn't, then it's length is less than the other one, but both are the same paths. 2. If a path doesn't end with '\' and is compared with a longer one that has the same first len chars, but is not the same, ex: c:\test c:\test123 Changelog: Added test for PathIsEqualOrSubFolder Index: dlls/shell32/tests/shellpath.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/tests/shellpath.c,v retrieving revision 1.6 diff -u -p -r1.6 shellpath.c --- dlls/shell32/tests/shellpath.c 10 Feb 2005 19:19:35 -0000 1.6 +++ dlls/shell32/tests/shellpath.c 28 Feb 2005 21:19:31 -0000 @@ -871,6 +871,55 @@ static void testNonExistentPath(void) userShellFolders); } +typedef BOOL (WINAPI*fnPathIsEqualOrSubFolder)(LPCWSTR path1, LPCWSTR path2); + +static void test_PathIsEqualOrSubFolder() +{ + fnPathIsEqualOrSubFolder pPathIsEqualOrSubFolder; + BOOL ret; + static const WCHAR path1[] = {'c',':','\\','t','e','s','t',0}; + static const WCHAR path2[] = {'c',':','\\','t','e','s','t','\\','t','e','s','t',0}; + static const WCHAR path3[] = {'c',':','\\','t','e','s','t','1','2','3',0}; + static const WCHAR path4[] = {'c',':','\\','t','e','s','t','\\',0}; + static const WCHAR path5[] = {'c',':','\\','t','e','s','t','\\','t','e','s','t','2', + '\\','.','.','\\','t','e','s','t',0}; + + pPathIsEqualOrSubFolder = GetProcAddress(hShell32, (LPSTR)755); + if(!pPathIsEqualOrSubFolder) + return; + +#define TEST_PATH(p1, p2, r) \ + ret = pPathIsEqualOrSubFolder(p1, p2); \ + ok(ret == r, "PathIsEqualOrSubFolder(" #p1 " " #p2 ") failed, expected: %x\n", r); + + TEST_PATH(path1, path1, TRUE); + TEST_PATH(path1, path2, TRUE); + TEST_PATH(path1, path3, FALSE); + TEST_PATH(path1, path4, TRUE); + TEST_PATH(path2, path1, FALSE); + TEST_PATH(path2, path2, TRUE); + TEST_PATH(path2, path3, FALSE); + TEST_PATH(path2, path4, FALSE); + TEST_PATH(path3, path1, FALSE); + TEST_PATH(path3, path2, FALSE); + TEST_PATH(path3, path3, TRUE); + TEST_PATH(path3, path4, FALSE); + TEST_PATH(path4, path1, TRUE); + TEST_PATH(path4, path2, TRUE); + TEST_PATH(path4, path3, FALSE); + TEST_PATH(path4, path4, TRUE); + TEST_PATH(path5, path1, FALSE); + TEST_PATH(path5, path2, FALSE); + TEST_PATH(path5, path3, FALSE); + TEST_PATH(path5, path4, FALSE); + TEST_PATH(path5, path5, TRUE); + TEST_PATH(NULL, path1, FALSE); + TEST_PATH(path1, NULL, FALSE); + TEST_PATH(NULL, NULL, FALSE); + +#undef TEST_PATH +} + START_TEST(shellpath) { if (!init()) return; @@ -892,5 +941,6 @@ START_TEST(shellpath) testWinDir(); testSystemDir(); testNonExistentPath(); + test_PathIsEqualOrSubFolder(); } }

3 2

New uninstaller
by Jonathan Ernst 01 Mar '05

01 Mar '05

As requested, I'm trying to make a new uninstaller using a dialog instead of a window. It's my first windows program and I have something working but there are still some issues. If someone could help with some of the following problems, I'd be very thanfull. 1) Strange problem with UpdateWindow uninstaller.c, line 264 I implemented a search/filter field and I want to repaint the window after each input in the EDITTEXT control. However, when I call UpdateWindow on this line, the value returned is 1 so that a WM_PAINT message should be sent right ? But strangly no message is sent and I have to make something else (like moving the dialog) to force the window to repaint and filter the entries. The funny thing is that UpdateWindow on line 279 works just fine. I guess it's a bug in my code and not in Wine so I'd be glad if you could help me. 2) Improve filter code Currently I filter the entries that match exactly the filter string. I would like to at least make a case insensitive strstr on the string. What's the best way to do it (See uninstaller.c, line 235) 3) Stringtables a)Is there a way to load localized strings without having to guess beforehand the size of the string in each language ? b)Is there a way to not call LoadString for each string ? c)Where is the best place to load every string of a stringtable ? in main(), just before calling DialogBox() ? 4) Please tell me if you see things that are bad in the attached code, so that I'll fix it before submitting a patch. Thanks you for your help

7 13

Tools for identifying what a DLL provides?
by David D. Hagood 01 Mar '05

01 Mar '05

I have a DLL from a manufacturer that I don't have the source for, nor do I have the header or the import library for. Since Wine developers frequently have to reverse engineer what a given DLL provides, does anybody have a good recommendation for a tool that can scan the DLL and report what functions it exports, and their arg types and return types?

4 4

Jump to page:

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 February 2005