Re: [3/4] gdi32: IntersectClipRect should update actual clipping region for a EMF DC.
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=24396 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: [2/4] gdi32: OffsetClipRgn should update actual clipping region for a EMF DC.
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=24395 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: [1/4] gdi32: Add more EMF clipping tests.
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=24394 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().
Johannes Kroll wrote: >It is in the log line that you deleted. Oops. >No, I don't have wineOSS. Does it require a proper OSSv4? Currently, yes. You'd have to try out wine-1.3.24 or older. I'll try and see how to use virtual MIDI devices to dump data without using a serial port. Anyway, I'll start writing a patch that decomposes LongMsg into snippets, although I don't know how to handle the three 00 00 00 bytes. Regards, Jörg Höhle
Re: [PATCH] dsound: copy program parameters in SetFormat
On Mon, Feb 11, 2013 at 02:06:42PM +0100, Maarten Lankhorst wrote: > Fixes bug #32312, apparently some programs depend on the format it specifies > being returned. > > Just set wBitsPerSample, nSamplesPerSec and nChannels to make those > applications happy. > The patch seems fine, but can you add some tests for this so we can nail down exactly what we should be taking from the SetFormat format? E.g. should we just do "device->primary_fmt = CopyFormat(passed_fmt)" in all cases, or can you find a case where the GetFormat() result is changed? FYI, your patch applies with an offset and the Wine patch tracker didn't like this: > --- a/dlls/dsound/primary.c > +++ a/dlls/dsound/primary.c but git-am imported the raw mail file just fine. Andrew
Re: winmm: More compatible waveIn/Out[Un]Prepare WHDR_* flag handling.
These two patches look fine to me. Thanks! On Mon, Feb 11, 2013 at 01:28:09PM +0100, joerg-cyril.hoe...@t-systems.com wrote: > Hi, > > This completes my winmm Prepare Header changes on the wave side. > > XyzPrepare: > +header->dwFlags &= ~(WHDR_DONE|WHDR_INQUEUE); /* flags cleared since w2k > */ > > I choose to implement the behavior since w2k. Hopefully this will not break > some w9x app. > > > WINMM_UnprepareHeader: > -header->dwFlags |= WHDR_DONE; > Never ever observed. Neither w95 nor xp or w7. > Perhaps MS would have been wise to do so, as simply looking at a header you > cannot > tell whether it's been processed or not (returned with error code). > I choose to implement compatible behaviour. > > > -if(!(lpWaveInHdr->dwFlags & WHDR_PREPARED)) > -return MMSYSERR_NOERROR; > if(lpWaveInHdr->dwFlags & WHDR_INQUEUE) > return WAVERR_STILLPLAYING; > +if(!(lpWaveInHdr->dwFlags & WHDR_PREPARED)) > +return MMSYSERR_NOERROR; > Note the subtle difference in behaviour between wave and midi headers... > > > >IMHO calling named winmm:xyz functions should be equivalent to dispatching > >MM* messages > > I forgot to add that I'm still surprised that Andrew Eikum could reimplement > waveIn/OutMessage *without* using MMDRV_Message by simply returning > MMSYSERR_NOTSUPPORTED. > > Either all apps use the named winmm:waveIn/OutXyz functions instead of > calling waveOutMessage() > or nobody bothered to complain that some apps (perhaps w3.1 ones?) lack sound. > > That area obviously needs some testing... > > Regards, > Jörg Höhle
Re: kernel32: Indicate that HeapValidate called by GlobalHandle is not the sign of heap corruption.
Dmitry Timoshkov writes: > This helps to distinguish this one from real signs of heap corruption, > and saves quite a bit of effort analysing +heap or warn+heap logs. Avoiding HeapValidate would probably be a better approach. -- Alexandre Julliard julli...@winehq.org
Re: advapi32: Report world-access ownership by default for registry objects (try 2).
"Erich E. Hoover" writes: > The attached patch fixes an issue where the Opera installer expects > registry keys to return ownership information (Bug #32904), concluding > the cleanup of [Get|Set]NamedSecurityInfo. This patch addresses the > issue by ensuring that NULL owner and group information is never > returned for registry keys and instead returns the World SID (S-1-1-0) > when this information is unavailable, which is sufficient to keep the > Opera installer from encountering an error. The included test shows > that this behavior is essentially the case for system keys on Windows, > though the Administrators SID is returned instead. Since > GetNamedSecurityInfo historically returned the World SID, and several > other routines use it as well) I've opted to use the World SID for > now. We should do the same as Windows unless there's a very good reason to be different. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH] netstat: Clarify labels in UDP statistics.
On 2013-02-13 11:03, Frédéric Delanoy wrote: On Tue, Feb 12, 2013 at 7:56 PM, Lauri Kenttä wrote: On 2013-02-09 23:15, Frédéric Delanoy wrote: "Invalid Datagrams" is too vague. It could mean datagrams sent or received. I think it's pretty obvious. Nobody should send invalid datagrams anyway, especially not using any actual datagram functions, so it would be ridiculous to have a counter for it. Yet it's what Windows uses, and is more specific, so I don't really think this should modified Ok, I'll leave it alone. On 2013-02-13 11:03, Frédéric Delanoy wrote: I meant if you find a msgstr ambiguous(which is not really a problem for the "No ports" IMHO), you can use msgctxt so that other translators benefit as well. My main point is that "No Ports" is not only ambiguous but also wrong in two ways. Bad wording: Why "ports" and not only "port" when this only concerns the single destination port of each datagram? How can there not be a port when the datagram always has a port field which can't be empty? (The RFC says that zero means empty only in the source port field, which implies that zero could be a valid destination.) Bad meaning: dwNoPorts actually includes also datagrams with non-zero port if the port is closed (not listening). MSDN hints something like this, and this can be easily verified on Windows (2003 Server). Ambiguity: There are many kinds of "no" and many kinds of "ports", and most people (even programmers!) probably don't know what's a datagram with "no ports". Also, translating "X" is quite different from translating "number of received datagrams with X", even more so when the source text is inaccurate. Windows has lots of bad texts, I hope Wine doesn't need to provide "compatibility" for that. But if you still say so, I'll just add a msgctxt. -- Lauri Kenttä
Re: msi/tests: Move a couple of tests from install.c to msi.c.
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=24381
Your paranoid android.
=== WNT4WSSP6 (32 bit install) ===
install.c:5673: Test failed: Per-user icon file isn't where it's expected
(C:\WINNT\Profiles\Default User\Application
Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)
Re: winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().
On Wed, 13 Feb 2013 09:29:19 +0100
wrote:
> Hi,
>
> Johannes Kroll wrote:
>
> 9.532:003a:trace:midi:modLongData dwBufferLength=88 !
> f0 42 41 00 01 11 01 7f 4b 40 7a 01 7f 02 7f 7f .BA.K@z.
> 7f 7f 71 7f 40 01 7f 7f 7f 7f 03 7f 7f 01 01 00 ..q.@...
> 00 7f 06 02 7f 7f 01 40 00 00 7c 7f 00 7f 7f 7f ...@..|.
> 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f
> 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f
> 7f 7f 01 7f f7 00 00 00
>
> Could you please log dwBytesRecorded next to
> TRACE("dwBufferLength=%u !\n", lpMidiHdr->dwBufferLength);
>
> I once proved that dwBytesRecorded is what gets used with midiSTREAMout
I did. It is in the log line that you deleted. Immediately after the
hex dump...
TRACE("dwBufferLength=%u !\n", lpMidiHdr->dwBufferLength);
//~ TRACE(" %02X %02X %02X ... %02X %02X %02X\n",
//~ lpData[0], lpData[1], lpData[2],
lpData[lpMidiHdr->dwBufferLength-3],
//~ lpData[lpMidiHdr->dwBufferLength-2],
lpData[lpMidiHdr->dwBufferLength-1]);
{ unsigned long dwToGo;
#define dprintf(x...) fprintf(stderr, x)
for (dwToGo = 0; dwToGo < lpMidiHdr->dwBufferLength; dwToGo += 16)
{
DWORD i;
BYTEch;
for (i = 0; i < min(16, lpMidiHdr->dwBufferLength - dwToGo);
i++)
dprintf("%02x ", lpData[dwToGo + i]);
for (; i < 16; i++)
dprintf(" ");
for (i = 0; i < min(16, lpMidiHdr->dwBufferLength - dwToGo);
i++) {
ch = lpData[dwToGo + i];
dprintf("%c", (ch >= 0x20 && ch < 0x7F) ? ch : '.');
}
dprintf("\n");
}
TRACE("dwBytesRecorded=%d\n", lpMidiHdr->dwBytesRecorded);
}
> >So there is an F7 there... Maybe the app expects that the driver scans
> >through the buffer for the F7 and doesn't send the following bytes...
>
> Net.wisdom is that modLongData need be scanned for coalesced regular status
> messages, e.g. some people use it to play chords, arguing that one LongMsg is
> faster than 3 consecutive midiOutShortMsg. That's a patch yet to be written.
>
> However, I wouldn't know what to do with the three 00 bytes. That's not MIDI!
No. Maybe dwBytesRecorded *should* be the length of the data. But it
isn't, it's always zero. Yes, really, I checked in several runs.
> Also, I'm wondering what ALSA does with that packet. Do the bytes as shown
> really
> make their way over the serial port? (Perhaps you could use some virtual
> MIDI device
> to dump what ALSA processes internally?)
If I figure out a way to do that I'll let you know...
> Do you have a working wineOSS? WineOSS simply dumps the bytes one by one and
> does
> not require us to tell it what a sysex might be. I already tested that
> disguising a chord
> as an ALSA SysEx within midiOutLongMsg doesn't work (at least with a SW
> synth).
No, I don't have wineOSS. Does it require a proper OSSv4? Or would it
work with ALSA OSS emulation? I don't have 'real' OSS.
Re: gdi32: Make sure that actual clipping region is updated for a EMF DC.
Alexandre Julliard wrote: > >> > This patch not only fixes a todo_wine in the tests, but also makes print > >> > preview and printing work in a pretty large application. > >> > >> You would most likely have to do that for all the clipping functions then. > > > > Do you prefer a separate patch or resend this one? > > Either way is fine. A couple of tests for the other functions would > probably also be a good idea. Ok, I'll see what can be done regarding the tests for other clipping APIs, please consider accepting this patch in the mean time. -- Dmitry.
Re: gdi32: Make sure that actual clipping region is updated for a EMF DC.
Dmitry Timoshkov writes: > Alexandre Julliard wrote: > >> > This patch not only fixes a todo_wine in the tests, but also makes print >> > preview and printing work in a pretty large application. >> >> You would most likely have to do that for all the clipping functions then. > > Do you prefer a separate patch or resend this one? Either way is fine. A couple of tests for the other functions would probably also be a good idea. -- Alexandre Julliard julli...@winehq.org
Re: gdi32: Make sure that actual clipping region is updated for a EMF DC.
Alexandre Julliard wrote: > > This patch not only fixes a todo_wine in the tests, but also makes print > > preview and printing work in a pretty large application. > > You would most likely have to do that for all the clipping functions then. Do you prefer a separate patch or resend this one? -- Dmitry.
Re: gdi32: Make sure that actual clipping region is updated for a EMF DC.
Dmitry Timoshkov writes: > This patch not only fixes a todo_wine in the tests, but also makes print > preview and printing work in a pretty large application. You would most likely have to do that for all the clipping functions then. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH] netstat: Clarify labels in UDP statistics.
On Tue, Feb 12, 2013 at 7:56 PM, Lauri Kenttä wrote: > On 2013-02-09 23:15, Frédéric Delanoy wrote: >> >> "Invalid Datagrams" is too vague. It could mean datagrams sent or >> received. > > I think it's pretty obvious. Nobody should send invalid datagrams anyway, > especially not using any actual datagram functions, so it would be > ridiculous to have a counter for it. Yet it's what Windows uses, and is more specific, so I don't really think this should modified > > On 2013-02-09 23:15, Frédéric Delanoy wrote: >> >> If you want to disambiguate/explain, use message contexts as explained >> in http://wiki.winehq.org/Translating > > This isn't (only) a translation ambiguity issue, this is about the original > texts, especially "No Ports". > > Or are you trying to suggest that I add #msgctxt#udp_received_stats# to that > "Invalid Datagrams"? I meant if you find a msgstr ambiguous(which is not really a problem for the "No ports" IMHO), you can use msgctxt so that other translators benefit as well. Frédéric
winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().
Hi,
Johannes Kroll wrote:
9.532:003a:trace:midi:modLongData dwBufferLength=88 !
f0 42 41 00 01 11 01 7f 4b 40 7a 01 7f 02 7f 7f .BA.K@z.
7f 7f 71 7f 40 01 7f 7f 7f 7f 03 7f 7f 01 01 00 ..q.@...
00 7f 06 02 7f 7f 01 40 00 00 7c 7f 00 7f 7f 7f ...@..|.
7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f
7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f
7f 7f 01 7f f7 00 00 00
Could you please log dwBytesRecorded next to
TRACE("dwBufferLength=%u !\n", lpMidiHdr->dwBufferLength);
I once proved that dwBytesRecorded is what gets used with midiSTREAMout
>So there is an F7 there... Maybe the app expects that the driver scans
>through the buffer for the F7 and doesn't send the following bytes...
Net.wisdom is that modLongData need be scanned for coalesced regular status
messages, e.g. some people use it to play chords, arguing that one LongMsg is
faster than 3 consecutive midiOutShortMsg. That's a patch yet to be written.
However, I wouldn't know what to do with the three 00 bytes. That's not MIDI!
Also, I'm wondering what ALSA does with that packet. Do the bytes as shown
really
make their way over the serial port? (Perhaps you could use some virtual MIDI
device
to dump what ALSA processes internally?)
Do you have a working wineOSS? WineOSS simply dumps the bytes one by one and
does
not require us to tell it what a sysex might be. I already tested that
disguising a chord
as an ALSA SysEx within midiOutLongMsg doesn't work (at least with a SW synth).
Thank you,
Jörg Höhle
