I have resubmitted this patch for discussion purposes.
Patch "user32/tests: Clarify the msgs to differentiate Unicode and ASCII in tests" cleans up existing tests for this situation and demonstrates the functionality.
The problem remains that the application passes to the dde/ddeml data that is of type LPBYTE. This can occur as a message post or a DDEML call. DDE operates in two ways.
* The first is the native DDE using POST and GET messaging. In this case data is passed without translation. * The second case uses DDEML. When using DDEML, the data is translated to and from Unicode depending on the server client window type. * However, there is a third case, the hybrid. In this case if the client uses messaging and posts a message, and the server uses DDEML translation will occur. If the client uses DDEML and the server uses a get to retrieve the message translation will not occur.
The data passed to DDE/DDEML is LPBYTE but it can be Unicode or ASCII regardless of the interface type of the client. In all cases the data is translated into the type of the server.
The issue is that the client passes data using messaging or DDEML there is no method in the api to inform the server whether the data is Unicode or not. The only method I have determined is to use IsTextUnicode() but that is guessing. However, it looks like Windows guesses too.
Can I get some advice on this as the existing code does need to be fixed.
Jeff
"Jeff Latimer" lats@yless4u.com.au wrote:
The issue is that the client passes data using messaging or DDEML there is no method in the api to inform the server whether the data is Unicode or not. The only method I have determined is to use IsTextUnicode() but that is guessing. However, it looks like Windows guesses too.
Have you looked at the info returned DdeQueryConvInfo, particularly iCodePage in the conversation context? Passing raw DDE messages should be out of interest, it's the application's problem.
Can I get some advice on this as the existing code does need to be fixed.
Is there a bug you are trying to fix, or is that a hypothetical problem?
Dmitry Timoshkov wrote:
"Jeff Latimer" lats@yless4u.com.au wrote:
The issue is that the client passes data using messaging or DDEML there is no method in the api to inform the server whether the data is Unicode or not. The only method I have determined is to use IsTextUnicode() but that is guessing. However, it looks like Windows guesses too.
Have you looked at the info returned DdeQueryConvInfo, particularly iCodePage in the conversation context?
No but it looks interesting. I will set up some tests and check it out.
Passing raw DDE messages should be out of interest, it's the application's problem.
DDE and DDEML are supposed to interchangeable. A DDE client can talk to a DDEML server and turnabout.
Can I get some advice on this as the existing code does need to be fixed.
Is there a bug you are trying to fix, or is that a hypothetical problem?
I was fixing a problem in winebrowser that was brought about by incorrect Unicode translation. I could not fix it on the client side because it broke DDE tests.
"Jeff Latimer" lats@yless4u.com.au wrote:
Passing raw DDE messages should be out of interest, it's the application's problem.
DDE and DDEML are supposed to interchangeable. A DDE client can talk to a DDEML server and turnabout.
DDEML is just a wrapper around raw DDE messages, and raw DDE messages don't have a translation layer in the user32 messaging system.
Is there a bug you are trying to fix, or is that a hypothetical problem?
I was fixing a problem in winebrowser that was brought about by incorrect Unicode translation. I could not fix it on the client side because it broke DDE tests.
Is there a test that exactly replicates the problem? Or how to run winebrowser to reproduce it?
Dmitry Timoshkov wrote:
DDE and DDEML are supposed to interchangeable. A DDE client can talk to a DDEML server and turnabout.
DDEML is just a wrapper around raw DDE messages, and raw DDE messages don't have a translation layer in the user32 messaging system.
Agreed, the point I was making is that DDEML wraps the raw DDE, the translation occurs in the server not the client.
Is there a test that exactly replicates the problem? Or how to run winebrowser to reproduce it?
I don't have a test but the problem was demonstrated by the Firefly softphone. Clicking on the link to go to the users account fires of winebrowser. The winebrowser scenario assumes an ANSI to Unicode conversion. In Firefly's case the data was already Unicode and under went a conversion. I am not sure how to create a test for this or simulate it.
"Jeff Latimer" lats@yless4u.com.au wrote:
DDE and DDEML are supposed to interchangeable. A DDE client can talk to a DDEML server and turnabout.
DDEML is just a wrapper around raw DDE messages, and raw DDE messages don't have a translation layer in the user32 messaging system.
Agreed, the point I was making is that DDEML wraps the raw DDE, the translation occurs in the server not the client.
Does it really matter?
Is there a test that exactly replicates the problem? Or how to run winebrowser to reproduce it?
I don't have a test but the problem was demonstrated by the Firefly softphone. Clicking on the link to go to the users account fires of winebrowser. The winebrowser scenario assumes an ANSI to Unicode conversion. In Firefly's case the data was already Unicode and under went a conversion. I am not sure how to create a test for this or simulate it.
Another probability is a bug in winebrowser.
Dmitry Timoshkov wrote:
DDE and DDEML are supposed to interchangeable. A DDE client can talk to a DDEML server and turnabout.
DDEML is just a wrapper around raw DDE messages, and raw DDE messages don't have a translation layer in the user32 messaging system.
Agreed, the point I was making is that DDEML wraps the raw DDE, the translation occurs in the server not the client.
Does it really matter?
It highlights the problem and that the translation should take place in the server. In earlier discussions last year this was an issue.
Another probability is a bug in winebrowser.
It may well be, it certainly is implemented for one case only at present but if the DDEML code was implemented as the Windows is then it does not matter as the situation is handled.
"Jeff Latimer" lats@yless4u.com.au wrote:
Agreed, the point I was making is that DDEML wraps the raw DDE, the translation occurs in the server not the client.
Does it really matter?
It highlights the problem and that the translation should take place in the server. In earlier discussions last year this was an issue.
Again, do you have a test case for that as a proof?
Another probability is a bug in winebrowser.
It may well be, it certainly is implemented for one case only at present but if the DDEML code was implemented as the Windows is then it does not matter as the situation is handled.
Have you tested winebrowser under Windows to see if that's the case? And again, a test replicating the problem is required in order to avoid a regression in future.
Dmitry Timoshkov wrote:
It highlights the problem and that the translation should take place in the server. In earlier discussions last year this was an issue.
Again, do you have a test case for that as a proof?
When solving the winebrowser problem, I was fixing the existing translation code in dde_client.c. This broke the raw dde tests. At that point I had a close look the results deduced that the code needed to be moved but a substantial test case had to be developed to demonstrate the situation. I submitted the following dde.c tests: /* Test the combinations of A and W interfaces with A and W data end to end to ensure that data conversions are accurate */ sprintf(buffer, "%s dde enda", argv[0]); CreateProcessA(NULL, buffer, NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, NULL, &startup, &proc);
test_end_to_end_server(proc.hProcess, proc.hThread, TRUE);
sprintf(buffer, "%s dde endw", argv[0]); CreateProcessA(NULL, buffer, NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, NULL, &startup, &proc);
test_end_to_end_server(proc.hProcess, proc.hThread, FALSE);
sprintf(buffer, "%s dde enda", argv[0]); CreateProcessA(NULL, buffer, NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, NULL, &startup, &proc);
test_end_to_end_server(proc.hProcess, proc.hThread, FALSE);
sprintf(buffer, "%s dde endw", argv[0]); CreateProcessA(NULL, buffer, NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, NULL, &startup, &proc);
test_end_to_end_server(proc.hProcess, proc.hThread, TRUE);
These tests have todo's that are fixed by this patch we are discussing. The existing code dde_client is actually broken as it does not handle the todo's that are retired by this patch. I am not sure that I can demonstrate the problem without "fixing" the existing code to demonstrate that it breaks the raw dde tests. Do I have to go to this trouble to prove the case?
Have you tested winebrowser under Windows to see if that's the case?
I did not know that we could do that. I will have a look at it.
And again, a test replicating the problem is required in order to avoid a regression in future.
The tests I have previously had accepted actually demonstrate the problem and guard against regression.
Dmitry Timoshkov wrote:
"Jeff Latimer" lats@yless4u.com.au wrote:
The issue is that the client passes data using messaging or DDEML there is no method in the api to inform the server whether the data is Unicode or not. The only method I have determined is to use IsTextUnicode() but that is guessing. However, it looks like Windows guesses too.
Have you looked at the info returned DdeQueryConvInfo, particularly iCodePage in the conversation context?
I have inserted DdeQueryConvInfo into dde.c for checking whether it would help in determining the Unicodeness of the passed data. The results are below. The tests are to pass two messages, the 1st is non Unicode and 2nd is Unicode. As can be seen, DdeQueryConvInfo does not help with determining if the data is Unicode as the codepage is determined by the Client initialisation not from the data.
dde.c:2472: start end to end server ASCII dde.c:2403: Start end to end client ASCII dde.c:2275: server iCodePage=1004 dde.c:2440: client iCodePage=1004 dde.c:2275: server iCodePage=1004 dde.c:2452: client iCodePage=1004 dde: 15 tests executed (0 marked as todo, 0 failures), 0 skipped. dde.c:2472: start end to end server UNICODE dde.c:2403: Start end to end client UNICODE dde.c:2275: server iCodePage=1200 dde.c:2440: client iCodePage=1200 dde.c:2275: server iCodePage=1200 dde.c:2452: client iCodePage=1200 dde: 15 tests executed (0 marked as todo, 0 failures), 0 skipped. dde.c:2472: start end to end server UNICODE dde.c:2403: Start end to end client ASCII dde.c:2275: server iCodePage=1004 dde.c:2440: client iCodePage=1004 dde.c:2275: server iCodePage=1004 dde.c:2452: client iCodePage=1004 dde: 15 tests executed (0 marked as todo, 0 failures), 0 skipped. dde.c:2472: start end to end server ASCII dde.c:2403: Start end to end client UNICODE dde.c:2275: server iCodePage=1200 dde.c:2440: client iCodePage=1200 dde.c:2275: server iCodePage=1200 dde.c:2452: client iCodePage=1200
Server code issuing the query pConvInfo.cb = sizeof(pConvInfo); err = DdeQueryConvInfo(hconv, QID_SYNC, &pConvInfo); ok(err == TRUE, "should be the number of bytes not %d\n", err); err = DdeGetLastError(server_pid); ok(err == DMLERR_NO_ERROR, "wrong dde error %x\n", err); trace("server iCodePage=%d\n", pConvInfo.ConvCtxt.iCodePage);
Client code issuing the query pConvInfo.cb = sizeof(pConvInfo); err = DdeQueryConvInfo(hconv, QID_SYNC, &pConvInfo); ok(err == TRUE, "should be the number of bytes not %d\n", err); err = DdeGetLastError(client_pid); ok(err == DMLERR_NO_ERROR, "wrong dde error %x\n", err); trace("Client iCodePage=%d\n", pConvInfo.ConvCtxt.iCodePage);
-
Dmitry Timoshkov -
Jeff Latimer