June 2009 - Wine-devel - list.winehq.org

How do I actually write a testcase for a 16-bit API ?
by Alex Villacís Lasso 09 Jun '09

09 Jun '09

I recently filed http://bugs.winehq.org/show_bug.cgi?id=18734 in which I showed that DlgDirList is behaving incorrectly for 16-bit apps. I also included a test program compiled with the Watcom C compiler, as well as a patch. Then a comment appeared saying that it should be possible to create a testcase for this API. So I tried. At first, I thought that since this was a 16-bit API, I should be adding -Wb,--subsystem,win16 to the Makefile. However, this results in the linker complaining that it cannot find WinMain16. So I removed it. Also, I had undefined link-time references to SendMessage16 and similar (because I want everything to go through the 16-bit APIs, else the whole point of the test is lost), so I had to manually add them to the spec files for kernel32 and user32. But after doing this and getting a test program, an attempt to create the window out of the registered class fails and triggers an assertion. I have no examples of previous 16-bit tests (as opposed to 16-bit Wine dlls) to draw upon, so I don't know how to proceed correctly to test a 16-bit API in a way that convinces everyone that the patch is correct. What do you think of this? -- perl -e '$x=2.3;printf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

5 6

How is 0.0.0.0 handled in Wine?
by Austin English 09 Jun '09

09 Jun '09

Howdy all, Doing some testing with PuTTY, I've noticed some strange behavior. I've got windows XP in a VM, and when comparing behavior to Wine, I noticed some inconsistencies with respect to the '0.0.0.0' invalid address. Windows: Putty -> 0.0.0.0: throws an error "Network error: Cannot assign requested address" ping (in cmd.exe): D:\appinstall>ping 0.0.0.0 Pinging 0.0.0.0 with 32 bytes of data: Destination specified is invalid. Destination specified is invalid. Destination specified is invalid. Destination specified is invalid. Ping statistics for 0.0.0.0: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), Wine: Putty -> 0.0.0.0 route to localhost, login succeeds (Not sure if it's routing to localhost or 127.0.0.1) FWIW, Ubuntu: ssh -> 0.0.0.0: routes to localhost, where I've got sshd running, connects fine. ping -> 0.0.0.0 routes to 127.0.0.1, succeeds Seems to me to be a bug, i.e., Wine shouldn't be able to use 0.0.0.0. It seems that we're simply passing this on to the host os, which is then routing it back to localhost. Perhaps we need to catch 0.0.0.0 as a special case and refuse? Grepping in the source code for 0.0.0.0 only shows a few hits: comctl32 (unrelated), rpcrt4 (appears unrelated) and ws2_32 (but only in the tests, not in the implementation). -- -Austin

5 13

Latest git fails compiling
by Uwe Bonnes 09 Jun '09

09 Jun '09

Hello, on a fresh tree check out and compiled successfully yesterday (090608) and updated today(090609), compile fails with: make[1]: Entering directory `/media/sda8/sdb8/spare/bon/Wine/wine-git/include' ../tools/widl/widl -I. -I. -I../include -I../include \ -h -H activaut.h activaut.idl ../tools/widl/widl -I. -I. -I../include -I../include \ -h -H activdbg.h activdbg.idl ../tools/widl/widl -I. -I. -I../include -I../include \ -h -H activscp.h activscp.idl oaidl.idl:121: error: parameter 'pvData' of (null) 'tagSAFEARRAY' \ cannot derive from void * make[1]: *** [activscp.h] Fehler 1 make[1]: Leaving directory `/media/sda8/sdb8/spare/bon/Wine/wine-git/include' This is on Suse 11.1, x86-64. I have not seens this reported before. Any hints for fixing (perhaps my setup)? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 5

Add-stub-for-IoOpenDeviceRegistryKey-needed-for-l.patch
by Uwe Bonnes 09 Jun '09

09 Jun '09

Appended stup is needed for libusb-win32-0.1x -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- >From 7216b1e26b9cbd3d4bb7eaa096757ad11d0b77b5 Mon Sep 17 00:00:00 2001 From: Uwe Bonnes <bon(a)hertz.ikp.physik.tu-darmstadt.de> Date: Tue, 9 Jun 2009 16:41:09 +0200 Subject: Add stub for IoOpenDeviceRegistryKey(), needed for libusb-win32-0.1.2 --- dlls/ntoskrnl.exe/ntoskrnl.c | 11 +++++++++++ dlls/ntoskrnl.exe/ntoskrnl.exe.spec | 2 +- 2 files changed, 12 insertions(+), 1 deletions(-) diff --git a/dlls/ntoskrnl.exe/ntoskrnl.c b/dlls/ntoskrnl.exe/ntoskrnl.c index 5a043e5..99c2847 100644 --- a/dlls/ntoskrnl.exe/ntoskrnl.c +++ b/dlls/ntoskrnl.exe/ntoskrnl.c @@ -2493,6 +2493,17 @@ NTSTATUS WINAPI PsSetCreateThreadNotifyRoutine( PCREATE_THREAD_NOTIFY_ROUTINE No /*********************************************************************** + * IoOpenDeviceRegistryKey (NTOSKRNL.EXE.@) + */ +NTSTATUS WINAPI IoOpenDeviceRegistryKey( PDEVICE_OBJECT DeviceObject, +ULONG DevInstKeyType, ACCESS_MASK DesiredAccess, PHANDLE DevInstRegKey) +{ + FIXME( "stub:\n"); + return STATUS_SUCCESS; +} + + +/*********************************************************************** * MmGetSystemRoutineAddress (NTOSKRNL.EXE.@) */ PVOID WINAPI MmGetSystemRoutineAddress(PUNICODE_STRING SystemRoutineName) diff --git a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec index 52efd92..cda9230 100644 --- a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec +++ b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec @@ -409,7 +409,7 @@ @ stdcall IoIsWdmVersionAvailable(long long) @ stub IoMakeAssociatedIrp @ stub IoOpenDeviceInterfaceRegistryKey -@ stub IoOpenDeviceRegistryKey +@ stdcall IoOpenDeviceRegistryKey (long long long long) @ stub IoPageRead @ stub IoPnPDeliverServicePowerNotification @ stub IoQueryDeviceDescription -- 1.6.0.2

1 0

Re: wine-patches Digest, Vol 47, Issue 40
by Piotr Caban 09 Jun '09

09 Jun '09

> Message: 2 > Date: Thu, 04 Jun 2009 22:37:48 +0200 > From: Piotr Caban <piotr.caban(a)gmail.com> > Subject: jscript: Added Date_getFullYear and Date_getUTCFullYear > implementation (3/7) > To: wine-patches(a)winehq.org > Message-ID: <4A28309C.9000401(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > --- > dlls/jscript/date.c | 73 > ++++++++++++++++++++++++++++++++++++++++++-- > dlls/jscript/tests/api.js | 9 +++++ > 2 files changed, 78 insertions(+), 4 deletions(-) Whats wrong with this patch? All the date expressions (e.g. day_from_year) are copied from ECMA-262 standard specification. Because of the date range it can be keep in double without error. Piotr Caban

2 1

Re: mlang/tests: [Patch 2] Skip some tests on systems, that do not support CP_UTF8
by Alexandre Julliard 09 Jun '09

09 Jun '09

Detlef Riekenberg <wine.dev(a)web.de> writes: > @@ -1164,6 +1165,14 @@ static void test_GetRfc1766Info(IMultiLanguage2 *iML2) > ok(!lstrcmpA(rfc1766A, info_table[i].rfc1766), > "#%02d: got '%s' (expected '%s')\n", i, rfc1766A, info_table[i].rfc1766); > > + if (!localenameA[0]) { > + /* old win95 systems do not support CP_UTF8 */ > + if (!i) > + win_skip("CP_UTF8 not supported on this system\n"); > + > + continue; > + } You should store the table in Unicode instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32: Prevent second loading of a library with specified path.
by Alexandre Julliard 09 Jun '09

09 Jun '09

Alexander Morozov <amorozov(a)etersoft.ru> writes: > Changelog > Prevent second loading of a library with specified path > > This patch fixes bug #18775. I tested WinXP and Win2003. > > When a library have long name (> 8 symbols before extension) an application > can run LoadLibrary(long name) and later LoadLibrary(8.3 name). > In some cases Windows will load image second time, in other it will return > pointer to already loaded image. > I found that Windows does not load library second time in these cases: > 1) c:\dir\libliblib.dll and c:\dir\LIBLIB~1.DLL > 2) \dir\libliblib.dll and \dir\LIBLIB~1.DLL > 3) .\libliblib.dll and .\LIBLIB~1.DLL > 4) dir\libliblib.dll and dir\LIBLIB~1.DLL > and load it in cases: > 5) libliblib.dll and LIBLIB~1.DLL > 6) c:libliblib.dll and c:LIBLIB~1.DLL This should most likely be done in ntdll. Also please add tests for these different cases. -- Alexandre Julliard julliard(a)winehq.org

3 3

re: How do I actually write a testcase for a 16-bit API ?
by Dan Kegel 08 Jun '09

08 Jun '09

See also http://lists.debian.org/debian-legal/2006/07/msg00007.html I kind of doubt it will ever make it in to ubuntu. When I tried building win16 binaries with the Linux version, there were lots of path problems. That was two years ago, but I wouldn't be surprised if they're still there. These two things together make me suspect that installing the windows version in Wine is the way to go. We could make a script that does that in an alternate prefix and provides wrapper scripts that hide the wine-ness of it to some extent, maybe. That could be done as a stopgap while the test suite is refreshed and gotten ready to add into the wine tree. Once that's far enough along, it might then be worth looking at getting the linux version working and into a PPA. Or vice versa. Wish I had time to play with this stuff. I would really be happy if somebody got the win16 test suite into the wine tree! - Dan

1 0

Re: wine-devel Digest, Vol 47, Issue 32
by chris ahrendt 08 Jun '09

08 Jun '09

Did we find out what the regression is for 1.1.23 that caused the ATI and other non NVIDIA cards to start failing? Chris

1 0

Re: riched20/tests: fix test for vista
by Paul Vriens 08 Jun '09

08 Jun '09

André Hentschel wrote: > Vista turns the "(WCHAR)1234" into a "(unsigned char)1234". > This causes error on vista machines<SP2: > http://test.winehq.org/data/7aeffc442cc1b9a454f1ff7d7b3175b4bba88b05/vista_… > > editor.c:3249: Test failed: EM_GETPASSWORDCHAR returned Ò (210) when set > to 'x', instead of x (120) > --- > dlls/riched20/tests/editor.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > ------------------------------------------------------------------------ > > Hi André, Is there anything special about this box? Could it be that the locale plays a role in this. I'm asking as my Vista box (and several others seen on test.winehq.org) doesn't have this issue. -- Cheers, Paul.

1 0