Re: try4 [1/3] kernel32/tests: Add tests for GetVolumeInformationA and QueryDosDevice
Guy Albertelli wrote: Fixed memory leak and changed skip to win_skip in this patch. Changelog: - Enhance QueryDosDevice test for attempting to return all devices. - Add tests for GetVolumeInformationA testing the different root dir formats. --- dlls/kernel32/tests/volume.c | 137 - 1 files changed, 133 insertions(+), 4 deletions(-) One of the tests fails here: volume.c:290: Test failed: GetVolumeInformationA w/o '\' did not fail, last error 2 I just ran the tests as your second mail/patch suggested it fixed something. That patch however didn't contain a change to the tests. If you add tests that fail on Wine and you don't include a fixed implementation in the same patch you should mark these with todo_wine(). If you fix the implementation in a later patch you should remove the todo_wine() again if needed. Bottom line: after each patch all tests should still succeed. -- Cheers, Paul.
Winprinfo tool
I just have struck one tool related to Windows printer drivers [*]: | In the process of developing a Windows printer driver, we created this | winprinfo tool to allow us to query the printer system from the point of | view of an application: there are several APIs that permit a wide range | of query. This tool exercises them all and proved to be indispensible in | our development. ... | Once a printer has been opened, there are several Win32 API calls that | can be used to query the device. These are DeviceCapabilities(), | GetDeviceCaps, and EnumForms() (there may be more, but we'll add them as | we discover them. | | Driver Info / GetPrinterDriver() | By fetching a DRIVER_INFO_4 object for this printer, we're able to | show the version (kernel or user), as well as the paths used for all the | support files (driver and UI DLLs, plus the dependent files). | | DEVMODE / DeviceCapabilities() | A central data structure involved in printing is the DEVMODE, which | is a collection of settings that apply to a printjob. Each printer has a | group of default settings that are used in the absense of any user input | on the subject, and they are managed with the printer's setup GUI. | Using the DeviceCapabilities() API function, we are able to extract | a number of individual parameters from the DEVMODE and report them. | | GetDeviceCaps() | Since a printer is a graphics device, there are some kinds of | parameters that are in common with other devices such as video displays. | The GetDeviceCaps() call returns a small set of numeric parameters, many | of which have no real interest to printer developers. | | EnumForms() | The NT print spooler supports the notion of forms, which is simply | a way of attaching a name to a specifically-sized piece of output media. | There are built-in sizes such as Letter and Legal, but there are at | least a hundreds defined for oddball paper sizes all over the world. A | print driver can define additional forms as well, though the interaction | between the central forms database and the driver is still a little | unclear. My guess, it could usefull for guys like Detlef working on Winspool and Co. also. Then it can query printers over SMB. One more (probably) interesting note (with regard to running the tool on Wine): | We built this to run strictly on NT/Win2000/XP platforms: if it works at | all on Win95/98/ME, we'd be very surprised. [*] http://unixwiz.net/tools/winprinfo.html
Winprinfo tool
(Excuse me for the flowed format in my previous msg) I just have struck one tool related to Windows printer drivers [*]: | In the process of developing a Windows printer driver, we created this | winprinfo tool to allow us to query the printer system from the point of | view of an application: there are several APIs that permit a wide range | of query. This tool exercises them all and proved to be indispensible in | our development. ... | Once a printer has been opened, there are several Win32 API calls that | can be used to query the device. These are DeviceCapabilities(), | GetDeviceCaps, and EnumForms() (there may be more, but we'll add them as | we discover them. | | Driver Info / GetPrinterDriver() | By fetching a DRIVER_INFO_4 object for this printer, we're able to | show the version (kernel or user), as well as the paths used for all the | support files (driver and UI DLLs, plus the dependent files). | | DEVMODE / DeviceCapabilities() | A central data structure involved in printing is the DEVMODE, which | is a collection of settings that apply to a printjob. Each printer has a | group of default settings that are used in the absense of any user input | on the subject, and they are managed with the printer's setup GUI. | Using the DeviceCapabilities() API function, we are able to extract | a number of individual parameters from the DEVMODE and report them. | | GetDeviceCaps() | Since a printer is a graphics device, there are some kinds of | parameters that are in common with other devices such as video displays. | The GetDeviceCaps() call returns a small set of numeric parameters, many | of which have no real interest to printer developers. | | EnumForms() | The NT print spooler supports the notion of forms, which is simply | a way of attaching a name to a specifically-sized piece of output media. | There are built-in sizes such as Letter and Legal, but there are at | least a hundreds defined for oddball paper sizes all over the world. A | print driver can define additional forms as well, though the interaction | between the central forms database and the driver is still a little | unclear. My guess, it could be usefull for guys like Detlef working on Winspool (and Co.) also. Then it can query printers over SMB. One more (probably) interesting note (with regard to running the tool on Wine): | We built this to run strictly on NT/Win2000/XP platforms: if it works at | all on Win95/98/ME, we'd be very surprised. [*] http://unixwiz.net/tools/winprinfo.html
Re: [5/6] WineD3D: Support the full amount of constants in GLSL
2009/4/15 Stefan Dösinger ste...@codeweavers.com:
+void record_const_read(DWORD reg, unsigned int *array, int *num) {
+int r;
+BOOL inc = TRUE;
+for(r = 0; r *num; r++) {
+if(array[r] == reg) {
+inc = FALSE;
+break;
+}
+}
+
+if(inc) {
+array[(*num)++] = reg;
+}
+}
+
This should be static. Using a bitmap and counting the bits would be nicer, imo.
Re: [PATCH 1/2] comctl32/tests: Test expanding of a invisible sub tree.
2009/4/15 Florian Köberle flor...@fkoeberle.de:
---
dlls/comctl32/tests/treeview.c | 80
1 files changed, 80 insertions(+), 0 deletions(-)
diff --git a/dlls/comctl32/tests/treeview.c b/dlls/comctl32/tests/treeview.c
index 5f310b5..7d9fcfa 100644
--- a/dlls/comctl32/tests/treeview.c
+++ b/dlls/comctl32/tests/treeview.c
@@ -748,6 +748,84 @@ static LRESULT CALLBACK MyWndProc(HWND hWnd, UINT msg,
WPARAM wParam, LPARAM lPa
return 0L;
}
+static void TestExpandInvisible(void)
+{
+ static CHAR nodeRText[] = R,
+ nodeIText[] = I,
+ nodeIIText[] = II,
+ node1Text[] = 1,
+ node2Text[] = 2;
+ TVINSERTSTRUCTA ins;
+ HTREEITEM nodeR;
+ HTREEITEM nodeI;
+ HTREEITEM nodeII;
+ HTREEITEM node1;
+ HTREEITEM node2;
+ RECT dummyRect;
+ BOOL nodeIVisible;
+ BOOL nodeIIVisible;
+ BOOL node1Visible;
+ BOOL node2Visible;
+ HWND window = CreateWindowExA(0, MyTestWnd, treeview:
TestExpandInvisible, WS_OVERLAPPEDWINDOW,
+ CW_USEDEFAULT, CW_USEDEFAULT, 130, 105, NULL, NULL,
GetModuleHandleA(NULL), 0);
+
+ HWND tree = CreateWindowExA(WS_EX_CLIENTEDGE, WC_TREEVIEWA, NULL,
WS_CHILD|WS_VISIBLE|
+ TVS_LINESATROOT|TVS_HASLINES|TVS_HASBUTTONS|TVS_EDITLABELS,
+ 0, 0, 120, 100, window, (HMENU)100, GetModuleHandleA(0), 0);
+
+
+ ins.hParent = TVI_ROOT;
+ ins.hInsertAfter = TVI_ROOT;
+ U(ins).item.mask = TVIF_TEXT;
+ U(ins).item.pszText = nodeRText;
+ nodeR = TreeView_InsertItem(tree, ins);
+ assert(nodeR);
+
+ ins.hInsertAfter = TVI_LAST;
+ U(ins).item.mask = TVIF_TEXT;
+ ins.hParent = nodeR;
+
+ U(ins).item.pszText = nodeIText;
+ nodeI = TreeView_InsertItem(tree, ins);
+ assert(nodeI);
+ U(ins).item.pszText = nodeIIText;
+ nodeII = TreeView_InsertItem(tree, ins);
+ assert(nodeII);
+
+ ins.hParent = nodeI;
+
+ U(ins).item.pszText = node1Text;
+ node1 = TreeView_InsertItem(tree, ins);
+ assert(node1);
+ U(ins).item.pszText = node2Text;
+ node2 = TreeView_InsertItem(tree, ins);
+ assert(node1);
+
+ nodeIVisible = TreeView_GetItemRect(tree, nodeI, dummyRect, FALSE);
+ ok(!nodeIVisible, Node I should not be visible.\n);
+ node1Visible = TreeView_GetItemRect(tree, node1, dummyRect, FALSE);
+ ok(!node1Visible, Node 1 should not be visible.\n);
+ node2Visible = TreeView_GetItemRect(tree, node2, dummyRect, FALSE);
+ ok(!node2Visible, Node 2 should not be visible.\n);
+ nodeIIVisible = TreeView_GetItemRect(tree, nodeII, dummyRect, FALSE);
+ ok(!nodeIIVisible, Node II should not be visible.\n);
+
+ ok(TreeView_Expand(tree, nodeI, TVE_EXPAND), Expand of node I
failed.\n);
+
+ nodeIVisible = TreeView_GetItemRect(tree, nodeI, dummyRect, FALSE);
+ ok(!nodeIVisible, Node I should not be visible.\n);
+ node1Visible = TreeView_GetItemRect(tree, node1, dummyRect, FALSE);
+todo_wine
+ ok(!node1Visible, Node 1 should not be visible.\n);
+ node2Visible = TreeView_GetItemRect(tree, node2, dummyRect, FALSE);
+todo_wine
+ ok(!node2Visible, Node 2 should not be visible.\n);
+ nodeIIVisible = TreeView_GetItemRect(tree, nodeII, dummyRect, FALSE);
+todo_wine
+ ok(!nodeIIVisible, Node II should not be visible.\n);
+}
+
+
START_TEST(treeview)
{
HMODULE hComctl32;
@@ -819,4 +897,6 @@ START_TEST(treeview)
TranslateMessage(msg);
DispatchMessageA(msg);
}
+
+ TestExpandInvisible();
}
--
1.5.4.3
Hi Florian,
I think you should use already created dialog and treeview.
Place your new function just after TestCallback(), clear tree view and
fill it, then just test visibility of expandable items.
--
Nicolas Le Cam
Compile error in taskmgr before 1.1.14
I'm trying to use a git tree to do a regression-test for something that seems to have gotten broken somewhere between 1.0 and 1.1.19; but when I do a full git reset _version_ ; git checkout -f ; ./configure CC='ccache gcc-3.4' ; make depend ; make I get the following error before about 1.1.14: ccache gcc-3.4 -c -I. -I. -I../../include -I../../include -I../../include/msvcrt -DNO_LIBWINE_PORT -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -fno-builtin -o about.o about.c In file included from about.c:29: ../../include/msvcrt/memory.h:27: error: redefinition of 'memicmp' ../../include/msvcrt/string.h:132: error: previous definition of 'memicmp' was here ../../include/msvcrt/memory.h:28: error: redefinition of 'memccpy' ../../include/msvcrt/string.h:131: error: previous definition of 'memccpy' was here make[2]: *** [about.o] Error 1 make[2]: Leaving directory `/usr/src/wine-git/programs/taskmgr' make[1]: *** [taskmgr] Error 2 make[1]: Leaving directory `/usr/src/wine-git/programs' make: *** [programs] Error 2 Does anyone remember seeing this error, or is it likely to be the result of misusing git? Build system is Debian 4.0 with gcc 3.3, 3.4 and 4.1 available. -- David Lee Lambert ... Software Developer, member IEEE, ACM Cell phone: +1 586-873-8813 GPG key at http://www.lmert.com/keyring.txt IM: davidleelambert (Yahoo!) or lambe...@cse.msu.edu (MSN)
Fixing the last remaining failure on W2K (rpcrt4:server)
Hi,
In an effort to fix that last failure on my box I found the culprit. I'm
not comfortable enough with just excluding (yet another) that test just
for the sake of having zero failures though.
Any idea?
--
Cheers,
Paul.
diff --git a/dlls/rpcrt4/tests/server.c b/dlls/rpcrt4/tests/server.c
index 18cfa59..2d8c4d5 100644
--- a/dlls/rpcrt4/tests/server.c
+++ b/dlls/rpcrt4/tests/server.c
@@ -616,9 +616,13 @@ s_context_handle_test(void)
ok(*(ULONG *)buf == 0, attributes should have been set to 0 instead of
0x%x\n, *(ULONG *)buf);
ok(!UuidIsNil((UUID *)buf[4], status), uuid should not have been
nil\n);
+/* Crashes on W2K */
+if (0)
+{
h = pNDRSContextUnmarshall2(binding, buf, NDR_LOCAL_DATA_REPRESENTATION,
NULL, 0);
ok(h != NULL, NDRSContextUnmarshall2 returned NULL\n);
ok(h-userContext == (void *)0xdeadbeef, userContext of interface didn't
unmarshal properly: %p\n, h-userContext);
+}
/* raises ERROR_INVALID_HANDLE exception on Vista upwards */
if (0)
Re: [PATCH 1/2] comctl32/tests: Test expanding of a invisible sub tree.
Nikolay Sivov wrote:
Florian Köberle wrote:
---
dlls/comctl32/tests/treeview.c | 80
1 files changed, 80 insertions(+), 0 deletions(-)
diff --git a/dlls/comctl32/tests/treeview.c
b/dlls/comctl32/tests/treeview.c
index 5f310b5..7d9fcfa 100644
--- a/dlls/comctl32/tests/treeview.c
+++ b/dlls/comctl32/tests/treeview.c
@@ -748,6 +748,84 @@ static LRESULT CALLBACK MyWndProc(HWND hWnd,
UINT msg, WPARAM wParam, LPARAM lPa
return 0L;
}
+static void TestExpandInvisible(void)
+{
+static CHAR nodeRText[] = R,
+nodeIText[] = I,
+nodeIIText[] = II,
+node1Text[] = 1,
+node2Text[] = 2;
Why not using array here?
The code builds up a tree like this:
R
|- I
| |- 1
| |- 2
|- II
So the different types of enumeration are used to give a hint of the
level of the node.
If I use arrays the tree would look like this:
0
|- 1
| |- 2
| |- 3
|- 4
If this version of the tree is really wanted I can change it of course
to use arrays.
Do you still prefer arrays after reading my explanation?
Re: [5/6] WineD3D: Support the full amount of constants in GLSL
Am Mittwoch, 15. April 2009 09:36:46 schrieb Henri Verbeet:
2009/4/15 Stefan Dösinger ste...@codeweavers.com:
+void record_const_read(DWORD reg, unsigned int *array, int *num) {
+int r;
+BOOL inc = TRUE;
+for(r = 0; r *num; r++) {
+if(array[r] == reg) {
+inc = FALSE;
+break;
+}
+}
+
+if(inc) {
+array[(*num)++] = reg;
+}
+}
+
This should be static. Using a bitmap and counting the bits would be nicer,
imo.
On the static thing I agree. Wrt a bitmap, how'll things work in d3d10? My
guess is that due to the constant buffer we do not have the issue this patch
addresses in the first place, but if we do, the array makes it easier to grow
the amount of int constants.
Re: oleaut32: [Patch 1/2] VarCat must use localized names for VT_BOOL
Detlef Riekenberg wrote: http://test.winehq.org/data/f212579ae9a1b770ebd34cec20f95e1977bb57f0/xp_dr-asus/oleaut32:vartest.html While reading the code for a test failure on all of my Windows installations, the current code was already strange: 5436 ok(hres == VARCMP_EQ || 5437broken(hres == VARCMP_GT), Expected VARCMP_EQ, got %08x\n, hres); I feel bad for adding a broken(hres == VARCMP_LT). Extending vartest and inserting a trace made the localization error obvisious: VARCMP_LT was returned when comparing 12Falsch and 12False. The failure for the similar test (VT_BOOL with True: 12Wahr 12True) was hidden by the wrong broken(hres == VARCMP_GT). We have also another XP Machine that produced this failure. (xp-home-SP2-czech) Hi Detlef, The lstrcpyW and lstrcatW additions to init() in the tests don't work on Win95. I guess that's where the new failures come from: http://test.winehq.org/data/ed74088d7ddf0c389e7596237add7cb751b17a0a/95_W95/oleaut32:vartest.html Could you have a look? -- Cheers, Paul.
Re: Fixing the last remaining failure on W2K (rpcrt4:server)
2009/4/15 Paul Vriens paul.vriens.w...@gmail.com: In an effort to fix that last failure on my box I found the culprit. I'm not comfortable enough with just excluding (yet another) that test just for the sake of having zero failures though. What exception is being raised? I think perhaps s_context_handle_test should be removed and replaced with another that uses widl-generated code for testing context handles rather than low-level functions. -- Rob Shearman
Re: Fixing the last remaining failure on W2K (rpcrt4:server)
Rob Shearman wrote: 2009/4/15 Paul Vriens paul.vriens.w...@gmail.com: In an effort to fix that last failure on my box I found the culprit. I'm not comfortable enough with just excluding (yet another) that test just for the sake of having zero failures though. What exception is being raised? I think perhaps s_context_handle_test should be removed and replaced with another that uses widl-generated code for testing context handles rather than low-level functions. I just see a RPC_S_CALL_FAILED -- Cheers, Paul.
Re: Compile error in taskmgr before 1.1.14
2009/4/15 David Lee Lambert dav...@lmert.com: I'm trying to use a git tree to do a regression-test for something that seems to have gotten broken somewhere between 1.0 and 1.1.19; but when I do a full git reset _version_ ; git checkout -f ; ./configure CC='ccache gcc-3.4' ; make depend ; make I get the following error before about 1.1.14: ccache gcc-3.4 -c -I. -I. -I../../include -I../../include -I../../include/msvcrt -DNO_LIBWINE_PORT -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -fno-builtin -o about.o about.c In file included from about.c:29: ../../include/msvcrt/memory.h:27: error: redefinition of 'memicmp' ../../include/msvcrt/string.h:132: error: previous definition of 'memicmp' was here ../../include/msvcrt/memory.h:28: error: redefinition of 'memccpy' ../../include/msvcrt/string.h:131: error: previous definition of 'memccpy' was here make[2]: *** [about.o] Error 1 make[2]: Leaving directory `/usr/src/wine-git/programs/taskmgr' make[1]: *** [taskmgr] Error 2 make[1]: Leaving directory `/usr/src/wine-git/programs' make: *** [programs] Error 2 Does anyone remember seeing this error, or is it likely to be the result of misusing git? Build system is Debian 4.0 with gcc 3.3, 3.4 and 4.1 available. Can you identify the last revision where this happens? I just tried setting my git tree to 1.1.13 and it builds fine.
Re: [5/6] WineD3D: Support the full amount of constants in GLSL
2009/4/15 Stefan Dösinger ste...@codeweavers.com:
Am Mittwoch, 15. April 2009 09:36:46 schrieb Henri Verbeet:
2009/4/15 Stefan Dösinger ste...@codeweavers.com:
+void record_const_read(DWORD reg, unsigned int *array, int *num) {
+ int r;
+ BOOL inc = TRUE;
+ for(r = 0; r *num; r++) {
+ if(array[r] == reg) {
+ inc = FALSE;
+ break;
+ }
+ }
+
+ if(inc) {
+ array[(*num)++] = reg;
+ }
+}
+
This should be static. Using a bitmap and counting the bits would be nicer,
imo.
On the static thing I agree. Wrt a bitmap, how'll things work in d3d10? My
guess is that due to the constant buffer we do not have the issue this patch
addresses in the first place, but if we do, the array makes it easier to grow
the amount of int constants.
Constant buffers mostly make the problem go away, although we still
need to integrate d3d9 style constants with that as well. Bitmaps can
have arbitrary sizes though, and in the 16 unsigned ints you currently
use you could register 512 integers/bools.
Re: msvcrt: Implement ___lc_codepage_func, ___lc_collate_cp_func and ___lc_handle_func.
Hans Leidekker h...@codeweavers.com wrote:
+/*
+ * ___lc_handle_func (MSVCRT.@)
+ */
+HANDLE * ___lc_handle_func(void)
+{
+return MSVCRT___lc_handle;
+}
+
+/*
+ * ___lc_codepage_func (MSVCRT.@)
+ */
+int ___lc_codepage_func(void)
+{
+return MSVCRT___lc_codepage;
+}
+
+/*
+ * ___lc_collate_cp_func (MSVCRT.@)
+ */
+int ___lc_collate_cp_func(void)
+{
+return MSVCRT___lc_collate_cp;
+}
All msvcrt public exports should have explicit CDECL calling convention.
--
Dmitry.
Re: gdi32: Don't add duplicate system_links entries
On Wed, Apr 15, 2009 at 01:59:50PM +0900, Dmitry Timoshkov wrote:
Paul TBBle Hampson paul.hamp...@pobox.com wrote:
+/* Make sure we haven't already got an entry for this due to
substitution */
+duplicate = FALSE;
+LIST_FOR_EACH_ENTRY(system_font_link, system_links,
SYSTEM_LINKS, entry)
+{
+if(!strcmpW(system_font_link-font_name,
font_link-font_name))
+{
+duplicate = TRUE;
+break;
+}
+}
Font name comparison should be case insensitive. If there are other places
that do that they should be fixed.
I'll fix that. I might have miscopied it, but I suspect I didn't, so
I'll add a patch to the series to fix the other instances.
+if(duplicate)
+{
+TRACE(\tDuplicate font_link entry, ignoring\n);
+HeapFree(GetProcessHeap(), 0, font_link);
+continue;
+}
A '\t' at the start of a trace message doesn't improve readability.
It's consistent with the other path for this code, which is a
tab-indented listing of fonts being added to the entry.
If needs be I could rearrange the messages to not do so, but again this
would be a different patch.
--
---
Paul TBBle Hampson, B.Sc, LPI, MCSE
Very-later-year Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
paul.hamp...@pobox.com
Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
-- Kristian Wilson, Nintendo, Inc, 1989
License: http://creativecommons.org/licenses/by/2.5/au/
---
pgp5YJY74mzh7.pgp
Description: PGP signature
Re: Compile error in taskmgr before 1.1.14
On Wed, Apr 15, 2009 at 5:32 AM, David Lee Lambert dav...@lmert.com wrote: I'm trying to use a git tree to do a regression-test for something that seems to have gotten broken somewhere between 1.0 and 1.1.19; but when I do a full git reset _version_ ; git checkout -f ; ./configure CC='ccache gcc-3.4' ; make depend ; make I get the following error before about 1.1.14: ccache gcc-3.4 -c -I. -I. -I../../include -I../../include -I../../include/msvcrt -DNO_LIBWINE_PORT -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -fno-builtin -o about.o about.c In file included from about.c:29: ../../include/msvcrt/memory.h:27: error: redefinition of 'memicmp' ../../include/msvcrt/string.h:132: error: previous definition of 'memicmp' was here ../../include/msvcrt/memory.h:28: error: redefinition of 'memccpy' ../../include/msvcrt/string.h:131: error: previous definition of 'memccpy' was here make[2]: *** [about.o] Error 1 make[2]: Leaving directory `/usr/src/wine-git/programs/taskmgr' make[1]: *** [taskmgr] Error 2 make[1]: Leaving directory `/usr/src/wine-git/programs' make: *** [programs] Error 2 Does anyone remember seeing this error, or is it likely to be the result of misusing git? Build system is Debian 4.0 with gcc 3.3, 3.4 and 4.1 available. -- David Lee Lambert ... Software Developer, member IEEE, ACM Cell phone: +1 586-873-8813 GPG key at http://www.lmert.com/keyring.txt IM: davidleelambert (Yahoo!) or lambe...@cse.msu.edu (MSN) http://wiki.winehq.org/ReverseRegressionTesting -- -Austin
Re: try4 [2/3] kernel32: Fix GetVolumeInformation[AW] to require trailing \
On Tue, Apr 14, 2009 at 11:17 PM, Guy Albertelli galbe...@neo.rr.com wrote: MSDN and test verify the valid root dirs for GetVolumeInformation[AW] must end in trailing '\' and if not then return ERROR_INVALID_NAME Changelog - Return correct error if GetVolumeInformation[AW] root dir does not end with '\' --- dlls/kernel32/volume.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Can you add a testcase for this? -- -Austin
Re: ntdll: Improve stubs for NtGet/SetInformationToken(TokenDefaultDacl).
2009/4/15 Hans Leidekker h...@codeweavers.com:
@@ -441,6 +441,23 @@ NTSTATUS WINAPI NtQueryInformationToken(
}
SERVER_END_REQ;
break;
+ case TokenDefaultDacl:
+ if (tokeninfo)
+ {
+ TOKEN_DEFAULT_DACL *token = (TOKEN_DEFAULT_DACL *)tokeninfo;
+ ACL *acl;
+
+ FIXME(returning empty DACL\n);
+
+ acl = token-DefaultDacl = (ACL *)token +
sizeof(TOKEN_DEFAULT_DACL);
+
+ acl-AclRevision = ACL_REVISION;
+ acl-Sbz1 = 0;
+ acl-AclSize = sizeof(ACL);
+ acl-AceCount = 0;
+ acl-Sbz2 = 0;
+ }
+ break;
default:
{
ERR(Unhandled Token Information class %d!\n, tokeninfoclass);
The server already tracks the default DACL of the token in the token
object, so implementing these functions properly shouldn't be much
more work than writing the code to marshall and unmarshall the ACL to
and from the server, with two new trivial functions in the server for
getting and setting the default_dacl field.
--
Rob Shearman
Fwd: [Wine] The easiest way to convert Mod/Tod video from JVC and any vi
There's been a lot of this spam recently (below). Can you take a look Jeremy? Perhaps banning that IP range if it's in the same block? Thanks! -- -Austin -- Forwarded message -- From: ll0 wineforum-u...@winehq.org Date: Wed, Apr 15, 2009 at 3:51 AM Subject: [Wine] The easiest way to convert Mod/Tod video from JVC and any vi To: wine-us...@winehq.org question: 1: What is .Mod and .Tod video? 2: How to convert .Mod and .Tod video to AVI, MPG, WMV, MPEG? 3. How to convert any video to the format you want? Answer: 1 .MOD and .TOD is the video format generated by most popular digital camcorders such as Panasonic SV AV100, Canon MOD Camcorders, JVC (MOD and TOD) and Panasonic (MOD only). It is not the common format, so it can not be accepted by popular portable players.
Re: do ERR messages imply bugs?
Vitaliy Margolen wrote: Vincent Povirk wrote: Chris Ahrendt filed a few bugs recently for err messages encountered during test runs (17997 and 17998 at least). 17997 is a bogus report - Gecko is not intalled. Nothing actually failed. 17998 is the same. Only I let our resident 3D gurus to respond. I don't see any problems with tests testing invalid conditions. This most likely one of those cases. If Chris doesn't like err messages, he can shut them off. Vitaliy. 17997 Gecko is installed and reran test... same result... valid bug 17998 is the locking issue... and it occurs not just in the rest but in another application as well..
Re: do ERR messages imply bugs?
Vitaliy Margolen wrote: chris ahrendt wrote: 17997 Gecko is installed and reran test... same result... valid bug 17998 is the locking issue... and it occurs not just in the rest but in another application as well.. What errors? What exactly isn't working for you? You have failed to explain that. Until you meaningfully can explain everyone what isn't working for you? What exact applications are you having problems with? Where are they failed tests you are speaking of, these bugs invalid! DO NOT REOPEN THEM! Vitaliy. THe ERR mesages which are in the logs I uloaded. As pointed out in the wine development logs an ERR is only supposed to happen if something goes wrong or is not working correctly. So either these are warning messages and need to be changed as such or they are actual failures in the underlying code and will need to get fixed. If the action is normal for the failure in the test case then it should be output on the screen somewhere in the log stating this is normal. Chris
Re: do ERR messages imply bugs?
Vincent Povirk wrote: On Sun, Apr 12, 2009 at 5:24 PM, Ben Klein shackl...@gmail.com wrote: 2009/4/13 Vincent Povirk madewokherd+8...@gmail.com: But the description doesn't say invalid conditions. It says serious errors in Wine. That's something that should never happen in tests, as it would imply that the state of the libraries we're testing (and thus the test) is invalid. How about serious errors in Wine, or in the test cases, sometimes deliberate errors in the tests? As Vitaliy points out, some tests deliberately do invalid things to make sure they fail. We can't ONLY test on things that succeed! I'm not against changing the description. If it's OK to have err messages for cases that we know fail (but don't crash or prevent the library from continuing to function), then the Developer's Guide is wrong and should be changed. I also don't care how long it takes to make the change, as long as there's a consensus that it's the guide that's wrong and not the reality of what's in Wine. This is EXACTLY the point I am trying to get to.. if they are normal and not ERRORS but warnings then they should be thus and noted in the developers guide. Right now Wine isn't even following its own guidelines in this case. Chris
Re: do ERR messages imply bugs?
Ben Klein wrote: 2009/4/13 James McKenzie jjmckenzi...@earthlink.net: Ben Klein wrote: 2009/4/13 chris ahrendt celtich...@aol.com: Vincent Povirk wrote: On Sun, Apr 12, 2009 at 5:24 PM, Ben Klein shackl...@gmail.com wrote: 2009/4/13 Vincent Povirk madewokherd+8...@gmail.com: But the description doesn't say invalid conditions. It says serious errors in Wine. That's something that should never happen in tests, as it would imply that the state of the libraries we're testing (and thus the test) is invalid. How about serious errors in Wine, or in the test cases, sometimes deliberate errors in the tests? As Vitaliy points out, some tests deliberately do invalid things to make sure they fail. We can't ONLY test on things that succeed! I'm not against changing the description. If it's OK to have err messages for cases that we know fail (but don't crash or prevent the library from continuing to function), then the Developer's Guide is wrong and should be changed. I also don't care how long it takes to make the change, as long as there's a consensus that it's the guide that's wrong and not the reality of what's in Wine. This is EXACTLY the point I am trying to get to.. if they are normal and not ERRORS but warnings then they should be thus and noted in the developers guide. Right now Wine isn't even following its own guidelines in this case. No. Not warnings. Errors. They are errors. There is no way to distinguish an error caused by a real application from an error caused by a Wine test. If the situation is an error and it is expected, the test should handle this, like: ok (some_test_here_that_should_fail, The test that should fail, did/n) I'm guessing that most of the tests that should fail, do. I don't know if there is a failure like there is an ok. AFAIK, this is how expected failures in tests are handled. I saw a few recent tests submitted and/or committed that do it like this. If you don't like it, run all your tests with WINEDEBUG=-all. And that will prove nothing. Tests should be run with debugging on. You are really being sarcastic, right? As to the discussion, I will add my .02 Eurocent here: Fixme: Code that is not implemented that should be. Warning: Code that encountered an unexpected or new condition that is not normal. Data should not be corrupted by this event. Error: Code encountered a condition that will result in corruption of data. It appears that we have 'error creep' and that is not good from a user point of view and it is really irritating from a support point of view. During testing an error could be either a Warning or an Error. Tests should not be run against non-existent Wine code, but should against existing Windows code. The situation with testing is that unexpected or improper behavior of code should be an error. There is no such thing as a warning during a test run. Either the test passes, which means that Wine is acting the same as a certain version of Windows, or it is not. There is no way for the Wine components that are producing the errors to distinguish between a test run and a real application. Again, the tests are triggering these errors not in the test applications but in other Wine components. In some (possibly all) cases that this happens, this is expected and correct (because it is impossible to distinguish between a genuine error and a test error). Now, the problem is that we are sending cryptic messages to end users, most of which they can and should ignore. Err messages piling up on their terminal windows should be a cause for concern. If we know that a condition does not cause data corruption, then we should not be marking it as an error, but maybe a warning or if the code is non-existent or improper, a fixme. End users shouldn't be running the tests without understanding how they work. Can we start to clean up some of the most obvious it is not an error but the message says it is so that we can calm down users who encounter them? The ERRs are being produced by components of Wine outside the test cases. It's highly likely for those ERRs to change in later versions of Wine. If you want to maintain a complete list of where ERRs will be triggered by test cases and include a message for each one that says It's OK, you can ignore this ERR, then I'm sure you're welcome to try it. 2009/4/13 James McKenzie jjmckenzi...@earthlink.net: Vitaliy Margolen wrote: You wrong. As I said, tests are _allowed_ and some really _supposed to_ test invalid cases. Where Wine 100% correct about complaining. But the goal of each test is either succeed or fail. If it succeeds then there is no bug. Conversely, if a good test starts to fail or error messages appear where there were none, we have a problem that needs to be reported so it can be fixed (this happened with Wine 1.1.18).
Re: do ERR messages imply bugs?
Ben Klein wrote: 2009/4/13 chris ahrendt celtich...@aol.com: So basically it, in your opinion, comes down to ERR's and the debug output from running tests or anything else should be ignored by anyone but developers? No, that the tests as a WHOLE should be ignored by everyone except developers. Is there a guide documenting what each test is supposed to do etc? I run the test set to see where the current version of wine is on any of my particular hardware. I am not allowed to develop wine due to NDA's , and so forth I am under. And have discussed with the Alexandre and Dan concerning these NDA's and what I can do to help. That does not make any sense... There has to be a consistent way for developers and users to report or work on issues.. It's called bugzilla. I believe you may be missing my point Ben. By consistent I mean an ERR means this and only means this. Warning, info etc... From what I have been following here and also seeing in the code an error doesn't always follow the coding standard set forth in the developers guide. and like Vincent says the use has gotten a little skewed. Or been misinterpreted ... though a review of the developers' guide description of ERR wouldn't hurt. I would agree it may be... and maybe a review is in order.. chris
Re: do ERR messages imply bugs?
An Excellent point was mad in one of the bugs I reported : Comment #25 from Austin English austinengl...@gmail.com The problem is that this isn't a 'normal' application doing weird things. It's our testsuite, which does some _really_ strange stuff, e.g., lots of corner case testing. Our implementation code, however, knows this is weird, and prints an error. The problem is that there's no way to tell, e.g, dlls/mshtml/htmldoc.c that what's being tested is dlls/mshtml/tests/doc.c, rather than foobar.exe. It's a bit misleading, which makes it a bit harder for users. So, there has to be a happy middle in this... why not have in the test suite some printf or the like that says to the effect that err output is to be expected or the like.. Most users if they see ERROR on the screen be it in a test case or an application will think its a bug and not just ignore it. Chris
Re: do ERR messages imply bugs?
Ben Klein wrote: 2009/4/13 chris ahrendt celtich...@aol.com: Is there a guide documenting what each test is supposed to do etc? Source code. Before you say that's an unacceptable answer, the sheer number of test cases (especially considering those that keep getting added) would make it impractical to the point of impossibility to maintain proper documentation on each test. And when the tests are only intended for developers anyway, the source code is perfectly suitable as documentation. The tests are relatively simple, and it's clear which case is being test by the use of ok(). I run the test set to see where the current version of wine is on any of my particular hardware. Then you should learn to interpret the ERRs correctly. I am not allowed to develop wine due to NDA's , and so forth I am under. And have discussed with the Alexandre and Dan concerning these NDA's and what I can do to help. That does not make any sense... There has to be a consistent way for developers and users to report or work on issues.. It's called bugzilla. I believe you may be missing my point Ben. By consistent I mean an ERR means this and only means this. Warning, info etc... As far as I'm concerned, that already exists, even if it's not written explicitly and finitely in the dev guide. ERRs caused by the test suite can be ignored as long as the tests run correctly. By the same logic, ERRs caused by real applications can be ignored as long as the apps still run correctly. In the former case, there is no motivation for the devs to fix them. In the latter, there is minimal motivation, and the devs have bigger problems to worry about than things that aren't actually *breaking* anything at the moment. From what I have been following here and also seeing in the code an error doesn't always follow the coding standard set forth in the developers guide. I don't think you understand the nature of the test suite. There are some tests that are 100% valid logic and are expected to create no ERRs or WARNs. These are called positive cases. There are some tests that are not 100% valid logic, and do things wrong deliberately, and are expected to create both ERRs and WARNs. That's an and there, not an or. Both ERRs and WARNs. This cannot change. and like Vincent says the use has gotten a little skewed. Or been misinterpreted ... though a review of the developers' guide description of ERR wouldn't hurt. I would agree it may be... and maybe a review is in order.. So who wants to volunteer? :) Not I =) 2009/4/13 chris ahrendt celtich...@aol.com: An Excellent point was mad in one of the bugs I reported : Comment #25 from Austin English austinengl...@gmail.com The problem is that this isn't a 'normal' application doing weird things. It's our testsuite, which does some _really_ strange stuff, e.g., lots of corner case testing. Our implementation code, however, knows this is weird, and prints an error. The problem is that there's no way to tell, e.g, dlls/mshtml/htmldoc.c that what's being tested is dlls/mshtml/tests/doc.c, rather than foobar.exe. It's a bit misleading, which makes it a bit harder for users. This is EXACTLY what I've been saying. You ignore me, and listen to Austin. Absolutely fantastic. not AT All ben =D I do and have understood that there are positive and negative test cases. The point I guess I am trying to make is in the test cases where there is an expected failure just print something out saying this is expected. Not Complicated at all. So, there has to be a happy middle in this... why not have in the test suite some printf or the like that says to the effect that err output is to be expected or the like.. Most users if they see ERROR on the screen be it in a test case or an application will think its a bug and not just ignore it. Most users DON'T RUN THE TEST SUITE. It's not useful for users, it's ONLY useful for developers, and developers know how to interpret these ERRs correctly. You don't. Thanks for the attack ben... again you miss the point.. alot more users do run the tests than you may think. People evaluating the code for use in their enterprise will run the test sets.. and if they don't complete or run clean than they don't implement. C
Re: Fwd: [Wine] The easiest way to convert Mod/Tod video from JVC and any vi
I changed the text question on the signup page. That should help a little. Where it will not help is mail coming from the mailing list. If you notice a spam from the list, let me know the email and I will will add that email address and/or domain to the blockers list in the mailman mailing list manager itself. -Newman Austin English wrote: There's been a lot of this spam recently (below). Can you take a look Jeremy? Perhaps banning that IP range if it's in the same block? Thanks! -- -Austin -- Forwarded message -- From: ll0 wineforum-u...@winehq.org Date: Wed, Apr 15, 2009 at 3:51 AM Subject: [Wine] The easiest way to convert Mod/Tod video from JVC and any vi To: wine-us...@winehq.org question: 1: What is .Mod and .Tod video? 2: How to convert .Mod and .Tod video to AVI, MPG, WMV, MPEG? 3. How to convert any video to the format you want? Answer: 1 .MOD and .TOD is the video format generated by most popular digital camcorders such as Panasonic SV AV100, Canon MOD Camcorders, JVC (MOD and TOD) and Panasonic (MOD only). It is not the common format, so it can not be accepted by popular portable players.
Re: Fwd: [Wine] The easiest way to convert Mod/Tod video from JVC and any vi
On Wed, Apr 15, 2009 at 3:55 PM, Jeremy Newman jnew...@codeweavers.com wrote: I changed the text question on the signup page. That should help a little. Thanks! Where it will not help is mail coming from the mailing list. If you notice a spam from the list, let me know the email and I will will add that email address and/or domain to the blockers list in the mailman mailing list manager itself. There hasn't been much spam coming from the mailing list side lately (a few from people thinking wine-users is about the drink rather than the software, but that's it). The forum's been the source recently. -- -Austin
Re: start: correct German translation
Am Tuesday 14 April 2009 19:43:13 schrieb Dawncrow: --- programs/start/De.rc |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Please send patches with your real name. -- Stefan
Re: [1/2] msi/tests: Test MsiRecordGetString on null and empty strings.
On Wed, Apr 15, 2009 at 4:34 PM, Nicolas Le Cam niko.le...@gmail.com wrote: While trying to solve ACTION_AppSearchDr problem revealed by my previous patch, I discovered that MSI_RecordGetStringW was returning a buffer length of 1 on null and empty strings. Here is the test, the fix follows. Tested on WinXP and Wine. This patch has 39 lines of test code without a single empty line. Unit tests test one thing at a time and should be well documented and easy to read. -- James Hawkins
Re: [1/2] msi/tests: Test MsiRecordGetString on null and empty strings.
2009/4/16 James Hawkins trui...@gmail.com: On Wed, Apr 15, 2009 at 4:34 PM, Nicolas Le Cam niko.le...@gmail.com wrote: While trying to solve ACTION_AppSearchDr problem revealed by my previous patch, I discovered that MSI_RecordGetStringW was returning a buffer length of 1 on null and empty strings. Here is the test, the fix follows. Tested on WinXP and Wine. This patch has 39 lines of test code without a single empty line. Unit tests test one thing at a time and should be well documented and easy to read. -- James Hawkins Hi James, Even if I was tempted to changed it, I tried to follow original code style, as stated multiple times on wine-devel. I will resubmit with empty lines between the different tests. What do you mean by well documented ? Isn't the test self explanatory ? I'm setting a null or empty string and verify that getting it back give me an empty string with a null buffer length for both A and W versions. Is a comment like MsiRecordGetString should return an empty string and null buffer length when getting back a null or empty string will help understanding what I'm trying to do ? BTW, this patch fixes all current failures in wine for msi package tests when run on a root drive dir. Unfortunately it also creates 12 new failures. I need to investigate. Seems that this msi patch series will be bigger than expected ;) Thanks for the review. -- Nicolas Le Cam
Re: [1/2] msi/tests: Test MsiRecordGetString on null and empty strings.
On Wed, Apr 15, 2009 at 7:21 PM, Nicolas Le Cam niko.le...@gmail.com wrote: Even if I was tempted to changed it, I tried to follow original code style, as stated multiple times on wine-devel. While that's encouraged, it's sometimes more of a suggestion than a rule. If you're changing a lot of the code and it helps readability to change the style, go for it. As James said, especially in tests, where each unit test should be it's own standalone piece of code. What do you mean by well documented ? Isn't the test self explanatory ? I'm setting a null or empty string and verify that getting it back give me an empty string with a null buffer length for both A and W versions. Is a comment like MsiRecordGetString should return an empty string and null buffer length when getting back a null or empty string will help understanding what I'm trying to do ? The unit tests should be readable for someone not familiar with Wine, but probably with the Windows API. But comments like: /* Setting a null string */ code... /* Verifying we got a null string back */ BTW, this patch fixes all current failures in wine for msi package tests when run on a root drive dir. Unfortunately it also creates 12 new failures. I need to investigate. Excellent! Keep up the great work! -- -Austin
Re: [1/2] msi/tests: Test MsiRecordGetString on null and empty strings.
On Wed, Apr 15, 2009 at 5:21 PM, Nicolas Le Cam niko.le...@gmail.com wrote: 2009/4/16 James Hawkins trui...@gmail.com: On Wed, Apr 15, 2009 at 4:34 PM, Nicolas Le Cam niko.le...@gmail.com wrote: While trying to solve ACTION_AppSearchDr problem revealed by my previous patch, I discovered that MSI_RecordGetStringW was returning a buffer length of 1 on null and empty strings. Here is the test, the fix follows. Tested on WinXP and Wine. This patch has 39 lines of test code without a single empty line. Unit tests test one thing at a time and should be well documented and easy to read. -- James Hawkins Hi James, Even if I was tempted to changed it, I tried to follow original code style, as stated multiple times on wine-devel. I will resubmit with empty lines between the different tests. With a unit test, you're testing one piece of functionality. Each of these tests has a comment above it explaining what you're testing. /* check behaviour of a record with 0 elements */ The following chunk of code tests different aspects of having a record with 0 elements. You've added to the comment and tests when you really should have started a new chunk of tests for the two new cases you're testing. To summarize, you should have three chunks of tests. * record with a non-empty string * record with null string * record with empty string What do you mean by well documented ? Isn't the test self explanatory ? I'm setting a null or empty string and verify that getting it back give me an empty string with a null buffer length for both A and W versions. These tests are rarely self explanatory. Come back in a couple months and try to see what you're testing in those 39 lines. It won't be obvious. Is a comment like MsiRecordGetString should return an empty string and null buffer length when getting back a null or empty string will help understanding what I'm trying to do ? No, the results of the test *are* explanatory. BTW, this patch fixes all current failures in wine for msi package tests when run on a root drive dir. Unfortunately it also creates 12 new failures. I need to investigate. Seems that this msi patch series will be bigger than expected ;) I suggest you break the fixes up into small chunks of fix + test for fix. -- James Hawkins
Re: RFC: Resource editing and validation
On Tue, 7 Apr 2009, Vincent Povirk wrote: [...] I don't think a dependency on po/gettext and the resulting two translation systems instead of one is a good idea. I think it is best to use the existing rc system to translate all text. The problem is there is no translation tool that knows how to handle rc files. If we handled all rc file translations through po files we would be able to leverage the many tools that support po files, in particular the various website-based tools thatt make it easy for non-programmers to do translations. -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm
Re: [1/2] msi/tests: Test MsiRecordGetString on null and empty strings.
2009/4/16 James Hawkins trui...@gmail.com: On Wed, Apr 15, 2009 at 5:21 PM, Nicolas Le Cam niko.le...@gmail.com wrote: 2009/4/16 James Hawkins trui...@gmail.com: On Wed, Apr 15, 2009 at 4:34 PM, Nicolas Le Cam niko.le...@gmail.com wrote: While trying to solve ACTION_AppSearchDr problem revealed by my previous patch, I discovered that MSI_RecordGetStringW was returning a buffer length of 1 on null and empty strings. Here is the test, the fix follows. Tested on WinXP and Wine. This patch has 39 lines of test code without a single empty line. Unit tests test one thing at a time and should be well documented and easy to read. -- James Hawkins Hi James, Even if I was tempted to changed it, I tried to follow original code style, as stated multiple times on wine-devel. I will resubmit with empty lines between the different tests. With a unit test, you're testing one piece of functionality. Each of these tests has a comment above it explaining what you're testing. /* check behaviour of a record with 0 elements */ The following chunk of code tests different aspects of having a record with 0 elements. You've added to the comment and tests when you really should have started a new chunk of tests for the two new cases you're testing. To summarize, you should have three chunks of tests. * record with a non-empty string * record with null string * record with empty string Test is already testing for null and empty strings but only call MsiRecordIsNull against them. It is also doing a lot of test on non empty string in the same function, even returned buffer length but that was not the purpose of my patch. As i'm just completing current test (with a lot of lines I admit) moving it into it's own chunk seems too much to me. As I'm only interested in buffer length value, I can limit the test to that (remove MsiRecordDataSize part and string content verification) but I thought it was better to have all returned value checked instead of needing to expand the test another time in case of a regression / discovery of a new bug. I will try to make this patch cleaner. What do you mean by well documented ? Isn't the test self explanatory ? I'm setting a null or empty string and verify that getting it back give me an empty string with a null buffer length for both A and W versions. These tests are rarely self explanatory. Come back in a couple months and try to see what you're testing in those 39 lines. It won't be obvious. It was the first time I looked at this part of wine, and it took me 5 min to understand what the test currently does and what I need to add to demonstrate the bug I discovered. But it's true that compact code style didn't help me. Is a comment like MsiRecordGetString should return an empty string and null buffer length when getting back a null or empty string will help understanding what I'm trying to do ? No, the results of the test *are* explanatory. BTW, this patch fixes all current failures in wine for msi package tests when run on a root drive dir. Unfortunately it also creates 12 new failures. I need to investigate. Seems that this msi patch series will be bigger than expected ;) I suggest you break the fixes up into small chunks of fix + test for fix. Doh, I was comparing results with another patch that I'm currently trying to rework (http://www.winehq.org/pipermail/wine-patches/2009-April/071756.html). This series doesn't introduce new failures. It unfortunately doesn't fix any failures in msi package tests too, (only 12 failures actually but expected values for 106 tests are wrong if test is run on a root drive directory). Sorry for the mess. -- James Hawkins Thank you for feedback James, Austin. -- Nicolas Le Cam
Re: DIB Engine - New approach
On Tue, Apr 14, 2009 at 1:22 AM, Massimo Del Fedele m...@veneto.com wrote: The approach taken so far consisted in having 2 device pointers inside GDI32, one for dib engine and the other for normal display driver. This way had the disadvantage of having to keep in sync the DC with the right driver depending on selected bitmap, which lead to many small changes spread along all gdi code; going deeper with development this approach showed many limits and problems. So I decided to start again from scratch with a completely different approach which is giving good results and is quite less invasive on gdi32 code. Instead of doing : -- DIB ENGINE / GDI32 --- \ -- X11 DRIVER I took this approach : GDI32 -- DIB ENGINE -- X11 DRIVER The (X11) display driver is loaded from inside the engine, which replaces it from gdi32 point of view. The changes in gdi32 are *very* limited, just in driver.c code, making it to load (if desired) the engine instead of normal x11 driver. No other changes needed. I added as usual the code allowing to enable/disable the engine on request by registry and/or environment variable. If the engine is not present or disabled, the driver loader falls back to usual behaviour. The Engine then loads the X11 driver in init phase and acts as a gate depending on selected BMP, forwarding to X11 driver all requests for DDB bitmaps and doing the job itself for DIB ones. This approach showed many advantages, and I' almost ready converting all old code to it. By now I'm posting here 3 patches showing the approach; the posted driver is a simple pass-throu one, so it just forwards all calls to X11 driver. The last patch of the series shows the forking behaviour of DIB/DDB processing from inside the engine, but still forwarding all to X11. I'd like some comments on the approach taken; on next days I'll post a more complete code with most of the engine implemented. What about other drivers? Is the DIB driver going to know how to handle the others then? Does it even make sense to keep the DIB engine a driver anymore? Jesse
Re: try4 [1/3] kernel32/tests: Add tests for GetVolumeInformationA and QueryDosDevice
On Wed, 2009-04-15 at 08:18 +0200, Paul Vriens wrote: Guy Albertelli wrote: Fixed memory leak and changed skip to win_skip in this patch. Changelog: - Enhance QueryDosDevice test for attempting to return all devices. - Add tests for GetVolumeInformationA testing the different root dir formats. --- dlls/kernel32/tests/volume.c | 137 - 1 files changed, 133 insertions(+), 4 deletions(-) One of the tests fails here: volume.c:290: Test failed: GetVolumeInformationA w/o '\' did not fail, last error 2 I just ran the tests as your second mail/patch suggested it fixed something. That patch however didn't contain a change to the tests. If you add tests that fail on Wine and you don't include a fixed implementation in the same patch you should mark these with todo_wine(). If you fix the implementation in a later patch you should remove the todo_wine() again if needed. Bottom line: after each patch all tests should still succeed. The point was that [2/3] actually fixed that issue. Since they were being rejected as a set, I tried to keep each patch to a single module. Thanks, Guy
Re: try4 [2/3] kernel32: Fix GetVolumeInformation[AW] to require trailing \
On Wed, 2009-04-15 at 10:58 -0500, Austin English wrote: On Tue, Apr 14, 2009 at 11:17 PM, Guy Albertelli galbe...@neo.rr.com wrote: MSDN and test verify the valid root dirs for GetVolumeInformation[AW] must end in trailing '\' and if not then return ERROR_INVALID_NAME Changelog - Return correct error if GetVolumeInformation[AW] root dir does not end with '\' --- dlls/kernel32/volume.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Can you add a testcase for this? The test cases are in [1/3]. Thanks, Guy
Re: DIB Engine - New approach
Massimo Del Fedele m...@veneto.com wrote: The approach taken so far consisted in having 2 device pointers inside GDI32, one for dib engine and the other for normal display driver. Please don't post huge attachments to the mailing list in future, post url for them instead. -- Dmitry.
Re: try4 [2/3] kernel32: Fix GetVolumeInformation[AW] to require trailing \
On Wed, Apr 15, 2009 at 10:51 PM, Guy Albertelli galbe...@neo.rr.com wrote: On Wed, 2009-04-15 at 10:58 -0500, Austin English wrote: On Tue, Apr 14, 2009 at 11:17 PM, Guy Albertelli galbe...@neo.rr.com wrote: MSDN and test verify the valid root dirs for GetVolumeInformation[AW] must end in trailing '\' and if not then return ERROR_INVALID_NAME Changelog - Return correct error if GetVolumeInformation[AW] root dir does not end with '\' --- dlls/kernel32/volume.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Can you add a testcase for this? The test cases are in [1/3]. Thanks, Guy You need to add todo_wine for the failing test you added: volume.c:290: Test failed: GetVolumeInformationA w/o '\' did not fail, last error 2 make: *** [volume.ok] Error 1 Then remove that todo in patch 2/3. Path 3/3 doesn't seem to affected, e.g., there's not a testcase for it, or the test is unaffected. -- -Austin
