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

Re: combo - implement GetComboBoxInfo
by Steven Edwards 16 Mar '05

16 Mar '05

Hi, --- Alexandre Julliard <julliard(a)winehq.org> wrote: > The IsWindow check is useless, what you need is to verify that it's > really a combobox. The right way to do that is probably to send a > CB_GETCOMBOBOXINFO message instead. How about something like this instead? Index: dlls/user/combo.c =================================================================== RCS file: /home/wine/wine/dlls/user/combo.c,v retrieving revision 1.8 diff -u -r1.8 combo.c --- dlls/user/combo.c 23 Dec 2004 17:21:05 -0000 1.8 +++ dlls/user/combo.c 15 Mar 2005 19:09:52 -0000 @@ -27,7 +27,6 @@ * If you discover missing features, or bugs, please note them below. * * TODO: - * - GetComboBoxInfo() * - ComboBox_[GS]etMinVisible() * - CB_GETCOMBOBOXINFO * - CB_GETMINVISIBLE, CB_SETMINVISIBLE @@ -2293,10 +2292,27 @@ /************************************************************************* * GetComboBoxInfo (USER32.@) */ -BOOL WINAPI GetComboBoxInfo(HWND hwndCombo, /* [in] handle to combo box */ - PCOMBOBOXINFO pcbi /* [in/out] combo box information */) -{ - FIXME("\n"); - return FALSE; - +BOOL WINAPI +GetComboBoxInfo(HWND hwndCombo, /* [in] handle to combo box */ + PCOMBOBOXINFO pcbi /* [in/out] combo box information */) +{ + static const WCHAR ComboBoxW[] = { 'C', 'o', 'm', 'b', 'o', 'B', 'o', 'x', 0 }; + CHAR szBuffer[MAX_PATH + 1]; + int dwSize; + LPHEADCOMBO lphc; + + dwSize = GetClassNameW(hwndCombo, szBuffer, sizeof(szBuffer)/sizeof(szBuffer[0])-1); + + if (lstrcmpiW(szBuffer, ComboBoxW) != 0) + return FALSE; + + lphc = (LPHEADCOMBO)GetWindowLongPtrW( hwndCombo, 0 ); + + pcbi->hwndCombo = hwndCombo; + pcbi->hwndList = lphc->hWndLBox; + pcbi->hwndItem = lphc->hWndEdit; + pcbi->rcItem = lphc->textRect; + pcbi->rcButton = lphc->buttonRect; + pcbi->stateButton = lphc->wState; + return TRUE; } __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

5 5

Debugging idiosyncrasy
by Paul Millar 16 Mar '05

16 Mar '05

Hi, Something I've noticed whilst playing with winedbg (and its auto mode). If there's no AeDebug key in the registry, then the default is to run the debugger in non-interactive mode: paul(a)scaramanga:~/CVS/wine$ grep cmdline.*winedbg dlls/kernel/except.c sprintf(cmdline, "winedbg --auto %ld %ld", Yet, if there's no registry at all, then the default registry values are configured to run the debugger in interactive mode: paul(a)scaramanga:~/CVS/wine$ grep AeDebug.*Debugger tools/wine.inf HKLM,Software\Microsoft\Windows NT\CurrentVersion\AeDebug,"Debugger",,"winedbg %ld %ld" I think we should be consistent here, no? Cheers, Paul

1 0

Got message form ./configure to send this e-mail
by Lauris Misa 16 Mar '05

16 Mar '05

Hello! I'm trying to compile wine on my AMD64 system and I got this message on STDERR: configure: WARNING: valgrind/memcheck.h: present but cannot be compiled configure: WARNING: valgrind/memcheck.h: check for missing prerequisite headers? configure: WARNING: valgrind/memcheck.h: see the Autoconf documentation configure: WARNING: valgrind/memcheck.h: section "Present But Cannot Be Compiled" configure: WARNING: valgrind/memcheck.h: proceeding with the preprocessor's result configure: WARNING: valgrind/memcheck.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to wine-devel(a)winehq.org ## configure: WARNING: ## ------------------------------------ ## and of course it crashes when I run make depend.;( Is there some way to get wine compiled? Thank You! Lauris >LMP< -- For people who like peace and quiet: a phoneless cord.

1 0

Re: shell32: set %AllUsersProfile%, and fix shell folder registration
by Juan Lang 16 Mar '05

16 Mar '05

--- Alexandre Julliard <julliard(a)winehq.org> wrote: > > ChangeLog: > > - %AllUsersProfile% was not getting set in the environment, spotted by > > Vitaly Lipatov > > This should be done in wine.inf, not in the code. Okay, but it's a subdirectory of the windows directory, and that's no longer getting set in wine.inf either. I rely on GetWindowsDirectory to find it. If you want it back here though I'll move it. --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

2 1

Wine's Documentation in French
by Francois Gouget 16 Mar '05

16 Mar '05

The Wine documentation has been translated to French by students from the Insa of Rouen. The credits for the translation go to: * Wine User Guide Romain CONSEIL Damien GIRAUDEAU Guillaume LEFEBVRE Yvon BENOIST (proofreading) http://fgouget.free.fr/wine/wine-user.html * Wine FAQ Romuald VIEUX Yvon BENOIST (proofreading) http://fgouget.free.fr/wine/wine-faq.html * WineLib User Guide José CARRENO Yvon BENOIST (proofreading) http://fgouget.free.fr/wine/winelib-user.html And believe me, this is a lot of work so they really deserve our kudos. You probably noticed that the Wine Developer's Guide was not translated but that makes sense: if you want to work on Wine it's really best if you speak English anyway. So what's needed now is to integrate the translation with Wine. This is what I have done by converting the translation to .po format to make it easier to maintain and tweaking the Makefiles accordingly. The patch is pretty big (even compressed it's more than 200KB) so I did not attach it to this email. Instead I have set up a page on my web site and you can the patch using this URL: http://fgouget.free.fr/wine/docfr.diff.gz Here is what the patch does: Add a Makedoc.rules.in file which handles the conversion of SGML files to the final documentation format. Modify documentation/Makefile.in to use Makedoc.rules.in. Add documentation/fr with the po files of the French translation. Use po4a to generate a translated Sgml file from the original sgml documentation and then let Makedoc.rules.in generate the documentation. Detect po4a in configure.ac. The translation appears to have been made from a snapshot of the documentation taken in the summer of 2004. Now, a bit more than 6 months later, the translation is still more than 90% complete. IMHO this proves that maintaining the translation is quite feasible. If you see any bits of English in the documents above, this is precisely because the translation is not 100% complete anymore: in that case po4a-translate keeps the original version rather than use the outdated translation. For more information about po4a: http://po4a.alioth.debian.org/ I will upload anything new to the following page: http://fgouget.free.fr/wine/docfr.shtml Now you pretty much know everything. Let me know if you have concerns, suggestions, etc. I'm hoping we can get this in place soon. -- Francois Gouget fgouget(a)codeweavers.com

2 2

Re: SHELL32: add defines for SLDF flags
by Dmitry Timoshkov 16 Mar '05

16 Mar '05

"Mike McCormack" <mike(a)codeweavers.com> wrote: > +typedef struct { > + DWORD cbSize; > + DWORD cbSignature; > + CHAR szTarget[MAX_PATH]; > + WCHAR szwTarget[MAX_PATH]; > +} EXP_SZ_LINK, EXP_SZ_LINK_SIG; It's for sure a typo: EXP_SZ_LINK_SIG was supposed to be *LPEXP_SZ_LINK. -- Dmitry.

1 0

Regression (SimCity 3000 is Broke )
by Tony Lambregts 16 Mar '05

16 Mar '05

After working prefectly for over 2 years SimCity 3000 is broken. The patch that broke it is http://www.winehq.org/hypermail/wine-cvs/2005/03/0098.html basicly the problem is simple. The source and the destination are both the same surface in DIB_DirectDrawSurface_Blt() and with the new locking in place the destination never gets updated. So althought it might fix Picasa2 it is definatly not correct. -- Tony Lambregts

5 12

Re: flexible-mmap breaks application
by Michael Ost 16 Mar '05

16 Mar '05

On Tue, 2005-03-15 at 15:55, Uwe Bonnes (bon_at_elektron.ikp.physik.tu-darmstadt.de) wrote: > The definition of the task is clear: > Have a way to tell the kernel to not mmap memory above 0x7fffffff > However the implementation is unclear to me: > - Should this be a new syscall? > - Or should we set some kernel parameter? Per task or global? There is a related problem in that Wine's VirtualAlloc won't allocate the full 2GB it should. As I understand it the problem is the different memory ranges that linux and windows allocate from --- the intersection of the two platforms is only 1GB (not the 2GB it should be) from 0x4000,0000 to 0x8000,0000. Could this patch also include a lower limit, letting linux mmap from addresses in the same range that win32 does? - mo PS: the thread on this issue starts at http://www.winehq.com/hypermail/wine-devel/2005/03/0643.html. It also covers the issue of Wine's lack of mlock/munlock functionality.

1 0

winsock conformance test - added tests for sendto, recvfrom, and getservbyname
by Thomas Kho 16 Mar '05

16 Mar '05

Hi, We're working to add conformance tests to winsock, and we've currently added tests for sendto, recvfrom, and getservbyname. Before we post to wine-patches, we'd appreciate any critiques/input. We chose these previously untested functions to test for the following reasons: - UDP is often used and was not previously tested - getservbyname uses the same critical section code as the other database functions; we thought it would be useful to stress tests this. We ran gcov to see how much of dlls/winsock/socket.c we tested, and found: Before: 41.16% of file dlls/winsock/socket.c After: 46.38% of file dlls/winsock/socket.c http://hkn.icsl.ucla.edu/~tom/socket_c_2.gcov.txt We'd also appreciate other targets to test. Thanks for your help, Thomas Kho Files available at: http://www.geekymedia.com/viewcvs/cgi/viewcvs.cgi/wine4/wine/dlls/winsock/t… Changelog: * dlls/winsock/tests/sock.c added tests for sendto, recvfrom, and getservbyname # Signed-off-by: Thomas Kho <tkho(a)ucla.edu> # --- wine_cvs/dlls/winsock/tests/sock.c 2005-03-15 07:49:01.000000000 -0800 +++ wine_build/dlls/winsock/tests/sock.c 2005-03-15 15:14:52.000000000 -0800 @@ -37,6 +37,14 @@ #define TEST_TIMEOUT 30 /* seconds to wait before killing child threads after server initialization, if something hangs */ +#define NUM_UDP_PEERS 3 /* Number of UDP sockets to create and test > 1 */ + +#define NUM_THREADS 3 /* Number of threads to run getservbyname */ +#define NUM_QUERIES 250 /* Number of getservbyname queries per thread */ + +#define SERVERIP "127.0.0.1" /* IP to bind to */ +#define SERVERPORT 9374 /* Port number to bind to */ + #define wsa_ok(op, cond, msg) \ do { \ int tmp, err = 0; \ @@ -862,8 +870,8 @@ #define STD_STREAM_SOCKET \ SOCK_STREAM, \ 0, \ - "127.0.0.1", \ - 9374 + SERVERIP, \ + SERVERPORT static test_setup tests [NUM_TESTS] = { @@ -932,6 +940,105 @@ } }; +static void test_UDP() +{ + /* This function tests UDP sendto() and recvfrom(). UDP is unreliable, so it is + possible that this test fails due to dropped packets. */ + + /* peer 0 receives data from all other peers */ + struct sock_info peer[NUM_UDP_PEERS]; + char buf[16]; + int ss, i, n_recv, n_sent; + + for ( i = NUM_UDP_PEERS - 1; i >= 0; i-- ) { + ok ( ( peer[i].s = socket ( AF_INET, SOCK_DGRAM, 0 ) ) != INVALID_SOCKET, "UDP: socket failed\n" ); + + peer[i].addr.sin_family = AF_INET; + peer[i].addr.sin_addr.s_addr = inet_addr ( SERVERIP ); + + if ( i == 0 ) { + peer[i].addr.sin_port = htons ( SERVERPORT ); + } else { + peer[i].addr.sin_port = htons ( 0 ); + } + + do_bind ( peer[i].s, (struct sockaddr *) &peer[i].addr, sizeof( peer[i].addr ) ); + + /* test getsockname() to get peer's port */ + ss = sizeof ( peer[i].addr ); + ok ( getsockname ( peer[i].s, (struct sockaddr *) &peer[i].addr, &ss ) != SOCKET_ERROR, "UDP: could not getsockname()\n" ); + ok ( peer[i].addr.sin_port != htons ( 0 ), "UDP: bind() did not associate port\n" ); + } + + /* test getsockname() */ + ok ( peer[0].addr.sin_port == htons ( SERVERPORT ), "UDP: getsockname returned incorrect peer port\n" ); + + for ( i = 1; i < NUM_UDP_PEERS; i++ ) { + /* send client's ip */ + memcpy( buf, &peer[i].addr.sin_port, sizeof(peer[i].addr.sin_port) ); + n_sent = sendto ( peer[i].s, buf, sizeof(buf), 0, (struct sockaddr*) &peer[0].addr, sizeof(peer[0].addr) ); + ok ( n_sent == sizeof(buf), "UDP: sendto() sent wrong amount of data or socket error: %d\n", n_sent ); + } + + for ( i = 1; i < NUM_UDP_PEERS; i++ ) { + n_recv = recvfrom ( peer[0].s, buf, sizeof(buf), 0,(struct sockaddr *) &peer[0].peer, &ss ); + ok ( n_recv == sizeof(buf), "UDP: recvfrom() received wrong amount of data or socket error: %d\n", n_recv ); + ok ( memcmp ( &peer[0].peer.sin_port, buf, sizeof(peer[0].addr.sin_port) ) == 0, "UDP: port numbers do not match\n" ); + } +} + +static void WINAPI do_getservbyname( HANDLE *starttest ) +{ + struct { + char *name; + char *proto; + int port; + } serv[2] = { {"domain", "udp", 53}, {"telnet", "tcp", 23} }; + + int i, j; + struct servent *pserv[2]; + + ok ( WaitForSingleObject ( *starttest, TEST_TIMEOUT * 1000 ) != WAIT_TIMEOUT, "test_getservbyname: timeout waiting for start signal\n"); + + // ensure that necessary buffer resizes are completed + for ( j = 0; j < 2; j++) { + pserv[j] = getservbyname ( serv[j].name, serv[j].proto ); + } + + for ( i = 0; i < NUM_QUERIES / 2; i++ ) { + for ( j = 0; j < 2; j++ ) { + pserv[j] = getservbyname ( serv[j].name, serv[j].proto ); + ok ( pserv[j] != NULL, "getservbyname could not retreive information for %s: %d\n", serv[j].name, WSAGetLastError() ); + ok ( pserv[j]->s_port == htons(serv[j].port), "getservbyname returned the wrong port for %s: %d\n", serv[j].name, ntohs(pserv[j]->s_port) ); + ok ( !strcmp ( pserv[j]->s_proto, serv[j].proto ), "getservbyname returned the wrong protocol for %s: %s\n", serv[j].name, pserv[j]->s_proto ); + ok ( !strcmp ( pserv[j]->s_name, serv[j].name ), "getservbyname returned the wrong name for %s: %s\n", serv[j].name, pserv[j]->s_name ); + } + + ok ( pserv[0] == pserv[1], "getservbyname: winsock resized servent buffer when not necessary\n" ); + } +} + +static void test_getservbyname() +{ + int i; + HANDLE starttest, thread[NUM_THREADS]; + DWORD thread_id[NUM_THREADS]; + + starttest = CreateEvent ( NULL, 1, 0, "test_getservbyname_starttest" ); + + /* create threads */ + for ( i = 0; i < NUM_THREADS; i++ ) { + thread[i] = CreateThread ( NULL, 0, (LPTHREAD_START_ROUTINE) &do_getservbyname, &starttest, 0, &thread_id[i] ); + } + + /* signal threads to start */ + SetEvent ( starttest ); + + for ( i = 0; i < NUM_THREADS; i++) { + WaitForSingleObject ( thread[i], TEST_TIMEOUT * 1000 ); + } +} + static void test_WSAAddressToStringA() { INT ret; @@ -1191,6 +1298,10 @@ trace ( " **** TEST %d COMPLETE **** \n", i ); } + test_UDP(); + + test_getservbyname(); + test_WSAAddressToStringA(); test_WSAAddressToStringW();

1 0

World Of Warcraft
by cyrix12＠cox.net 15 Mar '05

15 Mar '05

Hi, I'm the maintainer for World of Warcraft, and I've noticed a few things which have been pointed out before (on irc, bugzilla, mailing list) but have not really gotten any attention. As this is one of the most popular, if not THE most popular pc game at the moment, it seems as though it would be worthwhile to look into getting this to work if it does not require a complete rewrite of wine to do so. There are currently two things preventing operation of the game. Firstly, I'll start off by saying that there are two separate modes to run the game in. d3d9, and opengl. The d3d9 mode doesn't currently work since the support for this dll is not complete. I have been following it closely though, and I constantly find myself impressed with the amount of work being poured into it lately. It's really coming along, and I've even gotten it to run a few demos. Unfortunately, even with the latest patches it still comes up with a blank screen. I don't want to rush anything in this department since I know there's a massive transition from the d3d* architecture to wine3d, and I think it's a really great idea to funnel everything through opengl and only need one rendering library. It's hard for me to say as a WoW addict myself, but I would rather have a complete implementation of d3d9 than one that is only able to play WoW. So I guess what I'd like to say on this front is this: awesome work guys! As for the opengl mode, it crashes strangely just after the character loading screen, but before actually getting into the game. I'm not really sure exactly what is causing the crash. I've run several traces, and all that comes up is a large group of fixmes which look like this: fixme:thread:GetThreadTimes Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet The error I am able to get (when I change my winver to win2k) is an actual game error (not given by wine). This one looks like this: ERROR #0 (0x85100000) Program: C:\Program Files\World of Warcraft\WoW.exe File: C:\build\buildWoW\WoW\Source\Ui\MinimapFrame.cpp Line: 1287 Expr: !("CGMinimapFrame::Initialize(): can't get render target for minimap") I posted a bug about this on December 7, 2004 at this location: http://bugs.winehq.org/show_bug.cgi?id=2603 Nothing has happened yet with this bug except for someone else confirming it. I'd appreciate it if someone could give me one of two pieces of information (both would be spectacular!): 1) What exactly is causing the problem with the opengl version, and is it easy to fix? 2) Is there any sort of goal that the people working on d3d9 dlls have set as far as a date they would like to have it done by? Or is it just one of those "It will be done when it's done" sort of things? Thanks in advance, Darckness -- Stop searching forever. Happiness is unattainable.

14 57