Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.
Hmm... It still fails today. I have a better idea to fix it, will send a patch tomorrow. Sorry for introducing the failures :(
Re: [PATCH 5/5] user32: Implement better stub of OpenInputDesktop.
Hi Vincent, Thanks a lot for the advice, I'll try that. On Thu, Oct 10, 2013 at 12:41 AM, Vincent Povirk madewokh...@gmail.com wrote: I don't think it's possible to properly implement SwitchDesktop in either the X11 or Mac driver. There's just nothing sensible for it to do. That's one reason that I didn't try to implement SwitchDesktop, I was not very sure about this, thanks for confirming. One possible strategy would be to implement SwitchDesktop in user32 and wineserver. Wineserver could logically track the input desktop, and OpenInputDesktop would return the correct desktop, but SwitchDesktop wouldn't really do anything. If in the future we decide there's something SwitchDesktop can do that makes sense, we can add a function for it to the user driver, and OpenInputDesktop probably won't need to change. I ever though about this, but gave up. After more thought, I agree that this is a better approach, thanks again! -- Regards, Qian Hong - http://www.codeweavers.com
Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.
Hello, On Thu, Oct 10, 2013 at 6:48 PM, Alexandre Julliard julli...@winehq.org wrote: Can you please fix the test failures introduced by your previous changes first? cf. https://test.winehq.org/data/tests/user32:winstation.html Sorry for introduced the failures, I'd like to investigate, however I can't reproduce the failures on my own Win7. I try to run winetest-latest.exe on the testbot, but it ran timeout (as expect), is there any way I can increase the timeout value from 120 to something like 1800? Thanks! -- Regards, Qian Hong - http://www.codeweavers.com
Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.
On Thu, Oct 10, 2013 at 8:42 PM, Qian Hong qh...@codeweavers.com wrote: Sorry for introduced the failures, I'd like to investigate, however I can't reproduce the failures on my own Win7. I try to run winetest-latest.exe on the testbot, but it ran timeout (as expect), is there any way I can increase the timeout value from 120 to something like 1800? Oh, forgot to say: the test failures are most likely caused by side effects of other tests, I can't reproduce it on our testbots if only winstation tests are executed, that is why I asked for increasing the timeout so I can run a full test of winetest-latest.exe -- Regards, Qian Hong - http://www.codeweavers.com
Re: [PATCH 5/5] user32: Implement better stub of OpenInputDesktop.
Hello, this patch is in pending status, is there any way I can improve it? IMO there is no way to 'correctly' implement OpenInputDesktop before implementing SwitchDesktop, as far as SwitchDesktop is a stub, it is safe to assume that OpenInputDesktop will always return either NULL or Winsta0/Default, that is what the patch does and what the tests in [PATCH 3/5] shows.. It is not trivial to implement SwitchDesktop, also I don't know any real world app needing SwitchDesktop except some virtual desktop manager, so I'm not sure it is worth to spend time on implementing SwitchDesktop. However, OpenInputDesktop is needed by multiple apps (TeamViewer, QQ International, Inspect tool from Windows Platform SDK as bug 12067), is it acceptable to submit such a 'better stub' to Wine and leaving SwitchDesktop as a stub? Any comment is great appreciated! On Tue, Oct 8, 2013 at 11:41 AM, Qian Hong qh...@codeweavers.com wrote: Fixed http://bugs.winehq.org/show_bug.cgi?id=12067 , let QQ users happy :) --- dlls/user32/tests/winstation.c | 22 -- dlls/user32/winstation.c | 22 +++--- 2 files changed, 19 insertions(+), 25 deletions(-) -- Regards, Qian Hong - http://www.codeweavers.com
Re: [PATCH try3] atl110: Added new DLL.
On Tue, Sep 3, 2013 at 7:27 PM, Qian Hong fract...@gmail.com wrote: Hi Jacek, we already have a debug channel atl100 for atl100.dll, but we currently use atl for both atl.dll and atl80.dll, do you think it is better to use atl for all, or one debug channel per each dll? Oh, I just found dlls/atl100/atl_ax.c and dlls/atl100/atl.c used different debug channel, is that expected? -- Regards, Qian Hong - http://www.winehq.org
Re: [PATCH try3] atl110: Added new DLL.
+WINE_DEFAULT_DEBUG_CHANNEL(atl); Hi Jacek, we already have a debug channel atl100 for atl100.dll, but we currently use atl for both atl.dll and atl80.dll, do you think it is better to use atl for all, or one debug channel per each dll?
Re: [PATCH try3] atl110: Added new DLL.
On Tue, Sep 3, 2013 at 7:42 PM, Jacek Caban ja...@codeweavers.com wrote: Not really, good catch. We should make them consistent. Honestly, I'm not sure which one is better. Both have their problems. Some functions are forwarded, others are not, so having one debug channel would be guarantee that we don't miss some calls while debugging a bug. However, some functions have the same names and are not forwarded, so one debug channel would be ambiguous. I'm open for opinions. How about something like this: atl80.c: -BOOL WINAPI AtlAxWinInit(void) +BOOL WINAPI ATL80_AtlAxWinInit(void) atl80.spec: -42 stdcall AtlAxWinInit() +42 stdcall AtlAxWinInit() ATL80_AtlAxWinInit So we can always use one debug channel for all atlXX dlls, at the same time different exported function with the same name will generate different trace log. -- Regards, Qian Hong - http://www.winehq.org
Re: imm32/tests: Fix a trailing '\n' in an ok() call.
-ok(ic != NULL, ImmLockIMC failed\n!); +ok(ic != NULL, ImmLockIMC failed!\n); Oh, good catch... Thanks! -- Regards, Qian Hong - http://www.winehq.org
Draft: improve IMC/IMCC related functions
Hello,
This is a follow up of
http://www.winehq.org/pipermail/wine-devel/2013-July/100459.html (
[PATCH] imm32: Fixed crashing in ImmGetIMCCSize. )
I believe the attached patchset is the correct fix for the Office
crashing bug, how ever, I'm looking for a more graceful way to improve
ImmCreateContext and other IMC functions, I appreciate to any feedback
on the patches especially Patch 6/6.
My tests show that Windows return a HGLOBAL hmem for ImmCreateIMCC()
as the returned HIMCC, so it is easy to re-implement ImmCreateIMCC in
a graceful way. However, Windows return a magic number for
ImmCreateContext, (for instance, have a look at 000B01D9 in the test
show in https://testbot.winehq.org/JobDetails.pl?Key=26619log_207=1#k207)
I have no idea how that magic number comes, while I understand there
is no need to re-implement ImmCreateContext in the same way as Windows
does, I'm still interesting in a more beautiful implementation like my
ImmCreateIMCC reached, get rid of casting InputContextData to HIMC if
possible. Thanks in advance for any suggestions!
If there is no better way, I'll send this series to wine-patches.
--
Regards,
Qian Hong
-
http://www.winehq.org
From 8ef24f0fc1c962aa69ac2a1baec197abe3523068 Mon Sep 17 00:00:00 2001
From: Qian Hong qh...@codeweavers.com
Date: Mon, 5 Aug 2013 23:17:38 +0800
Subject: [PATCH 1/6] imm32/tests: Added more IMCC lock count tests.
To: wine-patches wine-patc...@winehq.org
Reply-To: wine-devel wine-devel@winehq.org
Cc: Qian Hongqh...@codeweavers.com
---
dlls/imm32/tests/imm32.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/dlls/imm32/tests/imm32.c b/dlls/imm32/tests/imm32.c
index 26101a4..2cdc662 100644
--- a/dlls/imm32/tests/imm32.c
+++ b/dlls/imm32/tests/imm32.c
@@ -715,7 +715,8 @@ static void test_ImmGetIMCLockCount(void)
static void test_ImmGetIMCCLockCount(void)
{
HIMCC imcc;
-DWORD count, ret;
+DWORD count, g_count, ret, i;
+VOID *p;
imcc = ImmCreateIMCC(sizeof(CANDIDATEINFO));
count = ImmGetIMCCLockCount(imcc);
@@ -731,6 +732,28 @@ static void test_ImmGetIMCCLockCount(void)
ok(ret == FALSE, expect FALSE, ret %d\n, ret);
count = ImmGetIMCCLockCount(imcc);
ok(count == 0, expect 0, returned %d\n, count);
+
+p = ImmLockIMCC(imcc);
+todo_wine ok(GlobalHandle(p) == imcc, expect %p, returned %p\n, imcc,
GlobalHandle(p));
+
+for (i = 0; i GMEM_LOCKCOUNT * 2; i++)
+{
+ImmLockIMCC(imcc);
+count = ImmGetIMCCLockCount(imcc);
+g_count = GlobalFlags(imcc) GMEM_LOCKCOUNT;
+todo_wine ok(count == g_count, count %d, g_count %d\n, count,
g_count);
+}
+count = ImmGetIMCCLockCount(imcc);
+todo_wine ok(count == GMEM_LOCKCOUNT, expect GMEM_LOCKCOUNT, returned
%d\n, count);
+
+for (i = 0; i GMEM_LOCKCOUNT - 1; i++)
+GlobalUnlock(imcc);
+count = ImmGetIMCCLockCount(imcc);
+todo_wine ok(count == 1, expect 1, returned %d\n, count);
+GlobalUnlock(imcc);
+count = ImmGetIMCCLockCount(imcc);
+todo_wine ok(count == 0, expect 0, returned %d\n, count);
+
ImmDestroyIMCC(imcc);
}
--
1.7.9.5
From 45a80c8cd1d0cb2dfa3d5afaadbfd22f41ee5cef Mon Sep 17 00:00:00 2001
From: Qian Hong qh...@codeweavers.com
Date: Mon, 5 Aug 2013 23:56:37 +0800
Subject: [PATCH 2/6] imm32/tests: Added tests for ImmDestroyIMCC.
To: wine-patches wine-patc...@winehq.org
Reply-To: wine-devel wine-devel@winehq.org
Cc: Qian Hongqh...@codeweavers.com
---
dlls/imm32/tests/imm32.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/dlls/imm32/tests/imm32.c b/dlls/imm32/tests/imm32.c
index 2cdc662..6965d5f 100644
--- a/dlls/imm32/tests/imm32.c
+++ b/dlls/imm32/tests/imm32.c
@@ -757,6 +757,38 @@ static void test_ImmGetIMCCLockCount(void)
ImmDestroyIMCC(imcc);
}
+static void test_ImmDestroyIMCC(void)
+{
+HIMCC imcc;
+DWORD ret, count, size;
+VOID *p;
+
+imcc = ImmCreateIMCC(sizeof(CANDIDATEINFO));
+count = ImmGetIMCCLockCount(imcc);
+ok(count == 0, expect 0, returned %d\n, count);
+p = ImmLockIMCC(imcc);
+ok(p != NULL, ImmLockIMCC failed!\n);
+count = ImmGetIMCCLockCount(imcc);
+ok(count == 1, expect 1, returned %d\n, count);
+size = ImmGetIMCCSize(imcc);
+ok(size == sizeof(CANDIDATEINFO), expect %d, returned %d\n,
sizeof(CANDIDATEINFO), size);
+p = ImmDestroyIMCC(imcc);
+ok(p == NULL, Destroy an locked IMCC should success!\n);
+p = ImmLockIMCC(imcc);
+todo_wine ok(p == NULL, Lock a destroyed IMCC should fail!\n);
+ret = ImmUnlockIMCC(imcc);
+todo_wine ok(ret == FALSE, Unlock a destroyed IMCC should return
FALSE!\n);
+count = ImmGetIMCCLockCount(imcc);
+todo_wine ok(count == 0, Get lock count of a destroyed IMCC should return
0!\n);
+size = ImmGetIMCCSize(imcc);
+todo_wine ok(size == 0, Get size of a destroyed IMCC should return 0!\n);
+SetLastError(0xdeadbeef);
+p = ImmDestroyIMCC
Re: [PATCH] imm32: Fixed crashing in ImmGetIMCCSize.
Forgot to say, as described in the last post, this patch doesn't kill the culprit, please reject the patch, thanks.
Re: [PATCH] imm32: Fixed crashing in ImmGetIMCCSize.
Hello Nikolay, On Wed, Jul 10, 2013 at 1:06 AM, Nikolay Sivov bungleh...@gmail.com wrote: This could be some a different bug, and putting exception handler around it is not necessary a right solution. Good catch, I think you are right. I found ImmLockIMC()/ImmUnLockIMC()/etc are called even after ImmDestroyContext(), the latter frees the input method context if the call successes, but the former try to access the IMC. I have a test case show that in some case native ImmDestroyContext() fails but builtin ImmDestroyContext() success: https://testbot.winehq.org/JobDetails.pl?Key=26499log_206=1#k206 That is why Office die on Wine but live on Windows, ImmDestroyContext() fails so following ImmLockIMC()/ImmUnLockIMC()/ImmGetIMCCSize() are safe, but on Wine ImmDestroyContext() success and free the memory of the IMC, and... Boom! --- snip --- Call imm32.ImmDestroyContext(08a29b28) ret=3927e447 Ret imm32.ImmDestroyContext() retval=0001 ret=3927e447 /* success, free the IMC (hIMC == 0x08a29b28) */ Call imm32.ImmLockIMC(08a29b28) ret=09ea2c54 /* would die sooner or later ... */ Ret imm32.ImmLockIMC() retval=08a29b2c ret=09ea2c54 ... Call imm32.ImmGetIMCCSize(0008) ret=09ea3545 /* 0x0008 comes from hIMC-IMC.hPrivate, unfortunately hIMC is freed... */ --- snip --- I need more tests to figure out what is the necessary and sufficient conditions to make ImmDestroyContext fails. Thanks for the help! -- Regards, Qian Hong - http://www.winehq.org
Re: Need help with debugging a directx9 game crashing
Hi Ken, On Thu, Jul 25, 2013 at 2:33 AM, Ken Thomases k...@codeweavers.com wrote: Hmm. You may need to mark the dummy array as volatile to prevent it from being optimized away. Worth trying. You might also increase the size of the array. You are right, thanks! Increasing the size of the array helps, the minimum working size I found is 588, I've attach the patch and the backtrace to Bug 34125. In my hack, I let: +char dummy[588]; +memset(dummy, 0x55, sizeof(dummy)); +dummy[4] = 0x88; +dummy[5] = 0x77; +dummy[6] = 0x66; +dummy[7] = 0x55; /* why 584 doesn't work? */ And I get a crashing like: Unhandled exception: page fault on read access to 0x55667788 in 32-bit code I've also hack wined3d/directx.c in a similar way, the minimum size is 592: +char dummy[592]; +memset(dummy, 0xee, sizeof(dummy)); +dummy[8] = 0xdd; +dummy[9] = 0xcc; +dummy[10] = 0xbb; +dummy[11] = 0xaa; /* why 584 and 588 doesn't work ? */ The crashing is like: Unhandled exception: page fault on read access to 0xaabbccdd in 32-bit code When combining the d3d9 hack and the wined3d hack, the behavior is the same to d3d9 hack only. I'll see how far I can get from here, also I'm open to any suggestion and appreciate to any help! Thanks again. -- Regards, Qian Hong - http://www.winehq.org
Re: Need help with debugging a directx9 game crashing
On Fri, Jul 26, 2013 at 2:52 AM, Ken Thomases k...@codeweavers.com wrote: I think your Valgrind results are telling us that there's a bug in the game where it's using an uninitialized stack variable. There's still a chance that it's something in Wine that's using the uninitialized variable and passing a garbage value to the game, causing it to crash. I'm not sure if Valgrind would attribute that to Wine for copying the uninitialized variable's value or to the game for using what Wine gave it. I _think_ Valgrind would blame Wine in that case. Since it's blaming the game, I lean toward the bug being in the game. There may not be any solution other than reporting the issue to the game developer. Hmm, thanks a lot for the great analysis :) I've just sent a message to someone in the game company, not sure if they care :) -- Regards, Qian Hong - http://www.winehq.org
Re: Need help with debugging a directx9 game crashing
Hello, Thanks everyone's help, sorry for delay, I was blocked by something else. I've created http://bugs.winehq.org/show_bug.cgi?id=34125 to track down this bug. On Fri, Jul 19, 2013 at 10:06 PM, Henri Verbeet hverb...@gmail.com wrote: Well, it sounds a bit like some form of memory corruption. Sometimes WINEDEBUG=warn+heap helps with tracking those down. Thanks Henri, warn+heap doesn't show warning, I've attached to Bug 34125, it shows some HeapSetInformation calls, I don't know if it harms. Also, I don't suppose the d3d9 object was already destroyed earlier? By reading +d3d9 log, I believe the d3d9 object was not destroyed earlier. -- Regards, Qian Hong - http://www.winehq.org
Re: Need help with debugging a directx9 game crashing
On Sat, Jul 20, 2013 at 2:21 AM, Marcus Meissner mar...@jet.franken.de wrote: Or timing ... Also can you print out refcount there to see if the refcounting is good? Thanks Marcus, yes, I tried replace the TRACE to printf, to my surprise, the magic disappear. In other words, if I replace the TRACE in d3d9_AddRef to FIXME, the crashing would be worked around. However, replacing the TRACE to printf doesn't help. I'm not sure why. by replacing TRACE to printf, I can reproduce the crashing while have a look at the refcounting, it seems good to me. -- Regards, Qian Hong - http://www.winehq.org
Re: Need help with debugging a directx9 game crashing
Hi Ken, On Sun, Jul 21, 2013 at 2:39 PM, Ken Thomases k...@codeweavers.com wrote: Instead of enabling the trace, try replacing it with something like: char dummy[256]; memset(dummy, 0x55, sizeof(dummy)); I bet the crash will change from a read access to 0x0001 to 0x. Thanks for the advice, it sounds cool and I learned new things, thank you. However, it doesn't help in this case, I didn't found any change after the dummy hack. The question is: is it a bug in the game or a bug in Wine where Wine is returning a garbage pointer to the game and the game is innocently dereferencing it? For that, you'd have to trace the execution from the call to d3d9_AddRef() to the crashing point to see what else is called and whether it uses an uninitialized value. Of course, another approach would be to run under Valgrind, if you can get it to work. I've run it under Valgrind, there are many outputs, I'm not sure which part of valgrind output is important and which part could be ignore, the output is attached to bug 34125 as well. Quite a lot of output are related to native msvcr80 installed by the app, I tried force using buitlin msvcr80, unfortunately the game doesn't start at all with buitlin msvcr80. I've send one test case (Patch 97446), but there is still other msvcrt bugs after that issue. By the way, the game ship with many native d3dx9_??, and with buitin d3dx9_?? it doesn't start as well. -- Regards, Qian Hong - http://www.winehq.org
Need help with debugging a directx9 game crashing
Hello,
I was debugging on a popular game [1] [2] (9 GB), it crashes on start.
+relay,+seh,+tid log show that there are some calls to
wined3d.wined3d_mutex_lock / wined3d.wined3d_buffer_map /
wined3d.wined3d_mutex_unlock before crashing, so I turn on +d3d9 trace
to get a new log in details.
To my surprise, the game doesn't crash anymore with +d3d9 trace!
After a serials of bisect, I found d3d9_AddRef is the key function
call related to the crashing. If I remove the TRACE statement in line
71, the game will crash with +d3d9 as well; if I upgrade the TRACE in
71 to FIXME, the game will not crash even without +d3d9.
66 static ULONG WINAPI d3d9_AddRef(IDirect3D9Ex *iface)
67 {
68 struct d3d9 *d3d9 = impl_from_IDirect3D9Ex(iface);
69 ULONG refcount = InterlockedIncrement(d3d9-refcount);
70
71 TRACE(%p increasing refcount to %u.\n, iface, refcount);
72
73 return refcount;
74 }
Further tests show that the simplest hack to avoid crashing is
replacing line 71 to:
FIXME(anything %x\n, 0xdeadbeef);
I have no idea what the real fix is, any suggestion what is the next
step to debug?
Thanks in advance!
Environment:
Wine 1.6-rc5
Ubuntu 12.04.2 LTS
gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
The installer ship with native d3dx9_40.dll
Backtrace on crash:
Wine-dbgc
Unhandled exception: page fault on read access to 0x0001 in 32-bit
code (0x0649e6e9).
Register dump:
CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b
EIP:0649e6e9 ESP:0033cc60 EBP: EFLAGS:00210206( R- -- I - -P- )
EAX:0001 EBX:19b871e0 ECX: EDX:
ESI:23f420b0 EDI:23f4f20c
Stack dump:
0x0033cc60: 80004005 19c0e0c0 19b871e0
0x0033cc70: 23f420b0 23f4f1f0 19b871e0
0x0033cc80: 0018 0040 001c
0x0033cc90: 0a9101df 0020 0034 7bc34159
0x0033cca0: 00110064 0033ccd8 7bc34d2d
0x0033ccb0: 000c 0010 0001
Backtrace:
=0 0x0649e6e9 in kg3dengine (+0x16e6e9) (0x)
0x0649e6e9: movl 0x0(%eax),%ecx
[1] http://jx3.xoyo.com/download
[2]
http://jx3.client.cdn.kingsoft.com/JXOnline3-v3.0.4.4980/JXOnline3-v3.0.4.4980.rar
--
Regards,
Qian Hong
-
http://www.winehq.org
Re: [PATCH 1/3] user32/tests: Sleep enough time to make sure all input message have been processed.
On Mon, Jul 15, 2013 at 7:02 PM, Alexandre Julliard julli...@winehq.org wrote: This looks like a better approach, yes Sorry, this approach doesn't work as I expected, further investigation show that posted messages would be processed before input messages, msdn confirms it: --- quote --- If no filter is specified, messages are processed in the following order: Sent messages Posted messages Input (hardware) messages and system internal events Sent messages (again) WM_PAINT messages WM_TIMER messages --- quote --- msdn also said: To retrieve input messages before posted messages, use the wMsgFilterMin and wMsgFilterMaxparameters. However, even we can change the filter in our test, native Popup WndProc still receive posted messages before input message because it has its own message loop and we can't (and of cause we shouldn't) change it. This situation run out of my head, I can't find any easy way to fix it, I doubt if there is any way better than the original patch (patch 97161, pending). I'm open to any suggestion, thanks! If no better solution I hope patch 97161 is acceptable. -- Regards, Qian Hong - http://www.codeweavers.com
Re: [PATCH 1/3] user32/tests: Sleep enough time to make sure all input message have been processed.
On Fri, Jul 12, 2013 at 7:11 PM, Qian Hong qh...@codeweavers.com wrote:
do {
sleeping;
} while (sent_msg match received_msg or slept too long)
typo, should be:
while (sent_msg does not match received_msg haven't sleep too long)
--
Regards,
Qian Hong
-
http://www.codeweavers.com
Re: po: update Simplified Chinese translation
#: winerror.mc:3016 -#, fuzzy msgid Unknown interface.\n -msgstr 不明来源。\n +msgstr 未知界面。\n Please keep persistent for the translation of 'interface'. Here 'Unknown interface.' is used with RPC_S_UNKNOWN_IF, should be translate to '接口' as well as other place. #: winecfg.rc:260 msgid Voice output device: -msgstr +msgstr 语言输出设备： #: winecfg.rc:261 msgid Input device: @@ -12313,7 +12281,7 @@ msgstr 输入设备： #: winecfg.rc:262 msgid Voice input device: -msgstr +msgstr 语音输入设备： Please keep persistent for the translation of 'voice', it seems like a typo here, one translated to 语言 while the other translated to '语音'. #: winerror.mc:186 msgid Sharing violation.\n -msgstr +msgstr 非法共享。\n #: winerror.mc:191 -#, fuzzy msgid Lock violation.\n -msgstr 位置。\n +msgstr 非法锁定。\n #: winerror.mc:696 -#, fuzzy msgid Cancel violation.\n -msgstr 信息。\n +msgstr 非法取消。\n The above three reference to: ERROR_SHARING_VIOLATION （共享冲突？） ERROR_LOCK_VIOLATION （锁冲突？） ERROR_CANCEL_VIOLATION （？） http://support.microsoft.com/kb/316609/en-us http://support.microsoft.com/kb/2698155/en-us http://support.microsoft.com/kb/155011/en-us I'm not sure your translation is correct, they are tricky to translate, for ERROR_CANCEL_VIOLATION, even the original English version is hard to understand :( maybe keep the English version is not a bad idea if there is no better alternative so far. Thanks for the work! On Fri, Jul 12, 2013 at 8:09 PM, Jactry Zeng jactr...@gmail.com wrote: -- Regards, Qian Hong - http://www.winehq.org
Re: po: update Simplified Chinese translation
Thanks Francois. On Fri, Jul 12, 2013 at 10:41 PM, Francois Gouget fgou...@free.fr wrote: | Colon | * Software localization: Use English colon (:) in Software |localization. A single byte space should be left between the |English colon and the subsequent characters (Chinese full-width |punctuation marks are excluded). For documentation they say to use a double byte colon. So it seems like our PO files should actually be using single-byte colons everywhere. Does this make sense? I'm fine with replacing existent double byte colon to single byte one in the Simplified Chinese translation of Wine UI, CC'ed previous Wine Simplified Chinese major translator. If no opposition I would suggest to follow the Microsoft's Simplified Chinese Style Guide. -- Regards, Qian Hong - http://www.winehq.org
Re: [PATCH 1/3] user32/tests: Sleep enough time to make sure all input message have been processed.
On Fri, Jul 12, 2013 at 3:07 AM, Alexandre Julliard julli...@winehq.org wrote:
Adding sleeps to work around timing issues is usually suspicious,
Hello, how about this one?
--
Regards,
Qian Hong
-
http://www.codeweavers.com
diff --git a/dlls/user32/tests/menu.c b/dlls/user32/tests/menu.c
index 3e4cf93..fab7539 100644
--- a/dlls/user32/tests/menu.c
+++ b/dlls/user32/tests/menu.c
@@ -120,8 +120,11 @@ typedef struct
static BOOL bMenuVisible;
static INT popmenu;
static BOOL got_input;
+static BOOL got_last_input;
static HMENU hMenus[4];
+#define WM_LAST_INPUT (WM_USER + 1)
+
#define MOD_SIZE 10
#define MOD_NRMENUS 8
@@ -2113,6 +2116,7 @@ static DWORD WINAPI test_menu_input_thread(LPVOID
lpParameter)
int ret = TRUE, elapsed = 0;
got_input = i menu_tests[i-1].bMenuVisible;
+ got_last_input = FALSE;
if (menu_tests[i].type == INPUT_KEYBOARD)
for (j = 0; menu_tests[i].wVk[j] != 0; j++)
@@ -2121,19 +2125,19 @@ static DWORD WINAPI test_menu_input_thread(LPVOID
lpParameter)
for (j = 0; menu_tests[i].menu_item_pairs[j].uMenu != 0; j++)
if (!(ret = click_menu(hWnd,
menu_tests[i].menu_item_pairs[j]))) break;
+ PostMessage( hWnd, WM_LAST_INPUT, 0, 0);
if (!ret)
{
skip( test %u: failed to send input\n, i );
PostMessage( hWnd, WM_CANCELMODE, 0, 0 );
return 0;
}
-while (menu_tests[i].bMenuVisible != bMenuVisible)
-{
+do {
if (elapsed 200)
break;
elapsed += 20;
Sleep(20);
-}
+} while (!got_last_input);
if (!got_input)
{
@@ -2166,6 +2170,9 @@ static LRESULT CALLBACK WndProc(HWND hWnd, UINT msg,
WPARAM wParam,
case WM_EXITMENULOOP:
case WM_MENUSELECT:
break;
+ case WM_LAST_INPUT:
+ got_last_input = TRUE;
+ break;
case WM_KEYDOWN:
case WM_SYSKEYDOWN:
Re: [PATCH 1/3] user32/tests: Sleep enough time to make sure all input message have been processed.
Hello, This patch is marked as pending, is there anything I can improve? Did the test results in [1] and [2] help? Thanks for any feedback! [1] https://testbot.winehq.org/JobDetails.pl?Key=26191 [2] https://testbot.winehq.org/JobDetails.pl?Key=26190 On Wed, Jul 3, 2013 at 2:45 AM, Qian Hong qh...@codeweavers.com wrote: Hello, Current menu test code may hide some failure tests [1], with the attached patch, all failure tests could be detected [2]. [1] https://testbot.winehq.org/JobDetails.pl?Key=26191 [2] https://testbot.winehq.org/JobDetails.pl?Key=26190 --- dlls/user32/tests/menu.c |1 + 1 file changed, 1 insertion(+) -- Regards, Qian Hong - http://www.codeweavers.com
Re: [PATCH] imm32: Fixed crashing in ImmGetIMCCSize.
Hi Nikolay, Thanks for comments! On Tue, Jul 9, 2013 at 9:01 PM, Nikolay Sivov bungleh...@gmail.com wrote: Do you really need this for Office 2010 or null check is enough? If it's passing 0 handle here that's what you should check imho. If HIMCC is really a handle and not a struct pointer like in wine, that's not how a handle validity check will look like. null check is not enough, see the below quoted log: --- snip --- 0029:Call imm32.ImmGetIMCCSize(bf9c73e5) ret=0d6d3545 --- snip --- Another example: --- snip --- 0029:Call imm32.ImmGetIMCCSize(0190) ret=0a193545 --- snip --- Could you provide more details for how to check the validity of the handle in the right way? Thanks a lot! -- Regards, Qian Hong - http://www.winehq.org
Re: po: Update Simplified Chinese translation. (newer)
Hi Andrew, While discussing the translation of 'Voice output device' and 'Voice input device' in winecfg, Jactry and I have no idea what does 'voice' mean here. Voice could be translated to both '声音‘ and '语音' in Chinese, the former means all kinds of sound, the latter means human voice only, which one is more accurate? I know you've subscribed wine-devel, I CC'ed you because you are the original contributor to the 'voice input device' related code. Thanks a lot! On Fri, Jul 5, 2013 at 9:53 PM, Jactry Zeng jactr...@gmail.com wrote: Please ignore the first patch, I modify some in this one. Thanks advice from Qian Hong. -- Regards, Qian Hong - http://www.winehq.org
Re: po: Update Simplified Chinese translation. (newer)
On Fri, Jul 5, 2013 at 11:49 PM, Andrew Eikum aei...@codeweavers.com wrote: It comes basically from the ERole enumeration in MMDevAPI: http://msdn.microsoft.com/en-us/library/windows/desktop/dd370842%28v=vs.85%29.aspx The Input device maps to eConsole (and eMultimedia, which is identical to eConsole in modern Windows). The Voice input device maps to eCommunications. So, human voice is the intended meaning. Hope this clears it up! Ah thanks, great info! This is exactly what we need :) -- Regards, Qian Hong - http://www.winehq.org
Re: [PATCH 2/3] user32/tests: Added tests for non-existent accelerator key.
Hello, On Wed, Jul 3, 2013 at 2:41 AM, Qian Hong qh...@codeweavers.com wrote: Current menu test code may hide some failure tests [1], with the attached patch, all failure tests could be detected [2]. [1] https://testbot.winehq.org/JobDetails.pl?Key=26191 [2] https://testbot.winehq.org/JobDetails.pl?Key=26190 Please ignore the above comments, they should be in [Patch 1/3], sorry for the mistake. They attached patch itself is OK. Thanks. -- Regards, Qian Hong - http://www.codeweavers.com
Re: [PATCH 3/3] user32: Deactivate popup menu if accelerator key not found when tracking top level menu.
Update: The commit message is a bit misleading, should be 'user32: Deactivate menu if accelerator key not found when tracking top level menu.', removed the word 'popup'. Sorry for the trouble. On Wed, Jul 3, 2013 at 2:45 AM, Qian Hong qh...@codeweavers.com wrote: --- dlls/user32/menu.c |6 +- dlls/user32/tests/menu.c |6 +++--- 2 files changed, 8 insertions(+), 4 deletions(-) -- Regards, Qian Hong - http://www.codeweavers.com
Re: Need help with a rsaenh bug
Hi Daniel, On Fri, Jun 28, 2013 at 3:43 AM, Daniel Jeliński djelins...@gmail.com wrote: It is definitely valid to call CryptDecrypt multiple times with the same key. Calls with Final = FALSE change the internal state of the key, calls with Final = TRUE restore the initial state. Subsequent calls with Final = TRUE should return the same result. Your testcase fails because CryptDecrypt changes the value of dwLen, which you do not restore before calling the function again. Thanks a lot of the hint, with your help I finally resolve it! I've improved my test and submit two rsaenh patches, would you mind help to review them? Thanks again! -- Regards, Qian Hong - http://www.winehq.org
Re: Need help with a rsaenh bug
Hi Daniel, On Fri, Jun 28, 2013 at 4:47 PM, Daniel Jeliński djelins...@gmail.com wrote: I'm not convinced that a failed call to CryptDecrypt actually resets the key state. It's also possible that CryptDecrypt returns FALSE before even trying to decrypt if data length is invalid. To check it, you would need to change the key state by (successfully) calling CryptDecrypt with Final=FALSE before your test. Could you add such test? Thanks for the important hints! I'll try to improve the test case. -- Regards, Qian Hong - http://www.winehq.org
Re: Need help with a rsaenh bug
Hi Daniel, new patches sent with improving from your hints, would you mind have a look? Thanks in advance!
Re: Need help with a rsaenh bug
On Sat, Jun 29, 2013 at 12:34 AM, Juan Lang juan.l...@gmail.com wrote: Ah. Thanks for following the existing style then :-/ No, don't bother changing the existing code. I leave it up to you whether to follow my suggestion or ignore it, either is fine in this case. Patch sent, thanks Juan Lang and Daniel Jeliński for so many helps! -- Regards, Qian Hong - http://www.winehq.org
Need help with a rsaenh bug
Hello, I was investigating Bug 33898 [1] hardly and get a partial result, I have a special test case demonstrate the behavior of Aliwangwang [2], however, I failed to expand the special case to a common test case. My attempting is shown in [3]. The hack in [3] works for Aliwangwang, but the test case in [3] doesn't fully pass on Windows as I expected [4]. I'm not sure if there is an APP bug rather than Wine bug here, is it valid to call multiple CryptDecrypt with only one CryptDeriveKey called? If true, is it correct to assume the second CryptDecrypt call should behavior identical as the first one? If there is a Wine bug here, what is the right way to write a common test case for it? Any hints on this bug is great appreciated! Thanks very much! [1] http://bugs.winehq.org/show_bug.cgi?id=33898 [2] http://bugs.winehq.org/attachment.cgi?id=44996 [3] http://bugs.winehq.org/attachment.cgi?id=44997action=diff [4] https://testbot.winehq.org/JobDetails.pl?Key=26138 -- Regards, Qian Hong - http://www.winehq.org
Re: riched20: ITextDocument implementation
Hi, Welcome again :) On Wed, Jun 26, 2013 at 3:11 PM, Tiger Soldier tigerso...@gmail.com wrote: This is my first time to develop WINE. Any comments/suggestions? [1] http://bugs.winehq.org/show_bug.cgi?id=17042 Improving Rich Edit is great appreciated! Interesting, one of GSoC2013 students Jactry Zeng is planning on implementing ITextDocument as well [1] [2]. Maybe it is a good idea to work with Jactry together, if that doesn't violate GSoC rules - actually I don't know, hopefully Austin English or other GSoC mentor/manager could comment on this. If you are interesting in Rich Edit, there are a lot of bugs to be fixed :) [3] Some of them may be good for beginner, for example this one with a test case [4], or maybe this one [5] which has a basic diagnosis. dlls/riched20/tests/ contains some example to show how Rich Edit api works, play with Wine's buitin wordpad maybe a good idea as well. Before you implementing something or debugging something, there is no harm to learn as more example as you can from website like msdn or codeproject. Be careful on copyright issues: never disassembling or tracing Windows binary. For those things without public document, the only way I know is guess and test :) (Since I know you personally, I believe you are good at this kind of fun :p ) Once you decided to debug on an app, WINEDEBUG=+tid,+richedit may be useful for you, also you can have a look at other debug channel [6]. I hope this helps, feel free to ask in wine-devel if you have further questions. My experience on Wine is limited, so my suggestions maybe not work, maybe not the best, hopefully other developers with more experience could help you when you get in trouble :) [1] http://www.google-melange.com/gsoc/project/google/gsoc2013/jactry/12001 [2] http://wine.1045685.n5.nabble.com/Application-for-GSoC-2013-improve-Richedit-td5752352.html [3] http://bugs.winehq.org/buglist.cgi?product=Winecomponent=richeditresolution=---list_id=113096 [4] http://bugs.winehq.org/show_bug.cgi?id=33191#c2 [5] http://bugs.winehq.org/show_bug.cgi?id=29769#c11 [6] http://wiki.winehq.org/DebugChannels -- Regards, Qian Hong - http://www.winehq.org
Re: po: Update Simplified Chinese translation (resend)
On Sat, Jun 22, 2013 at 6:43 AM, Hin-Tak Leung hintak_le...@yahoo.co.uk wrote: @@ -9838,19 +9856,19 @@ 句柄 sounds a bit funny. 句柄 is a common usage in Simplified Chinese, I agree it isn't perfect, but it has been use for long time, any better suggestions? @@ -9870,7 +9888,7 @@ 列表中没有内容。\n - probably should use 条目 for uniformity? Both is ok to me, while 条目 is better, good catch, thanks. @@ -9905,145 +9926,119 @@ 活跃连接 - sounds a bit funny. 接口统计 - 界面 is probably better? 接口 is a common usage in Simplified Chinese, there is few people use 界面 here. 未知协议 主动打开连接数 @@ -10404,20 +10399,20 @@ a few 接口 - I prefer the older 界面, actually... Well, I prefer 接口... @@ -10839,41 +10834,45 @@ 错误：键名无效\n @@ -11402,7 +11403,7 @@ -msgstr 指定优先权(P) +msgstr 指定优先级(P) - prefer old Sounds like 优先级 is more common in Simplified Chinese, but I don't have strong preference here. @@ -11418,7 +11419,7 @@ -msgstr 亲和度指定(A)... +msgstr 关联 CPU(A)... - I think the old version was correct, the new wrong. I think 关联 is more common in Simplified Chinese. http://msdn.microsoft.com/zh-cn/library/vstudio/system.diagnostics.processthread.processoraffinity.aspx http://www.ibm.com/developerworks/cn/aix/library/au-processinfinity.html http://msdn.microsoft.com/zh-cn/library/windows/hardware/gg463378.aspx @@ -11510,13 +11511,13 @@ -msgstr 处理器亲和度 +msgstr 处理器关联 - again -msgstr 处理器亲和度决定了各进程允许运行在哪些 CPU 上。 +msgstr 处理器关联决定了各进程允许运行在哪些 CPU 上。 @@ -11653,7 +11654,7 @@ -msgstr 选择任务管理器中“进程”标签页显示哪些列。 +msgstr 选择任务管理器中进程标签页显示哪些列。 - 列 is row, you want column! Interesting... I didn't known 行 and 列 has opposite meaning in Traditional Chinese and Simplified Chinese... http://www.zhihu.com/question/21143622 So translate to 列 here in Simplified Chinese is right. Thanks for point out this as well, learned new things :) @@ -11945,27 +11946,27 @@ -msgstr +msgstr CPU 时间 --- you want something more precise to mean time *period*. I think CPU 时间 is right here, do you have better suggestion? @@ -11973,36 +11974,35 @@ -msgstr +msgstr 用户对象 - sounds wrong -msgstr +msgstr 会话 ID - also 会话 ID is a common usage in Simplified Chinese. @@ -11973,36 +11974,35 @@ -msgstr 向下翻页 +msgstr 已分页池 ... paged shouldn't be translated as 分页. I think it is a common usage in Simplified Chinese. @@ -12027,44 +12029,48 @@ -msgstr +msgstr 没有响应 @@ -12081,7 +12087,7 @@ msgid -你想把这项卸载命令从注册表中删除吗？ +您想把这项卸载命令从注册表中删除吗？ - probably should use 条目. 条目 is better, as the previous one, thanks, good catch. @@ -12137,6 +12143,9 @@ ...更高版本。 - later version, not higher version. Both is OK to me, maybe 更新 is better. Thanks for the thought! -- Regards, Qian Hong - http://www.winehq.org
Re: po: Update Simplified Chinese translation (resend)
Hi Caibin, Welcome to Wine! Thanks for the great work, patch looks perfect to me. It's a bit pity that Julliard just finishing today's patch committing several minutes ago, hopefully this patch would be committed next week, if we have rc4 :) Cheers. On Sat, Jun 22, 2013 at 12:36 AM, Tiger Soldier tigerso...@gmail.com wrote: - Used real name in commit message - Superseded patch 96985 --- po/zh_CN.po | 373 +++- 1 file changed, 190 insertions(+), 183 deletions(-) -- Regards, Qian Hong - http://www.winehq.org
Re: [1/2] explorer: Initial implementation of desktop launchers.
Hello Hans,
On Tue, May 28, 2013 at 6:42 PM, Hans Leidekker h...@codeweavers.com wrote:
+hr = SHGetKnownFolderPath( FOLDERID_Desktop, 0, NULL, desktop_folder );
+if (FAILED( hr ))
+{
+WINE_ERR(Could not get user desktop folder\n);
+return;
+}
+hr = SHGetKnownFolderPath( FOLDERID_PublicDesktop, 0, NULL,
desktop_folder_public );
+if (FAILED( hr ))
+{
+WINE_ERR(Could not get public desktop folder\n);
+CoTaskMemFree( desktop_folder );
+return;
+}
Does KF_FLAG_CREATE look better here? Other wise every time a new
wineprefix created there is an err output.
Maybe I'm missing something here, thanks for your work.
--
Regards,
Qian Hong
-
http://www.winehq.org
Re: [PATCH] ws2_32: Automatically sets a socket to non-blocking mode when WSAAsyncSelect or WSAEventSelect is called (try 2).
On Tue, May 21, 2013 at 11:03 PM, Alexandre Julliard julli...@winehq.org wrote: You shouldn't need 2 server calls for this. There's no reason to abort on every failure. An improved version is sent, thanks a lot for review! -- Regards, Qian Hong - http://www.codeweavers.com
Re: [PATCH] ws2_32: Automatically sets a socket to non-blocking mode when WSAAsyncSelect or WSAEventSelect is called.
Hi Dmitry, On Mon, May 20, 2013 at 6:13 PM, Dmitry Timoshkov dmi...@baikal.ru wrote: This change requires a test case, MSDN is often wrong, so its claims at least need to be very carefully checked. Thanks for the comment, actually I already guess you will point out it requires a test :) There is no win32 api to detect whether a socket is blocking or non-blocking, do you have any advice how to test it in our Wine test framework? Thanks a lot, as always! -- Regards, Qian Hong - http://www.codeweavers.com
Re: [PATCH] ws2_32: Automatically sets a socket to non-blocking mode when WSAAsyncSelect or WSAEventSelect is called.
On Mon, May 20, 2013 at 7:02 PM, Dmitry Timoshkov dmi...@baikal.ru wrote: Qian Hong qh...@codeweavers.com wrote: MSDN page you referenced has a hint how this behaviour could be tested: The WSAAsyncSelect or WSAEventSelect routine automatically sets a socket to non-blocking mode. If WSAAsyncSelect or WSAEventSelect has been issued on a socket, then any attempt to use WSAIoctl to set the socket back to blocking mode will fail with WSAEINVAL. To set the socket back to blocking mode, an application must first disable WSAAsyncSelect by calling WSAAsyncSelect with the lEvent parameter equal to zero, or disable WSAEventSelect by calling WSAEventSelect with the lNetworkEvents parameter equal to zero. Thanks for advice, I noticed that method and I though it is not ideal since it is an indirect test rather than a direct test. The above description implies two behaviors: A: 'The WSAAsyncSelect or WSAEventSelect routine automatically sets a socket to non-blocking mode' B: 'any attempt to use WSAIoctl to set the socket back to blocking mode will fail with WSAEINVAL' Currently Wine's winsock implementation already respects the behavior B, but doesn't respect the behavior A. I can add a test to proof behavior B, is that enough? Thanks again! -- Regards, Qian Hong - http://www.codeweavers.com
Re: [PATCH] ws2_32: Automatically sets a socket to non-blocking mode when WSAAsyncSelect or WSAEventSelect is called.
On Mon, May 20, 2013 at 7:53 PM, Dmitry Timoshkov dmi...@baikal.ru wrote: I'd test it like the following: 1. create a socket 2. check that WSAIoctl works 3. call WSAAsyncSelect/WSAEventSelect 4. check that WSAIoctl fails 5. set the socket back to blocking mode using described technique 6. check that WSAIoctl works of course checking for exact error codes and such. Ok, will send a test patch, thanks for advice! -- Regards, Qian Hong - http://www.codeweavers.com
Re: [website] Simplified Chinese translation for release 1.5.30
On Sun, May 12, 2013 at 11:16 AM, Jactry Zeng jactr...@gmail.com wrote: This translation seems suspect, but I don't have a very good alternative yet. I also can think a word in Simplified China to describe it. But I have found some documents about WinInet in Simplified Chinese[1], and ‘旁路' or '旁路列表' was used to describe this process. Ok, I don't have strong opinion on it, thanks for your work. -- Regards, Qian Hong - http://www.winehq.org
Re: [website] Simplified Chinese translation for release 1.5.30
2013/5/11 Jactry Zeng jactr...@gmail.com: + liWinInet 对代理旁路的支持。/li This translation seems suspect, but I don't have a very good alternative yet. In 'Internet Options' setting of MSIE7, 'Bypass proxy server for local address' is translated to '跳过本地地址的代理服务器' Thanks for the work. -- Regards, Qian Hong - http://www.winehq.org
Re: [PATCH 2/2] Fixing ReleaseCapture of child window bug in EnableWindow
Hello Guo Jian, On Fri, May 10, 2013 at 1:36 AM, Guo Jian orz...@gmail.com wrote: A window should not lose mouse capture even when it's parent window is disabled. Did you forget to remove the todo_wine introduced in [patch 1/2]? Thanks for your work on it. -- Regards, Qian Hong
Re: [Patch 1/2] user32/tests: Added test to show EnableWindow cause wrong ReleaseCapture
Hi orzhvs, Thanks for your work on it, however, it seems gmail's line wrap 'feature' (hmm, isn't that a bug...) breaks your patch, you could try fight with that feature or send your patch as attachment instead.
Re: [user32] Add DECLSPEC_NOINLINE, use it on call_hook_proc()
On Sat, Apr 20, 2013 at 1:38 AM, Dan Kegel d...@kegel.com wrote: I tried explicitly add 'inline' to every static functions in hook.c but complie with -O0, to see if the bug can be reproduced in this way, but nothing happen, this make me doubt being inline is not the culprit. call_hook_proc is probably the only function whose inlining matters for this problem (since my patch solved your problem at -O2). (inline is only a hint. FORCEINLINE is stronger.) Thanks Dan and André, I tried FORCEINLINE and tried bisect on gcc flags to reproduce the bug but failed with strange gcc behaviors, then Dan had worked out an actual fix for this bug, what I learned is, understanding the real bug seems faster than playing with gcc flags... Anyway, thanks Dan and André as always! -- Regards, Qian Hong - http://www.winehq.org
Re: [user32] Add DECLSPEC_NOINLINE, use it on call_hook_proc()
Hi Dan, Thanks for working on it! It is really an annoying bug, however, is adding DECLSPEC_NOINLINE a workaround or a real fix? If it is only a workaround, would that hide some real bug behind it? Or is that possible that there is a gcc bug here that we want to report to gcc? Thanks for your time!
Re: [user32] Add DECLSPEC_NOINLINE, use it on call_hook_proc()
On Sat, Apr 20, 2013 at 12:52 AM, Dan Kegel d...@kegel.com wrote: I suspect this is a real fix, and there is no gcc bug. Thanks for clarify. Curiosity killed the cat, what is the theory behind this patch? I tried explicitly add 'inline' to every static functions in hook.c but complie with -O0, to see if the bug can be reproduced in this way, but nothing happen, this make me doubt being inline is not the culprit. Any inspire is great appreciated! Best wishes from a curiosity cat :) -- Regards, Qian Hong - http://www.winehq.org
Re: [website] Simplified Chinese translation for release 1.5.27
Hi Jactry, 2013/3/30 Jactry Zeng jactr...@gmail.com: + li一些 C 运行时的改进。/li I think it is better to translate C runtime to “C 运行时库“ rather than just ”C 运行时“。 + li为内建程序提供更高质量的图标。/li Large icon means 大图标，not 高质量图标。You can verify this by the git commits。 Thanks for the work. -- Regards, Qian Hong - http://www.winehq.org
Re: [PATCH 1/6] atl100/tests: Added class name test for AtlAxWinInit.
On Fri, Mar 15, 2013 at 9:24 PM, Alexandre Julliard julli...@winehq.org wrote: It's not useful to load this dynamically if you are not going to check that it was found. Thanks very much, I'll send an improved version. -- Regards, Qian Hong - http://www.codeweavers.com
Re: gdi32: Fix the GdiGetCodePage() support ANSI_CHARSET font associated charset.
On Fri, Feb 22, 2013 at 10:21 AM, Byeongsik Jeon bsj...@hanmail.net wrote: This patch fix a original topic of the wine-bugs #16325. Thanks for the great work! I've been waiting for this fix for a really long time :) Out basic Wine test VM does not include Chinese/Japanese Windows, so I submit Byeongsik's patch to the testbot again with Chinese/Japanese Windows included: https://testbot.winehq.org/JobDetails.pl?Key=24496 All tests related to this patch passed (Those failed tests are not related to this patch) I also manually test the patch on Windows with Korean locale and the test case passed as well. Hopes that helps :) -- Regards, Qian Hong - http://www.winehq.org
Re: [website] Added simplified chinese
On Thu, Jan 31, 2013 at 1:24 AM, Jeremy Newman jnew...@codeweavers.com wrote:
We prefer UTF-8 as that is what the underlying template engine of the
website understands. Modern browsers should be able to use it just fine
(hopefully, even in China).
Don't worry about UTF-8, let's commit the patch and see what happens. grin
According to http://tongji.baidu.com/data/browser , 74% of Chinese
users are using MSIE{6,8,9}, if MSIE has any trouble to display UTF-8
Chinese text, we could consider providing a binary patch to MS, or
maybe even source code patch, we already has a gecko-based IE which
supports UTF-8 pretty good...
Just a joke, but seriously, UTF-8 is supported even in China :)
The translation part of the patch looks good to me, but as I know
Jactry is working on an improved version, let's wait for his new work.
Thanks.
--
Regards,
Qian Hong
-
Sent from Ubuntu
http://www.ubuntu.com/
Re: [website] Added Simplified Chinese translation
On Thu, Jan 31, 2013 at 11:34 AM, Jactry Zeng jactr...@gmail.com wrote: Hi folks, this is Simplified Chinese translation for Wine's website The translation looks good to me, thanks for the great work! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH] gdi32: Don't enumerate fonts when OpenFontFace fails (try 2).
Hello,
On Fri, Dec 7, 2012 at 6:28 AM, Alexandre Julliard julli...@winehq.org wrote:
../../../tools/runtest -q -P wine -M gdiplus.dll -T ../../.. -p
gdiplus_test.exe.so font.c touch font.ok
font.c:400: Test failed: Expected 0, got 3
font.c:401: Test failed: got NULL font collection
make[1]: *** [font.ok] Error 2
I can reproduce the failure with run gdiplus font test right after
gdi32 font test, however, if a `wineserver -k` is executed between
the two test, then the gdiplus failure will disappear.
The attach patch should fix this problem.
This time I grepped
EnumFontFamilies/CreateScalableFontResource/AddFontResource in all
dlls and manually run similar tests with related dlls
(usp10/dwrite/oleaut32/comdlg32/gdiplus...), each test is executed
either right after gdi32/font test or independently, hopefully this
time such failure will not happen again.
This patch is here for fixing the side effect of
gdi32/tests/font.c:test_CreateScalableFontResource().
usp10/tests/usp10.c:test_ScriptGetFontProperties() fails due to this
side effect because the font file is removed but the wine_test font is
not removed from the font list since RemoveFontResource() is a stub in
Wine.
However, the attached solution is not exactly match what Windows does:
On Windows, if the font file is deleted after
CreateScalableFontResource() and AddFontResource(), EnumFontFamilies
still enumerate the missing font until next reboot. Do we need to
follow what Windows does in this case?
I don't know if there is any real world app rely on this behavior, if
no I don't have a strong motivation for implementing it.
IMO the best solution is to correctly implement RemoveFontResource()
so Bug 8292 will be fixed, then we don't need to worry about the
broken test in usp10, which is the original reason for this patch.
Would you like me send this patch which is still an improvement, or
just leave the broken test there until RemoveFontResource is
implement?
Thanks for any suggestions.
--
Regards,
Qian Hong
-
Sent from Ubuntu
http://www.ubuntu.com/
From 1f4934e24fe6a9c56a206519e7214ccf8a4a66b8 Mon Sep 17 00:00:00 2001
From: Qian Hong fract...@gmail.com
Date: Thu, 6 Dec 2012 03:19:58 +0800
Subject: [PATCH] gdi32: Ignore fonts in enum_face_charsets if OpenFontFace
fails.
Reply-To: wine-devel@winehq.org
To: wine-patc...@winehq.org
---
dlls/gdi32/freetype.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/dlls/gdi32/freetype.c b/dlls/gdi32/freetype.c
index 456a094..1ff8625 100644
--- a/dlls/gdi32/freetype.c
+++ b/dlls/gdi32/freetype.c
@@ -2992,7 +2992,7 @@ struct fontdir
#include poppack.h
-static void GetEnumStructs(Face *face, LPENUMLOGFONTEXW pelf,
+static BOOL get_enum_structs(Face *face, LPENUMLOGFONTEXW pelf,
NEWTEXTMETRICEXW *pntm, LPDWORD ptype);
static BOOL get_fontdir( const char *unix_name, struct fontdir *fd )
@@ -3012,7 +3012,11 @@ static BOOL get_fontdir( const char *unix_name, struct
fontdir *fd )
insert_face_in_family_list( face, family );
pFT_Done_Face( ft_face );
-GetEnumStructs( face, elf, ntm, type );
+if (!get_enum_structs( face, elf, ntm, type ))
+{
+free_family( family );
+return FALSE;
+}
free_family( family );
if ((type TRUETYPE_FONTTYPE) == 0) return FALSE;
@@ -5185,7 +5189,7 @@ static DWORD create_enum_charset_list(DWORD charset,
struct enum_charset_list *l
return n;
}
-static void GetEnumStructs(Face *face, LPENUMLOGFONTEXW pelf,
+static BOOL get_enum_structs(Face *face, LPENUMLOGFONTEXW pelf,
NEWTEXTMETRICEXW *pntm, LPDWORD ptype)
{
GdiFont *font;
@@ -5197,7 +5201,7 @@ static void GetEnumStructs(Face *face, LPENUMLOGFONTEXW
pelf,
*pelf = face-cached_enum_data-elf;
*pntm = face-cached_enum_data-ntm;
*ptype = face-cached_enum_data-type;
-return;
+return TRUE;
}
font = alloc_font();
@@ -5214,7 +5218,7 @@ static void GetEnumStructs(Face *face, LPENUMLOGFONTEXW
pelf,
if (!(font-ft_face = OpenFontFace(font, face, width, height)))
{
free_font(font);
-return;
+return FALSE;
}
font-name = strdupW(face-family-FamilyName);
@@ -5290,6 +5294,7 @@ static void GetEnumStructs(Face *face, LPENUMLOGFONTEXW
pelf,
}
free_font(font);
+return TRUE;
}
static BOOL family_matches(Family *family, const LOGFONTW *lf)
@@ -5324,7 +5329,7 @@ static BOOL enum_face_charsets(const Family *family, Face
*face, struct enum_cha
DWORD type = 0;
int i;
-GetEnumStructs(face, elf, ntm, type);
+if (!get_enum_structs(face, elf, ntm, type)) return TRUE;
for(i = 0; i list-total; i++) {
if(!face-scalable face-fs.fsCsb[0] == 0) { /* OEM bitmap */
elf.elfLogFont.lfCharSet = ntm.ntmTm.tmCharSet = OEM_CHARSET;
--
1.7.9.5
Re: [PATCH] gdi32: Don't enumerate font when OpenFontFace fails.
Hello, On Thu, Dec 6, 2012 at 3:19 PM, Qian Hong fract...@gmail.com wrote: Hello, On Thu, Dec 6, 2012 at 3:42 PM, Dmitry Timoshkov dmi...@baikal.ru wrote: 'face' and 'family' are leaked here. Also returning FALSE at this point is too late since both 'face' and 'family' are already in the linked lists. Thanks for point out this! I'll investigate more. The 'family' is not inserted to the font list here, get_enum_structs() is called by get_fontdir(), which is called by WineEngCreateScalableFontResource(). When we create a scalable font resource, we don't add the font to the font list, we add the font to the font list in WineEngAddFontResourceEx() instead, so there is no need to worry about returning FALSE at this point. The only reason to create a family and insert the face to the family here is because get_enum_structs() need to copy string from face-family-FamilyName. I've send an improved patch which fixed the memory leak issue, thanks for your good eyes :) Please let me know if I'm wrong with the above thinking, thanks! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH] gdi32: Don't enumerate font when OpenFontFace fails.
Hello, On Thu, Dec 6, 2012 at 3:42 PM, Dmitry Timoshkov dmi...@baikal.ru wrote: 'face' and 'family' are leaked here. Also returning FALSE at this point is too late since both 'face' and 'family' are already in the linked lists. Thanks for point out this! I'll investigate more. -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH 2/2] usp10/tests: Added tests for wgBlank, wgDefault, wgInvalid and wgKashida.
Hello, On Wed, Nov 21, 2012 at 2:53 AM, Alexandre Julliard julli...@winehq.org wrote: Still no luck I'm afraid: Sorry for the failure, I guess there are some fonts installed on your system but not on my system, could you run the test in interactive mode and send the full log to me so I can see on what font it fails? Thanks a lot for your time! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH 1/2] usp10: Fixed wgBlank, wgDefault, wgInvalid and wgKashida (try 4).
On Tue, Nov 20, 2012 at 2:12 AM, Alexandre Julliard julli...@winehq.org wrote: It doesn't seem useful to have all these separate set and get functions, particularly since their implementation is very similar. Ah, yes, thanks for reminder! I must drank too much Wine LOL. -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH 1/2] usp10/tests: Added tests for wgBlank, wgDefault, wgInvalid and wgKashida (try 3).
Hello, On Sat, Nov 17, 2012 at 6:48 PM, Alexandre Julliard julli...@winehq.org wrote: Yes, that's OK. Tests need to succeed after every commit, even in the middle of a series. Thanks, I see, will resend my patches. -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH 1/2] usp10/tests: Added tests for wgBlank, wgDefault, wgInvalid and wgKashida (try 3).
Hello, On Sat, Nov 17, 2012 at 1:03 AM, Alexandre Julliard julli...@winehq.org wrote: The test fails: ../../../tools/runtest -q -P wine -M usp10.dll -T ../../.. -p usp10_test.exe.so usp10.c touch usp10.ok usp10.c:1958: Test failed: wgBlank tmBreakChar 0020 usp10.c:1958: Test failed: wgBlank tmBreakChar 0020 usp10.c:1958: Test failed: wgBlank tmBreakChar 0020 usp10.c:1958: Test failed: wgBlank tmBreakChar 0020 Does the test run before or after patch [2/2] applied? If the failure is before patch [2/2] then it's expected because I didn't add todo_wine to [1/2]. I didn't add todo_wine because before [2/2] those test will success for some fonts on Wine and fail for the other fonts on Wine, and it seems doesn't make sense to test on only a few fonts. Is the following solution acceptable? - Swap the order of patch [1/2] and [2/2], add test cases after fix the implementation . Thanks a lot! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH 1/2] usp10/tests: Added tests for wgBlank, wgDefault, wgInvalid and wgKashida (try 2).
Hello, On Fri, Nov 16, 2012 at 3:09 AM, Alexandre Julliard julli...@winehq.org wrote: There's no need to have two separate tests functions. Thanks for comment, will merge them. -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH 2/2] usp10: Fixed wgBlank, wgDefault, wgInvalid and wgKashida.
Hello, On Wed, Nov 14, 2012 at 2:22 AM, Alexandre Julliard julli...@winehq.org wrote: There's no reason to add #defines for that kind of thing, just put the values in the string directly. Thanks for comment, will remove these #defines. -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH 2/2] usp10: Fixed wgBlank, wgDefault, wgInvalid and wgKashida.
Hello,
Thanks for comment too!
On Wed, Nov 14, 2012 at 3:25 AM, Nikolay Sivov bungleh...@gmail.com wrote:
I think it's better to avoid macros if possible.
Got it.
+if (!sc-sfnt)
+{
+if (GetTextMetricsW(hdc, tmW))
+sc-sfp.wgBlank = tmW.tmBreakChar;
+else
+{
+ERR(Get wgBlank failed, fallback to Numeric_space.\n);
+sc-sfp.wgBlank = Numeric_space;
+}
If it's a normal fallback case it's not an error I guess.
It's not a normal fallback, GetTextMetricsW() should not fail, and I
didn't see fail here for all fonts I tested.
Should I remove the else{} block?
+{
+#define Zero_width_space 0x200b /* Zero Width Space */
+#define Invalid_char3 0xf71b /* Unknow, found by black box testing */
+#define NON_EXIST_INDEX 0x /* Default non exist char index */
+WCHAR invalid_chars[3] = {Numeric_space, Zero_width_space,
Invalid_char3};
I don't see why this can't be hardcoded without macros and one line comment
about meaning of this.
Thanks, will change that.
+#define Kashida_char0x0640 /* Kashida */
+WCHAR kashida_chars[] = {Kashida_char};
Same here, also naming is a bit strange. I think it's enough to name it
'kashida' and make it 'static const WCHAR'.
Good point, thanks Nikolay.
Re: [PATCH] tools/wine.inf.in: Added UTF8 bom header. (resend)
Hello, On Thu, Nov 8, 2012 at 3:25 AM, Alexandre Julliard julli...@winehq.org wrote: It's here to support Unicode data in wine.inf, as you noted. However, I don't think it makes sense to add the BOM unless we actually have Unicode keys in there. Thanks for explain! Let me make a summary of Bug 32136: Since Wine1.4 we added the 'font replacement' feature to Wine, and leave the 'font replacement' setting to distribution folks, for example, Ubuntu's Wine packager has a patch like 0001-tools-wine.inf.in-Added-font-name-replacement.txt To solve Bug 32136, we need not only English font name replacement for CJK fonts, but also localized font name replacement for CJK fonts, so Ubuntu need to update their patch like 0001-tools-wine.inf.in-Added-localized-font-name-replacemen.txt. The second patch is a bit strange and ugly, because it change the encoding of a upstream file, that will make people confused. What's worse, once Wine update the encoding of wine.inf.in from ANSI to UTF8_with_bom in the future, the second patch will confilict to the new wine.inf.in. My idea is split the second patch into two parts, the first part is 0001-tools-wine.inf.in-Added-UTF8-bom-header.txt, the second part is adding english and localized font name replacement settings without changing the encoding of wine.inf.in. Did I explain clearly enough? Does that make sense? Thank you! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/ From 2a1216e71ad99be207c445336d7a97b3a42813f7 Mon Sep 17 00:00:00 2001 From: Qian Hong fract...@gmail.com Date: Thu, 8 Nov 2012 15:51:21 +0800 Subject: [PATCH] tools/wine.inf.in: Added font name replacement. Reply-To: wine-devel@winehq.org To: wine-patc...@winehq.org --- tools/wine.inf.in | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/tools/wine.inf.in b/tools/wine.inf.in index 03a748a..213b878 100644 --- a/tools/wine.inf.in +++ b/tools/wine.inf.in @@ -581,6 +581,18 @@ HKLM,%FontSubStr%,Times New Roman CYR,204,,Times New Roman,204 HKLM,%FontSubStr%,Times New Roman Greek,161,,Times New Roman,161 HKLM,%FontSubStr%,Times New Roman TUR,162,,Times New Roman,162 HKLM,System\CurrentControlSet\Hardware Profiles\Current\Software\Fonts,LogPixels,0x10003,0x0060 +HKCU,Software\Wine\Fonts\Replacements,SimSun,,WenQuanYi Micro Hei +HKCU,Software\Wine\Fonts\Replacements,PMingLiU,,WenQuanYi Micro Hei +HKCU,Software\Wine\Fonts\Replacements,MS Gothic,,Ume Gothic +HKCU,Software\Wine\Fonts\Replacements,MS PGothic,,Ume P Gothic +HKCU,Software\Wine\Fonts\Replacements,MS UI Gothic,,Ume UI Gothic +HKCU,Software\Wine\Fonts\Replacements,MS Mincho,,Ume Mincho +HKCU,Software\Wine\Fonts\Replacements,MS PMincho,,Ume P Mincho +HKCU,Software\Wine\Fonts\Replacements,Batang,,UnBatang +HKCU,Software\Wine\Fonts\Replacements,Dotum,,UnDotum +HKCU,Software\Wine\Fonts\Replacements,Gulim,,UnDotum +HKCU,Software\Wine\Fonts\Replacements,Arial Unicode MS,,Droid Sans Fallback + [MCI] HKLM,%Mci32Str%,AVIVideo,,mciavi32.dll -- 1.7.5.4 From df84ea7bf12ebacf8d5cd1fecceeeccc64ac363a Mon Sep 17 00:00:00 2001 From: Qian Hong fract...@gmail.com Date: Thu, 8 Nov 2012 15:48:08 +0800 Subject: [PATCH] tools/wine.inf.in: Added localized font name replacement. Reply-To: wine-devel@winehq.org To: wine-patc...@winehq.org --- tools/wine.inf.in | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/tools/wine.inf.in b/tools/wine.inf.in index 03a748a..24cc0b9 100644 --- a/tools/wine.inf.in +++ b/tools/wine.inf.in @@ -1,3 +1,6 @@ +;; To support localized font name replacement, this file should be encoded in +;; UTF-8 with BOM, be careful not to strip the BOM header! +;; ;; .INF script for the basic Wine configuration ;; Version: @PACKAGE_STRING@ ;; @@ -581,6 +584,21 @@ HKLM,%FontSubStr%,Times New Roman CYR,204,,Times New Roman,204 HKLM,%FontSubStr%,Times New Roman Greek,161,,Times New Roman,161 HKLM,%FontSubStr%,Times New Roman TUR,162,,Times New Roman,162 HKLM,System\CurrentControlSet\Hardware Profiles\Current\Software\Fonts,LogPixels,0x10003,0x0060 +HKCU,Software\Wine\Fonts\Replacements,SimSun,,WenQuanYi Micro Hei +HKCU,Software\Wine\Fonts\Replacements,宋体,,WenQuanYi Micro Hei +HKCU,Software\Wine\Fonts\Replacements,PMingLiU,,WenQuanYi Micro Hei +HKCU,Software\Wine\Fonts\Replacements,新細明體,,WenQuanYi Micro Hei +HKCU,Software\Wine\Fonts\Replacements,MS Gothic,,Ume Gothic +HKCU,Software\Wine\Fonts\Replacements,MS PGothic,,Ume P Gothic +HKCU,Software\Wine\Fonts\Replacements,ＭＳＰゴシック,,Ume P Gothic +HKCU,Software\Wine\Fonts\Replacements,MS UI Gothic,,Ume UI Gothic +HKCU,Software\Wine\Fonts\Replacements,MS Mincho,,Ume Mincho +HKCU,Software\Wine\Fonts\Replacements,MS PMincho,,Ume P Mincho +HKCU,Software\Wine\Fonts\Replacements,Batang,,UnBatang +HKCU,Software\Wine\Fonts\Replacements,Dotum,,UnDotum +HKCU,Software\Wine\Fonts\Replacements,Gulim,,UnDotum +HKCU,Software\Wine\Fonts\Replacements,Arial Unicode MS,,Droid Sans Fallback + [MCI] HKLM,%Mci32Str
Re: [PATCH] tools/wine.inf.in: Added UTF8 bom header. (resend)
On Thu, Nov 8, 2012 at 4:04 PM, Qian Hong fract...@gmail.com wrote: My idea is split the second patch into two parts, the first part is 0001-tools-wine.inf.in-Added-UTF8-bom-header.txt, the second part is adding english and localized font name replacement settings without changing the encoding of wine.inf.in. I mean, after splitting into two parts, commit the first part to upstream Wine, and leave the second part to the distribution folks, just like what we do for 0001-tools-wine.inf.in-Added-font-name-replacement.txt right now. -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH] tools/wine.inf.in: Added UTF8 bom header. (resend)
Hello, On Thu, Nov 8, 2012 at 5:53 PM, Dmitry Timoshkov dmi...@baikal.ru wrote: What's wrong with having a .reg file with unicode file names and feed it to reg.exe? Then there is no any need for custom wine.inf patches. Then we have to feed it to reg.exe every time when a new wineprefix created, or did I miss something? I can't see how it could replace the custom wine.inf patch in Ubuntu/Fedora's packages, could you be more details? Thanks! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH] tools/wine.inf.in: Added UTF8 bom header. (resend)
Hi Dmitry,
On Wed, Nov 7, 2012 at 11:25 AM, Dmitry Timoshkov dmi...@baikal.ru wrote:
So, how is this supposed to work under Windows?
I wrote a test case, to my surprise, Windows doesn't support UTF8 .inf
file, no matter with or without BOM.
However, Windows support Little-endian UTF-16 Unicode .inf file.
The test case compiled with mingw-w64 and run on
https://testbot.winehq.org/JobDetails.pl?Key=22822
However, in git log I see such a commit:
commit 31ade1eb67e6b55f1b0c09ef7a806cd53652b1e2
Author: Alexandre Julliard julli...@winehq.org
Date: Wed Mar 21 13:52:43 2007 +0100
setupapi: Add support for .inf files in utf-8 format.
Did I miss anything or was there a reason to add utf8 support for inf
files in Wine?
Thanks a lot!
--
Regards,
Qian Hong
-
Sent from Ubuntu
http://www.ubuntu.com/
#include windows.h
#include stdio.h
#include setupapi.h
BOOL create_inf(const WCHAR *tmpfilenameW, void *data, UINT sz)
{
HANDLE handle = CreateFileW(tmpfilenameW, GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, CREATE_ALWAYS, 0, 0);
DWORD res;
if (handle == INVALID_HANDLE_VALUE) return FALSE;
if (!WriteFile(handle, data, sz, res, NULL))
{
CloseHandle(handle);
DeleteFileW(tmpfilenameW);
return FALSE;
}
CloseHandle(handle);
return TRUE;
}
void check_inf(const WCHAR *tmpfilenameW)
{
HINF inf;
UINT err_line = 0;
BOOL ret;
INFCONTEXT context;
WCHAR bufferW[MAX_INF_STRING_LENGTH+32];
char bufferA[MAX_INF_STRING_LENGTH+32];
WCHAR chineseW[] = {'c','h','i','n','e','s','e','\0'};
WCHAR hanziW[] = {0x4e2d, 0x6587, 0};
inf = SetupOpenInfFileW(tmpfilenameW, 0, INF_STYLE_WIN4, err_line);
if (inf == INVALID_HANDLE_VALUE)
{
printf(SetupOpenInfFile fail\n);
return;
}
ret = SetupFindFirstLineA(inf, Test, 0, context);
SetupGetStringFieldW(context, 0, bufferW, sizeof(bufferW), NULL);
WideCharToMultiByte(CP_ACP, 0, bufferW, -1, bufferA, sizeof(bufferA), NULL, FALSE);
ret = lstrcmpW(bufferW, chineseW);
printf(%s %s\n, bufferA, ret == 0 ? matches : does not match);
SetupGetStringFieldW(context, 1, bufferW, sizeof(bufferW), NULL);
WideCharToMultiByte(CP_ACP, 0, bufferW, -1, bufferA, sizeof(bufferA), NULL, FALSE);
ret = lstrcmpW(bufferW, hanziW);
printf(%s %s\n, bufferA, ret == 0 ? matches : does not match);
return;
}
int main(void)
{
WCHAR tmpfilenameW[] = {'.','\\','t','m','p','.','i','n','f','\0'};
//const char tmpfilename[] = .\\tmp.inf;
WCHAR data[] = {0xfeff, '[','v','e','r','s','i','o','n',']','\r','\n','S','i','g','n','a','t','u','r','e','=','','$','C','H','I','C','A','G','O','$','','\r','\n', '[','T','e','s','t',']','\r','\n','c','h','i','n','e','s','e','=', 0x4e2d, 0x6587,'\r','\n'};
char data_utf8[4096];
char data_utf8_bom[4096];
INT srclen, dstlen;
srclen = sizeof(data)/sizeof(data[0]);
dstlen = WideCharToMultiByte(CP_UTF8, 0, data + 1, srclen - 1, NULL, 0, NULL, FALSE);
WideCharToMultiByte(CP_UTF8, 0, data + 1, srclen -1, data_utf8, dstlen, NULL, FALSE);
memcpy(data_utf8_bom, \xef\xbb\xbf, 3);
memcpy(data_utf8_bom + 3, data_utf8, dstlen);
printf(Testing Little-endian UTF-16 Unicode .inf file...\n);
if (create_inf(tmpfilenameW, data, sizeof(data)))
{
check_inf(tmpfilenameW);
DeleteFileW(tmpfilenameW);
}
printf(\n);
printf(Testing UTF-8 without BOM...\n);
if (create_inf(tmpfilenameW, data_utf8, dstlen))
{
check_inf(tmpfilenameW);
DeleteFileW(tmpfilenameW);
}
printf(\n);
printf(Testing UTF-8 with BOM...\n);
if (create_inf(tmpfilenameW, data_utf8_bom, dstlen + 3))
{
check_inf(tmpfilenameW);
DeleteFileW(tmpfilenameW);
}
printf(\n);
return 0;
}
Re: [PATCH] tools/wine.inf.in: Added UTF8 bom header.
Hi Dmitry, On Tue, Nov 6, 2012 at 3:59 PM, Dmitry Timoshkov dmi...@baikal.ru wrote: It should be possible to specify a not localized font name. In general, wine.inf follows Windows format of .inf files, you should investigate how unicode is supposed to work inside of .inf files. Thanks for advice! Unfortunately I'm worrying about my google skills... I search for storing unicode string in .inf files / .reg files, most related samples are covered in [1], but none of them match my purpose. What I need is something like: HKCU,Software\Wine\Fonts\Replacements,\x5b8b\x4f53,WenQuanYi Micro Hei But I can't found anyway like that which works. I also check the code in dlls/setupapi, there seems no code related to decode similar strings into unicode. Could you point out if I miss something? Any sample or reference is great appreciated! PS: The artical[1] referers to two books: Inside the Registry for Windows 95 by Günter Born and The Windows 98 Registry by John Woram, but I can't get them right now. [1] http://franck.kiechel.free.fr/dbr_eng/RegInf.htm -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH] tools/wine.inf.in: Added UTF8 bom header.
Hi Dmitry, On Tue, Nov 6, 2012 at 12:44 PM, Dmitry Timoshkov dmi...@baikal.ru wrote: Qian Hong fract...@gmail.com wrote: This patch solve the wine side of Bug 32136. Why is this needed? wine.inf.in doesn't contain non ASCII strings. Currently wine.inf.in does not contain non ASCII strings, but if we want to solve Bug 32136, as Comment 4, we need to add some non ASCII strings to wine.inf.in, such as: --- snip --- HKCU,Software\Wine\Fonts\Replacements,宋体,,WenQuanYi Micro Hei --- snip --- My idea is leaving these work for the distribution folks, however, I think it is better to add a UTF8 BOM header in the Wine side, or the distribution patch will be strange and ugly. Thanks for any suggestions! -- Dmitry. -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH 2/7] gdi32/tests: Fixed broken bitmap font metrics test on CJK locales.
Hello, On Fri, Oct 19, 2012 at 2:11 AM, Qian Hong fract...@gmail.com wrote: Including Arabic, Chinese, English, Dutch, Japanese, Russian Forgot to say, we have no Korean system in our testbot vms, so I tested this patch locally with Korean Windows 8 preview. -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH 2/2] gdi32/tests: Fixed broken tests on non English system Part 2.
Hello Dmitry, On Mon, Oct 8, 2012 at 1:59 PM, Dmitry Timoshkov dmi...@baikal.ru wrote: Any feedback for this patch? Thanks a lot for any comments! I'd try to avoid extra EnumFontFamiliesEx call, and probably do the checks you need in the previous one. Thanks for advice! I'll send an improved version. -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH 2/2] gdi32/tests: Fixed broken tests on non English system Part 2.
Hello Dmitry, Any feedback for this patch? Thanks a lot for any comments! On Thu, Oct 4, 2012 at 3:02 PM, Qian Hong fract...@gmail.com wrote: Dmitry, could you review this patch? Thanks a lot ;-) This series of patch fix some broken tests on Japanese Windows and Chinese Windows: -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH 1/2] gdi32/tests: Fixed broken tests on non English system Part 1.
Hello, On Thu, Oct 4, 2012 at 3:03 PM, Dmitry Timoshkov dmi...@baikal.ru wrote: On what system do you see broken results? I'm asking because i did run this test with japanese locale at the time I touched it last time. Please see https://testbot.winehq.org/JobDetails.pl?Key=21902#k207 ( WXPPROJASP3 ) Thanks! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH 1/2] gdi32/tests: Fixed broken tests on non English system Part 1.
Hello, On Thu, Oct 4, 2012 at 3:19 PM, Dmitry Timoshkov dmi...@baikal.ru wrote: I wouldn't pay too much attention to the XP results, what about results on newer Windows versions? I don't have Japanese version of Vista or Win7, there seems no Japanese Vista or Japanese Win7 in our winehq testbots. I tested on Japanese version of Win8 preview, and the result is the same as XP. What version of Japanese Windows did you test last time? Thanks! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH 1/2] gdi32/tests: Fixed broken tests on non English system Part 1.
Hello, On Thu, Oct 4, 2012 at 3:34 PM, Dmitry Timoshkov dmi...@baikal.ru wrote: I just tested with japanese locale, I don't have a localized japanese Windows here. Hello, Now I tested on my Chinese Windows, change the locale to Japanese as the steps from http://windows.microsoft.com/en-US/windows-vista/Change-the-system-locale , the result is the same as WXPPROJASP3 . Could this patch be got in first? Thanks! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH] iphlpapi: Set DhcpEnabled to TRUE for all interfaces.
Hi Juan, On Tue, Sep 25, 2012 at 11:53 PM, Juan Lang juan.l...@gmail.com wrote: I think this is fine, but you'd want to remove/fix some outdated comments I wrote at the same time: Thank you very much! I'll send an improved version tomorrow since I just drank some beer right now and I think it is not compatible with Wine ;-) -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH 3/5] gdi32: Fixed localized font style name.
Hello, On Tue, Sep 11, 2012 at 1:05 AM, Qian Hong fract...@gmail.com wrote: and the symbol font bug (with todo_wine because it need to be fixed in [PATCH 4/5].) Sorry for a typo, should be: with todo_wine because it need to be fixed in [PATCH 5/5]. Thanks! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH 4/5] gdi32: Added font name tests on non English locale.
Hello, On Fri, Sep 7, 2012 at 2:28 AM, Alexandre Julliard julli...@winehq.org wrote: You should avoid that sort of thing, it will be hard to debug, particularly since get_ttf_nametable_entry itself has ok() calls. Store the result in a variable instead. Thanks for review! I've sent a improved version. -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH 1/2] gdi32/tests: Added tests for symbol fonts.
Hello, Please ignore this series of patch, I'll provide a fix for the failure test.
Re: Wine bot results
Hello Alistair, On Tue, Aug 28, 2012 at 6:04 PM, Alistair Leslie-Hughes leslie_alist...@hotmail.com wrote: http://testbot.winehq.org/JobDetails.pl?Key=21257 http://testbot.winehq.org/JobDetails.pl?Key=21256 I downloaded your patch from http://testbot.winehq.org/GetFile.pl?JobKey=21257StepKey=1 , compiled with i686-w64-mingw32-gcc on Ubuntu 10.10, then resubmit it to wine testbot, my result is the same as the one built by testbot: https://testbot.winehq.org/JobDetails.pl?Key=21288 Maybe it is interesting to know what compiler you use and which one is used by testbot. Though we should make sure we are always test on the same patch first =) $ i686-w64-mingw32-gcc -v Using built-in specs. COLLECT_GCC=i686-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-w64-mingw32/4.6.1/lto-wrapper Target: i686-w64-mingw32 Configured with: ../../src/configure --build=i686-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --libexecdir='/usr/lib/gcc-mingw-w64' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --disable-shared --disable-multilib --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes --with-tune=generic --enable-version-specific-runtime-libs --enable-languages=c,c++,fortran --enable-lto --with-plugin-ld --enable-fully-dynamic-string --target=i686-w64-mingw32 --with-gxx-include-dir=/usr/include/c++/4.6 --with-as=/usr/bin/i686-w64-mingw32-as --with-ld=/usr/bin/i686-w64-mingw32-ld Thread model: win32 gcc version 4.6.1 (GCC) -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH 1/4] include/wine/test.h: Added wine_dbgstr_a[n] to test framwork.
On Thu, Aug 16, 2012 at 4:55 PM, Alexandre Julliard julli...@winehq.org wrote: This shouldn't be necessary, you can use a simple printf. Functions should only be added to test.h if there's a clear need across a wide range of tests. Thanks for review! Will provide an updated patch set soon. -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: [PATCH 2/3] riched20: Added support for UTF8 BOM stream. (Try 2)
On Fri, Aug 17, 2012 at 1:37 AM, Alexandre Julliard julli...@winehq.org wrote: There's no reason to move the data. Thanks for review! Will provide a better version soon. -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: Investigating iexplore/activex issues
Hi Joel, On Fri, Jul 27, 2012 at 11:12 PM, Joel Holdsworth j...@airwebreathe.org.uk wrote: Hi Qian, That's the easiest solution I've heard so far. Unfortunately I ran straight into bug #25919 (http://bugs.winehq.org/show_bug.cgi?id=25918). Maybe I can find a work-about, unless you know the solution already? What version of Chrome did you try? As Comment 4, later version of Chrome Standalone Installer does not affected by this bug. However, latest version of Chrome will affected by Bug 27168. I just check my Chrome, it is 16.0.912.63 m, I use it for more than half year without major problem. The sha1sum of the installer is: 73d5ec5c16951b9ad1582266a54ac799fa378b80 It was download at 2011-12-20 I think you could try a Chrome version later then 16.0.912.63 but older than 17, or I can simply send my copy to you. -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: Need suggestion to choose a GSoC idea
Hi Holy, On Tue, Mar 27, 2012 at 12:38 PM, HolyCause holy.ca...@gmail.com wrote: I already asked Austin about that for my GSoC proposal: in short, I think this effort is best spent somewhere else. GUI testing is really hard to get right, and very expensive(time, effort, disk space, cpu power, etc.). Thanks for reminder, I agree GUI testing is expensive, but I think manpower is more expensive :) However I've no idea how hard is it to get GUI testing right yet, maybe you are right, but from my view it is worth to try. I've since decided against GSoC for this year, but my idea revolved around improving cmd's parser, notably getting Firefox/Chromium and/or other software to build under wine (or at least, isolate potential/existing issues to non-cmd parts). I was partway through fixing http://bugs.winehq.org/show_bug.cgi?id=21174 Dan Kegel seemed pretty interested in the project. If you're interested you could e-mail him. Thanks, if this idea is not suitable for GSoC, I'll push it in my todo list. I'll contact to Dan and Austin once I'm going to do this. Thank you for your suggestion and good luck to your GSoC project! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: Need suggestion to choose a GSoC idea
Hi Aric, Thanks for reply. On Tue, Mar 27, 2012 at 7:56 PM, Aric Stewart a...@codeweavers.com wrote: Hi, Oh, I would love this. However speaking from experience font code is very hard. You would need to directly specify what you wanted to try to do and what needs improvement. The code there is very messy and fragile but also critical so it gets tricky to make any sweeping modifications. My favorite is to implement Font Association support, since currently we have no workaround for it without recompile source code. However, before investigate on font issue deeply, could I ask here for other wine developers' work plan? Just half day after I post my previous email, Huw and Kusanagi have sent their patches regarding font support to wine-patch. we have multiple developers working on this area, to prevent duplicate work, could you tell me is anyone working on Font Association support? Thanks a lot! I dont know if we need OCR. With the dib engine if we have a known font we can probably just do bitmap compares. I am not an expert here but it sounds interesting. I didn't known we can just do bitmap compares, if that's possible I think the OCR plan could be schedule low priority, maybe I'll investigate it in the future. Is it a good GSoC idea to improve font related testcase base on bitmap compares? Thank you! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Need suggestion to choose a GSoC idea
Hi all, I'm a student in Department of Mathematics, Sun Yat-sen University. My irc nick name is fracting, my real name is Qian Hong. I'm in GMT+8 time zone, availible on 10:00 to 18:00 (GMT+8) on #winehackers. I know C/bash and some Linux skills. Currently I'm an intern in Redhat, working in the kernel-qe group. I have great interesting in the Wine project. Last year I spent most of my spare time on reporting bugs to Wine. When I doing this I found lots of bugs regarding Chinese software have beem complained in local Linux forum for years but no one reported them to Wine project. In other words, I found most Chinese Linux users didn't report bugs to open source projects, well, I think that is a bug too :) After reported 100+ bugs, I'm surprised so many bugs have been fixed in just one year. I wish I can do some more then reporting bugs for Wine project, great if I can get start with the 2012 GSoC and keep submitting patches to Wine after that. I have lots of ideas in my TODO list, unfortunately most of them might too hard to do as a GSoC project. Anyway, I'll post my ideas here, wait for feedbacks, choose one of them as my GSoC idea, and leave others as my job in the coming years. Certainly I'm glad to see any others working on those ideas :) Here is my list: - Implement ndis.sys This idea come from the off-standard network authentication in China. Lots of Universities in China using some off-standard network authentication methods for campus network connection, the authentication protocols are usually private and changed frequently, the authentication clients are usually Windows-only. This issue is the main blocker for students in those Universities to change to Linux desktop or Mac. I've filed some bugs regarding some network authentication clients, such as [1],[2],[3],[4],[5]. However, even the above bugs are fixed, these clients might not work on wine because they depends on ndis.sys which is not implemented yet. As an intern in Redhat network-qe group focus on NIC testing, I have great interesting in implement ndis.sys, though I think it is too hard for a GSoC project. The ndiswrapper code is a great resource but not complete, also I known ReactOS project has a ndis.sys too but obviously it won't work on Wine. Is it allowed to read ReactOS implementation to learn how things work? Anyway I'm interesting in what you think :) - Implement/improve wpcap proxy This idea is similar with the first one, in fact André H has already done the most important part [6],[7]. I hope André's patch will be accepted, and I'm interesting in improving it. I have done some proof-of-concept to show that some kinds of network auth client wich depends on winpcap will work on wine with André's patch. - Improve builtin iexplore This idea is come from another main blocker for using Linux/Mac in China. Most Chinese online banks are ie-only, depends on ActiveX and some ie-only style JavaScript or even VBScript. Jacek and other wine developers has done lots of work on them, and I'm interesting in participating. I've filed 40+ bugs regarding online bank support with Wine [8]. My goal is to make wine builtin iexplore works for as many online banks, currently I have more then 6 different online bank accounts for testing, guys in openbank-discuss group [9] will help on testing too. - Improve USB support Yeah, this might be another idea which is too hard for a GSoC project. We already have a third party patch, I wonder will Wine-1.6 have official USB support? This idea is similar with the above one, my goal is to solve the online bank USB-key issues. After testing on 8 different USB-keys with the USB patch [10], I noticed they won't work on wine without hidusb.sys. ReactOS project has implement hidusb.sys in the last few months, again, is it allow to learn ReactOS code if I would like to contribute to Wine? - Improve Wine CJK font support The main idea is fix Bug 16325 [11], Aric and others have done a lot of work on it, and I'm glad to participating too. I think the main blocker for Wine CJK font support is Font Association now, is it suitable for a GSoC project? Also I've filed some other Wine font bugs [12],[13],[14],[15],[16], I'm happy to working on them. - Improve Wine font test case This idea is similar with the above one, however, instead of fixing real bugs, this idea is to prevent new bugs(regression). As having filed 100+ bugs I know the pain of doing regression test if we can't script the test, this happens on font related bugs. The main idea is to integrate an OCR engine to wine testcase, use ORC method to detect whether the fonts display correctly. We already have very good open source ORC engine [17] which is in Apache License. However tesseract-ocr is written in C++ an I am worring that will not be integrated to Wine code tree. - Improve Wine App install / App running testing This idea is similar with Austin's early work [18], my idea is using sikuli [19] instead of autohotkey, since
Re: GSoC proposal
Hi, On Sun, Mar 25, 2012 at 10:30 PM, Aric Stewart a...@codeweavers.com wrote: Hi, As a developer who has done a lot of work in the IME/XIM areas of wine I thought I would chime in. The IME/XIM stuff sounds interesting but I am really not sure how useful it is going to be. I will have to review what the GSoC outline is like but it feels like something that would not really get into wine not would regularly get used by people outside of wine. If you want to flesh it out a bit more I could maybe see where you are going with it but it feels more like a project Making use of Wine instead of Improving Wine This is not a discouragement, just an invitation to sell it to me more. Make me see why you think this would be good for IME in Wine. IMO using win32 IME on Linux is necessary for some people. In fact even most Chinese users don't know how many Chinese IMEs there exist, some of them have no alternative at all. Also, some handwriting input method editors and some speech-to-text input method editors have no alternative on Linux. Another reason to implement win32 IME bridge is, some win32 IME, such as sogou pinyin, google pinyin, are much better than there alternative on Linux ( ibus-pinyin, sunpinyin), maybe it is hard to understanded by non Chinese users... -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: GSoC proposal
On Sun, Mar 25, 2012 at 11:02 PM, Henri Verbeet hverb...@gmail.com wrote: On 25 March 2012 16:49, Qian Hong fract...@gmail.com wrote: IMO using win32 IME on Linux is necessary for some people. In fact even most Chinese users don't know how many Chinese IMEs there exist, some of them have no alternative at all. Also, some handwriting input method editors and some speech-to-text input method editors have no alternative on Linux. Another reason to implement win32 IME bridge is, some win32 IME, such as sogou pinyin, google pinyin, are much better than there alternative on Linux ( ibus-pinyin, sunpinyin), maybe it is hard to understanded by non Chinese users... I'm sure that's all true, but why would making Win32 input methods run through Wine be a better (or even easier) solution than improving the Linux/X11 input methods? Yeah, good question :) Some reasons I know: - Some win32 input method using copyrighted input method tables, for those IME, we can't develop an alternative until the copyright is expired. - For speech-to-text input method, there are many different dialects in China, some of them are already pretty well handled by some commercial software, in theoretic we can develop alternative for them, but it takes some time, maybe that will not happen in near feature, before the chicken-and-egg problem is solved :) - For sogou pinyin and other IMEs using Statistical language model, the quality of the IME depends on not only the algorithm but also the thesaurus and corpus, currently the best open source SLM input method -- sunpinyin, has a good algorithm, but we have no any good thesaurus at all. Google and sogou use there web search engine as a source of thesaurus and corpus, new words are generated day by day, sogou and google collect them to there input method frequently. It is really hard to do the same thing for a non-profit open source project. -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: Translators wanted!
Hi Cheer, On Sun, Feb 26, 2012 at 10:19 PM, Cheer Xiao xiaqq...@gmail.com wrote: I had maintained zh_CN translation for quite some time, but haven't touched it for about a year (since Wine switched to po files). I might get down to cleaning up zh_CN.po in the near future, but I'll contact you before that. Great. I'll contact to you via gtalk. BTW, we have meet in Ubuntu Release Party in Tsinghua :) -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: Translators wanted!
Hello, If a group of people translated Wine on a web base platform such as [1], is it allowed to send a single large patch with a commit log which mentions all authors, but without details about which part exactly translated by which people? Thanks. [1] http://tryneeds.westart.tw/tryneeds/project/show/project_id/8/project_tree_id/4441 ,
Re: Translators wanted!
Hello, On Fri, Feb 17, 2012 at 2:13 AM, Francois Gouget fgou...@free.fr wrote: I feel that we should put out a call for translators to the wider community. In preparation for that I updated the Wiki's Translating page and added a winepo script to help translators who don't want to check out the whole Wine source: http://wiki.winehq.org/Translating I would like to help to update the Simplified Chinese translation, but most likely I have no enouth time to complete it before wine-1.4 final release. Could anyone give a deadline? If anyone would like to translate Simplified Chinese please post a reply here to prevent duplication work. Also I'll forward this mail to Traditional Chinese community, since as a native Simplified Chinese speaker I can't use Traditional Chinese correctly every time. Thanks Francois and the Wine community :) -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: Daily builds of latest Git now available as Ubuntu packages
On Thu, Sep 1, 2011 at 8:43 PM, Scott Ritchie sc...@open-vote.org wrote: Unfortunately I have to use Launchpad Recipe's supported substitution variables here, and while they do have one for the latest git-tag if I build locally this doesn't work on launchpad itself. The reason for this is that the launchpad recipe builders don't have git proper, but instead rely on bzr-git imports (the package is actually building off the launchpad bzr import of the Wine git tree merged with my packaging bzr branch). Yeah it's a bit lame, and I'll raise the issue with the launchpad folks when I see them next, but it's a pretty minor problem atm. Hello, Is there any good ways to get the git-describe-like version number from the daily build ppa version number? That's useful while running a regression test. For example, I'd like to know exactly what is wine1.3_1.3.28+daily-20110912 in http://bugs.winehq.org/show_bug.cgi?id=28450 . Thanks! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: Daily builds of latest Git now available as Ubuntu packages
On Wed, Sep 21, 2011 at 2:48 AM, Octavian Voicu octavian.vo...@gmail.com wrote: I'm guessing daily builds are done after daily commits, so you could use the build id (which is just a prefix of the last commit id) from here [1]. In your case, it's probably 9b729bb1b348 - 12-Sep-2011 15:45. Octavian [1] http://test.winehq.org/data/ Thanks Octavian, this tip helps a lot. Thanks Austin all the same ;) -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: Make sure This-bsc.doc will be initialized while opening a zero byte html file, fix bug 25999 . modified: dlls/mshtml/navigate.c
Hi Jacek, On Wed, Mar 9, 2011 at 12:41 AM, Jacek Caban ja...@codeweavers.com wrote: Hi Zuno, I don't think that's the right place for the fix. What's the exact problem you're trying to fix? AFAICS the only important difference your patch makes is that on_start_nsrequest will be always called in read_stream_data (possibly many times), but it's also called in on_stop_nsrequest if no data was read. Jacek Is there any update of this bug? Thanks! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Try to fix bug 25999 , patch for dlls/mshtml/navigate.c
Hi Jacek, It seems http://bugs.winehq.org/show_bug.cgi?id=25999 has no update from Wine developers, my friend Zhuo Wei has write a patch for it, tests in dlls/mshtml/tests are run on Wine, ( according to http://www.winehq.org/docs/winedev-guide/testing-wine ), every test passes successfully, could you help to review it ? Thanks a lot! From c5ee98396123c6cccdd295025a6b5aceb87dc0f7 Mon Sep 17 00:00:00 2001 From: Zhuo Wei zhuo.wei.m...@gmail.com Date: Mon, 7 Mar 2011 23:58:09 +0800 Subject: Make sure This-bsc.doc will be initialized while opening a zero byte html file, fix bug 25999 . modified: dlls/mshtml/navigate.c --- dlls/mshtml/navigate.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/dlls/mshtml/navigate.c b/dlls/mshtml/navigate.c index bb71c79..0e7a298 100644 --- a/dlls/mshtml/navigate.c +++ b/dlls/mshtml/navigate.c @@ -985,8 +985,6 @@ static HRESULT read_stream_data(nsChannelBSC *This, IStream *stream) read = 0; hres = IStream_Read(stream, This-nsstream-buf+This-nsstream-buf_size, sizeof(This-nsstream-buf)-This-nsstream-buf_size, read); -if(!read) -break; This-nsstream-buf_size += read; @@ -1014,6 +1012,9 @@ static HRESULT read_stream_data(nsChannelBSC *This, IStream *stream) on_start_nsrequest(This); } +if(!read) +break; + This-bsc.readed += This-nsstream-buf_size; nsres = nsIStreamListener_OnDataAvailable(This-nslistener, -- 1.7.1 -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/ From c5ee98396123c6cccdd295025a6b5aceb87dc0f7 Mon Sep 17 00:00:00 2001 From: Zhuo Wei zhuo.wei.m...@gmail.com Date: Mon, 7 Mar 2011 23:58:09 +0800 Subject: Make sure This-bsc.doc will be initialized while opening a zero byte html file, fix bug 25999 . modified: dlls/mshtml/navigate.c --- dlls/mshtml/navigate.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/dlls/mshtml/navigate.c b/dlls/mshtml/navigate.c index bb71c79..0e7a298 100644 --- a/dlls/mshtml/navigate.c +++ b/dlls/mshtml/navigate.c @@ -985,8 +985,6 @@ static HRESULT read_stream_data(nsChannelBSC *This, IStream *stream) read = 0; hres = IStream_Read(stream, This-nsstream-buf+This-nsstream-buf_size, sizeof(This-nsstream-buf)-This-nsstream-buf_size, read); -if(!read) -break; This-nsstream-buf_size += read; @@ -1014,6 +1012,9 @@ static HRESULT read_stream_data(nsChannelBSC *This, IStream *stream) on_start_nsrequest(This); } +if(!read) +break; + This-bsc.readed += This-nsstream-buf_size; nsres = nsIStreamListener_OnDataAvailable(This-nslistener, -- 1.7.1
A patch trying to fix Bug 25999 - wine builtin IE crash while opening file with zero bytes
Dear All, I'm trying to fix http://bugs.winehq.org/show_bug.cgi?id=25999 Below is my patch. This my first patch, I wonder weather it is ugly, I'm grateful for any advice. From 0598dc0acf14a18d28e78e7b924384c46040a81e Mon Sep 17 00:00:00 2001 From: Qian Hong fract...@gmail.com Date: Fri, 18 Feb 2011 04:46:41 +0800 Subject:modified: dlls/mshtml/navigate.c --- dlls/mshtml/navigate.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/dlls/mshtml/navigate.c b/dlls/mshtml/navigate.c index bb71c79..f978e8e 100644 --- a/dlls/mshtml/navigate.c +++ b/dlls/mshtml/navigate.c @@ -1106,7 +1106,8 @@ static HRESULT async_stop_request(nsChannelBSC *This) IBindStatusCallback_AddRef(This-bsc.IBindStatusCallback_iface); task-bsc = This; -push_task(task-header, stop_request_proc, This-bsc.doc-basedoc.doc_obj-basedoc.task_magic); +if(This-bsc.doc) +push_task(task-header, stop_request_proc, This-bsc.doc-basedoc.doc_obj-basedoc.task_magic); return S_OK; } -- Thanks very much! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces
On Wed, Feb 2, 2011 at 11:08 PM, Dan Kegel d...@kegel.com wrote: Qian wrote: 1. If a function is implemented in wine dll as a stup, then usually this function won't cause crash, and the wine debug will output fix:me ...stup rather then Unimplemented function, is it right? I think stub is somewhat ambiguous, it can mean either something without an implementation, or something with a very minimal implementation. But yes, if something is listed in dlls/*/*.spec as a stub, you get 'Unimplemented function', and if something is listed in grep FIXME.*stub dlls/*/*.c as a stub, you get fixme: ... stub. Thanks very much! I think now I understand. Thanks Ricardo as well. Grateful to you all! 2. If a function is listed in the Wine API guide, http://source.winehq.org/WineAPI/ , and marked as stup, then this function must be implemented as a stup in wine source code, is it right? The Wine API guide is not a very reliable guide, it might be out of date. Better to just look in the source code. - Dan -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces
Dear Nikolay and James, On Sun, Jan 30, 2011 at 11:09 PM, James McKenzie jjmckenzi...@earthlink.net wrote: Qian: I would like to echo Nikolay's comment and add one more: Please search through the Bug Reports before submitting a new one. I really feel very sorry, I apologize for posting such issues the wrong place and making noise. Thank you for your reminder and your nice work on wine. I have searched the Bugzilla with ntoskrnl.exe as keyword carefully, it seems that none of the current bugs mentions unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, so I report a new issue here: http://bugs.winehq.org/show_bug.cgi?id=25964 Wish it not a duplicate. You might receive more assistance on the Wine User list as well. Most of the developers lurk there. I'll post such mails on the Wine User list from now on. However, may I modestly consults below questions here: 1. If a function is implemented in wine dll as a stup, then usually this function won't cause crash, and the wine debug will output fix:me ...stup rather then Unimplemented function, is it right? 2. If a function is listed in the Wine API guide, http://source.winehq.org/WineAPI/ , and marked as stup, then this function must be implemented as a stup in wine source code, is it right? I've read http://wiki.winehq.org/DebugChannels and http://wiki.winehq.org/Developers-Hints, but I still have some confusion. Thanks a lot! Thank you. -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces
Dear all,
While test another online bank with wine ActiveX,
I got an unimplemented fuction of ntoskrnl: IoGetDeviceInterfaces,
I found it listed in http://source.winehq.org/WineAPI/ntoskrnl.html as a stup,
so I can't understand this log:
wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called
at address 0x7b839552 (thread 0022), starting debugger...
Grateful for any explain!
env:
wine1.3.12 on Ubuntu 10.04
Here are the steps:
1. install an ActiveX from
https://e.bank.ecitic.com/perbank5/plugs/CNCBSecPkg_EN.exe
$ rm -rf ~/.wine
$ winetricks -q mfc42
$ wine CNCBSecPkg_EN.exe
fixme:ole:DllRegisterServer stub
fixme:win:DisableProcessWindowsGhosting : stub
fixme:msg:ChangeWindowMessageFilter c057 0001
fixme:msg:ChangeWindowMessageFilter c057 0001
fixme:msg:ChangeWindowMessageFilter c057 0001
fixme:ole:CoCreateInstance no instance created for interface
{ea1afb91-9e28-4b86-90e9-9e9f8a5eefaf} of class
{56fdf344-fd6d-11d0-958a-006097c9a090}, hres is 0x80004002
fixme:sfc:SfcIsFileProtected ((nil), LC:\\Program
Files\\\4e2d\4fe1\94f6\884c\7f51\94f6\5b89\5168\63a7\4ef6\\unins000.exe)
stub
fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub!
fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 -1: stub!
fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub!
wine: Call from 0x7b839552 to unimplemented function
ntoskrnl.exe.IoGetDeviceInterfaces, aborting
wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called
at address 0x7b839552 (thread 002b), starting debugger...
wine: Call from 0x7b839552 to unimplemented function
ntoskrnl.exe.IoGetDeviceInterfaces, aborting
wine: Call from 0x7b839552 to unimplemented function
ntoskrnl.exe.IoGetDeviceInterfaces, aborting
2. open the online bank entry with wine builtin IE, then IE will crash:
$ wine iexplore https://e.bank.ecitic.com/perbank5/signIn.do
Please checkout the full log here:
http://pastebin.com/rbAg7gwj
Should I file a singel bug in ntoskrnl component , or separate bugs,
one for ntoskrnl and one for the IE crashing?
Generalliy what component should I switch while file a bug about IE crashing?
Many thanks!
--
Regards,
Qian Hong
-
Sent from Ubuntu
http://www.ubuntu.com/
