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

Wine booth/BOF and Linuxworld San Francisco, Aug 2008?
by Dan Kegel 11 Apr '08

11 Apr '08

Wine has come a long way, and will have just had its 1.0 release (knock on wood). So perhaps this is a good year to have a .org booth. What do folks think?

4 3

Re: LoadStringW [1/2]
by Dmitry Timoshkov 09 Apr '08

09 Apr '08

"Christopher" <raccoonone(a)procyongames.com> wrote: > +static void test_LoadStringW(void) > +{ > + HINSTANCE hInst = GetModuleHandle(NULL); > + WCHAR copiedstring[128], returnedstring[128], *resourcepointer = NULL; > + int strlen, strlen2; > + > + /* Check that the string which is returned by LoadStringW matches > + the string at the pointer returned by Load StringW when called with buflen = 0 */ > + strlen = LoadStringW(hInst, 2, (WCHAR *) &resourcepointer, 0); /* get pointer to resource. */ > + ok(strlen > 0, "LoadStringW failed to get pointer to resource 2, ret %d, err %d \n", strlen, GetLastError()); > + > + strlen2 = LoadStringW(hInst, 2, returnedstring, sizeof(returnedstring) /sizeof(WCHAR)); > + ok(strlen == strlen2, "LoadStringW returned different values dependent on buflen. ret1 %d, ret2 %d \n", > + strlen, strlen2); > + ok(strlen2 > 0, "LoadStringW failed to load resource 2, ret %d, err %d \n", strlen2, GetLastError()); > + > + if(resourcepointer != NULL) > + { > + memcpy(copiedstring, resourcepointer, strlen * sizeof(WCHAR)); > + copiedstring[strlen] = '\0'; > + } > + /* check that strings match */ > + ok(!memcmp(copiedstring, returnedstring, (strlen + 1)*sizeof(WCHAR)), > + "LoadStringW returned a string that does not match the string pointed to by the pointer it returned. \ > + returnedstring = %ls, copiedstring = %ls", returnedstring, copiedstring); > +} It's not clear what this test is supposed to show. If the 1st call to LoadStringW is supposed to set resourcepointer to not NULL, why don't you test it? Then 'if(resourcepointer != NULL)' check and copying to copiedstring are not needed. Also, if the test depends on a later patch to not fail, the test should be included in the patch. -- Dmitry.

4 15

USB Human Interface Device support
by Christopher 08 Apr '08

08 Apr '08

I have a flight sim, PhoenixRC, which I'd like to get working under Wine. As of a couple months ago most of the DirectX problems have been fixed, but the game uses a USB adapter to connect various controllers to the computer. The USB adapter is an HID and is recognized by Linux; however I can't get it to work through Wine. At least part of the problem seems to be that SetupDiGetClassDevs calls SETUPDI_EnumerateInterfaces which tries to open registry keys that don't exist. There isn't an entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses for HID interfaces, in fact that whole set of registry keys seems to be missing. Is anyone working on patches to make this work, or can someone point me to the function(s) that need to be implemented for HIDs to be setup in the registry correctly? I'm not sure when/how those keys are suppose to be created. Thanks, Christopher Berner

3 5

MinGW cross compilation fails for d3dx9_36/tests
by Paul Vriens 07 Apr '08

07 Apr '08

Hi, We didn't have a new winetest executable for the last few days. MinGW doesn't know anything about a d3dx9 dll (yet) that's imported in the d3dx9_36 tests. Especially while in the process of getting ready for 1.0 we should have winetest run as much as possible. My main focus will be adding tests btw until 1.0 is out. These will be both tests to proof the correctness of the current implementation as well as tests to show missing stuff. There are loads of functions for which we have no tests yet and with the 1.0 in sight I think it becomes very important to have tests for virtually every function we (have) implement(ed). -- Cheers, Paul.

11 31

Proposal: versioning .wine directory
by Dan Kegel 07 Apr '08

07 Apr '08

On the wine-users list, we're getting a lot of users who have old or even ancient .wine directories, and whose problems go away with a fresh .wine directory Perhaps we should have wineprefixcreate stamp the version of wine the .wine directory was created with, make wine-1.0 refuse to run with pre-1.0 .wine directories, and require that future versions of wine run properly with .wine directories created by any earlier stable release of wine. It wouldn't be hard, at least at first, and it might save a lot of support inquiries. What say?

9 16

DLL exports... HELP?!
by pure_evil＠mail.bg 05 Apr '08

05 Apr '08

Folks, I've been trying to make a bunch of control panel applets for wine for some time now. a CPL is basically a DLL which (the most importnat part) exports a function called "CPlApplet"; Without it, the cpl isn't worth a thing. It is the presence of that export which basically identifies it as a control panel applet. Indeed, opening a random .cpl with dllexp yields: Function: CPlApplet Address: 0x0041b604 Relative Address: 0x0041b604 Ordinal 1 (0x1) Filename: intl.cpl This one is from the cpl I wrote some time ago in Delphi, and it's the same with all other 'doze cpls. I'm working on porting it to C and wine, but that export is really getting the best of me. However, dllexp doesn't detect _any_ DLL exports in wine's .dlls, so I'm stuck without a template :( Am I missing something? (A simple *hello world* dll source that compiles against wine's source and exports ANY function would be greatly appreciated) Thanks in advance, Stefanov. ------------------------------------- Вземи 2 безплатни месеца БТК ADSL! Поръчай online дo 20 март 2008! Надежден Високоскоростен Интернет! http://www.btc.bg/bg/adsl_order.php?residential&action=order&view_pack=1 Folks, I've been trying to make a bunch of control panel applets for wine for some time now. a CPL is basically a DLL which (the most importnat part) exports a function called "CPlApplet"; Without it, the cpl isn't worth a thing. It is the presence of that export which basically identifies it as a control panel applet. Indeed, opening a random .cpl with dllexp yields: Function: CPlApplet Address: 0x0041b604 Relative Address: 0x0041b604 Ordinal 1 (0x1) Filename: intl.cpl This one is from the cpl I wrote some time ago in Delphi, and it's the same with all other 'doze cpls. I'm working on porting it to C and wine, but that export is really getting the best of me. However, dllexp doesn't detect _any_ DLL exports in wine's .dlls, so I'm stuck without a template :( Am I missing something? (A simple *hello world* dll source that compiles against wine's source and exports ANY function would be greatly appreciated) Thanks in advance, Stefanov.

5 13

Some considerations about the Wine FUSE project for GSoC
by Kai Blin 02 Apr '08

02 Apr '08

Hi folks, after another chat about Wine's goals in respect to FUSE file systems on IRC, I just wanted to point the students who applied for this project already (I've Bcced them) at the goals Wine has for this GSoC project. For Wine, the goal is to create prototype FUSE file systems so we can figure out if this approach is useful to Wine at all. There is no immediate goal to include the file systems into Wine in the near future, we first want to know if they're what we need. I think it's important to be clear and outspoken about this so nobody starts working on this under the wrong assumptions. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

2 6

crash on exit in hardy on intel graphics?
by Dan Kegel 02 Apr '08

02 Apr '08

Grumble. wineprefixcreate is showing a crash while running rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf No traceback is shown normally, but running that command under winedbg shows one on exit: Unhandled exception: page fault on read access to 0x00000200 in 32-bit code (0xb7f03bad). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:b7f03bad ESP:0034fa90 EBP:0034fab8 EFLAGS:00010292( - 00 -RISA1) EAX:b7f0bce0 EBX:b7f0bff4 ECX:b7efe5b9 EDX:b7c5e6ac ESI:00000000 EDI:00000000 Stack dump: 0x0034fa90: b7ef0eec b7f0bff4 0034fae0 7c017834 0x0034faa0: 0034fb14 b7efa059 0034fb5c b7c61ff4 0x0034fab0: 00000000 7c003188 0034fac8 b7c5fcb4 0x0034fac0: 00000000 b7f0bff4 0034fba8 b7efe5d6 0x0034fad0: 00000000 00000000 0034fb38 b7cce2d1 0x0034fae0: 7c003190 7c003198 7c003194 b7c5e6ac Backtrace: =>1 0xb7f03bad in ld-linux.so.2 (+0x12bad) (0x0034fab8) 2 0xb7c5fcb4 GLIBC_2+0xcb4() in libdl.so.2 (0x0034fac8) 3 0xb7efe5d6 in ld-linux.so.2 (+0xd5d6) (0x0034fba8) 4 0xb7c602bc in libdl.so.2 (+0x12bc) (0x0034fbc8) 5 0xb7c5fcea GLIBC_2+0xcea() in libdl.so.2 (0x0034fbd8) 6 0x7dda57bd in libgl.so.1 (+0x477bd) (0x0034fbf8) 7 0x7dd8584a in libgl.so.1 (+0x2784a) (0x0034fc18) 8 0x7dd87924 in libgl.so.1 (+0x29924) (0x0034fc48) 9 0x7dd80ba4 in libgl.so.1 (+0x22ba4) (0x0034fc58) 10 0x7ddc39bc glIsRenderbufferEXT+0x16c() in libgl.so.1 (0x0034fc68) 11 0xb7efefdf in ld-linux.so.2 (+0xdfdf) (0x0034fe18) 12 0xb7c90f74 exit+0xd4() in libc.so.6 (0x0034fe38) 13 0x7efacc80 RtlGetCurrentPeb() [/home/dank/wine-git/dlls/ntdll/process.c:70] in ntdll (0x0034fec8) 14 0x7ee7d62f ExitProcess+0x2f(status=0x0) [/home/dank/wine-git/dlls/kernel32/process.c:2046] in kernel32 (0x0034fee8) 15 0x7ecad3ba __wine_spec_exe_entry+0x6a(peb=0x7ffdf000) [/home/dank/wine-git/dlls/winecrt0/exe_entry.c:38] in rundll32 (0x0034ff08) 16 0x7ee7fd4e start_process+0xee(arg=0x0) [/home/dank/wine-git/dlls/kernel32/process.c:883] in kernel32 (0x0034ffe8) 17 0xb7de18f7 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) 0xb7f03bad: testb $0x8,0x200(%edi) libgl.so is involved, so perhaps the is a graphics driver bug? The system is a thinkpad x60 with intel graphics. glxgears gets 960 fps. Anybody else seeing this? It seems kind of benign, and doesn't keep 'wine notepad' from working...

2 5

Hey all, introducing myself and my GSoC idea...
by a a 01 Apr '08

01 Apr '08

My name is Alex. I'm an 18 year old Freshman at the University of South Florida. I'm an electrical engineer, but I've been coding since I was 13. I love low-level stuff, like assembly and ugly C, machine code, etc. I like to be able to smell the processor I'm so close to the metal. I made a proposal on GSoC to improve support for the Native API, an undocumented API in Windows. I'd really like to code for the Wine Project, since I like Windows, I like Linux, and I especially like low-level scrounging. I'm usually available by MSN, and generally fairly friendly. Send me an IM, or reply here to critique my proposal. It's entitled " Proposal to improve Wine's support of the Native API". I'm registered as cholinesterase(a)gmail.com. Will someone look it over and tell me what they think? Also, suggested reading would be nice, especially if it pertains to the project idea and Wine's code base! Thanks for reading.

5 6

Re: user32: Implement GetWindowModuleFileName with tests (try 2)
by Alexandre Julliard 01 Apr '08

01 Apr '08

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> writes: > @@ -3121,9 +3133,21 @@ UINT WINAPI GetWindowModuleFileNameA( HWND hwnd, LPSTR lpszFileName, UINT cchFil > */ > UINT WINAPI GetWindowModuleFileNameW( HWND hwnd, LPWSTR lpszFileName, UINT cchFileNameMax) > { > - FIXME("GetWindowModuleFileNameW(hwnd %p, lpszFileName %p, cchFileNameMax %u) stub!\n", > - hwnd, lpszFileName, cchFileNameMax); > - return 0; > + HINSTANCE hInst; > + UINT ret; > + TRACE("hwnd %p, lpszFileName %p, cchFileNameMax %u\n", hwnd, lpszFileName, cchFileNameMax); > + > + hInst = (HINSTANCE)GetWindowLongPtrW(hwnd, GWLP_HINSTANCE); > + if (!hInst) > + { > + if (hwnd == GetDesktopWindow() || !IsWindow(hwnd)) > + return 0; > + hInst = GetModuleHandleW(0); > + } > + > + ret = GetModuleFileNameW(hInst, lpszFileName, cchFileNameMax); > + TRACE("--> %d %s\n", ret, debugstr_wn(lpszFileName, ret)); > + return ret; This won't work across processes. -- Alexandre Julliard julliard(a)winehq.org

2 2