Re: [WineHQ][WWN] WWN 362 - Brought to you by Edward Savage
Zachary Goldberg wrote: +topicAppDB / BugZilla/topic +centerbBugZilla Changes:/b/center +p +center +table border=1 bordercolor=#22 cellspacing=0 cellpadding=3 +tr +td align=center + bCategory/b +/td +td +bTotal Bugs Last Issue/b +/td +td + bTotal Bugs This Issue/b +/td +td + bNet Change/b +/td +/tr + +tr +td align=center + UNCONFIRMED +/td +td align=center + 2795 +/td +td align=center + 2821 +/td + +td align=center + +26 +/td +/tr + +tr +td align=center + NEW +/td +td align=center + 2677 +/td +td align=center + 2683 +/td + +td align=center + +6 +/td +/tr + +tr +td align=center + ASSIGNED +/td +td align=center + 28 +/td +td align=center + 26 +/td + +td align=center + -2 +/td +/tr + +tr +td align=center + REOPENED +/td +td align=center + 119 +/td +td align=center + 117 +/td + +td align=center + -2 +/td +/tr + +tr +td align=center + CLOSED +/td +td align=center + 3 +/td +td align=center + 1 +/td + +td align=center + -2 +/td +/tr + +tr +td align=center + TOTAL OPEN +/td +td align=center + 5619 +/td +td align=center + 5647 +/td +td align=center + +28 +/td +/tr +tr +td align=center + TOTAL +/td +td align=center + 5622 +/td +td align=center + 5648 +/td +td align=center + +26 +/td +/tr +/table Hey Zach, This says that there is 1 closed bug, while there must be thousands. That can't be right. Also, it doesn't say anything about not-closed resolved bugs (like fixed ones), so it doesn't say anything about the real total. Sven
Re: [kernel32] Return the correct processor arch and type in wow64 mode
On 05/13/2010 01:54 AM, (Marvin) wrote: Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2036 Your paranoid android. === W98SE (32 bit process) === Failure running script in VM: Exceeded timeout limit of 315 sec Hi, This is a false positive. The Win9x kernel32 tests have always shown such behavior. This of course needs to be fixed but has nothing to do with this patch. Notice the kernel32:process done (0) in the log for Win98. I'm not sure if this behavior is caused by the tests themselves or whether it's caused by some interaction issues when run from a command prompt (or batch file like WTB is doing). -- Cheers, Paul.
Re: urlmon: CreateUri should return E_INVALIDARG for NULL args.
On 05/13/2010 04:49 AM, Thomas Mullaly wrote:
@@ -75,6 +77,22 @@ static void test_CreateUri_InvalidFlags(void) {
}
}
+/*
+ * CreateUri returns E_INVALIDARG if the IUri it recieves is NULL.
+ * CreateUri returns E_INVALIDARG if the uri string is NULL and sets the IUri
to NULL.
+ */
I don't think these comments are needed as the same is shown in the
tests below (I was actually triggered by the wrong spelling of
'receives' btw).
+static void test_CreateUri_InvalidArgs(void) {
+HRESULT hr;
+IUri*uri = (void*) 0xdeadbeef;
+
+hr = pCreateUri(http_urlW, 0, 0, NULL);
+ok(hr == E_INVALIDARG, Error: CreateUri returned 0x%08x, expected
0x%08x\n, hr, E_INVALIDARG);
+
+hr = pCreateUri(NULL, 0, 0,uri);
+ok(hr == E_INVALIDARG, Error: CreateUri returned 0x%08x, expected
0x%08x\n, hr, E_INVALIDARG);
+ok(uri == NULL, Error: Expected the IUri to be NULL, but it was %p
instead\n, uri);
+}
--
Cheers,
Paul.
Re: [PATCH 0/2] Unaligned mmap() on Mac OS X
Charles Davis cda...@mymail.mines.edu writes: On 5/12/10 5:37 PM, Ken Thomases wrote: What problems does this cause? It makes Wine use more memory than it needs to. In theory, but in practice it's not worth the trouble. We used to do this on Linux but it has been removed. It's definitely not worth breaking libwine compatibility for this. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 5/5] server: get rid of sock_try_event
Mike Kaplinskiy mike.kaplins...@gmail.com writes: We *might* need to ignore POLLERR messages for UDP sockets, as the condition is actually temporary and sock_try_event was hiding this. It doesn't work here: ../../../tools/runtest -q -P wine -M ws2_32.dll -T ../../.. -p ws2_32_test.exe.so sock.c touch sock.ok sock.c:941: Test failed: some threads have not completed: 102 sock.c:3567: Tests skipped: WSAIoctl failed to get AcceptEx with ret -1 + errno 10045 make: *** [sock.ok] Error 1 -- Alexandre Julliard julli...@winehq.org
Re: More benchmarks of 3d performance comparing windows and linux
Am 10.05.2010 02:46, schrieb Dan Kegel: On Sun, May 9, 2010 at 4:14 PM, Dan Kegeld...@kegel.com wrote: in general, Wine's D3D version achieves only half to three-quarters the performance of Vista's. I just tried 'winetricks glsl-disable' on heaven2_d3d9. It sped it up about 8% (to 16.0 fps), but added some fun problems (e.g. scenes 7, 10, and 12 have a black sky). Sceenes 7, 10 and 12 are totally black here on wine on opengl. But the linux native client has the same problem. So I guess there opengl engine is lacking some futures.
Re: winemp3.acm: Fixes the Mac-specific code
Hi, It is good to see someone working on this code. But your patch makes it so that all the mp3 sound clips in the game that I was coding for stop working. trace:mpeg3:mp3_leopard_horse ndst 147456 0x2eab348 - 19901 0x2ea657c trace:mpeg3:mp3_leopard_horse First 16 bytes to input: \x00\x1f\x84\n\x92_\x81h\x00\x00\x00\x00\x00\x00\x00\x00 trace:mpeg3:mp3_leopard_horse Invalid header at 0x2ea657c I was also under the impression that a single input stream could come through as a series of ACMDM_STREAM_CONVERT messages that may or may not align as containing full packets or have a header on each call. This may not be what is happening here since it appear to be happening at the beginning of a given sound clip. But that is why I used the AudioFileStream (that and i was seeing apple documentation recommending so) -aric Kristofer Henriksson wrote: The current winemp3.acm does not work if the Mac-specific code is used. This rewrites the relevant portion to fix, for example, background music on things like Oblivion.
Re: More benchmarks of 3d performance comparing windows and linux
2010/5/13 Rico Schüller kgbric...@web.de: I just tried 'winetricks glsl-disable' on heaven2_d3d9. It sped it up about 8% (to 16.0 fps), but added some fun problems (e.g. scenes 7, 10, and 12 have a black sky). Sceenes 7, 10 and 12 are totally black here on wine on opengl. But the linux native client has the same problem. So I guess there opengl engine is lacking some futures. That's interesting. What graphics hardware + drivers are you using?
Re: urlmon: CreateUri should return E_INVALIDARG for NULL args.
On Thu, May 13, 2010 at 3:41 AM, Paul Vriens paul.vriens.w...@gmail.comwrote: I don't think these comments are needed as the same is shown in the tests below (I was actually triggered by the wrong spelling of 'receives' btw). Whoops. I always manage to misspell receive somehow... I'll submit a new patch here shortly. -- Thomas Mullaly thomas.mull...@gmail.com
Re: [Fwd: Re: winemp3.acm: Fixes the Mac-specific code]
Hi, I will admit that my understanding of both ACM drivers as well as the os x audio libraries are not perfect and mostly come from work on this code itself. So i will fully admit it is most likely full of areas needing improvement. Kristofer Henriksson wrote: Aric, I may have been operating under some faulty assumptions. I thought that all mp3 files would begin at the beginning and also keep track of how much of the source data the convert function said that it used. I am very careful to set the value of *nsrc to agree with how much source data was successfully used and assume that the calling function with resend the data that is not used. If this is done, it ensures a valid frame at the start of each invocation. Yes, a proper application should do just that. It should be tracking the value in nsrc and resend unused data at the beginning of the next buffer. You get a lot of the expected source stream format from MPEG3_StreamOpen. With that i wonder if the presence of an ID3 tag becomes optional. My familiarity with mp3 format makes me unsure if a packet header would also be required. As far as using AudioFileStream, I tried for a bit to get it to work before I wrote my own custom mp3 parser. I'm running Snow Leopard (10.6.3) and never got the background music to work in Oblivion. One of the problems is that Mp3AudioConverterComplexInputDataProc needs to return an error if it will have more data in the future, rather than returning zero. However, even changing this, AudioFileStream seemed to be skipping a lot of mp3 frames. The lack of an error in that return is probably an oversight on my part. All the mp3 clips in the game i was working with where sent in one piece so there was only one pass through the loop that consumed all of the data. I am unsure why skipping mp3 frames would occure. My guess is that I am feeding the data in incorrectly and on those boundries between feeds frames are being ignored/corrupted or the like. If you tell me what are more appropriate assumptions I should be making in my parser, I can fix it to work the way it should. I suppose I am also assuming that it will usually receive at least one full packet, and if this is unjustified I can fix this as well. If I should expect calling functions to ignore the value of *nsrc, then I can just implement an internal single-packet buffer, and this should take care of the problem. I think the assumptions we need to investigate is the one about there being a packet header at the beginning. Maybe for non variable bit rate mp3s we just get the data given to us when the stream is opened. In fact, going on a hunch i just got your code to work great with my game! What i did was this: I added PACMDRVSTREAMINSTANCE adsi to Mp3GetPacketLength and then when you would return -1 if you could not determin the header I instead returned (192000 * 144) / adsi-pwfxDst-nSamplesPerSec. I picked that because it shows up in other areas of the code where we need to get a length. This is exciting also because there where a few mp3s that whre returning 'Fmt?' errors from the stream code and would not play. But with your patch and this change those clips played as well. Does that give you something to work with? You clearly understand mp3 format better than I. -aric
Re: [Fwd: Re: winemp3.acm: Fixes the Mac-specific code]
There is a bug in the code i just posted, It should clearly be adsi-pwfxSrc-nSamplesPerSec not Dst. Still works great, probibly because my tests had the same nSamplesPerSec for both Src and Dst. -aric Aric Stewart wrote: Hi, I will admit that my understanding of both ACM drivers as well as the os x audio libraries are not perfect and mostly come from work on this code itself. So i will fully admit it is most likely full of areas needing improvement. Kristofer Henriksson wrote: Aric, I may have been operating under some faulty assumptions. I thought that all mp3 files would begin at the beginning and also keep track of how much of the source data the convert function said that it used. I am very careful to set the value of *nsrc to agree with how much source data was successfully used and assume that the calling function with resend the data that is not used. If this is done, it ensures a valid frame at the start of each invocation. Yes, a proper application should do just that. It should be tracking the value in nsrc and resend unused data at the beginning of the next buffer. You get a lot of the expected source stream format from MPEG3_StreamOpen. With that i wonder if the presence of an ID3 tag becomes optional. My familiarity with mp3 format makes me unsure if a packet header would also be required. As far as using AudioFileStream, I tried for a bit to get it to work before I wrote my own custom mp3 parser. I'm running Snow Leopard (10.6.3) and never got the background music to work in Oblivion. One of the problems is that Mp3AudioConverterComplexInputDataProc needs to return an error if it will have more data in the future, rather than returning zero. However, even changing this, AudioFileStream seemed to be skipping a lot of mp3 frames. The lack of an error in that return is probably an oversight on my part. All the mp3 clips in the game i was working with where sent in one piece so there was only one pass through the loop that consumed all of the data. I am unsure why skipping mp3 frames would occure. My guess is that I am feeding the data in incorrectly and on those boundries between feeds frames are being ignored/corrupted or the like. If you tell me what are more appropriate assumptions I should be making in my parser, I can fix it to work the way it should. I suppose I am also assuming that it will usually receive at least one full packet, and if this is unjustified I can fix this as well. If I should expect calling functions to ignore the value of *nsrc, then I can just implement an internal single-packet buffer, and this should take care of the problem. I think the assumptions we need to investigate is the one about there being a packet header at the beginning. Maybe for non variable bit rate mp3s we just get the data given to us when the stream is opened. In fact, going on a hunch i just got your code to work great with my game! What i did was this: I added PACMDRVSTREAMINSTANCE adsi to Mp3GetPacketLength and then when you would return -1 if you could not determin the header I instead returned (192000 * 144) / adsi-pwfxDst-nSamplesPerSec. I picked that because it shows up in other areas of the code where we need to get a length. This is exciting also because there where a few mp3s that whre returning 'Fmt?' errors from the stream code and would not play. But with your patch and this change those clips played as well. Does that give you something to work with? You clearly understand mp3 format better than I. -aric
Re: [PATCH 5/5] server: get rid of sock_try_event
On Thu, May 13, 2010 at 6:28 AM, Alexandre Julliard julli...@winehq.org wrote: Mike Kaplinskiy mike.kaplins...@gmail.com writes: We *might* need to ignore POLLERR messages for UDP sockets, as the condition is actually temporary and sock_try_event was hiding this. It doesn't work here: ../../../tools/runtest -q -P wine -M ws2_32.dll -T ../../.. -p ws2_32_test.exe.so sock.c touch sock.ok sock.c:941: Test failed: some threads have not completed: 102 sock.c:3567: Tests skipped: WSAIoctl failed to get AcceptEx with ret -1 + errno 10045 make: *** [sock.ok] Error 1 -- Alexandre Julliard julli...@winehq.org Hmm, this turns out to be somewhat intermittent. Looks like I forgot one of the patches in the series (we tend to ignore POLLHUP on SOCK_SHUTDOWN_EOF). Sorry about that, I'll resend for tomorrow. The patches before this one should be ok. Mike.
Re: More benchmarks of 3d performance comparing windows and linux
Am 13.05.2010 14:52, schrieb Dan Kegel: 2010/5/13 Rico Schüllerkgbric...@web.de: I just tried 'winetricks glsl-disable' on heaven2_d3d9. It sped it up about 8% (to 16.0 fps), but added some fun problems (e.g. scenes 7, 10, and 12 have a black sky). Sceenes 7, 10 and 12 are totally black here on wine on opengl. But the linux native client has the same problem. So I guess there opengl engine is lacking some futures. That's interesting. What graphics hardware + drivers are you using? Geforce 8800 GTS, 195.36.15 It could also be a bad driver. Could you see all scenes correctly using Heaven_gl.bat ? The easiest way to detect this is to run two copys, one with d3d9 and one with opengl. This way one could see, when a scene is not drawn. Otherwise you could think that the black screen is only the scene switching.
Re: Release plans
On Wed, 12 May 2010, Alexandre Julliard wrote: Scott Ritchie sc...@open-vote.org writes: On 05/09/2010 05:00 PM, Alexandre Julliard wrote: We definitely need a release changelog, yes. It seems to me what we really want is more than a changelog but a proper release announcement. I want a journalist who has hardly heard of Wine to read the page and understand what we've done and why it's great. Sure, that's the press release, we should have one too, but it's a different thing. A changelog would be a detailed description of changes that matter from a user point of view. It would list for instance new builtin programs, new configuration options, new behaviors, new system dependencies, backwards compatibility concerns, etc. Isn't that more a release notes document? So we'd have: * Press Release Announcing the new Wine to the world at large. Must be readable by people who have never heard of Wine before. * Release notes A user friendly and high-level description what's new and what's changed. * Changelog A detailed description of what's changed from a developper perspective, that is the usual list of commit messages. -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.
Re: comctl32/tests: Remove variable res which is not really used from test_monthcal_size.
On Thu, 6 May 2010, Nikolay Sivov wrote: -res = SendMessage(hwnd, MCM_GETMINREQRECT, 0, (LPARAM)r1); +SendMessage(hwnd, MCM_GETMINREQRECT, 0, (LPARAM)r1); Actually it won't hurt to test for it here. Okay. I am currently testing a patch that does exactly that in both cases. Thanks for the constructive feedback! Gerald
Re: advpack: Only do_ocx_reg (and thus DllRegisterServer) from RegisterOCX when 'N' is passed as a flag. Clarify documentation.
On Tue, 11 May 2010, James Hawkins wrote: I'm very hesitant about this. MSDN has no documentation about RegisterOCX, so I'm not sure how you're justifying this change. It's been a long time since I worked on this, so I don't remember much, but I do remember testing this method and documenting the parameters correctly. Where are you getting information that 'I' is required when using 'N'? I had to look again, and it seems the best I managed to find is the following: http://msdn.microsoft.com/en-us/library/bb759846%28VS.85%29.aspx If you experimentally verified something differently I will be happy to follow that. However, I did not found the original documentation sufficiently clear to really use it as a specification to base the implementation on. Specific questions I ran into were: - what happens if none of these are specified? - can the string contain more than one character? (pressumably yes?) - what happens if both are specified? Would you feel more comfortable leaving the documentation as is and me just suggesting the following? if(strchrW(str_flags,'I')) hr = do_ocx_reg(hm, TRUE); to replace hr = do_ocx_reg(hm, TRUE); ? Or would you prefer to submit a patch to clarify the documentation (copying me) and based on that I hack the code? That way we'd ensure that the former is sufficiently clear and I assume you'll verify whether the code matches that? Whatever works for you as long as we make progress. :-) Gerald
Re: [Fwd: Re: winemp3.acm: Fixes the Mac-specific code]
I think the reason why your change works is that it seems the AudioConverter doesn't care if it has invalid data at the beginning of its stream. There will be however a little creeping error in computation of frame lengths over time, which is that there may or may not be one extra byte of padding on any given frame, and you need to look at the frame header to know if it's there. Ignoring the padding is essentially equivalent to ignoring the remainder in the division you do to get the frame size. I'm still perplexed why the very first call to the conversion function will not start the source data with an ID3 tag or a frame header. The data shouldn't start in the middle of a frame, and there should be nothing else in an MP3 file than frames and ID3. At any rate, I can fix my code to properly sync to MP3 frames, and then the padding should be properly picked up as well. Regards, Kristofer On Thu, May 13, 2010 at 12:46 PM, Aric Stewart a...@codeweavers.com wrote: There is a bug in the code i just posted, It should clearly be adsi-pwfxSrc-nSamplesPerSec not Dst. Still works great, probibly because my tests had the same nSamplesPerSec for both Src and Dst. -aric Aric Stewart wrote: Hi, I will admit that my understanding of both ACM drivers as well as the os x audio libraries are not perfect and mostly come from work on this code itself. So i will fully admit it is most likely full of areas needing improvement. Kristofer Henriksson wrote: Aric, I may have been operating under some faulty assumptions. I thought that all mp3 files would begin at the beginning and also keep track of how much of the source data the convert function said that it used. I am very careful to set the value of *nsrc to agree with how much source data was successfully used and assume that the calling function with resend the data that is not used. If this is done, it ensures a valid frame at the start of each invocation. Yes, a proper application should do just that. It should be tracking the value in nsrc and resend unused data at the beginning of the next buffer. You get a lot of the expected source stream format from MPEG3_StreamOpen. With that i wonder if the presence of an ID3 tag becomes optional. My familiarity with mp3 format makes me unsure if a packet header would also be required. As far as using AudioFileStream, I tried for a bit to get it to work before I wrote my own custom mp3 parser. I'm running Snow Leopard (10.6.3) and never got the background music to work in Oblivion. One of the problems is that Mp3AudioConverterComplexInputDataProc needs to return an error if it will have more data in the future, rather than returning zero. However, even changing this, AudioFileStream seemed to be skipping a lot of mp3 frames. The lack of an error in that return is probably an oversight on my part. All the mp3 clips in the game i was working with where sent in one piece so there was only one pass through the loop that consumed all of the data. I am unsure why skipping mp3 frames would occure. My guess is that I am feeding the data in incorrectly and on those boundries between feeds frames are being ignored/corrupted or the like. If you tell me what are more appropriate assumptions I should be making in my parser, I can fix it to work the way it should. I suppose I am also assuming that it will usually receive at least one full packet, and if this is unjustified I can fix this as well. If I should expect calling functions to ignore the value of *nsrc, then I can just implement an internal single-packet buffer, and this should take care of the problem. I think the assumptions we need to investigate is the one about there being a packet header at the beginning. Maybe for non variable bit rate mp3s we just get the data given to us when the stream is opened. In fact, going on a hunch i just got your code to work great with my game! What i did was this: I added PACMDRVSTREAMINSTANCE adsi to Mp3GetPacketLength and then when you would return -1 if you could not determin the header I instead returned (192000 * 144) / adsi-pwfxDst-nSamplesPerSec. I picked that because it shows up in other areas of the code where we need to get a length. This is exciting also because there where a few mp3s that whre returning 'Fmt?' errors from the stream code and would not play. But with your patch and this change those clips played as well. Does that give you something to work with? You clearly understand mp3 format better than I. -aric
Re: [1/3] user32: Convert data in WM_DDE_EXECUTE to unicode when expected.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2058 Your paranoid android. === W98SE (32 bit dde) === dde.c:586: Test failed: Expected TestDDEServer(, got TestDDEServer:(04dc) dde.c:588: Test failed: Got size 20 for TestDDEServer:(04dc) dde.c:659: Test failed: Expected 1, got 0 dde.c:692: Test failed: Expected 12, got 28 dde.c:700: Test failed: Expected 1, got 0 dde.c:922: Test failed: Expected FALSE, got 1 dde.c:939: Test failed: Expected item atom, got dde.c:942: Test failed: Expected poke, got dde.c:943: Test failed: Expected 4, got 0 dde.c:692: Test failed: Expected 12, got 28 dde.c:934: Test failed: Expected 0, got c1ae dde.c:935: Test failed: Expected empty string, got 4 dde.c:731: Test failed: Expected '[Command(Var)]', got (null) dde.c:732: Test failed: Expected 15, got 12 dde.c:939: Test failed: Expected item atom, got dde.c:750: Test failed: DdeGetData should have returned 17 not 0 dde.c:756: Test failed: Expected '[Command-2(Var)]' got t dde.c:757: Test failed: Expected 17, got 0 dde.c:886: Test failed: Execpted execute hglobal, got dde.c:892: Test failed: Expected '[Command(Var)]', got (null) dde.c:737: Test failed: Expected '[BadCommand(Var)]', got [Command(Var)] dde.c:738: Test failed: Expected 18, got 32 dde.c:895: Test failed: Expected TRUE, got 0 dde.c:896: Test failed: Expected '[Command-2(Var)]', got [Command(Var)] dde.c:714: Test failed: Expected 9 or 11, got 12 dde.c:901: Test failed: Expected '[BadCommand(Var)]', got [Command-2(Var)] dde.c:714: Test failed: Expected 9 or 11, got 13 dde.c:857: Test failed: Expected 2, 3, 4, 6, 7, 8, 9, 10 or 11, got 12 dde.c:918: Test failed: Expected TRUE, got 0 dde.c:939: Test failed: Expected item atom, got 008307f4 dde.c:812: Test failed: client failed with 15 error(s) dde.c:2040: Test failed: Expected 0xcafebabe, got 0884 dde.c:2041: Test failed: Expected 0xdeadbeef, got 0083
Re: [3/3] user32: Convert data in WM_DDE_EXECUTE to ansi when expected.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2059 Your paranoid android. === W98SE (32 bit dde) === dde.c:586: Test failed: Expected TestDDEServer(, got TestDDEServer:(04dc) dde.c:588: Test failed: Got size 20 for TestDDEServer:(04dc) dde.c:659: Test failed: Expected 1, got 0 dde.c:692: Test failed: Expected 12, got 28 dde.c:700: Test failed: Expected 1, got 0 dde.c:922: Test failed: Expected FALSE, got 1 dde.c:939: Test failed: Expected item atom, got dde.c:942: Test failed: Expected poke, got dde.c:943: Test failed: Expected 4, got 0 dde.c:692: Test failed: Expected 12, got 28 dde.c:934: Test failed: Expected 0, got c1ae dde.c:935: Test failed: Expected empty string, got 4 dde.c:731: Test failed: Expected '[Command(Var)]', got (null) dde.c:732: Test failed: Expected 15, got 12 dde.c:939: Test failed: Expected item atom, got dde.c:750: Test failed: DdeGetData should have returned 17 not 0 dde.c:756: Test failed: Expected '[Command-2(Var)]' got t dde.c:757: Test failed: Expected 17, got 0 dde.c:886: Test failed: Execpted execute hglobal, got dde.c:892: Test failed: Expected '[Command(Var)]', got (null) dde.c:737: Test failed: Expected '[BadCommand(Var)]', got [Command(Var)] dde.c:738: Test failed: Expected 18, got 32 dde.c:895: Test failed: Expected TRUE, got 0 dde.c:896: Test failed: Expected '[Command-2(Var)]', got [Command(Var)] dde.c:714: Test failed: Expected 9 or 11, got 12 dde.c:901: Test failed: Expected '[BadCommand(Var)]', got [Command-2(Var)] dde.c:714: Test failed: Expected 9 or 11, got 13 dde.c:857: Test failed: Expected 2, 3, 4, 6, 7, 8, 9, 10 or 11, got 12 dde.c:918: Test failed: Expected TRUE, got 0 dde.c:939: Test failed: Expected item atom, got 008307f4 dde.c:812: Test failed: client failed with 15 error(s) dde.c:2040: Test failed: Expected 0xcafebabe, got 0884 dde.c:2041: Test failed: Expected 0xdeadbeef, got 0083
Re: gdi32: use usp10 to optionally generate glyphs for bidi strings
Aric Stewart a...@codeweavers.com wrote: allows us to be able to make use of the mirroring code and eventually the shaping code when it is in place. This should be done the other way around. gdi32 should not depend on a high level dll (that creates circular dependencies), gdi32 in Windows doesn't use usp10 either. -- Dmitry.
