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

Re: msvcrt: Implement ___lc_codepage_func, ___lc_collate_cp_func and ___lc_handle_func.
by Dmitry Timoshkov 15 Apr '09

15 Apr '09

"Hans Leidekker" <hans(a)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.

1 0

Fixing the last remaining failure on W2K (rpcrt4:server)
by Paul Vriens 15 Apr '09

15 Apr '09

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)

2 2

Re: [5/6] WineD3D: Support the full amount of constants in GLSL
by Henri Verbeet 15 Apr '09

15 Apr '09

2009/4/15 Stefan Dösinger <stefan(a)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.

2 2

Re: [PATCH 1/2] comctl32/tests: Test expanding of a invisible sub tree.
by Florian Köberle 15 Apr '09

15 Apr '09

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?

1 0

Re: [PATCH 1/2] comctl32/tests: Test expanding of a invisible sub tree.
by Nicolas Le Cam 15 Apr '09

15 Apr '09

2009/4/15 Florian Köberle <florian(a)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

1 0

Winprinfo tool
by Saulius Krasuckas 15 Apr '09

15 Apr '09

(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

1 0

Re: [mountmgr.sys] add unittests for registry keys of serial ports
by Dmitry Timoshkov 15 Apr '09

15 Apr '09

"Stefan Leichter" <Stefan.Leichter(a)camline.com> wrote: > [mountmgr.sys] add unittests for registry keys of serial ports The closest match these tests belong to is dlls/kernel32/tests/comm.c Is there any app that checks for a registry key instead of using an API? -- Dmitry.

2 2

Re: FYI -- Dragon Naturally Speaking running a bit better today.
by Susan Cragin 15 Apr '09

15 Apr '09

>On Do, 2009-04-09 at 16:05 -0400, Susan Cragin wrote: >> Dragon Naturally Speaking ... >> the amount of time one can use it before it crashes crept up about 2 >> minutes, ... >> Today I dictated for about 14 minutes until it crashed. >> That's progress. > >Susan, thanks a lot for your sedulous testing of DNS in Wine! > >-- > >By by ... Detlef > Thank you all for making "my" program run better. 16 minutes with today's git, 14-Apr. Susan

1 0

DIB Engine - New approach (resent as first got lost...)
by Massimo Del Fedele 14 Apr '09

14 Apr '09

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 (EDIT : posted on bug421 page, as here they disappeared....) 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. Ciao Max

2 2

Re: Christian Costa : amstream/tests: Beginning of tests.
by Nikolay Sivov 14 Apr '09

14 Apr '09

Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: b5dbbd4f3a16d074f0bdff39077973efdffe6c55 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=b5dbbd4f3a16d074f0bdff390… > > Author: Christian Costa <titan.costa(a)wanadoo.fr> > Date: Mon Apr 13 10:07:35 2009 +0200 > > amstream/tests: Beginning of tests. > > --- > > Breaks 'make crosstest' for me with unresolved GUID definitions. Looks like linking with strmiids has same affect when using uuid in tests. CLSID_AMMultiMediaStream IID_IAMMultiMediaStream should be defined inline I think.

1 0