Re: A tiny GetSystemMetrics question
On Sat, 04 Jul 2009 00:10:02 +0400, you wrote:
>Hi.
>
>Trying to fix some ListView bugs I've found that on native (XP SP2)
>system this call:
>---
>GetSystemMetrics(SM_CXICONSPACING)
>---
>doesn't return the value specified in appearance -> advanced settings of
>Display properties sheet.
>
>I've got 75 value for both cx and cy while I have set it to 43 in dialog
>box.
>
>This look weird for me. Does anybody know what is the reason of this
>behavior?
>
>P.S. Yes, I'm using default 96 dpi on this XP box (if it does matter).
>
>
Values here are 94 and 62.
The dialog presents the value
"GetSystemMetrics(SM_C{X|Y}ICONSPACING)-IconSize"
IOW the space _between_ icons, instead of distance from one icon to the
next.
Rein.
Re: [PATCH 3/5] d3d9/tests: Add a small test for having multiple device active at the same time.
2009/7/3 Paul Vriens : > Is D3DERR_NOTAVAILABLE an acceptable error? If so than the ok() message can > be easily extended (maybe with an extra skip() message?). > Probably, although you can also just remove the test if it causes a lot of failures. I added it because this situation exposed a bug in wined3d's initialization code, but it's not by itself critical for anything.
[rfc] lstrcmpi: order still wrong (was "Re: Regression in lstrcmpiA (occurred in late June, NLS related)" from 2003 year)
Hello! Previous thread on this topic: http://www.mail-archive.com/wine-devel@winehq.org/msg01080.html I've stumbled over problem with lstrcmpi sorting is still wrong. Some japanese game engine uses binary search on presorted array, and fails with a-la "object not found" errors. Judging by object order in archive, === cut === ... conf_p.MGD- (would fail with strcasecmp, ok with wine) conf01.MGD--/ ... title.MGD-- fails with vanilla wine title_p.MGD--/ ... === cut === proper order should be "_" < "0" (ok) and "." < "_" (fails with vanilla wine). I've replaced collation weight of '_' with 0x02560111, and now these games run fine; but that's dirty hack, of cause, and should not be applied to upstream: 1) it is modifies generated file; 2) weight for "_" chosen arbitrary and can cause conflicts somewhere else (or, rather, not can, but certainly will - there are other symbols with weight 0x0256???); 3) weight for other "_"-like chars should be modified too. Hope you can suggest better solution. FWIW, I've checked mentioned in previous thread unicode-2.1.9d8 tables - same mismatch, will not work too. I think, only proper way is somehow extract this table from windows (either directly by LCMapStringW(LC_MAP_SORTKEY), or sorting array of a[i]=i; with CompareStringW and using that order). I'm not a lawyer, but really doubt that such reproduced table can be considered copyrightable anywhere. How can anyone make compatible reimplementation without reproducing in some way this table? --
Re: user32: Windows test request (cursors/icons)
Daniel Santos wrote: I don't have access to a working windows machine right now and would appreciate if somebody can run these tests against XP, vista and/or 9x. Thanks! Daniel Hi Daniel, Tested on XP Professional SP3: cursoricon.c:1367: Test failed: Last error is 1402 (0x57a), expected 1414 (0x586). cursoricon.c:1369: Test failed: Last error is 1402 (0x57a), expected 1414 (0x586). cursoricon.c:1371: Test failed: Last error is 1402 (0x57a), expected 1414 (0x586). cursoricon.c:184: Test failed: Last error is 1402 (0x57a), expected 1414 (0x586). cursoricon: 6 tests executed (0 marked as todo, 0 failures), 0 skipped. cursoricon: 553 tests executed (0 marked as todo, 4 failures), 0 skipped. NT4 Server SP6a: cursoricon.c:1363: Test failed: DestroyCursor returned 1, expected FALSE. cursoricon.c:1363: Test failed: Last error is 3735928559 (0xdeadbeef), expected 1402 (0x57a). cursoricon.c:1367: Test failed: Last error is 1402 (0x57a), expected 1414 (0x586). cursoricon.c:1369: Test failed: DestroyIcon returned 1, expected FALSE. cursoricon.c:1369: Test failed: Last error is 3735928559 (0xdeadbeef), expected 1414 (0x586). cursoricon.c:1371: Test failed: Last error is 1402 (0x57a), expected 1414 (0x586). cursoricon.c:184: Test failed: Last error is 1402 (0x57a), expected 1414 (0x586). cursoricon: 6 tests executed (0 marked as todo, 0 failures), 0 skipped. cursoricon: 553 tests executed (0 marked as todo, 7 failures), 0 skipped. W2K Professional SP4: cursoricon.c:1367: Test failed: Last error is 1402 (0x57a), expected 1414 (0x586). cursoricon.c:1369: Test failed: Last error is 1402 (0x57a), expected 1414 (0x586). cursoricon.c:1371: Test failed: Last error is 1402 (0x57a), expected 1414 (0x586). cursoricon.c:184: Test failed: Last error is 1402 (0x57a), expected 1414 (0x586). cursoricon: 6 tests executed (0 marked as todo, 0 failures), 0 skipped. cursoricon: 553 tests executed (0 marked as todo, 4 failures), 0 skipped. W2K3 SE SP2: cursoricon.c:1367: Test failed: Last error is 1402 (0x57a), expected 1414 (0x586). cursoricon.c:1369: Test failed: Last error is 1402 (0x57a), expected 1414 (0x586). cursoricon.c:1371: Test failed: Last error is 1402 (0x57a), expected 1414 (0x586). cursoricon.c:184: Test failed: Last error is 1402 (0x57a), expected 1414 (0x586). cursoricon: 6 tests executed (0 marked as todo, 0 failures), 0 skipped. cursoricon: 554 tests executed (0 marked as todo, 4 failures), 0 skipped. Vista Ultimate - SP2: cursoricon.c:1367: Test failed: Last error is 1402 (0x57a), expected 1414 (0x586). cursoricon.c:1369: Test failed: Last error is 1402 (0x57a), expected 1414 (0x586). cursoricon.c:1371: Test failed: Last error is 1402 (0x57a), expected 1414 (0x586). cursoricon.c:184: Test failed: Last error is 1402 (0x57a), expected 1414 (0x586). cursoricon: 11 tests executed (0 marked as todo, 0 failures), 0 skipped. cursoricon: 553 tests executed (0 marked as todo, 4 failures), 0 skipped. I get a blue screen on Win95 and Win98 (VMware issue?) !! Some remarks on your patch: - Please move the new functions to the top so you don't have to forward declare them. - The level of comments for the 2 added functions is something we usually expect for implementations, not for tests ;) -- Cheers, Paul.
Re: [PATCH 3/5] d3d9/tests: Add a small test for having multiple device active at the same time.
Henri Verbeet wrote: This is essentially the situation that caused problems with reusing the initial GL context. --- dlls/d3d9/tests/device.c | 65 ++ 1 files changed, 65 insertions(+), 0 deletions(-) Hi Henri, +hr = IDirect3D9_CreateDevice(d3d9, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hwnd1, +D3DCREATE_SOFTWARE_VERTEXPROCESSING, &present_parameters, &device1); +ok(SUCCEEDED(hr), "Failed to create a device, hr %#x\n", hr); This one seems to fail on a lot of boxes, currently only VMware and ATI so it seems. NVIDIA and Intel seem to be fine though (for now as only a few tests are in). Is D3DERR_NOTAVAILABLE an acceptable error? If so than the ok() message can be easily extended (maybe with an extra skip() message?). Could you have a look? -- Cheers, Paul.
A tiny GetSystemMetrics question
Hi. Trying to fix some ListView bugs I've found that on native (XP SP2) system this call: --- GetSystemMetrics(SM_CXICONSPACING) --- doesn't return the value specified in appearance -> advanced settings of Display properties sheet. I've got 75 value for both cx and cy while I have set it to 43 in dialog box. This look weird for me. Does anybody know what is the reason of this behavior? P.S. Yes, I'm using default 96 dpi on this XP box (if it does matter).
user32: Windows test request (cursors/icons)
I don't have access to a working windows machine right now and would appreciate
if somebody can run these tests against XP, vista and/or 9x.
Thanks!
Daniel
From 55d99a143c3787f4e387a0b6f6866ad467df9d9b Mon Sep 17 00:00:00 2001
From: Daniel Santos
Date: Fri, 3 Jul 2009 13:44:15 -0500
Subject: user32/tests: Add more tests for SetCursor & DestroyCursor
---
dlls/user32/tests/cursoricon.c | 264 +---
1 files changed, 217 insertions(+), 47 deletions(-)
diff --git a/dlls/user32/tests/cursoricon.c b/dlls/user32/tests/cursoricon.c
index 3f8bd82..50edb62 100644
--- a/dlls/user32/tests/cursoricon.c
+++ b/dlls/user32/tests/cursoricon.c
@@ -18,6 +18,9 @@
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
+ *
+ * FIXME: Add tests for CreateCursor and verify that width & hight cannot
exceed
+ * SM_CXCURSOR & SM_CYCURSOR (because they can)
*/
#include
@@ -63,6 +66,10 @@ static HWND parent = 0;
static HANDLE child_process;
#define PROC_INIT (WM_USER+1)
+static HCURSOR test_SetCursor(HANDLE hNewCursor, BOOL shouldFail, int line,
+BOOL retValTodo);
+static BOOL test_DestroyCursorIcon(HANDLE h, BOOL isCursor, BOOL expectedRet,
+int line, DWORD expectedError);
static LRESULT CALLBACK callback_child(HWND hwnd, UINT msg, WPARAM wParam,
LPARAM lParam)
{
@@ -72,14 +79,15 @@ static LRESULT CALLBACK callback_child(HWND hwnd, UINT msg,
WPARAM wParam, LPARA
switch (msg)
{
/* Destroy the cursor. */
-case WM_USER+1:
+case WM_USER + 1:
SetLastError(0xdeadbeef);
ret = DestroyCursor((HCURSOR) lParam);
error = GetLastError();
-todo_wine ok(!ret || broken(ret) /* win9x */, "DestroyCursor on
the active cursor succeeded.\n");
+todo_wine ok(!ret || broken(ret), /* win9x */
+"DestroyCursor on the active cursor of another process
succeeded.\n");
ok(error == ERROR_DESTROY_OBJECT_OF_OTHER_THREAD ||
- error == 0xdeadbeef, /* vista */
-"Last error: %u\n", error);
+error == 0xdeadbeef, /* vista */
+"Last error: %u\n", error);
return TRUE;
case WM_DESTROY:
PostQuitMessage(0);
@@ -169,6 +177,14 @@ static void do_parent(void)
0, 0, 200, 200, 0, 0, 0, NULL);
ok(parent != 0, "CreateWindowA failed. Error: %u\n", GetLastError());
+/* make sure Destroy{Cursor,Icon} wont accept other user handle types */
+todo_wine {
+test_DestroyCursorIcon(parent, TRUE, FALSE, __LINE__,
+ERROR_INVALID_CURSOR_HANDLE);
+test_DestroyCursorIcon(parent, FALSE, FALSE, __LINE__,
+ERROR_INVALID_ICON_HANDLE);
+}
+
/* Start child process. */
memset(&startup, 0, sizeof(startup));
startup.cb = sizeof(startup);
@@ -217,7 +233,7 @@ static void test_child_process(void)
cursor = CreateIconIndirect(&cursorInfo);
ok(cursor != NULL, "CreateIconIndirect returned %p.\n", cursor);
-SetCursor(cursor);
+test_SetCursor(cursor, FALSE, __LINE__, FALSE);
/* Destroy the cursor. */
SendMessage(child, WM_USER+1, 0, (LPARAM) cursor);
@@ -520,12 +536,12 @@ static void test_CreateIcon(void)
hIcon = CreateIcon(0, 16, 16, 1, 1, bmp_bits, bmp_bits);
ok(hIcon != 0, "CreateIcon failed\n");
test_icon_info(hIcon, 16, 16, 1);
-DestroyIcon(hIcon);
+test_DestroyCursorIcon(hIcon, FALSE, TRUE, __LINE__, 0xdeadbeef);
hIcon = CreateIcon(0, 16, 16, 1, display_bpp, bmp_bits, bmp_bits);
ok(hIcon != 0, "CreateIcon failed\n");
test_icon_info(hIcon, 16, 16, display_bpp);
-DestroyIcon(hIcon);
+test_DestroyCursorIcon(hIcon, FALSE, TRUE, __LINE__, 0xdeadbeef);
hbmMask = CreateBitmap(16, 16, 1, 1, bmp_bits);
ok(hbmMask != 0, "CreateBitmap failed\n");
@@ -560,7 +576,7 @@ static void test_CreateIcon(void)
hIcon = CreateIconIndirect(&info);
ok(hIcon != 0, "CreateIconIndirect failed\n");
test_icon_info(hIcon, 16, 16, display_bpp);
-DestroyIcon(hIcon);
+test_DestroyCursorIcon(hIcon, FALSE, TRUE, __LINE__, 0xdeadbeef);
DeleteObject(hbmMask);
DeleteObject(hbmColor);
@@ -577,7 +593,7 @@ static void test_CreateIcon(void)
hIcon = CreateIconIndirect(&info);
ok(hIcon != 0, "CreateIconIndirect failed\n");
test_icon_info(hIcon, 16, 16, 1);
-DestroyIcon(hIcon);
+test_DestroyCursorIcon(hIcon, FALSE, TRUE, __LINE__, 0xdeadbeef);
DeleteObject(hbmMask);
DeleteObject(hbmColor);
@@ -610,7 +626,7 @@ static void test_CreateIcon(void)
hIcon = CreateIconIndirect(&info);
ok(hIcon != 0, "CreateIconIndirect failed\n");
test_icon_info(hIcon, 32, 32, 8);
-DestroyIcon(hIcon);
+test_DestroyCursorIcon(hIcon, FA
Re: [2/2] gdiplus: Implement GdipBeginContainer2 and GdipEndContainer
I don't think it's a good idea to rely on gdiplus functions being called from only one thread. Most of gdiplus currently is not thread-safe (maybe it should be), but it will work as long as a single object is only used from a single thread at a time. Adding global state makes things more complex, and that's part of the reason I think it's better not to put it in the initial implementation. If you do add it, I think you should do it in a separate patch. (I must confess my implementation of GdipNewInstalledFontCollection breaks the little thread-safety we have, but the race condition happens only the first time it's called.) You can clean up global data in DllMain in the PROCESS_DETACH case. -- Vincent Povirk
Re: kernel32: Compile .mc files to resources as independent files.
Paul Vriens writes: > kernel32 translations don't show up at the translation page > anymore. Do we need to teach wrc to deal with rc files being one level > lower (nls directory?) or what is needed to correct this? It should be fixed now, thanks for catching this. -- Alexandre Julliard julli...@winehq.org
Re: [2/2] gdiplus: Implement GdipBeginContainer2 and GdipEndContainer
Andrew Eikum wrote:
Nikolay Sivov wrote:
Vincent Povirk wrote:
On Fri, Jul 3, 2009 at 10:00 AM, Andrew
Eikum wrote:
I agree that the behavior of the container IDs doesn't match native.
However, do we really care to duplicate that behavior? I can't
see any
documentation in MSDN that says container IDs must be unique across
either
graphics objects or within a single graphics object.
I can't imagine any application depending on the uniqueness of
container
IDs; if they try to pass a container for graphics1 to graphics2,
nothing
happens, so there's no behavior to depend on. Ditto for invalid or
already-used containers. The only scenario I can think of where the
uniqueness of container IDs would be a dependency would be an
application
error calling EndContainer() with invalid values. I don't know if
it's
worth the effort of making a handle table and whatnot to work
around an
application glitch that might not even exist.
So, I would argue against the validity of the test you quote. Why
should
the same value not be returned twice?
+1
If an application does need the ID's to be more like Windows, the code
can be changed to account for it. We don't have to match every quirk
of Windows the first time something is implemented.
Exactly. I'm not talking about that. Allocating handle on Begin..()
or Save..() and releasing it on
End...() or Restore...() should be enough. After that we will
probably never want to change that
but for a first time it's necessary I think.
Okay, how about this patch? It creates a list of available IDs and
assigns/releases them as needed. Seems to work fine from my testing.
It also adds some fixes for things Vincent pointed out last night.
Can you guys check if everything is done correctly from a C/Wine
perspective? I notice that the objects in availableGCIDs are never
explicitly freed; can we just let this happen during cleanup as the
program exits?
Appears it didn't attach for some reason? Attempting to re-send, also
available at
http://www.brightnightgames.com/wine/GdipBeginContainer2.patch
>From 91a2ba1aa77cdf5d3c2bf7fe55dc78d24bc5bd9b Mon Sep 17 00:00:00 2001
From: Andrew Eikum
Date: Thu, 2 Jul 2009 18:43:58 -0500
Subject: gdiplus: Implement GdipBeginContainer2 and GdipEndContainer
To: wine-patches
Reply-To: wine-devel
---
dlls/gdiplus/gdiplus_private.h |2 +
dlls/gdiplus/graphics.c| 189 ++--
include/gdiplusflat.h |1 +
3 files changed, 186 insertions(+), 6 deletions(-)
diff --git a/dlls/gdiplus/gdiplus_private.h b/dlls/gdiplus/gdiplus_private.h
index 95133ca..b6ed8fe 100644
--- a/dlls/gdiplus/gdiplus_private.h
+++ b/dlls/gdiplus/gdiplus_private.h
@@ -29,6 +29,7 @@
#include "objbase.h"
#include "ocidl.h"
+#include "wine/list.h"
#include "gdiplus.h"
@@ -109,6 +110,7 @@ struct GpGraphics{
BOOL busy; /* hdc handle obtained by GdipGetDC */
GpRegion *clip;
UINT textcontrast; /* not used yet. get/set only */
+struct list containers;
};
struct GpBrush{
diff --git a/dlls/gdiplus/graphics.c b/dlls/gdiplus/graphics.c
index 3525743..78c68be 100644
--- a/dlls/gdiplus/graphics.c
+++ b/dlls/gdiplus/graphics.c
@@ -38,6 +38,7 @@
#include "gdiplus.h"
#include "gdiplus_private.h"
#include "wine/debug.h"
+#include "wine/list.h"
WINE_DEFAULT_DEBUG_CHANNEL(gdiplus);
@@ -941,6 +942,141 @@ GpStatus trace_path(GpGraphics *graphics, GpPath *path)
return result;
}
+typedef struct _GraphicsContainerItem {
+struct list entry;
+GraphicsContainer contid;
+
+SmoothingMode smoothing;
+CompositingQuality compqual;
+InterpolationMode interpolation;
+CompositingMode compmode;
+TextRenderingHint texthint;
+REAL scale;
+GpUnit unit;
+PixelOffsetMode pixeloffset;
+UINT textcontrast;
+GpMatrix* worldtrans;
+GpRegion* clip;
+} GraphicsContainerItem;
+
+typedef struct _GraphicsContainerID {
+struct list entry;
+
+GraphicsContainer id;
+} GraphicsContainerID;
+
+static struct list availableGCIDs = LIST_INIT(availableGCIDs);
+static GraphicsContainer lowest_unallocated_GCID = 0;
+
+static void make_available_gcid(GraphicsContainer id){
+GraphicsContainerID *gcid;
+
+gcid = GdipAlloc(sizeof(GraphicsContainerID));
+gcid->id = id;
+list_add_head(&availableGCIDs, &gcid->entry);
+}
+
+static void allocate_gcids(){
+const GraphicsContainer num_new_ids = 20;
+GraphicsContainer i;
+
+for(i = 0; i < num_new_ids; i++){
+make_available_gcid(i + lowest_unallocated_GCID);
+}
+
+lowest_unallocated_GCID += num_new_ids;
+}
+
+static void get_available_gcid(GraphicsContainer* id){
+GraphicsContainerID *gcid;
+
+if(list_empty(&availableGCIDs))
+allocate_gcids();
+
+gcid = LIST_ENTRY(list_head(&availableGCIDs), GraphicsContainerID, entry);
+*id = gcid->id;
+list_remove(&gcid->entry);
+GdipFree(gcid);
+}
+
+static GpStatus init_container(Graph
Re: [2/2] gdiplus: Implement GdipBeginContainer2 and GdipEndContainer
Nikolay Sivov wrote:
Vincent Povirk wrote:
On Fri, Jul 3, 2009 at 10:00 AM, Andrew
Eikum wrote:
I agree that the behavior of the container IDs doesn't match native.
However, do we really care to duplicate that behavior? I can't see
any
documentation in MSDN that says container IDs must be unique across
either
graphics objects or within a single graphics object.
I can't imagine any application depending on the uniqueness of
container
IDs; if they try to pass a container for graphics1 to graphics2,
nothing
happens, so there's no behavior to depend on. Ditto for invalid or
already-used containers. The only scenario I can think of where the
uniqueness of container IDs would be a dependency would be an
application
error calling EndContainer() with invalid values. I don't know if it's
worth the effort of making a handle table and whatnot to work around an
application glitch that might not even exist.
So, I would argue against the validity of the test you quote. Why
should
the same value not be returned twice?
+1
If an application does need the ID's to be more like Windows, the code
can be changed to account for it. We don't have to match every quirk
of Windows the first time something is implemented.
Exactly. I'm not talking about that. Allocating handle on Begin..() or
Save..() and releasing it on
End...() or Restore...() should be enough. After that we will probably
never want to change that
but for a first time it's necessary I think.
Okay, how about this patch? It creates a list of available IDs and
assigns/releases them as needed. Seems to work fine from my testing.
It also adds some fixes for things Vincent pointed out last night.
Can you guys check if everything is done correctly from a C/Wine
perspective? I notice that the objects in availableGCIDs are never
explicitly freed; can we just let this happen during cleanup as the
program exits?
>From 91a2ba1aa77cdf5d3c2bf7fe55dc78d24bc5bd9b Mon Sep 17 00:00:00 2001
From: Andrew Eikum
Date: Thu, 2 Jul 2009 18:43:58 -0500
Subject: gdiplus: Implement GdipBeginContainer2 and GdipEndContainer
To: wine-patches
Reply-To: wine-devel
---
dlls/gdiplus/gdiplus_private.h |2 +
dlls/gdiplus/graphics.c| 189 ++--
include/gdiplusflat.h |1 +
3 files changed, 186 insertions(+), 6 deletions(-)
diff --git a/dlls/gdiplus/gdiplus_private.h b/dlls/gdiplus/gdiplus_private.h
index 95133ca..b6ed8fe 100644
--- a/dlls/gdiplus/gdiplus_private.h
+++ b/dlls/gdiplus/gdiplus_private.h
@@ -29,6 +29,7 @@
#include "objbase.h"
#include "ocidl.h"
+#include "wine/list.h"
#include "gdiplus.h"
@@ -109,6 +110,7 @@ struct GpGraphics{
BOOL busy; /* hdc handle obtained by GdipGetDC */
GpRegion *clip;
UINT textcontrast; /* not used yet. get/set only */
+struct list containers;
};
struct GpBrush{
diff --git a/dlls/gdiplus/graphics.c b/dlls/gdiplus/graphics.c
index 3525743..78c68be 100644
--- a/dlls/gdiplus/graphics.c
+++ b/dlls/gdiplus/graphics.c
@@ -38,6 +38,7 @@
#include "gdiplus.h"
#include "gdiplus_private.h"
#include "wine/debug.h"
+#include "wine/list.h"
WINE_DEFAULT_DEBUG_CHANNEL(gdiplus);
@@ -941,6 +942,141 @@ GpStatus trace_path(GpGraphics *graphics, GpPath *path)
return result;
}
+typedef struct _GraphicsContainerItem {
+struct list entry;
+GraphicsContainer contid;
+
+SmoothingMode smoothing;
+CompositingQuality compqual;
+InterpolationMode interpolation;
+CompositingMode compmode;
+TextRenderingHint texthint;
+REAL scale;
+GpUnit unit;
+PixelOffsetMode pixeloffset;
+UINT textcontrast;
+GpMatrix* worldtrans;
+GpRegion* clip;
+} GraphicsContainerItem;
+
+typedef struct _GraphicsContainerID {
+struct list entry;
+
+GraphicsContainer id;
+} GraphicsContainerID;
+
+static struct list availableGCIDs = LIST_INIT(availableGCIDs);
+static GraphicsContainer lowest_unallocated_GCID = 0;
+
+static void make_available_gcid(GraphicsContainer id){
+GraphicsContainerID *gcid;
+
+gcid = GdipAlloc(sizeof(GraphicsContainerID));
+gcid->id = id;
+list_add_head(&availableGCIDs, &gcid->entry);
+}
+
+static void allocate_gcids(){
+const GraphicsContainer num_new_ids = 20;
+GraphicsContainer i;
+
+for(i = 0; i < num_new_ids; i++){
+make_available_gcid(i + lowest_unallocated_GCID);
+}
+
+lowest_unallocated_GCID += num_new_ids;
+}
+
+static void get_available_gcid(GraphicsContainer* id){
+GraphicsContainerID *gcid;
+
+if(list_empty(&availableGCIDs))
+allocate_gcids();
+
+gcid = LIST_ENTRY(list_head(&availableGCIDs), GraphicsContainerID, entry);
+*id = gcid->id;
+list_remove(&gcid->entry);
+GdipFree(gcid);
+}
+
+static GpStatus init_container(GraphicsContainerItem** container,
+GDIPCONST GpGraphics* graphics){
+GpStatus sts;
+
+*container = GdipAlloc(sizeof(GraphicsContainerItem));
+if(!(*containe
Re: kernel32: Compile .mc files to resources as independent files.
Hi, kernel32 translations don't show up at the translation page anymore. Do we need to teach wrc to deal with rc files being one level lower (nls directory?) or what is needed to correct this? (Before this patch the page basically showed if there was a translation or not and not whether the content was correct) -- Cheers, Paul.
Re: [2/2] gdiplus: Implement GdipBeginContainer2 and GdipEndContainer
Vincent Povirk wrote: On Fri, Jul 3, 2009 at 10:00 AM, Andrew Eikum wrote: I agree that the behavior of the container IDs doesn't match native. However, do we really care to duplicate that behavior? I can't see any documentation in MSDN that says container IDs must be unique across either graphics objects or within a single graphics object. I can't imagine any application depending on the uniqueness of container IDs; if they try to pass a container for graphics1 to graphics2, nothing happens, so there's no behavior to depend on. Ditto for invalid or already-used containers. The only scenario I can think of where the uniqueness of container IDs would be a dependency would be an application error calling EndContainer() with invalid values. I don't know if it's worth the effort of making a handle table and whatnot to work around an application glitch that might not even exist. So, I would argue against the validity of the test you quote. Why should the same value not be returned twice? +1 If an application does need the ID's to be more like Windows, the code can be changed to account for it. We don't have to match every quirk of Windows the first time something is implemented. Exactly. I'm not talking about that. Allocating handle on Begin..() or Save..() and releasing it on End...() or Restore...() should be enough. After that we will probably never want to change that but for a first time it's necessary I think.
Re: [2/2] gdiplus: Implement GdipBeginContainer2 and GdipEndContainer
Andrew Eikum wrote: Nikolay Sivov wrote: Andrew Eikum wrote: --- dlls/gdiplus/gdiplus_private.h |3 + dlls/gdiplus/graphics.c| 154 ++-- include/gdiplusflat.h |1 + 3 files changed, 152 insertions(+), 6 deletions(-) This looks wrong for me cause I don't think you could pass container id created with one Graphics to Graphics.EndContainer() of another. I've just checked it and it doesn't return any error code, but generated container ids aren't the same when you call BeginContainer() for e.g. two objects as sequent steps. It looks like on native these value are module unique, some kind of handle table needed. This kills the first problem I described - passing strange value to another Graphics. Also note that Save()/Restore() functionality uses the same stack with container calls (at least msdn tells us that), for that Save/Restore we already have a test: --- static void test_save_restore(void) /* The same state value should never be returned twice. */ todo_wine check_no_duplicates(state_log); --- It clearly says that no duplicates allowed, even after multiple object deletion - it checks for values returned during the whole test. I agree that the behavior of the container IDs doesn't match native. However, do we really care to duplicate that behavior? I can't see any documentation in MSDN that says container IDs must be unique across either graphics objects or within a single graphics object. It doesn't matter is it explicitly documented or not. We should care only about how it really works. I can't imagine any application depending on the uniqueness of container IDs; if they try to pass a container for graphics1 to graphics2, nothing happens, so there's no behavior to depend on. If you create container c1 for graphics1 (0 numbered), then c2 for graphics2 (0 numbered too), then pop container for graphics2 with c1 value (c1 == c2) you implementation will successfully restore graphics2 to previous state. This doesn't happen on native - it will return Ok status, but status will be retained. This is a behavior we should depend on. Ditto for invalid or already-used containers. The only scenario I can think of where the uniqueness of container IDs would be a dependency would be an application error calling EndContainer() with invalid values. I don't know if it's worth the effort of making a handle table and whatnot to work around an application glitch that might not even exist. What you mean it might not? If somebody (e.g. me) will write a test for that will it exist then? So, I would argue against the validity of the test you quote. Why should the same value not be returned twice? Agreed, test isn't so obvious cause it shows that id value doesn't reoccur even after releasing containers. But test passes well on Windows, and only this matters here. To simplify this we possibly could not to reproduce this exactly, but only guaranty ID uniqueness for currently valid Graphics objects in a process wide way. After that we could consider making this test pass as a second step to get closer to native behavior.
Re: [2/2] gdiplus: Implement GdipBeginContainer2 and GdipEndContainer
On Fri, Jul 3, 2009 at 10:00 AM, Andrew Eikum wrote: > I agree that the behavior of the container IDs doesn't match native. > However, do we really care to duplicate that behavior? I can't see any > documentation in MSDN that says container IDs must be unique across either > graphics objects or within a single graphics object. > > I can't imagine any application depending on the uniqueness of container > IDs; if they try to pass a container for graphics1 to graphics2, nothing > happens, so there's no behavior to depend on. Ditto for invalid or > already-used containers. The only scenario I can think of where the > uniqueness of container IDs would be a dependency would be an application > error calling EndContainer() with invalid values. I don't know if it's > worth the effort of making a handle table and whatnot to work around an > application glitch that might not even exist. > > So, I would argue against the validity of the test you quote. Why should > the same value not be returned twice? +1 If an application does need the ID's to be more like Windows, the code can be changed to account for it. We don't have to match every quirk of Windows the first time something is implemented. -- Vincent Povirk
Re: [2/2] gdiplus: Implement GdipBeginContainer2 and GdipEndContainer
Nikolay Sivov wrote: Andrew Eikum wrote: --- dlls/gdiplus/gdiplus_private.h |3 + dlls/gdiplus/graphics.c| 154 ++-- include/gdiplusflat.h |1 + 3 files changed, 152 insertions(+), 6 deletions(-) This looks wrong for me cause I don't think you could pass container id created with one Graphics to Graphics.EndContainer() of another. I've just checked it and it doesn't return any error code, but generated container ids aren't the same when you call BeginContainer() for e.g. two objects as sequent steps. It looks like on native these value are module unique, some kind of handle table needed. This kills the first problem I described - passing strange value to another Graphics. Also note that Save()/Restore() functionality uses the same stack with container calls (at least msdn tells us that), for that Save/Restore we already have a test: --- static void test_save_restore(void) /* The same state value should never be returned twice. */ todo_wine check_no_duplicates(state_log); --- It clearly says that no duplicates allowed, even after multiple object deletion - it checks for values returned during the whole test. I agree that the behavior of the container IDs doesn't match native. However, do we really care to duplicate that behavior? I can't see any documentation in MSDN that says container IDs must be unique across either graphics objects or within a single graphics object. I can't imagine any application depending on the uniqueness of container IDs; if they try to pass a container for graphics1 to graphics2, nothing happens, so there's no behavior to depend on. Ditto for invalid or already-used containers. The only scenario I can think of where the uniqueness of container IDs would be a dependency would be an application error calling EndContainer() with invalid values. I don't know if it's worth the effort of making a handle table and whatnot to work around an application glitch that might not even exist. So, I would argue against the validity of the test you quote. Why should the same value not be returned twice? Andrew
Re: Patch feedback (GetProductInfo)
Fredag 03 juli 2009 11:10:01 skrev Nikolay Sivov: > Alexander Nicolaysen Sørnes wrote: > > Hello, > > > > Could someone give me a hint as to what is wrong with the following > > patches? > > > > http://www.winehq.org/pipermail/wine-patches/2009-June/074908.html > > http://www.winehq.org/pipermail/wine-patches/2009-June/074909.html > > > > They only adds some defines plus a stub, so hopefully there isn't that > > much I can have done wrong :) > > > > > > > > Alexander N. Sørnes > > Hi, Alexander. > > First of all constant defines should go to winnt.h to match PSDK. > Next I found RtlGetProductInfo() call in winnt.h. That's make me think > that kernel32 call should be a thin wrapper > over this ntdll call. I don't have Vista installed (I suppose it's Vista > related call), so I can't check. > > After that it might be nice to have a combo in winecfg to choose edition > - as I know upcoming Win7 also has > this product categories. Default value could be Ultimate of course. And > combo should only appear on >= Vista. > > Nikolay S. Thanks!
Re: comdlg32: Fix a problem with the returned value of a CDN_FILEOK notification.
On Fri, 03 Jul 2009 07:49:33 +0200, you wrote: >Hi Rein, > >This one introduced extra test failures on Vista. On 1 Vista box and >W2K8 the test times out (crashes?). > >Could you have a look. I have submitted a fix. Works for me on Vista, XP (real) and W2k, W2k8 (vmware). Rein.
Re: Patch feedback (GetProductInfo)
Alexander Nicolaysen Sørnes wrote: Hello, Could someone give me a hint as to what is wrong with the following patches? http://www.winehq.org/pipermail/wine-patches/2009-June/074908.html http://www.winehq.org/pipermail/wine-patches/2009-June/074909.html They only adds some defines plus a stub, so hopefully there isn't that much I can have done wrong :) Alexander N. Sørnes Hi, Alexander. First of all constant defines should go to winnt.h to match PSDK. Next I found RtlGetProductInfo() call in winnt.h. That's make me think that kernel32 call should be a thin wrapper over this ntdll call. I don't have Vista installed (I suppose it's Vista related call), so I can't check. After that it might be nice to have a combo in winecfg to choose edition - as I know upcoming Win7 also has this product categories. Default value could be Ultimate of course. And combo should only appear on >= Vista. Nikolay S.
Re: [2/2] gdiplus: Implement GdipBeginContainer2 and GdipEndContainer
Andrew Eikum wrote: --- dlls/gdiplus/gdiplus_private.h |3 + dlls/gdiplus/graphics.c| 154 ++-- include/gdiplusflat.h |1 + 3 files changed, 152 insertions(+), 6 deletions(-) This looks wrong for me cause I don't think you could pass container id created with one Graphics to Graphics.EndContainer() of another. I've just checked it and it doesn't return any error code, but generated container ids aren't the same when you call BeginContainer() for e.g. two objects as sequent steps. It looks like on native these value are module unique, some kind of handle table needed. This kills the first problem I described - passing strange value to another Graphics. Also note that Save()/Restore() functionality uses the same stack with container calls (at least msdn tells us that), for that Save/Restore we already have a test: --- static void test_save_restore(void) /* The same state value should never be returned twice. */ todo_wine check_no_duplicates(state_log); --- It clearly says that no duplicates allowed, even after multiple object deletion - it checks for values returned during the whole test.
Re: comdlg32: Fix a problem with the returned value of a CDN_FILEOK notification.
On Fri, 03 Jul 2009 07:49:33 +0200, you wrote: >Hi Rein, > >This one introduced extra test failures on Vista. On 1 Vista box and >W2K8 the test times out (crashes?). > >Could you have a look. No time outs here, but I see the failures. The PostMessage( ..., WM_COMMAND, IDOK, ...) seems not enough to simulate that the "open file" button has been pressed. Looking for an alternative ... Rein.
