Re: mpr: Changes comparison of dwScope in WNetOpenEnum function
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
