Re: mpr: Changes comparison of dwScope in WNetOpenEnum function

2007-09-25 Thread Konstantin Kondratyuk
Hello, Juan!

 Hi Konstantin,

 - providerTable-table[index].dwEnumScopes
  dwScope)
 + providerTable-table[index].dwEnumScopes
  WNNC_ENUM_GLOBAL)

 This change looks correct, but it should be changed in the next block as
 well:

 ret = providerTable-table[index].openEnum(
  dwScope, dwType, dwUsage, lpNet, handle);

 It also looks incorrect in _enumerateGlobalPassthroughW:
 ret = providerTable-table[enumerator-providerIndex].
  openEnum(enumerator-dwScope, enumerator-dwType,
  enumerator-dwUsage, enumerator-lpNet,
  enumerator-handle);

 In fact, all of these usages of dwScope look to confuse the two
 meanings.  (D'oh.)
 --Juan

Well, I have looked all code in mpr/wnet.c
The following condition in _globalEnumeratorAdvance() looks incorrect:

for (; enumerator-providerIndex  providerTable-numProviders 
 !(enumerator-dwScope  providerTable-table
 [enumerator-providerIndex].dwEnumScopes);
 enumerator-providerIndex++)

Other conditions and parameters look correctly. For example, function 
NPOpenEnum() expects a dwScope, containing RESOURCE_CONNECTED, 
RESOURCE_GLOBALNET or RESOURCE_CONTEXT.
Correct for me if I am not right.

-- 
Best regards,
Konstantin Kondratyuk.




Re: widl [2/6]: Fix conformant array test failures

2007-09-25 Thread Alexandre Julliard
Dan Hipschman [EMAIL PROTECTED] writes:

 This patch gets conformant arrays working in the tests.  Currently, only
 the address of some conformant arrays are being marshalled, and this wasn't
 showing up in the tests because some storage was static.  This patch fixes
 the problem by writing pointers to conformant array types in the format
 string.  This also requires handling field pointer conformances, and
 expression evaluation routines that expect the containing structure of a
 conformant array at the top of the stack, rather than the conformant array
 itself.  With this patch, the tests still pass, but correctly this time.

It breaks the ole32 tests:

../../../tools/runtest -q -P wine -M ole32.dll -T ../../.. -p ole32_test.exe.so 
moniker.c  touch moniker.ok
moniker.c:897: Test failed: IRunningObjectTable_EnumRunning hr=800703e6
wine: Unhandled page fault on read access to 0x at address 0x60527ff6 
(thread 0010), starting debugger...
WineDbg starting on pid 000f
Unhandled exception: page fault on read access to 0x in 32-bit code 
(0x60527ff6).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:60527ff6 ESP:0033fa90 EBP:0033fe58 EFLAGS:00010206(   - 00  - RIP1)
 EAX:0033fe30 EBX:6054601c ECX: EDX:
 ESI:800703e6 EDI:6053e4ec
Stack dump:
0x0033fa90:   6053e498 800703e6 60542308
0x0033faa0:  0033fe34 0100  
0x0033fab0:  60547478 60547474 6053cdc8 0033fe48
0x0033fac0:  0033fe44 0033fe40 0033fe38 0033fe20
0x0033fad0:  6053d190 60542308 0033fe14 6053e720
0x0033fae0:  6053e2dc 60539d74 6053e154 60539de8
Backtrace:
=1 0x60527ff6 func_moniker+0x15f6() 
[/home/julliard/wine/wine/dlls/ole32/tests/moniker.c:898] in ole32_test 
(0x0033fe58)
  2 0x60538df8 run_test+0x128(name=0x1103ce) 
[/home/julliard/wine/wine/dlls/ole32/tests/../../../include/wine/test.h:389] in 
ole32_test (0x0033fea8)
  3 0x6053948d main+0x14d(argc=register ECX not in topmost frame, 
argv=register ECX not in topmost frame) 
[/home/julliard/wine/wine/dlls/ole32/tests/../../../include/wine/test.h:437] in 
ole32_test (0x0033fed8)
  4 0x6053955b __wine_spec_exe_entry+0x5b(peb=0x7ffdf000) 
[/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in ole32_test 
(0x0033ff08)
  5 0x7b87446e start_process+0xee(arg=0x0) 
[/home/julliard/wine/wine/dlls/kernel32/process.c:839] in kernel32 (0x0033ffe8)
  6 0x600289a7 wine_switch_to_stack+0x17() in libwine.so.1 (0x)
0x60527ff6 func_moniker+0x15f6 
[/home/julliard/wine/wine/dlls/ole32/tests/moniker.c:898] in ole32_test: movl   
 0x0(%edx),%ecx
898 hr = IEnumMoniker_QueryInterface(spEM1, IID_IUnknown, (void*) 
lpEM1);
Wine-dbg

-- 
Alexandre Julliard
[EMAIL PROTECTED]




Re: user32: Make message test pass cleanly under XP SP2

2007-09-25 Thread Anatoly Lyutin
Dmitry Timoshkov wrote:
 Hello,

 Changelog:
 user32: Make message test pass cleanly under XP SP2.

 ---
  dlls/user32/tests/msg.c |  142 +-
  1 files changed, 102 insertions(+), 40 deletions(-)


  
 @@ -224,51 +226,53 @@ static const struct message WmSwitchChild[] = {
  /* Switch MDI child */
  { WM_MDIACTIVATE, sent },/* in the MDI client */
  { WM_WINDOWPOSCHANGING, sent|wparam,SWP_NOSIZE|SWP_NOMOVE },/* in the 
 1st MDI child */
 +{ EVENT_OBJECT_REORDER, winevent_hook|wparam|lparam, OBJID_CLIENT, 0 },
  { WM_CHILDACTIVATE, sent },/* in the 1st MDI child */
  /* Deactivate 2nd MDI child */
 -{ WM_NCACTIVATE, sent|defwinproc|optional },/* in the 2nd MDI child */
 -{ WM_MDIACTIVATE, sent|defwinproc|optional },/* in the 2nd MDI child */
 -{ WM_CREATE, hook },
 +{ WM_NCACTIVATE, sent|wparam|defwinproc, 0 }, /* in the 2nd MDI child */
 +{ WM_MDIACTIVATE, sent|defwinproc }, /* in the 2nd MDI child */
 +{ HCBT_MINMAX, hook|lparam, 0, SW_MAXIMIZE },
  /* Preparing for maximize and maximaze the 1st MDI child */
 -{ WM_GETMINMAXINFO, sent|defwinproc|optional },/* in the 1st MDI child */
 -{ WM_WINDOWPOSCHANGING, sent|wparam|defwinproc|optional, 
 SWP_FRAMECHANGED|SWP_STATECHANGED },/* in the 1st MDI child */
 -{ WM_GETMINMAXINFO, sent|defwinproc|optional },/* in the 1st MDI child */
 -{ WM_NCCALCSIZE, sent|wparam|defwinproc|optional, 1 },/* in the 1st MDI 
 child */
 -{ WM_CHILDACTIVATE, sent|defwinproc|optional },/* in the 1st MDI child */
 -{ WM_WINDOWPOSCHANGED, sent|defwinproc|optional },/* in the 1st MDI 
 child */
 -{ WM_MOVE, sent|defwinproc|optional },/* in the 1st MDI child */
 -{ WM_SIZE, sent|defwinproc|optional },/* in the 1st MDI child */
 +{ WM_GETMINMAXINFO, sent|defwinproc }, /* in the 1st MDI child */
 +{ WM_WINDOWPOSCHANGING, sent|wparam|defwinproc, 
 SWP_FRAMECHANGED|SWP_STATECHANGED }, /* in the 1st MDI child */
 +{ WM_NCCALCSIZE, sent|wparam|defwinproc, 1 }, /* in the 1st MDI child */
 +{ WM_CHILDACTIVATE, sent|defwinproc }, /* in the 1st MDI child */
 +{ WM_WINDOWPOSCHANGED, sent|wparam|defwinproc, 
 SWP_FRAMECHANGED|SWP_NOSIZE|SWP_NOMOVE|SWP_NOCLIENTSIZE|SWP_NOCLIENTMOVE|0x8000
  }, /* in the 1st MDI child */
 +{ WM_SIZE, sent|defwinproc|wparam, SIZE_MAXIMIZED }, /* in the 1st MDI 
 child */
  /* Lock redraw 2nd MDI child */
 -{ WM_SETREDRAW, sent|defwinproc|optional },/* in the 2nd MDI child */
 -{ WM_WINDOWPOSCHANGING, sent|wparam|defwinproc|optional, 
 SWP_FRAMECHANGED|SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE },/* in the 2nd MDI 
 child */
 -{ WM_NCCALCSIZE, sent|wparam|defwinproc|optional, 1 },/* in the 2nd MDI 
 child */
 -{ WM_WINDOWPOSCHANGED, sent|defwinproc|optional },/* in the 2nd MDI 
 child */
 -{ WM_CREATE, hook },
 +{ WM_SETREDRAW, sent|wparam|defwinproc, 0 }, /* in the 2nd MDI child */
 +{ HCBT_MINMAX, hook|lparam, 0, SW_NORMALNA },
  /* Restore 2nd MDI child */
 -{ WM_WINDOWPOSCHANGING, sent|wparam|defwinproc|optional, 
 SWP_NOACTIVATE|SWP_FRAMECHANGED|SWP_SHOWWINDOW|SWP_STATECHANGED  },/* in the 
 2nd MDI child */
 -{ WM_GETMINMAXINFO, sent|defwinproc|optional },/* in the 2nd MDI child */
 -{ WM_NCCALCSIZE, sent|wparam|defwinproc|optional, 1 },/* in the 2nd MDI 
 child */
 -{ WM_WINDOWPOSCHANGED, sent|defwinproc|optional },/* in the 2nd MDI 
 child */
 -{ WM_MOVE, sent|defwinproc|optional },/* in the 2nd MDI child */
 -{ WM_SIZE, sent|defwinproc|optional },/* in the 2nd MDI child */
 +{ WM_WINDOWPOSCHANGING, sent|wparam|defwinproc, 
 SWP_SHOWWINDOW|SWP_NOACTIVATE|SWP_FRAMECHANGED|0x8000 },/* in the 2nd MDI 
 child */
 +{ WM_NCCALCSIZE, sent|wparam|defwinproc, 1 },/* in the 2nd MDI child */
 +{ EVENT_OBJECT_SHOW, winevent_hook|wparam|lparam, 0, 0 }, /* in the 2nd 
 MDI child */
 +{ WM_WINDOWPOSCHANGED, sent|wparam|defwinproc, 
 SWP_SHOWWINDOW|SWP_NOACTIVATE|SWP_FRAMECHANGED|SWP_NOSIZE|SWP_NOMOVE|SWP_NOCLIENTSIZE|SWP_NOCLIENTMOVE|0x8000
  }, /* in the 2nd MDI child */
 +{ WM_SIZE, sent|defwinproc|wparam, SIZE_RESTORED }, /* in the 2nd MDI 
 child */
 +{ EVENT_OBJECT_LOCATIONCHANGE, winevent_hook|wparam|lparam, 0, 0 }, /* 
 in the 2nd MDI child */
  /* Redraw 2nd MDI child */
 -{ WM_SETREDRAW, sent|defwinproc|optional },/* in the 2nd MDI child */
 -{ WM_WINDOWPOSCHANGING, sent|wparam, 
 SWP_NOACTIVATE|SWP_NOSIZE|SWP_FRAMECHANGED|SWP_NOMOVE },/* in the MDI frame */
 -{ WM_NCCALCSIZE, sent|wparam, 1 },/* in the MDI frame */
 -{ WM_WINDOWPOSCHANGED, sent},/* in the MDI frame */
 -{ WM_WINDOWPOSCHANGING, sent|wparam|defwinproc|optional, 
 SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE },/* in the 1st MDI child */
 -{ WM_NCACTIVATE, sent|wparam|defwinproc|optional, 1 },/* in the 1st MDI 
 child */
 -{ WM_SETVISIBLE, hook },
 -{ WM_KILLFOCUS, sent|defwinproc|optional }, /* in the 2nd MDI child */
 -{ WM_IME_SETCONTEXT, 

Re: [5/5] winex11: Use an offscreen redirected window for child OpenGL rendering

2007-09-25 Thread Alexandre Julliard
Chris Robinson [EMAIL PROTECTED] writes:

 +if(w  0  h  0) {
 +XFlush(gdi_display);
 +XCopyArea(gdi_display, physDev-gl_drawable, physDev-drawable,
 +  physDev-gc, 0, 0, w, h, physDev-dc_rect.left,
 +  physDev-dc_rect.top);

Why do you need an XFlush here?

 +if(data-whole_window  vis-visualid == XVisualIDFromVisual(visual))
 +{
 +TRACE(Whole window available and visual match, rendering 
 onscreen\n);
 +goto done;
 +}
 +
 +if(!composite_gl)
 +goto done;

There's no sense in having a config option for this since the
alternative doesn't work anyway, particularly since you removed the
scissor support.

 +data-gl_drawable = XCreateWindow(gdi_display, root_window, -w, 0, 
 w, h,
 +  0, vis-depth, InputOutput,
 +  vis-visual,
 +  CWColormap | CWOverrideRedirect,
 +  attrib);

The window needs to be created on the thread display, and as a child
of the main window.

 +static void update_gl_drawable(struct x11drv_win_data *data)
 +{
 +unsigned int border, depth;
 +int x, y, w, h;
 +Window root_win;
 +
 +if(!data-gl_drawable)
 +return;
 +
 +wine_tsx11_lock();
 +XGetGeometry(gdi_display, data-gl_drawable, root_win, x, y,
 + (unsigned int*)w, (unsigned int*)h, border, depth);

You must not use XGetGeometry, this incurs a server round-trip.

-- 
Alexandre Julliard
[EMAIL PROTECTED]




Re: user32: Make message test pass cleanly under XP SP2

2007-09-25 Thread Dmitry Timoshkov
Anatoly Lyutin [EMAIL PROTECTED] wrote:

 Sorry! It falls in my Windows XP SP2 with:
 msg.c:3267:expected 0009 - actual 0009
 msg.c:3267:expected 0008 - actual 0008
 msg.c:3267:expected 0281 - actual 0007
 msg.c:3267: Test failed: Child did not switch correctly: the msg 0x0281 
 was expected, but got msg 0x0007 instead
 msg.c:3268:end of test for switch maximized MDI children

As the subject of the patch says the tests pass absolutely cleanly for me.
The failure you see above is a very minor thing in comparison to current state.
Usually I'm monitoring test.winehq.org/data and trying to fix failures reported
there.

-- 
Dmitry.




Re: user32: Make message test pass cleanly under XP SP2

2007-09-25 Thread Anatoly Lyutin
Dmitry Timoshkov wrote:
 Anatoly Lyutin [EMAIL PROTECTED] wrote:

 As the subject of the patch says the tests pass absolutely cleanly for 
 me.
 The failure you see above is a very minor thing in comparison to 
 current state.
 Usually I'm monitoring test.winehq.org/data and trying to fix failures 
 reported
 there.

Ok. I hope, that the general number of mistakes will decrease after this 
work.

-- 
Best regards
Anatoly Lyutin.





Re: user32: Make message test pass cleanly under XP SP2

2007-09-25 Thread Alexandre Julliard
Dmitry Timoshkov [EMAIL PROTECTED] writes:

  /* posted message */
  PostMessageA( hwnd, WM_CHAR, dbch[0], 0 );
 +msg.message = 0xdeadbeef;
  ok( !PeekMessageW( msg, hwnd, 0, 0, PM_REMOVE ), got message %x\n, 
 msg.message );
  PostMessageA( hwnd, WM_CHAR, dbch[1], 0 );
  ok( PeekMessageW( msg, hwnd, 0, 0, PM_REMOVE ), no message\n );
  ok( msg.message == WM_CHAR, unexpected message %x\n, msg.message );
  ok( msg.wParam == wch, bad wparam %lx/%x\n, msg.wParam, wch );
 +msg.message = 0xdeadbeef;
  ok( !PeekMessageW( msg, hwnd, 0, 0, PM_REMOVE ), got message %x\n, 
 msg.message );
  
  /* posted thread message */
  PostThreadMessageA( GetCurrentThreadId(), WM_CHAR, dbch[0], 0 );
 +msg.message = 0xdeadbeef;
  ok( !PeekMessageW( msg, hwnd, 0, 0, PM_REMOVE ), got message %x\n, 
 msg.message );
  PostMessageA( hwnd, WM_CHAR, dbch[1], 0 );
  ok( PeekMessageW( msg, hwnd, 0, 0, PM_REMOVE ), no message\n );
  ok( msg.message == WM_CHAR, unexpected message %x\n, msg.message );
  ok( msg.wParam == wch, bad wparam %lx/%x\n, msg.wParam, wch );
 +msg.message = 0xdeadbeef;
  ok( !PeekMessageW( msg, hwnd, 0, 0, PM_REMOVE ), got message %x\n, 
 msg.message );

I'm not sure I see the point of that change, since the message is not
tested when PeekMessage fails.

-- 
Alexandre Julliard
[EMAIL PROTECTED]




Re: user32: Make message test pass cleanly under XP SP2

2007-09-25 Thread Dmitry Timoshkov
Alexandre Julliard [EMAIL PROTECTED] wrote:

 Dmitry Timoshkov [EMAIL PROTECTED] writes:
 
  /* posted message */
  PostMessageA( hwnd, WM_CHAR, dbch[0], 0 );
 +msg.message = 0xdeadbeef;
  ok( !PeekMessageW( msg, hwnd, 0, 0, PM_REMOVE ), got message %x\n, 
 msg.message );
  PostMessageA( hwnd, WM_CHAR, dbch[1], 0 );
  ok( PeekMessageW( msg, hwnd, 0, 0, PM_REMOVE ), no message\n );
  ok( msg.message == WM_CHAR, unexpected message %x\n, msg.message );
  ok( msg.wParam == wch, bad wparam %lx/%x\n, msg.wParam, wch );
 +msg.message = 0xdeadbeef;
  ok( !PeekMessageW( msg, hwnd, 0, 0, PM_REMOVE ), got message %x\n, 
 msg.message );
  
  /* posted thread message */
  PostThreadMessageA( GetCurrentThreadId(), WM_CHAR, dbch[0], 0 );
 +msg.message = 0xdeadbeef;
  ok( !PeekMessageW( msg, hwnd, 0, 0, PM_REMOVE ), got message %x\n, 
 msg.message );
  PostMessageA( hwnd, WM_CHAR, dbch[1], 0 );
  ok( PeekMessageW( msg, hwnd, 0, 0, PM_REMOVE ), no message\n );
  ok( msg.message == WM_CHAR, unexpected message %x\n, msg.message );
  ok( msg.wParam == wch, bad wparam %lx/%x\n, msg.wParam, wch );
 +msg.message = 0xdeadbeef;
  ok( !PeekMessageW( msg, hwnd, 0, 0, PM_REMOVE ), got message %x\n, 
 msg.message );
 
 I'm not sure I see the point of that change, since the message is not
 tested when PeekMessage fails.

I added that changes because Microsoft compiler from latest Vista SDK
complains that variables might be used without being initialized.

-- 
Dmitry.




Re: [5/5] winex11: Use an offscreen redirected window for child OpenGL rendering

2007-09-25 Thread Chris Robinson
On Tuesday 25 September 2007 04:31:04 am Alexandre Julliard wrote:
 Chris Robinson [EMAIL PROTECTED] writes:
  +if(w  0  h  0) {
  +XFlush(gdi_display);
  +XCopyArea(gdi_display, physDev-gl_drawable, physDev-drawable,
  +  physDev-gc, 0, 0, w, h, physDev-dc_rect.left,
  +  physDev-dc_rect.top);

 Why do you need an XFlush here?

Given the nature of glFlush/glFinish, I think it would probably be correct 
behavior to make sure the X copy command is flushed by the time the GL 
functions finish, too. Why it ended up before the copy though, I don't know.

  +if(data-whole_window  vis-visualid ==
  XVisualIDFromVisual(visual)) +{
  +TRACE(Whole window available and visual match, rendering
  onscreen\n); +goto done;
  +}
  +
  +if(!composite_gl)
  +goto done;

 There's no sense in having a config option for this since the
 alternative doesn't work anyway, particularly since you removed the
 scissor support.

True. I guess I can use an option just for extra onscreen pixel formats being 
composited instead, in a seperate patch of course.

  +data-gl_drawable = XCreateWindow(gdi_display, root_window, -w,
  0, w, h, +  0, vis-depth,
  InputOutput, +  vis-visual,
  +  CWColormap |
  CWOverrideRedirect, +  attrib);

 The window needs to be created on the thread display, and as a child
 of the main window.

With the child being parented to the main window, a BadWindow error sometimes 
crops up on XDestroyWindow for the X11 child. I couldn't see why, but 
parenting it to the root_window works. Would that be due to using gdi_display 
for creating/destroying the child?

  +static void update_gl_drawable(struct x11drv_win_data *data)
  +{
  +unsigned int border, depth;
  +int x, y, w, h;
  +Window root_win;
  +
  +if(!data-gl_drawable)
  +return;
  +
  +wine_tsx11_lock();
  +XGetGeometry(gdi_display, data-gl_drawable, root_win, x, y,
  + (unsigned int*)w, (unsigned int*)h, border, depth);

 You must not use XGetGeometry, this incurs a server round-trip.

Is it safe to call XMoveResizeWindow even if the size didn't change, and have 
X make it a no-op (or at least be negligible for processing time)? Calling to 
resize the child window every time the hwnd simply moves (or whenever it 
thinks it resized/moved) can cause it to be done unnecessarilly often.




Re: pdh: add tests for XP variant of api call

2007-09-25 Thread Jeff Latimer
Hans Leidekker wrote:
 From this we should write tests to accept all values.  It would seem 
 that the wine dll still needs to implement the API accurately, so you 
 are saying, code the API correctly but make the tests generic?
 

 Quote from MSDN on PdhLookupPerfNameByIndex:

  PDH_INVALID_ARGUMENT
  A parameter is not valid or is incorrectly formatted. For example,
  on some releases you could receive this error if the specified size
  on input is greater than zero but less than the required size.
   
I am happy with that though the tests I added relate to the following 
paragraph where it says that XP requires the buffer parameter as well as 
the size at all times and testing shows that it returns 
PDH_INVALID_ARGUMENT.  It also returns PDH_INSUFFICIENT_BUFFER instead 
of PDH_MORE_DATA.
 So we should accept this return value too. Our implemention is fine
 as-is because it still passes the test.
   
I am not sure that I follow.  Each of the tests in the patch is there 
because they satisfied the returns from XP and failed on my platform.
 Note that there is another problem with the tests which is that
 performance counter names are localized but the tests assume that the
 current locale is English. I intend to fix this in my next batch of
 patches.
Sounds good.

BTW I can see that the tests could be merged into the existing tests so 
that the tests handle multiple situations.   It means that in some ways 
it means that conformance to particular release will not be specifically 
tested in wine and hence conformance will not be assured.  If that is 
the way ist done than thats ok. 

Jeff




Re: [5/5] winex11: Use an offscreen redirected window for child OpenGL rendering

2007-09-25 Thread Alexandre Julliard
Chris Robinson [EMAIL PROTECTED] writes:

 With the child being parented to the main window, a BadWindow error sometimes 
 crops up on XDestroyWindow for the X11 child. I couldn't see why, but 
 parenting it to the root_window works. Would that be due to using gdi_display 
 for creating/destroying the child?

Maybe, but in any case making it a child of the root window is wrong.

 Is it safe to call XMoveResizeWindow even if the size didn't change, and have 
 X make it a no-op (or at least be negligible for processing time)? Calling to 
 resize the child window every time the hwnd simply moves (or whenever it 
 thinks it resized/moved) can cause it to be done unnecessarilly often.

No, you have all the info you need in SetWindowPos, there's no reason
to guess.

-- 
Alexandre Julliard
[EMAIL PROTECTED]




Re: user32: Make message test pass cleanly under XP SP2

2007-09-25 Thread Alexandre Julliard
Dmitry Timoshkov [EMAIL PROTECTED] writes:

 I added that changes because Microsoft compiler from latest Vista SDK
 complains that variables might be used without being initialized.

It sounds like that compiler is on crack. I don't think we want to
sprinkle assignments all over the place just to work around that.

-- 
Alexandre Julliard
[EMAIL PROTECTED]




Re: pdh: add tests for XP variant of api call

2007-09-25 Thread Hans Leidekker
On Tuesday 25 September 2007 14:19:34 Jeff Latimer wrote:

 I am happy with that though the tests I added relate to the following
 paragraph where it says that XP requires the buffer parameter as well as
 the size at all times and testing shows that it returns
 PDH_INVALID_ARGUMENT.  It also returns PDH_INSUFFICIENT_BUFFER instead
 of PDH_MORE_DATA.

Then I suggest to remove tests with a NULL buffer parameter and
accept both PDH_INSUFFICIENT_BUFFER and PDH_MORE_DATA in tests where
the specified buffer size is too small.

 -Hans




Recent BiDi changes

2007-09-25 Thread Shachar Shemesh
Hi Maarten,

Can you, please, explain the advantage of creating our own
implementation of the BiDi algorithm over using existing
implementations? I know ICU sucks (especially as far as linkage is
concerned), but there are other implementations, major among which is
fribidi, which are free, are C based, and have a compatible license. Is
there any need to Wine to be aware of the inside working of the algorithm?

Also, so long as you are picking up the BiDi glove I dropped oh so many
years ago, it seems to me that the proper place to implement BiDi would
be in unscribe, where it is for Windows. The GDI implementation Wine has
is a hack that reached it's useful end the moment you realize that
DrawText needs its own implementation, independent of ExtTextOut (mostly
due to line breaking code).

Thanks,
Shachar




Re: Recent BiDi changes

2007-09-25 Thread Alexandre Julliard
Shachar Shemesh [EMAIL PROTECTED] writes:

 Hi Maarten,

 Can you, please, explain the advantage of creating our own
 implementation of the BiDi algorithm over using existing
 implementations? I know ICU sucks (especially as far as linkage is
 concerned), but there are other implementations, major among which is
 fribidi, which are free, are C based, and have a compatible license. Is
 there any need to Wine to be aware of the inside working of the algorithm?

The algorithm is pretty simple, and since we need to have the
character tables anyway there's no reason to add an external
dependency for this.

 Also, so long as you are picking up the BiDi glove I dropped oh so many
 years ago, it seems to me that the proper place to implement BiDi would
 be in unscribe, where it is for Windows. The GDI implementation Wine has
 is a hack that reached it's useful end the moment you realize that
 DrawText needs its own implementation, independent of ExtTextOut (mostly
 due to line breaking code).

Actually the proper place would be libwine along with the rest of the
Unicode support.

-- 
Alexandre Julliard
[EMAIL PROTECTED]




Re: Recent BiDi changes

2007-09-25 Thread Shachar Shemesh
Alexandre Julliard wrote:

 Actually the proper place would be libwine along with the rest of the
 Unicode support.
   
I've spent the past hour downloading 12% of the git repository, so I'm
unable to look at current Wine code for at least the next 24 hours :-(.
From memory, libwine contains mostly tables and stuff, not actual
algorithms. Wouldn't it be better to place the tables at libwine, but
the algorithm at uniscribe, if only to follow Window's design of things?

Also, I suspect it might be necessary, at some point in the extreme
distant future, to do some deviation from the Unicode algorithm. It's
pretty far away, as we're talking about nuances that are hard to pick if
you don't know your stuff, but there are places where Windows can be
said to be either implementing an old version of the standard, or
implementing its own idea altogether.

My original plan was to import the fribidi code into a subdirectory of
the wine tree, and make the necessary changes there.

On a related note - I haven't been able to get an answer to that one,
not even through experimentation. Does anyone know whether Windows'
Unicode is UTF-16 or UCS-2? Whether it's necessary to handle aggregates
is crucially important when reordering characters.

Shachar





Re: Recent BiDi changes

2007-09-25 Thread Shachar Shemesh
Alexandre Julliard wrote:

 Actually the proper place would be libwine along with the rest of the
 Unicode support.
   
I've spent the past hour downloading 12% of the git repository, so I'm
unable to look at current Wine code for at least the next 24 hours :-(.
From memory, libwine contains mostly tables and stuff, not actual
algorithms. Wouldn't it be better to place the tables at libwine, but
the algorithm at uniscribe, if only to follow Window's design of things?

Also, I suspect it might be necessary, at some point in the extreme
distant future, to do some deviation from the Unicode algorithm. It's
pretty far away, as we're talking about nuances that are hard to pick if
you don't know your stuff, but there are places where Windows can be
said to be either implementing an old version of the standard, or
implementing its own idea altogether.

My original plan was to import the fribidi code into a subdirectory of
the wine tree, and make the necessary changes there.

On a related note - I haven't been able to get an answer to that one,
not even through experimentation. Does anyone know whether Windows'
Unicode is UTF-16 or UCS-2? Whether it's necessary to handle aggregates
is crucially important when reordering characters.

Shachar





Re: Recent BiDi changes

2007-09-25 Thread Alexandre Julliard
Shachar Shemesh [EMAIL PROTECTED] writes:

 I've spent the past hour downloading 12% of the git repository, so I'm
 unable to look at current Wine code for at least the next 24 hours
 :-(.

You can always browse the code at http://source.winehq.org/git/wine.git

From memory, libwine contains mostly tables and stuff, not actual
 algorithms. Wouldn't it be better to place the tables at libwine, but
 the algorithm at uniscribe, if only to follow Window's design of things?

libwine certainly contains algorithms, but Uniscribe is a possibility
too, if it provides everything we need.

 Also, I suspect it might be necessary, at some point in the extreme
 distant future, to do some deviation from the Unicode algorithm. It's
 pretty far away, as we're talking about nuances that are hard to pick if
 you don't know your stuff, but there are places where Windows can be
 said to be either implementing an old version of the standard, or
 implementing its own idea altogether.

That's one more reason for having our own instead of using an external
library.

 My original plan was to import the fribidi code into a subdirectory of
 the wine tree, and make the necessary changes there.

I think Maarten's work shows that this is not necessary.

 On a related note - I haven't been able to get an answer to that one,
 not even through experimentation. Does anyone know whether Windows'
 Unicode is UTF-16 or UCS-2? Whether it's necessary to handle aggregates
 is crucially important when reordering characters.

Recent Windows versions do support surrogates.

-- 
Alexandre Julliard
[EMAIL PROTECTED]




Re: Recent BiDi changes

2007-09-25 Thread Maarten Lankhorst
Shachar Shemesh schreef:
 Alexandre Julliard wrote:
   
 Actually the proper place would be libwine along with the rest of the
 Unicode support.
   
 
 I've spent the past hour downloading 12% of the git repository, so I'm
 unable to look at current Wine code for at least the next 24 hours :-(.
 From memory, libwine contains mostly tables and stuff, not actual
 algorithms. Wouldn't it be better to place the tables at libwine, but
 the algorithm at uniscribe, if only to follow Window's design of things?

 Also, I suspect it might be necessary, at some point in the extreme
 distant future, to do some deviation from the Unicode algorithm. It's
 pretty far away, as we're talking about nuances that are hard to pick if
 you don't know your stuff, but there are places where Windows can be
 said to be either implementing an old version of the standard, or
 implementing its own idea altogether.

 My original plan was to import the fribidi code into a subdirectory of
 the wine tree, and make the necessary changes there.
   
Actually dlls/gdi32/bidi.c now already has a full implementation of the
bidirectional algorythm, you could easily take it out there and replace
it by a (reverse)memcpy depending on which forced direction, since the
force direction flag overrides all other flags that determine direction.
It shouldn't be much of an effort to implement whatever uniscribe needs
using bidi.c..

 On a related note - I haven't been able to get an answer to that one,
 not even through experimentation. Does anyone know whether Windows'
 Unicode is UTF-16 or UCS-2? Whether it's necessary to handle aggregates
 is crucially important when reordering characters.

 Shachar
   
I'm guessing utf-16, not 100% sure though.

Maarten





Wine GSoC 2007 project membership

2007-09-25 Thread Alexander Nicolaysen Sørnes
Hello all,

I received a passing evaluation in this year's GSoC, but I was not added to 
the Wine project hosting for 2007, does anyone here have the power to add me?



Alexander N. Sørnes




Re: comctl32: remove unneeded todo_wine, because test pass

2007-09-25 Thread James Hawkins
On 9/25/07, Christian Gmeiner [EMAIL PROTECTED] wrote:
 I am running make test an a fresh git fetch; git rebase origin and am
 getting this:

 ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p
 comctl32_test.exe.so monthcal.c  touch monthcal.ok
 err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp= lp=
 err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=0001 lp=
 err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp= lp=
 err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp= lp=
 err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp= lp=
 err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=0001 lp=
 monthcal.c:818: Test succeeded inside todo block: Expected 131073, got 131073
 make[2]: *** [monthcal.ok] Fehler 1

 This patch removes the todo_wine.. as it seems to work now. If this
 patch gets not accepted, please tell me why.


Becuase it doesn't pass for other people, particularly Julliard;
otherwise, it would have been fixed by now.

-- 
James Hawkins




Re: Wine GSoC 2007 project membership

2007-09-25 Thread Juan Lang
 I received a passing evaluation in this year's GSoC, but I was not added to
 the Wine project hosting for 2007, does anyone here have the power to add me?

If you mean on the wine wiki, you can edit that yourself, of course.
If you mean somewhere on Google's SoC site, you'll need to contact the
Google folks, e.g. Leslie.
--Juan




Re: Wine GSoC 2007 project membership

2007-09-25 Thread Alexander Nicolaysen Sørnes
On Wednesday 26 September 2007 00:36:20 Juan Lang wrote:
  I received a passing evaluation in this year's GSoC, but I was not added
  to the Wine project hosting for 2007, does anyone here have the power to
  add me?

 If you mean on the wine wiki, you can edit that yourself, of course.
 If you mean somewhere on Google's SoC site, you'll need to contact the
 Google folks, e.g. Leslie.
 --Juan

Tanks for the short reply, man.  I did contact Google, and they told me to 
contact our admin, whichh from the Google page appeared to be Dan Kegel, but 
he never replied to my mail.


Alexander N. Sørnes




Re: Wine GSoC 2007 project membership

2007-09-25 Thread Juan Lang
 I did contact Google, and they told me to contact our admin, whichh from the 
 Google
 page appeared to be Dan Kegel, but he never replied to my mail.

Ah, right.  He's probably the right person, and he reads this list, so
hopefully you've got his attention now ;)
--Juan




Re: mpr: Changes comparison of dwScope in WNetOpenEnum function

2007-09-25 Thread Juan Lang
 The following condition in _globalEnumeratorAdvance() looks incorrect:

 for (; enumerator-providerIndex  providerTable-numProviders 
  !(enumerator-dwScope  providerTable-table
  [enumerator-providerIndex].dwEnumScopes);
  enumerator-providerIndex++)

I agree, that's not correct.

 Other conditions and parameters look correctly. For example, function
 NPOpenEnum() expects a dwScope, containing RESOURCE_CONNECTED,
 RESOURCE_GLOBALNET or RESOURCE_CONTEXT.

Ah, you're right.  It's only where dwEnumScopes is used that it's
being used incorrectly.

Your patch should probably fix both of those, then (and please ignore
my earlier comment.)

Thanks,
--Juan




Re: comctl32: remove unneeded todo_wine, because test pass

2007-09-25 Thread Lei Zhang
On 9/25/07, James Hawkins [EMAIL PROTECTED] wrote:
 On 9/25/07, Christian Gmeiner [EMAIL PROTECTED] wrote:
  I am running make test an a fresh git fetch; git rebase origin and am
  getting this:
 
  ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p
  comctl32_test.exe.so monthcal.c  touch monthcal.ok
  err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp= lp=
  err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=0001 lp=
  err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp= lp=
  err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp= lp=
  err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp= lp=
  err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=0001 lp=
  monthcal.c:818: Test succeeded inside todo block: Expected 131073, got 
  131073
  make[2]: *** [monthcal.ok] Fehler 1
 
  This patch removes the todo_wine.. as it seems to work now. If this
  patch gets not accepted, please tell me why.
 

 Becuase it doesn't pass for other people, particularly Julliard;
 otherwise, it would have been fixed by now.

 --
 James Hawkins




The monthcal layout is definitely incorrect. See
http://bugs.winehq.org/attachment.cgi?id=4485 for an example.

Commit 7495d814954420c16e21de40c3031a9c95385f56
(gdi32: Using a bitmap font as the fallback sans serif is a very bad idea.)

change the fonts used for many people. This made the test pass for
some simply because they got lucky. I see this because the monthcal
test fails on my work machine but works on my home machine.

I can pick a new coordinate to fix this, but then the new hit test
will be just as brittle as the current one. Anyone have better ideas
on how to make these coordinate based tests more robust?




Re: comctl32: remove unneeded todo_wine, because test pass

2007-09-25 Thread Mikołaj Zalewski

 I can pick a new coordinate to fix this, but then the new hit test
 will be just as brittle as the current one. Anyone have better ideas
 on how to make these coordinate based tests more robust?
   
  For the toolbar tests I have been sending WM_SETFONT with 
GetStockObject(SYSTEM_FONT) . It seems to work fine. For the default 
font the results will vary depending on if corefonts are installed or not.

Mikolaj