February 2012 - Wine-Devel - list.winehq.org

Debugging WINE 1.3.24 with GDB

by louis＠museresearch.com

Hi All, I've been attempting to debug a WINElib application on Fedora 15 (WINE 1.3.24) and not having much success. Winedbg works, but using gdb I'm not able to see symbols or multiple threads. In Fedora 8, running GDB on wine-pthreads (and not wine!) used to work under 1.1.7. However, under 1.3.24 there's no wine-pthreads. I've also tried attaching to various threads after the program was running with little success. I'm also not having any success using "winedbg --gdb"-- the same thing happens there as if I'd run it using just gdb (strange). The big picture is that I'd like to get an IDE such as QtCreator or KDevelop to work debugging a WINE application. Any way that is possible would be a good solution for me; it doesn't necessarily have to be through GDB if there's another way. Thanks for your help in advance! -Louis

Feb. 29, 2012

Re: [PATCH] winepulse: Add pulse driver, v8

by Maarten Lankhorst

Op 29-02-12 17:29, Joerg-Cyril.Hoehle(a)t-systems.com schreef: > Hi, > > Chris is right about the format. The shared mode mixer ought to return FLOAT(32), > and it always appears to return the extensible format as a consequence. > For weird reasons, wineoss may return integer formats, but that's certainly > going to cause some unexpecting app to crash. I think it's because wineoss may not always have float support because mixing float in the kernel would require special attention. >> + assert(oldpad >= This->pad); > Wasn't there a discussion some time ago that asserts are bad? > Better back out, return INVALIDATED or some such, but don't crash the app > just because there's a problem with sound. (I agree that winmm&mmdevapi > ought to contain self/consistency tests). This is an internal consistency problem, somehow we have more sound queued than we know about. I think crashing is the best thing it's a genuine bug that should never be possible, if I don't crash it will manifest itself differently, presumably in a subtle impossible to find way.. Outside of that callback, the assertion This->pad == This->bufsize_bytes - pa_stream_writable_size should hold. > It would be nice if you could attach some > WINETEST_DEBUG=2 render.log 2>&1 to bugzilla somewhere. > There is stuff that do not cause a failure yet diverges from native. > > +static void pulse_wr_callback(pa_stream *s, size_t bytes, void *userdata) > + if (This->event) > + SetEvent(This->event); > This should be the last thing in the callback. It may well cause your thread > to be kicked out by the scheduler. Oops, thanks for catching, it's why the other setevents are the last indeed. > + if (filled_one && This->event) > + SetEvent(This->event); > Don't the capture tests prove that events get in even when the buffer is full? (please cross-check) You should get an event then, I steal the earliest full buffer. :) I don't think the full case is completely correctly handled yet. Unlike pulseaudio won't send multiples of fragsize, unlike for rendering, but since pa_stream_peek is guaranteed to return the same data until I drop it with pa_stream_drop, I suppose I could add a workaround that will only fill a multiple of periods. >> - Align buffer size to a multiple of period size > How can you pass the tests with that? It's wrong with both capture (annoyingly IMHO) and playback. > > I don't have more time now (and know nothing about the pa_* API). > Is pa_mainloop_run the thread that dispatches the pulse_xyz_callbacks? > > I wouldn't mind a winepulse driver in 1.4.0 > I only really need it for capture, rendering needs it too since the tests show that this is the case, but there's nothing in the code that depends on it. For capture it's different, you need to keep track of packets somehow. This is why I keep the meta information in little packets until the application has come around to read them. Having one packet that's not a period is a pain, and seems to be against the tests too that everything is a multiple of period. ~Maarten

Feb. 29, 2012

Re: po: Spanish translation update for cmd.rc (almost complete)

by Eduardo García

Sorry, attached the wrong patch, this one is the correct one. With regards. Eduardo. El 02/29/12 21:00, Eduardo García escribió: > This one was fun to do as I fouund a couple of "my hovercraft is full > of eels" phrases. > > With regards. > > Eduardo. > > > > >

Feb. 29, 2012

Re: po: Spanish translation update for cmd.rc (almost complete)

by Eduardo García

Sorry, attached the wrong patch, this one is the correct. With regards. Eduardo. El 02/29/12 21:00, Eduardo García escribió: > This one was fun to do as I fouund a couple of "my hovercraft is full > of eels" phrases. > > > > > > >

Feb. 29, 2012

Spelling errors in en_US translation

by Julian Rüger

Hi Francois, (and everybody else ;) are there any plans to create an ignore-list for these: http://fgouget.free.fr/wine-po/en_US.spell.html to be able to distinguish real typos from false positives? Most reported errors are false positives (like "codec" or "checksum") but there are real errors, or at least instances of uncommon spelling (like "customising", which is British English afaik, or "Cancelled") which should be fixed (after 1.4), imho. Best regards, Julian

Feb. 29, 2012

Re: Fix references to the LGPL

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > So the problem is that start.rc (it's always about start) > contains slightly incorrect references to the LGPL in its license > message (no less): I would say we should get rid of that license message. No other Wine command-line app does this, and we have the license in the about box already for graphical apps. This would also avoid the need for a different usage message in cmd. -- Alexandre Julliard julliard(a)winehq.org

Feb. 29, 2012

Re: AW: Major mmdevapi and winmm audio bugs

by Maarten Lankhorst

Hey Joerg, Having actually finished the pulseaudio implementation and trying to fix some fallout. Op 29-02-12 16:28, Joerg-Cyril.Hoehle(a)t-systems.com schreef: > Hi, > > Maarten Lankhorst wrote: >> For capture I plan to just add 2 queues, one for readable packets, and one >> for packets that can be filled for reading. > Winecoreaudio uses exactly this. Working now, with timestamps so all tests pass. IAudioClock::GetPosition I have to figure out still, I was allowing it to update based on stream time passed, but dsound fails with that, so I have to determine windows' behavior some more. >> ... for the pulse driver, I'm using the auto timing >> update feature and the callback for when rendering is not running. >> When the buffer is not underflowed, I'm using the write callback to >> signal more data is available. > I'm not familiar with PA's API, so I'm not following you. I'm not even > sure we talk about the same thing. Because pulseaudio receives all data on mainloop you can specify callbacks that will be run when those events are received too. I'm using the latency callback when first starting to signal the event when no data is playing. When data is buffered I use the pulse_rd_callback which fires every period because of pa_stream_early_requests. pulse_wr_callback is fired when there's at least a period buffered. >> I believe the event should be triggered when there is actual data >> available, at least that's how I understood the event is supposed >> to work. > I distinguish 2 events: > a) ALSA/PA backend ready for more data > b) mmdevapi SetEventHandle to the app > > Note that b) only exists when using EVENTCALLBACK. > > We have tests about b) that show that mmdevapi delivers events > to the app even when stopped (Wine fails those with todo_wine). I > don't know at what rate. Presumably at the same rate, but since in those cases you have no data I doubt it matters if you fire less often. > Regarding a), nothing prevents you from using the back-end's > favourite notification mechanism to wake up - or use a timer. Which my winepulse does. :) > I agree with you that ideally, somehow, b) and a) should be in sync, > otherwise we'll have clock skew and the XAudio scenario will exhibit > occasional underruns. > > But there are big HOWEVER: > - ALSA/PA may not grant us the period we'd like (10ms). 21.333ms is common with ALSA/dmix. > I don't know how important the 10ms are. > You're familiar with DSound, so perhaps you have an opinion why DSound > has been using 10ms intervals in Wine regardless of the back-end's period. > I believe that Wine ought to use the same rate as native or some app will exhibit a bug. If dmix doesn't support 10ms, set default period to 1024 samples and use that, no point in trying to do something it's not. Don't forget to update GetStreamLatency in that case, though. > - We do not need 10ms events when not using EVENTCALLBACK, so why not > write all available data (e.g. 333ms from winmm:PlaySound) and sleep > that much? Laptop owners will thank us. It's possible for winmm and dsound, but the drivers will have to keep the default period in any case, for when other mmdevapi programs rely on it. > - How to continue signaling type a events after IAudioClient_Stop? > By continuing to write silence to the back-end?!? Could work, I'm abusing the auto timing update from pulseaudio, which fires periodically as well, even when playing nothing. > - Last but not least, I don't know whether ALSA's signaling and mmdevapi's > SetEvent needs can be made compatible even when the periods would agree. > mmdevapi's SetEvent means "don't worry, you have one period time to write data" > or even "you may write data, but I already have buffered some". > ALSA/PA's signal means(?) "hurry up, you're on the verge of underrun". Please correct me. As far as my understanding of mmdevapi is, it fires every period. If you have some data gogogogo, but write at least GetStreamLatency worth of samples, or you'll have an underrun. That also means mmdevapi rendering will have to be periodic or bad things occur. > - The test_worst_case aka. XAudio scenario has tough requirements: > - Signal events not often enough and you'll enter an underrun. > - Signal events too early and it'll write no data. The event was wasted and > the next one may come too late to avoid an underrun. > > In summary, if the back-end guarantees 10ms wake-ups, you should be able to > nicely sync a) and b) (probably by writing silence when stopped...) > If not, then some mechanism must be there to decouple the two. Or never use anything but dmix/real hardware with winealsa and just use winepulse for pulseaudio. You know the period size in that case and can force a wake up. pulseaudio's alsa wrapper might have issues because it will wait until at least one frame is filled before marking it as such, in the worst case hiding the pulseaudio native length from alsa applications. > So far we've followed the "decouple" route in winealsa/oss. I believe the key to > the solution in mmdevapi will come from both being able to vary the sleeping > intervals to adapt to clock skew *and* not be bound to be exactly in sync with > the back-end, thanks to a latency-inducing buffer large enough to compensate > for the variability. > IOW, the design goal is to reach during normal playback a state where: > Event received => GetCurrentPadding has (or pretends to have) decreased by > at least 1 period (which implies there's room for writing). I think the key is to use accurate periods and report GetStreamLatency correctly. Use it in wine where needed for winmm and dsound. ~Maarten

Feb. 29, 2012

Re: [PATCH] winepulse: Add pulse driver, v8

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Chris is right about the format. The shared mode mixer ought to return FLOAT(32), and it always appears to return the extensible format as a consequence. For weird reasons, wineoss may return integer formats, but that's certainly going to cause some unexpecting app to crash. >+ assert(oldpad >= This->pad); Wasn't there a discussion some time ago that asserts are bad? Better back out, return INVALIDATED or some such, but don't crash the app just because there's a problem with sound. (I agree that winmm&mmdevapi ought to contain self/consistency tests). It would be nice if you could attach some WINETEST_DEBUG=2 render.log 2>&1 to bugzilla somewhere. There is stuff that do not cause a failure yet diverges from native. +static void pulse_wr_callback(pa_stream *s, size_t bytes, void *userdata) + if (This->event) + SetEvent(This->event); This should be the last thing in the callback. It may well cause your thread to be kicked out by the scheduler. + if (filled_one && This->event) + SetEvent(This->event); Don't the capture tests prove that events get in even when the buffer is full? (please cross-check) >- Align buffer size to a multiple of period size How can you pass the tests with that? It's wrong with both capture (annoyingly IMHO) and playback. I don't have more time now (and know nothing about the pa_* API). Is pa_mainloop_run the thread that dispatches the pulse_xyz_callbacks? I wouldn't mind a winepulse driver in 1.4.0 Regards, Jörg

Feb. 29, 2012

Re: gdiplus: Create a GDI brush only when needed.

by Vincent Povirk

Looks better. Maybe create_gdi_logbrush should fall back to creating a solid brush, so that pens with weird brushes set will do something vaguely sensible. Eventually, we will want to use a different implementation of pens that does not involve gdi32 in those cases. On Wed, Feb 29, 2012 at 2:29 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Vincent Povirk <madewokherd(a)gmail.com> wrote: > >> The right solution is to remove the gdibrush and logbrush fields from >> GpBrush, and generate the HBRUSH as needed in brush_fill_path. Note >> that brush_fill_path will only be called for solid and hatch brushes >> (those for which brush_can_fill_path returns true), so we don't need >> the code to create a gdi brush for the other types. > > Does the attached patch look better? Next step would be to get rid of bmp > in GpSolidFill structure. > > -- > Dmitry.

Feb. 29, 2012

AW: Major mmdevapi and winmm audio bugs

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Maarten Lankhorst wrote: >For capture I plan to just add 2 queues, one for readable packets, and one >for packets that can be filled for reading. Winecoreaudio uses exactly this. >... for the pulse driver, I'm using the auto timing >update feature and the callback for when rendering is not running. >When the buffer is not underflowed, I'm using the write callback to >signal more data is available. I'm not familiar with PA's API, so I'm not following you. I'm not even sure we talk about the same thing. >I believe the event should be triggered when there is actual data >available, at least that's how I understood the event is supposed >to work. I distinguish 2 events: a) ALSA/PA backend ready for more data b) mmdevapi SetEventHandle to the app Note that b) only exists when using EVENTCALLBACK. We have tests about b) that show that mmdevapi delivers events to the app even when stopped (Wine fails those with todo_wine). I don't know at what rate. Regarding a), nothing prevents you from using the back-end's favourite notification mechanism to wake up - or use a timer. I agree with you that ideally, somehow, b) and a) should be in sync, otherwise we'll have clock skew and the XAudio scenario will exhibit occasional underruns. But there are big HOWEVER: - ALSA/PA may not grant us the period we'd like (10ms). 21.333ms is common with ALSA/dmix. I don't know how important the 10ms are. You're familiar with DSound, so perhaps you have an opinion why DSound has been using 10ms intervals in Wine regardless of the back-end's period. I believe that Wine ought to use the same rate as native or some app will exhibit a bug. - We do not need 10ms events when not using EVENTCALLBACK, so why not write all available data (e.g. 333ms from winmm:PlaySound) and sleep that much? Laptop owners will thank us. - How to continue signaling type a events after IAudioClient_Stop? By continuing to write silence to the back-end?!? - Last but not least, I don't know whether ALSA's signaling and mmdevapi's SetEvent needs can be made compatible even when the periods would agree. mmdevapi's SetEvent means "don't worry, you have one period time to write data" or even "you may write data, but I already have buffered some". ALSA/PA's signal means(?) "hurry up, you're on the verge of underrun". Please correct me. - The test_worst_case aka. XAudio scenario has tough requirements: - Signal events not often enough and you'll enter an underrun. - Signal events too early and it'll write no data. The event was wasted and the next one may come too late to avoid an underrun. In summary, if the back-end guarantees 10ms wake-ups, you should be able to nicely sync a) and b) (probably by writing silence when stopped...) If not, then some mechanism must be there to decouple the two. So far we've followed the "decouple" route in winealsa/oss. I believe the key to the solution in mmdevapi will come from both being able to vary the sleeping intervals to adapt to clock skew *and* not be bound to be exactly in sync with the back-end, thanks to a latency-inducing buffer large enough to compensate for the variability. IOW, the design goal is to reach during normal playback a state where: Event received => GetCurrentPadding has (or pretends to have) decreased by at least 1 period (which implies there's room for writing). Regards, Jörg

Feb. 29, 2012

Re: [PATCH] wined3d: Do not use double-buffered dynamic buffers (try 2)

by Henri Verbeet

On 29 February 2012 13:32, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Fine with me, just don't blame me that those bugs aren't fixed :-) Yeah well, 27600 was reported in June last year.

Feb. 29, 2012

Re: [PATCH] wined3d: Do not use double-buffered dynamic buffers (try 2)

by Stefan Dösinger

Am Mittwoch, 29. Februar 2012, 11:54:11 schrieb Henri Verbeet: > I guess I didn't explicitly say it yesterday, but I think this should > be deferred and fixed properly after 1.4. While in principle dropping > VBOs might be ok as a temporary fix for the release, the vertex / > index buffer code is pretty fragile in general, and I can't guarantee > that this won't introduce more regressions than it fixes. Fine with me, just don't blame me that those bugs aren't fixed :-)

Feb. 29, 2012

Re: [PATCH] winepulse: Add pulse driver, v8

by Maarten Lankhorst

Hey Chris, Op 29-02-12 06:58, Chris Robinson schreef: > On Tuesday, February 28, 2012 5:32:13 PM Maarten Lankhorst wrote: >> + * This is basically the same as the pa_threaded_mainloop implementation, >> + * but that cannot be used because it uses pthread_create directly >> + * >> + * pa_threaded_mainloop_(un)lock -> pthread_mutex_(un)lock >> + * pa_threaded_mainloop_signal -> pthread_cond_signal >> + * pa_threaded_mainloop_wait -> pthread_cond_wait > I'm curious why you're using pthreads. Doesn't WinAPI have anything comparable > to pthread_cond_wait? I'm literally following the pulseaudio mainloop here. If you look at their definitions they will map to those. Pulseaudio library on win32 was having their own weird version of pthread_cond_* which would go through wineserver multiple times for each signalling. The extra context switches would have been a sure way to kill any hope of efficiency and decreased the chances of the scheduler doing things right. :) pulseaudio/src/pulsecore/mutex-win32.c for reference >> +static void pulse_probe_settings(void) { > ... >> + ret = pa_stream_connect_playback(stream, NULL, &attr, >> + PA_STREAM_START_CORKED|PA_STREAM_FIX_RATE|PA_STREAM_FIX_FORMAT|PA_S >> TREAM_FIX_CHANNELS|PA_STREAM_EARLY_REQUESTS, NULL, NULL); > Is it necessary to fix the format? MSDN says that the audio service always > works with floating-point, and GetMixFormat always specified floating-point in > my dealings with it. I don't think it should blindly return whatever > PulseAudio does, unless it can be shown that Windows doesn't always give > floating-point. I'd have to recheck on my windows pc, to see if that's the case. However if it is I don't see a problem with always specifying float and removing the fix flag for it. >> +static WAVEFORMATEX *clone_format(const WAVEFORMATEX *fmt) >> +{ >> + WAVEFORMATEX *ret; >> + size_t size; >> + >> + if (fmt->wFormatTag == WAVE_FORMAT_EXTENSIBLE) >> + size = sizeof(WAVEFORMATEXTENSIBLE); >> + else >> + size = sizeof(WAVEFORMATEX); >> + >> + ret = HeapAlloc(GetProcessHeap(), 0, size); > This should probably use CoTaskMemAlloc, as it's used for IsFormatSupported. > I'm also curious if IsFormatSupported should always return a > WAVE_FORMAT_EXTENSIBLE object. Aye indeed, seems to be an old copy/paste bug too. Was fixed on 27 Apr 2011 in winealsa. >> +static enum pa_channel_position pulse_map[] = { > This should probably be const. Yes. :) >> + if (fmt->wFormatTag == WAVE_FORMAT_IEEE_FLOAT) >> + This->ss.format = PA_SAMPLE_FLOAT32LE; > ... >> + if (IsEqualGUID(&wfe->SubFormat, &KSDATAFORMAT_SUBTYPE_IEEE_FLOAT)) >> + This->ss.format = PA_SAMPLE_FLOAT32LE; > You likely should check that the format specifies 32 bits, and not 64 or > something different like that. Yes indeed, I've moved those checks to a separate function now, Initialize was getting too long. I should probably use it for IsFormatSupported, but likely PulseAudio supports any sane format you throw at it, although I haven't tested the limits... Is it really IsFormatSupported's job to deal with a WAVEFORMATEX struct with only cbSize and wFormatTag and it will get out something sane all the time, no matter how stupid the input? This isn't an all-inclusive lookover, just some things that caught my eye. Also, does this driver fail to load if it can't connect to a pulse server? Yeah, mmdevapi checks priority, I set it to 0 if driver is unavailable, 3 if it is. See AUDDRV_GetPriority Thanks for reviewing, ~Maarten

Feb. 29, 2012

Re: [PATCH] wined3d: Do not use double-buffered dynamic buffers (try 2)

by Henri Verbeet

On 29 February 2012 11:12, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > try 2: Invalidate the index buffer state as well, as the buffer might be > an index buffer. > > Otherwise unmodified reesend after the discussion from yesterday. This > is for bugs 29079, 29897(suspected) and 30019. > I guess I didn't explicitly say it yesterday, but I think this should be deferred and fixed properly after 1.4. While in principle dropping VBOs might be ok as a temporary fix for the release, the vertex / index buffer code is pretty fragile in general, and I can't guarantee that this won't introduce more regressions than it fixes.

Feb. 29, 2012

Re: RFT: Use Greek semicolons for comdlg32's printer status enumeration?

by Jerome Leclanche

Yes. Looks good. J. Leclanche On Wed, Feb 29, 2012 at 9:51 AM, Francois Gouget <fgouget(a)free.fr> wrote: > On Sat, 25 Feb 2012, Jerome Leclanche wrote: > [...] > > - I don't think an ano telia would be appropriate for this. To be honest > I > > don't even find a semicolon appropriate in English here. > > I don't build with printing support but it sounds to me like it would be > > more appropriate to use a comma, or a dash. > > Would the attached patch be better? > > > -- > Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > The greatest programming project of all took six days; on the seventh day > the > programmer rested. We've been trying to debug the *&^%$#@ thing ever > since. > Moral: design before you implement.

Feb. 29, 2012

Remove an obsolete string chunk fom the Swedish translation?

by Francois Gouget

This translation seems to have an extra example which is not present in the English string. Would it be ok to remove it? msgid "" "MOVE relocates a file or directory to a new point within the file system.\n" "\n" "If the item being moved is a directory then all the files and " "subdirectories\n" "below the item are moved as well.\n" "\n" "MOVE fails if the old and new locations are on different DOS drive letters.\n" msgstr "" "MOVE flyttar en fil eller mapp till ett nytt ställe inom filsystemet.\n" "\n" "Om du flyttar på en mapp, så flyttas allting under mappen med.\n" "\n" "MOVE misslyckas om den gamla och det den nya stället är på olika\n" "DOS-enhetsbokstäver. Till exempel från C: till D:.\n" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ If you think the whole world revolves around you, quit staring at the GPS display while driving.

Feb. 29, 2012

Re: RFT: Use Greek semicolons for comdlg32's printer status enumeration?

by Francois Gouget

On Sat, 25 Feb 2012, Jerome Leclanche wrote: [...] > - I don't think an ano telia would be appropriate for this. To be honest I > don't even find a semicolon appropriate in English here. > I don't build with printing support but it sounds to me like it would be > more appropriate to use a comma, or a dash. Would the attached patch be better? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The greatest programming project of all took six days; on the seventh day the programmer rested. We've been trying to debug the *&^%$#@ thing ever since. Moral: design before you implement.

Feb. 29, 2012

Re: Major mmdevapi and winmm audio bugs

by Joerg-Cyril.Hoehle＠t-systems.com

Andrew Eikum wrote: >And, not too surprisingly, TimerQueue isn't sufficient. I've attached >my tests here. The tests ask to execute the callback every 12 ms. On >my Windows 7 VM, I found that it executed with intervals like: >20, 10, 10, 10, 10, 20, 10, 10, 10, 10, ... >With an 11 occasionally interspersed. >So, forget that. No. Did you notice that on *average*, a callback occurs every 12ms (5 within 60ms)? This is the same essential property that winmm:setTimer exhibits too. Wine's CreateTimerQueue is buggy, because it doesn't do that. Wine's winmm:timer does. A patch is needed for CTQ. Now if Wine's CTQ would be fixed, Wine's audio would have fewer underruns. The periodicity is another topic. >my Windows 7 VM I don't trust timings from a VM. 10/20ms may be an artefact. OTOH it may be a design decision from MS related to scheduler quantums or whatever. >Since we're already using poll() in winmm and it seems to work well, >that would be my suggestion. Sure, but then you need an own thread in mmdevapi, don't you? So we're back at the point where I said earlier that I can well imagine a fix to CTQ for wine-1.4.0, but less so a move to an own thread + poll. Regards, Jörg Höhle

Feb. 29, 2012

Re: doc: Update Italian README

by Luca Bennati

2012/2/28 Frédéric Delanoy <frederic.delanoy(a)gmail.com> > 2012/2/28 Luca Bennati <lucak3(a)gmail.com>: > > I tried converting README.it to UTF8, instead of the current Extended > ASCII, > > which works really bad on my system. > > However, it does not seems like Git caught this change: could this be > done > > manually? > > I applied the patch manually and it seems the conversion went fine. > Maybe there were some accentuated letters already. > (hint: 'iconv' can be useful for those kind of conversions, or a save > with your favorite editor) > > BTW, > > -6. ESEGUIRE I PROGRAMMI > +6. RUNNING PROGRAMS > > seems wrong... > > Frédéric > It's good that it works as planned. Thanks for spotting that line, I've sent another patch to correct it.

Feb. 29, 2012

Re: gdiplus: Create a GDI brush only when needed.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > The right solution is to remove the gdibrush and logbrush fields from > GpBrush, and generate the HBRUSH as needed in brush_fill_path. Note > that brush_fill_path will only be called for solid and hatch brushes > (those for which brush_can_fill_path returns true), so we don't need > the code to create a gdi brush for the other types. Does the attached patch look better? Next step would be to get rid of bmp in GpSolidFill structure. -- Dmitry.

Feb. 29, 2012

Re: [PATCH] winepulse: Add pulse driver, v8

by Charles Davis

On Feb 28, 2012, at 10:58 PM, Chris Robinson wrote: > On Tuesday, February 28, 2012 5:32:13 PM Maarten Lankhorst wrote: >> + * This is basically the same as the pa_threaded_mainloop implementation, >> + * but that cannot be used because it uses pthread_create directly >> + * >> + * pa_threaded_mainloop_(un)lock -> pthread_mutex_(un)lock >> + * pa_threaded_mainloop_signal -> pthread_cond_signal >> + * pa_threaded_mainloop_wait -> pthread_cond_wait > > I'm curious why you're using pthreads. Doesn't WinAPI have anything comparable > to pthread_cond_wait? It does: http://msdn.microsoft.com/en-us/library/ms686301(v=vs.85).aspx For some reason, the condition variable API just hasn't been implemented in Wine yet. Chip

Feb. 29, 2012

Re: [PATCH] winepulse: Add pulse driver, v8

by Chris Robinson

On Tuesday, February 28, 2012 5:32:13 PM Maarten Lankhorst wrote: > + * This is basically the same as the pa_threaded_mainloop implementation, > + * but that cannot be used because it uses pthread_create directly > + * > + * pa_threaded_mainloop_(un)lock -> pthread_mutex_(un)lock > + * pa_threaded_mainloop_signal -> pthread_cond_signal > + * pa_threaded_mainloop_wait -> pthread_cond_wait I'm curious why you're using pthreads. Doesn't WinAPI have anything comparable to pthread_cond_wait? > +static void pulse_probe_settings(void) { ... > + ret = pa_stream_connect_playback(stream, NULL, &attr, > + PA_STREAM_START_CORKED|PA_STREAM_FIX_RATE|PA_STREAM_FIX_FORMAT|PA_S > TREAM_FIX_CHANNELS|PA_STREAM_EARLY_REQUESTS, NULL, NULL); Is it necessary to fix the format? MSDN says that the audio service always works with floating-point, and GetMixFormat always specified floating-point in my dealings with it. I don't think it should blindly return whatever PulseAudio does, unless it can be shown that Windows doesn't always give floating-point. > +static WAVEFORMATEX *clone_format(const WAVEFORMATEX *fmt) > +{ > + WAVEFORMATEX *ret; > + size_t size; > + > + if (fmt->wFormatTag == WAVE_FORMAT_EXTENSIBLE) > + size = sizeof(WAVEFORMATEXTENSIBLE); > + else > + size = sizeof(WAVEFORMATEX); > + > + ret = HeapAlloc(GetProcessHeap(), 0, size); This should probably use CoTaskMemAlloc, as it's used for IsFormatSupported. I'm also curious if IsFormatSupported should always return a WAVE_FORMAT_EXTENSIBLE object. > +static enum pa_channel_position pulse_map[] = { This should probably be const. > + if (fmt->wFormatTag == WAVE_FORMAT_IEEE_FLOAT) > + This->ss.format = PA_SAMPLE_FLOAT32LE; ... > + if (IsEqualGUID(&wfe->SubFormat, &KSDATAFORMAT_SUBTYPE_IEEE_FLOAT)) > + This->ss.format = PA_SAMPLE_FLOAT32LE; You likely should check that the format specifies 32 bits, and not 64 or something different like that. This isn't an all-inclusive lookover, just some things that caught my eye. Also, does this driver fail to load if it can't connect to a pulse server?

Feb. 29, 2012

Re: [PATCH] README: updated Linux and FreeBSD kernels

by Marcus Meissner

On Wed, Feb 22, 2012 at 10:44:31AM +0100, Francois Gouget wrote: > On Wed, 22 Feb 2012, Marcus Meissner wrote: > > > --- > > README | 13 ++++++------- > > 1 files changed, 6 insertions(+), 7 deletions(-) > > > > diff --git a/README b/README > > index baa6ab3..0cbb047 100644 > > --- a/README > > +++ b/README > > @@ -29,7 +29,7 @@ especially the wealth of information found at http://www.winehq.org. > > To compile and run Wine, you must have one of the following: > > > > Linux version 2.0.36 or above > > - FreeBSD 6.3 or later > > + FreeBSD 8.0 or later > [...] > > FreeBSD info: > > - Wine will generally not work properly on versions before FreeBSD > > - 6.3 or 7.0, and FreeBSD 6.3 has additional patches available. See > > - http://wiki.freebsd.org/Wine for more information. > > + Wine will generally not work properly on versions before FreeBSD 8.0. > > + See http://wiki.freebsd.org/Wine for more information. > > Is there a reason why Wine won't work right on FreeBSD 7.0? > Winetest seems mostly ok. > http://test.winehq.org/data/f43f37d3613db57c732196f88e1225191cd62c30/index_… I followed the note on http://wiki.freebsd.org/Wine who does not mention older versions than 8.0. I have no other information. Ciuao, Marcus

Feb. 29, 2012

Re: doc: Update Italian README

by Frédéric Delanoy

2012/2/28 Luca Bennati <lucak3(a)gmail.com>: > I tried converting README.it to UTF8, instead of the current Extended ASCII, > which works really bad on my system. > However, it does not seems like Git caught this change: could this be done > manually? I applied the patch manually and it seems the conversion went fine. Maybe there were some accentuated letters already. (hint: 'iconv' can be useful for those kind of conversions, or a save with your favorite editor) BTW, -6. ESEGUIRE I PROGRAMMI +6. RUNNING PROGRAMS seems wrong... Frédéric

Feb. 28, 2012

Re: Web based translation tool

by Yaron Shahrabani

OK, I came up with something. We can lock up the wiki registration and the Admin will have to approve each and every translator manually (TranslateWiki works that way when you want to contribute to MediaWiki). That way the user will have to provide his/her real name upon registration. There's also a possibility that the registration will remain open but the main coordinator will have to approve each translator manually, just like what Siebrand does. Well, there are plenty of possibilities... Having a distinct TranslateWiki instance is not such a bad idea... (This way the current rules won't be applied). What else can I check for you guys? Kind regards, Yaron Shahrabani <Hebrew translator> On Tue, Feb 28, 2012 at 3:03 PM, Aric Stewart <aric(a)codeweavers.com> wrote: > Hi, > > I have had quite a long discussion with the TranslateWiki people. They > are great and while what we need would require a bit of PHP development > they expressed that they would be happy to do the work. > > The main sticking block is that our requirement for Real Names and e-mail > for all contributors runs contrary to their privacy policy. So we would not > be able to get that information in our patches. > > They are currently exploring that idea and we are in continued discussion > about this. If we can get around that road block then they may be our best > option. > > Transifex's Dimitris Glezos has also been very communicative with me, and > very helpful, however Transifex does not actually do PO management > converting the POs into their own database format and requiring developers > to have a client tool to be able to get and push the translations. That > could be done by a translation manager who would then generate all the > patches and mail them with the proper credit. However he still has not > answered my basic question of if we would be able to get that information. > > So I am still actively following up on these leads and hopefully something > will work out. > > -aric > > > On 2/28/12 1:42 AM, Yaron Shahrabani wrote: > >> Hi guys! >> >> If I understand correctly the wanted solution is the translation >> attribution will be per string basis meaning that we can attribute a >> certain author to a string. >> >> The only system I'm aware of that is capable of such thing is >> TranslateWiki, which is a little overkill because we will have to use a >> full wiki system in order to implement gettext (which can be done using >> a much less sophisticated system). >> >> Since the Wine project already has a Wiki, maybe we can utilize this >> wiki in order to install TranslateWiki. >> >> There are several advantages: >> 1. The strings are saved just like wiki pages meaning that there's a >> full history and diff of all strings including dates and authors. >> 2. The statistics are great (The current statistics is nice as well but >> contains less info). >> 3. It's a full wiki system (Both advantage and disadvantage). >> >> None of the other systems can attribute a certain translation to a >> certain author AFAICT. >> >> Kind regards, >> YaronShahrabani >> >> <Hebrew translator> >> >> >> >> >> 2012/2/27 Miroslav Suchý <msuchy(a)redhat.com <mailto:msuchy(a)redhat.com>> >> >> Hi, >> I just read: >> http://www.winehq.org/news/__**2012022001<http://www.winehq.org/news/__2012022001> >> <http://www.winehq.org/news/**2012022001<http://www.winehq.org/news/2012022001> >> > >> and then >> http://wiki.winehq.org/__**Translating<http://wiki.winehq.org/__Translating> >> >> <http://wiki.winehq.org/**Translating<http://wiki.winehq.org/Translating> >> > >> especially: >> >> The Wine project would be very interested in making its PO files >> available on web-based community translations systems such as >> Pootle or Launchpad. Our hope is that this would make >> translating Wine even easier and engage new translators. >> >> The reason why it has not happened yet is that all Wine >> contributions, including for translations, must be attributable >> to a specific author and that these tools don't make that >> possible yet. For more details see the wine-devel discussion >> here and here. Any contributions that would solve this issue >> would be very welcome. >> >> >> which refer: >> http://www.winehq.org/__**pipermail/wine-devel/2012-__** >> January/093908.html<http://www.winehq.org/__pipermail/wine-devel/2012-__January/093908.html> >> >> <http://www.winehq.org/**pipermail/wine-devel/2012-** >> January/093908.html<http://www.winehq.org/pipermail/wine-devel/2012-January/093908.html> >> > >> >> I would like to point you to: >> https://www.transifex.net/ >> which can do the tracking. >> >> Latest version is probably not what you want, because it just add at >> the top of the file: >> # Translators: >> # Martin Minar <skulliq(a)gmail.com <mailto:skulliq(a)gmail.com>>, 2011 >> <tel:2011>. >> # Milan Kerslager <kerslage(a)linux.cz <mailto:kerslage(a)linux.cz>>, >> 2002 <tel:2002>, 2007 <tel:2007>. >> # Miloslav Trmac <mitr(a)volny.cz <mailto:mitr(a)volny.cz>>, 2002 >> <tel:2002>. >> # Miroslav Suchý <msuchy(a)redhat.com <mailto:msuchy(a)redhat.com>>, >> 2011 <tel:2011>. >> >> msgid "" >> msgstr "" >> "Project-Id-Version: Spacewalk\n" >> "Report-Msgid-Bugs-To: \n" >> "POT-Creation-Date: 2011-12-21 13:07+0100\n" >> "PO-Revision-Date: 2011-12-14 09:21+0000\n" >> "Last-Translator: Miroslav Suchý <msuchy(a)redhat.com >> <mailto:msuchy(a)redhat.com>>\n" >> "Language-Team: Czech >> (http://www.transifex.net/__**projects/p/fedora/team/cs/<http://www.transifex.net/__projects/p/fedora/team/cs/> >> <http://www.transifex.net/**projects/p/fedora/team/cs/<http://www.transifex.net/projects/p/fedora/team/cs/> >> >)\n >> >> >> So you had overview of contributors, but you could not tell which >> one contributor done which string. >> >> But version 0.7 (IIRC) sent each contribution immediately to git. >> Under login (and email) of that contributor. That contributor was >> "Author" and commiter was some transifex user. So this way you allow >> git commit access to those contributors directly to git, but since >> it goes via that web interface, they could commit only to /po/ >> directory and even only to language, for which they had been granted. >> >> You can download it here: >> http://trac.transifex.org/__**files/<http://trac.transifex.org/__files/>< >> http://trac.transifex.org/**files/ <http://trac.transifex.org/files/>> >> >> and setup your own instance. >> >> If is sufficient for you only tracking name of contributors, you can >> use that hosted solution at: https://www.transifex.net/ >> >> >> -- >> Miroslav Suchy >> Red Hat Satellite Engineering >> >> >> >> >> >> >> > >

Feb. 28, 2012

Re: [PATCH] winepulse: Add pulse driver, v8

by Dmitry Timoshkov

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > >From 8aa5903b1ee75a6c538d7e1d99560bcb39a47ed2 Mon Sep 17 00:00:00 2001 > From: Maarten Lankhorst <m.b.lankhorst(a)gmail.com> > Date: Thu, 28 Apr 2011 09:45:18 +0200 > Subject: [PATCH 10/10] winepulse: Add pulse driver, v8 You forgot to fix the date, 1 Apr would be more appropriate I'd guess. -- Dmitry.

Feb. 28, 2012

Re: [PATCH] winepulse: Add pulse driver, v8

by Maarten Lankhorst

Hey Dmitry, Op 28-02-12 18:42, Dmitry Timoshkov schreef: > Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > >> >From 8aa5903b1ee75a6c538d7e1d99560bcb39a47ed2 Mon Sep 17 00:00:00 2001 >> From: Maarten Lankhorst <m.b.lankhorst(a)gmail.com> >> Date: Thu, 28 Apr 2011 09:45:18 +0200 >> Subject: [PATCH 10/10] winepulse: Add pulse driver, v8 > You forgot to fix the date, 1 Apr would be more appropriate I'd guess. > I'm surprised it used that date, but I'm no less serious about my intentions to get it included into wine. If you have any technical concerns I would be glad to hear them. ~Maarten

Feb. 28, 2012

Re: Major mmdevapi and winmm audio bugs

by Juan Lang

Hi Andrew, one small contribution: > Winmm's timer functions use poll() with a timeout value, subtracting > the time elapsed curing the callback. This works quite well in dsound. > > The Win32 API also provides the SetTimer API. But that depends on a > message queue, which is a hassle I don't know if we want to bother > with in the drivers (plus, it may be no more reliable than the > TimerQueues). Using SetTimer is not the way you want to go. Its timing is unpredictable and its interface strange. I'd stay away from it. --Juan

Feb. 28, 2012

Re: Major mmdevapi and winmm audio bugs

by Andrew Eikum

On Tue, Feb 28, 2012 at 08:24:37AM -0600, Andrew Eikum wrote: > I'm investigating native TimerQueue's operation now. If it turns out > that TimerQueue isn't sufficient, we'll probably just switch over to > using poll() like winmm's timer stuff does. > And, not too surprisingly, TimerQueue isn't sufficient. I've attached my tests here. The tests ask to execute the callback every 12 ms. On my Windows 7 VM, I found that it executed with intervals like: 20, 10, 10, 10, 10, 20, 10, 10, 10, 10, ... With an 11 occasionally interspersed. So, forget that. Winmm's timer functions use poll() with a timeout value, subtracting the time elapsed curing the callback. This works quite well in dsound. The Win32 API also provides the SetTimer API. But that depends on a message queue, which is a hassle I don't know if we want to bother with in the drivers (plus, it may be no more reliable than the TimerQueues). Since we're already using poll() in winmm and it seems to work well, that would be my suggestion. Any thoughts? Andrew

Feb. 28, 2012

Re: [PATCH 1/4] ddraw: Make D3DVBCAPS_WRITEONLY vertex buffers dynamic

by Stefan Dösinger

Am Dienstag, 28. Februar 2012, 14:51:06 schrieb Henri Verbeet: > Yes, but that's the other way around. If anything, that pdf suggests > that buffers are dynamic by default in ddraw. Making buffers dynamic by default in ddraw will disable rhw vertex and color conversion for ddraw apps. We could create non-dynamic buffers by default and destroy and recreate the wined3d buffer with the dynamic flag when the app uses DISCARDCONTENTS or NOOVERWRITE the first time.

Feb. 28, 2012

Re: [PATCH 2/4] wined3d: Do not use double-buffered dynamic buffers

by Stefan Dösinger

Am Dienstag, 28. Februar 2012, 14:50:28 schrieb Henri Verbeet: > Ok, but we could just be more clever about doing uploads and only > upload what's actually referenced by draws. We already have most of > the code for tracking uploaded ranges. Similarly, are we really sure > that maintaining a sysmem copy of the entire buffer is really better > than mapping the VBO for drawStridedSlow() in the first place? At some > point the data needs to be sent to the GPU, and I think we're in a > better position to decide what to upload and when than the driver. Indexed draws will be tricky, it depends on how decent the app-provided index ranges are. It also means we'd have to track which parts of the VB are uploaded and which aren't. Mapping the VBO in drawStridedSlow might be an option, although I guess that would force the driver to wait until previous draws are done. All those options are out of reach for Wine 1.4, and beyond Wine 1.4 I'd prefer to fix the problems that force us into drawStridedSlow by implementing a vertex pipeline and proper instancing.

Feb. 28, 2012

Re: Major mmdevapi and winmm audio bugs

by Andrew Eikum

On Mon, Feb 27, 2012 at 11:41:56PM +0100, Maarten Lankhorst wrote: > > W.r.t. to 1.4.0, I believe the following path should be taken: > > - Write CreateTimerQueue tests to verify whether native behaves like: > > a) sleep(Xms) /* what Wine does now */ or > > b) sleep(Xms - elapsed) /* what winmm:timeSetEvent does */ > > - If b), fix CreateTimerQueue. > > - If a), CreateTimerQueue is unusable for the purposes of Wine's mmdevapi > > and something else must be sought... > Even if so, it is unneeded for the pulse driver, I'm using the auto timing > update feature and the callback for when rendering is not running. > When the buffer is not underflowed, I'm using the write callback to > signal more data is available. > > Timerqueue would be a lie, the driver should schedule when data can > actually be written and not based purely on ticks. Pulseaudio allows > this and I'm using this feature in my driver. It passes all the render > tests now except the volume related ones (they're a reminder, > and a nop on other drivers anyhow), and I'm working to complete > capture in a similar fashion as well. > > I believe the event should be triggered when there is actual data > available, at least that's how I understood the event is supposed > to work. Doing it based on a timer that isn't tied to the state in > any way feels wrong. Having 2 threads for pulse feels wrong too, > especially since it can be done with just using the one pulse > provides, because you can set callbacks for when more data > can be read or written. > Unfortunately, the only backend that actually produces that kind of information is Pulse. So we need a solution for the other drivers anyway. At that point, we'll have to decide whether we want to use the same mechanism for Pulse, or rely on the callbacks. There's an argument for having each driver behave as similar as possible, even if it's arguably less "correct." I've also been burned enough times by relying on the audio backend to work correctly that I hesitate to give the backends more responsibility than absolutely necessary. I'm investigating native TimerQueue's operation now. If it turns out that TimerQueue isn't sufficient, we'll probably just switch over to using poll() like winmm's timer stuff does. Andrew

Feb. 28, 2012

Re: [PATCH 1/4] ddraw: Make D3DVBCAPS_WRITEONLY vertex buffers dynamic

by Henri Verbeet

On 28 February 2012 14:17, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Am Dienstag, 28. Februar 2012, 13:05:16 schrieb Henri Verbeet: >> I don't see why WRITEONLY should imply DYNAMIC. > For one, the documents from nvidia tell you to set D3DVBCAPS_WRITEONLY when > you want to stream data[1]. Microsoft doesn't really document how dynamic > buffers work in d3d7. > > The other consideration is that DYNAMIC buffers that are not WRITEONLY are a > bad idea in d3d8/9. Yes, we don't handle WINED3DUSAGE_WRITEONLY at the moment, > but the consideration makes sense for d3d7 too. > Yes, but that's the other way around. If anything, that pdf suggests that buffers are dynamic by default in ddraw.

Feb. 28, 2012

Re: [PATCH 2/4] wined3d: Do not use double-buffered dynamic buffers

by Henri Verbeet

On 28 February 2012 13:46, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > buffer_direct_upload is working correctly and the gl buffer is mapped with > GL_MAP_UNSYNCHRONIZED_BIT or GL_MAP_INVALIDATE_BUFFER_BIT, depending on the > lock flags the buffer used. The performance hit comes from the memcpy, not the > buffer map. This is particularly bad in 30019 because d3d7 forces us to memcpy > the entire buffer. I added some dummy writes to the start and the end of the > buffer instead of the memcpy to make sure the driver is forced to upload data. > Ok, but we could just be more clever about doing uploads and only upload what's actually referenced by draws. We already have most of the code for tracking uploaded ranges. Similarly, are we really sure that maintaining a sysmem copy of the entire buffer is really better than mapping the VBO for drawStridedSlow() in the first place? At some point the data needs to be sent to the GPU, and I think we're in a better position to decide what to upload and when than the driver.

Feb. 28, 2012

Re: [PATCH 1/4] ddraw: Make D3DVBCAPS_WRITEONLY vertex buffers dynamic

by Stefan Dösinger

Am Dienstag, 28. Februar 2012, 13:05:16 schrieb Henri Verbeet: > I don't see why WRITEONLY should imply DYNAMIC. For one, the documents from nvidia tell you to set D3DVBCAPS_WRITEONLY when you want to stream data[1]. Microsoft doesn't really document how dynamic buffers work in d3d7. The other consideration is that DYNAMIC buffers that are not WRITEONLY are a bad idea in d3d8/9. Yes, we don't handle WINED3DUSAGE_WRITEONLY at the moment, but the consideration makes sense for d3d7 too. > Setting it for all > ddraw buffers may make sense, but even then I'd like to hear a > somewhat more convincing argument that now is the right time to change > this. To fix bug 30019. That's the one argument I have. I'm happy to defer this change until after Wine 1.4. It's fairly obvious that we have to set DYNAMIC somewhere if we want DDLOCK_DISCARDCONTENTS and DDLOCK_NOOVERWRITE to work, but I think that's not your point of concern. 1: http://developer.download.nvidia.com/assets/gamedev/docs/top5perfkill.pdf

Feb. 28, 2012

Re: Web based translation tool

by Aric Stewart

Hi, I have had quite a long discussion with the TranslateWiki people. They are great and while what we need would require a bit of PHP development they expressed that they would be happy to do the work. The main sticking block is that our requirement for Real Names and e-mail for all contributors runs contrary to their privacy policy. So we would not be able to get that information in our patches. They are currently exploring that idea and we are in continued discussion about this. If we can get around that road block then they may be our best option. Transifex's Dimitris Glezos has also been very communicative with me, and very helpful, however Transifex does not actually do PO management converting the POs into their own database format and requiring developers to have a client tool to be able to get and push the translations. That could be done by a translation manager who would then generate all the patches and mail them with the proper credit. However he still has not answered my basic question of if we would be able to get that information. So I am still actively following up on these leads and hopefully something will work out. -aric On 2/28/12 1:42 AM, Yaron Shahrabani wrote: > Hi guys! > > If I understand correctly the wanted solution is the translation > attribution will be per string basis meaning that we can attribute a > certain author to a string. > > The only system I'm aware of that is capable of such thing is > TranslateWiki, which is a little overkill because we will have to use a > full wiki system in order to implement gettext (which can be done using > a much less sophisticated system). > > Since the Wine project already has a Wiki, maybe we can utilize this > wiki in order to install TranslateWiki. > > There are several advantages: > 1. The strings are saved just like wiki pages meaning that there's a > full history and diff of all strings including dates and authors. > 2. The statistics are great (The current statistics is nice as well but > contains less info). > 3. It's a full wiki system (Both advantage and disadvantage). > > None of the other systems can attribute a certain translation to a > certain author AFAICT. > > Kind regards, > YaronShahrabani > > <Hebrew translator> > > > > > 2012/2/27 Miroslav Suchý <msuchy(a)redhat.com <mailto:msuchy(a)redhat.com>> > > Hi, > I just read: > http://www.winehq.org/news/__2012022001 > <http://www.winehq.org/news/2012022001> > and then > http://wiki.winehq.org/__Translating > <http://wiki.winehq.org/Translating> > especially: > > The Wine project would be very interested in making its PO files > available on web-based community translations systems such as > Pootle or Launchpad. Our hope is that this would make > translating Wine even easier and engage new translators. > > The reason why it has not happened yet is that all Wine > contributions, including for translations, must be attributable > to a specific author and that these tools don't make that > possible yet. For more details see the wine-devel discussion > here and here. Any contributions that would solve this issue > would be very welcome. > > > which refer: > http://www.winehq.org/__pipermail/wine-devel/2012-__January/093908.html > <http://www.winehq.org/pipermail/wine-devel/2012-January/093908.html> > > I would like to point you to: > https://www.transifex.net/ > which can do the tracking. > > Latest version is probably not what you want, because it just add at > the top of the file: > # Translators: > # Martin Minar <skulliq(a)gmail.com <mailto:skulliq(a)gmail.com>>, 2011 > <tel:2011>. > # Milan Kerslager <kerslage(a)linux.cz <mailto:kerslage(a)linux.cz>>, > 2002 <tel:2002>, 2007 <tel:2007>. > # Miloslav Trmac <mitr(a)volny.cz <mailto:mitr(a)volny.cz>>, 2002 > <tel:2002>. > # Miroslav Suchý <msuchy(a)redhat.com <mailto:msuchy(a)redhat.com>>, > 2011 <tel:2011>. > msgid "" > msgstr "" > "Project-Id-Version: Spacewalk\n" > "Report-Msgid-Bugs-To: \n" > "POT-Creation-Date: 2011-12-21 13:07+0100\n" > "PO-Revision-Date: 2011-12-14 09:21+0000\n" > "Last-Translator: Miroslav Suchý <msuchy(a)redhat.com > <mailto:msuchy(a)redhat.com>>\n" > "Language-Team: Czech > (http://www.transifex.net/__projects/p/fedora/team/cs/ > <http://www.transifex.net/projects/p/fedora/team/cs/>)\n > > So you had overview of contributors, but you could not tell which > one contributor done which string. > > But version 0.7 (IIRC) sent each contribution immediately to git. > Under login (and email) of that contributor. That contributor was > "Author" and commiter was some transifex user. So this way you allow > git commit access to those contributors directly to git, but since > it goes via that web interface, they could commit only to /po/ > directory and even only to language, for which they had been granted. > > You can download it here: > http://trac.transifex.org/__files/ <http://trac.transifex.org/files/> > and setup your own instance. > > If is sufficient for you only tracking name of contributors, you can > use that hosted solution at: https://www.transifex.net/ > > > -- > Miroslav Suchy > Red Hat Satellite Engineering > > > > > >

Feb. 28, 2012

Re: [PATCH 2/4] wined3d: Do not use double-buffered dynamic buffers

by Stefan Dösinger

Am Dienstag, 28. Februar 2012, 13:05:36 schrieb Henri Verbeet: > I don't find this all that convincing either. My impression is that > the reason we have these kinds of problems is mostly that the buffer > conversion code is broken. I don't think there are legitimate cases > where not creating a VBO should improve performance. There's no conversion involved. 30019 uses double-buffered buffers because it falls back to drawStridedSlow for material source tracking. 29897 and 29079 also have double-buffered buffers without conversion too, I assume because of instanced draws. buffer_direct_upload is working correctly and the gl buffer is mapped with GL_MAP_UNSYNCHRONIZED_BIT or GL_MAP_INVALIDATE_BUFFER_BIT, depending on the lock flags the buffer used. The performance hit comes from the memcpy, not the buffer map. This is particularly bad in 30019 because d3d7 forces us to memcpy the entire buffer. I added some dummy writes to the start and the end of the buffer instead of the memcpy to make sure the driver is forced to upload data. It's not a minor performance difference. In 30019 it's 65 fps vs 0.67 fps. The d3d9 bugs are less severe, but in Serious Sam HD the framerate is still cut in half.

Feb. 28, 2012

Re: [PATCH 2/4] wined3d: Do not use double-buffered dynamic buffers

by Henri Verbeet

On 28 February 2012 12:19, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This is for bug 30019. > > They are a lot slower than using no VBO at all in at least some, if not all > games. The reason for the slowdown is the memcpy call, not the buffer > map. I don't find this all that convincing either. My impression is that the reason we have these kinds of problems is mostly that the buffer conversion code is broken. I don't think there are legitimate cases where not creating a VBO should improve performance.

Feb. 28, 2012

Re: [PATCH 1/4] ddraw: Make D3DVBCAPS_WRITEONLY vertex buffers dynamic

by Henri Verbeet

On 28 February 2012 12:19, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This is for bug 30019. > > Out ddraw.dll forwards DDLOCK_DISCARDCONTENTS and DDLOCK_NOOVERWRITE to > wined3d, but wined3d ignores those flags because we never set > WINED3DUSAGE_DYNAMIC. D3d7 docs refer to D3DVBCAPS_WRITEONLY as the flag > to set when creating a buffer, so translate it to DYNAMIC | WRITEONLY. > > An argument could be made that we should set the DYNAMIC flag on all > d3d7 buffers, but until I see a game that needs it I prefer to keep > non-D3DVBCAPS_WRITEONLY buffers regular buffers. I don't see why WRITEONLY should imply DYNAMIC. Setting it for all ddraw buffers may make sense, but even then I'd like to hear a somewhat more convincing argument that now is the right time to change this.

Feb. 28, 2012

Re: A small cs.po file update

by Francois Gouget

On Mon, 27 Feb 2012, David wrote: > Hello. > > There is attached a small cs.po update. Gzipped. Generated using > winepo. More is coming. I am planning to update it all. Last will be > translation of certificates/encryption strings. Thanks for the translation update. Unfortunately the tool you used to edit the PO file converted all the line ends from LF to CR+LF. The resulting diff was not so small as it contained the whole file twice. I have cleaned it up and rediffed it for this time (and I'll try to modify winepo to detect this). Some notes about the patch: -#, fuzzy msgid "&Modify..." msgstr "Z&měnit" msgid "&Install" -msgstr "&Instalovat" +msgstr "Na&instalovat..." The ellipses don't match here. Ellipses are very important because, for instance, they make all the difference between a 'Print' button that will send the page to the default printer right away, and a 'Print...' button that will first display a dialog that will let you choose the destination printer or cancel before anything happens. These look like th eonly two issues so things are looking pretty good. msgid "" "Is '%1' a filename or directory\n" "on the target?\n" "(F - File, D - Directory)\n" msgstr "" "Je '%1' název souboru nebo adresáře\n" "v cíli?\n" "(F - Soubor, D - Adresář)\n" It would probably be more intuitive for users if you change the 'shortcut keys': "(S - Soubor, A - Adresář)\n" And then modify the two other corresponding translations: msgctxt "File key" msgid "F" msgstr "S" msgctxt "Directory key" msgid "D" msgstr "A" -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ A black hole is just God dividing by zero.

Feb. 28, 2012

Re: po: zh_TW translation updates

by Francois Gouget

On Mon, 27 Feb 2012, Hin-Tak Leung wrote: [...] > that aside, I think you are quite wrong in trying to "improve user > experience". That's a matter of opinion - and unfortunately, I have > already pointed out, some of the changes are just opinions, and > therefore subject to churns - i.e. some will disagree and want the > older version of a translation of a particular phrase back, etc. I don't have an opinion on the quality of the Taiwanese translation besides the typography aspects for the simple that I don't speak that language. So I'm making no judgement on it and will let Taiwanese translators hash it out. All I want to make clear is that blindly copying Windows' strings is not the wrong approach and not acceptable (and that's true for all languages). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ question = ( to ) ? be : ! be; -- Wm. Shakespeare

Feb. 28, 2012

Re: Translators wanted!

by Francois Gouget

On Mon, 27 Feb 2012, Hin-Tak Leung wrote: [...] > > Do not do that. That would be copyright infrigement. That's > > not what we > > want. This would get your contributions removed from Wine. > > claiming copyright on short phrases like 'loading dlls failed' (in > whatever language) seems very far-fetched. Claiming copyright on a set of such sentences isn't. Not all books are exclusively composed of paragraph long sentences... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ A polar bear is a cartesian bear after a coordinate transform.

Feb. 28, 2012

Re: po: zh_TW translation updates

by Franklin Weng

Hi, I rechecked the translation with old zh_TW.po file. I used Kompare and picked the better one for each entry. I hope that the new patch file is okay and acceptable. I'll post the new patch again later. BTW, the Chinese name (used in Taiwan) of Free Software Foundation is "自由軟體基金會", that's correct. Thanks, Franklin 2012/2/27 Hin-Tak Leung <hintak_leung(a)yahoo.co.uk>: > --- On Mon, 27/2/12, Francois Gouget <fgouget(a)free.fr> wrote: > >> Patches are posted to wine-patches(a)winehq.org: >> http://www.winehq.org/pipermail/wine-patches/2012-February/111804.html > > A quick look at it (it is a few hundred k) - says a few of the problems I saw and suspected: > > - some of the changes are not improvements/corrections but just opinionated changes > > - some changes are wrong (i.e. the older version is more correct/natural and the change makes it worse, not better). > > - some of the changes are over-eager: i.e. it "improves" on windows and tried to be more user-friendly, but not exactly how windows does it. > > I think there should be a notes on the translation FAQ: one is not looking to be "better than" windows, but bug-for-bug-compatible. Therefore translation is preferably what regional/localized windows (whatever version) does. > > 20% of the world's population is Chinese, I am sure it is easy enough to do a few screenshots of localized windows (be in traditional or simplied) and show how those behave. > > There is a definitive answer (or "definition answers") to most of these translation strings: what localized windows (some version) does. It is not up to individual or group opinions, really. I mean, public libraries, etc have windows in the far east, there is no excuse to be wrong, or on the opposite extreme, "try to improve on windows", even if one does not want to get one's hand dirty and own a windows box. > > > >

Feb. 28, 2012

Re: msvcrt/file.c: file mode T (temporary file) (try 3)

by Frédéric Delanoy

On Mon, Feb 27, 2012 at 11:23, Robert van Herk <mijnspamboxje(a)hotmail.com> wrote: >> So what actually prevents you from properly implementing this? Especially >> that Wine already supports temporary files. Search for MSVCRT__O_TEMPORARY >> >> Vitaliy. > > I wrote a new version that maps > 'D' -> MSVCRT__O_TEMPORARY, and > 'T' -> MSVCRT__O_SHORT_LIVED | MSVCRT__O_TEMPORARY > > I deliberately included MSVCRT__O_TEMPORARY in 'T': on Windows, when a file > is opened in 'T' mode, a subsequent call to GetFileAttributes(tempfile) show > that the FILE_ATTRIBUTE_TEMPORARY flag is set, so this seemed like to most > sensible thing to do. > > I updated the conformance test such that it checks that the file is actually > deleted after fclose. > > Kind regards, > Robert van Herk You may already be aware of this, but you can request a testbot account to check your patches before submission to wine-patches. See http://testbot.winehq.org/ Frédéric

Feb. 28, 2012

Re: Web based translation tool

by Yaron Shahrabani

Hi guys! If I understand correctly the wanted solution is the translation attribution will be per string basis meaning that we can attribute a certain author to a string. The only system I'm aware of that is capable of such thing is TranslateWiki, which is a little overkill because we will have to use a full wiki system in order to implement gettext (which can be done using a much less sophisticated system). Since the Wine project already has a Wiki, maybe we can utilize this wiki in order to install TranslateWiki. There are several advantages: 1. The strings are saved just like wiki pages meaning that there's a full history and diff of all strings including dates and authors. 2. The statistics are great (The current statistics is nice as well but contains less info). 3. It's a full wiki system (Both advantage and disadvantage). None of the other systems can attribute a certain translation to a certain author AFAICT. Kind regards, Yaron Shahrabani <Hebrew translator> 2012/2/27 Miroslav Suchý <msuchy(a)redhat.com> > Hi, > I just read: > http://www.winehq.org/news/**2012022001<http://www.winehq.org/news/2012022001> > and then > http://wiki.winehq.org/**Translating <http://wiki.winehq.org/Translating> > especially: > >> The Wine project would be very interested in making its PO files >> available on web-based community translations systems such as Pootle or >> Launchpad. Our hope is that this would make translating Wine even easier >> and engage new translators. >> >> The reason why it has not happened yet is that all Wine contributions, >> including for translations, must be attributable to a specific author and >> that these tools don't make that possible yet. For more details see the >> wine-devel discussion here and here. Any contributions that would solve >> this issue would be very welcome. >> > > which refer: > http://www.winehq.org/**pipermail/wine-devel/2012-**January/093908.html<http://www.winehq.org/pipermail/wine-devel/2012-January/093908.html> > > I would like to point you to: > https://www.transifex.net/ > which can do the tracking. > > Latest version is probably not what you want, because it just add at the > top of the file: > # Translators: > # Martin Minar <skulliq(a)gmail.com>, 2011. > # Milan Kerslager <kerslage(a)linux.cz>, 2002, 2007. > # Miloslav Trmac <mitr(a)volny.cz>, 2002. > # Miroslav Suchý <msuchy(a)redhat.com>, 2011. > msgid "" > msgstr "" > "Project-Id-Version: Spacewalk\n" > "Report-Msgid-Bugs-To: \n" > "POT-Creation-Date: 2011-12-21 13:07+0100\n" > "PO-Revision-Date: 2011-12-14 09:21+0000\n" > "Last-Translator: Miroslav Suchý <msuchy(a)redhat.com>\n" > "Language-Team: Czech (http://www.transifex.net/** > projects/p/fedora/team/cs/<http://www.transifex.net/projects/p/fedora/team/cs/> > )\n > > So you had overview of contributors, but you could not tell which one > contributor done which string. > > But version 0.7 (IIRC) sent each contribution immediately to git. Under > login (and email) of that contributor. That contributor was "Author" and > commiter was some transifex user. So this way you allow git commit access > to those contributors directly to git, but since it goes via that web > interface, they could commit only to /po/ directory and even only to > language, for which they had been granted. > > You can download it here: > http://trac.transifex.org/**files/ <http://trac.transifex.org/files/> > and setup your own instance. > > If is sufficient for you only tracking name of contributors, you can use > that hosted solution at: https://www.transifex.net/ > > > -- > Miroslav Suchy > Red Hat Satellite Engineering > > >

Feb. 28, 2012

Re: po: zh_TW translation updates

by Hin-Tak Leung

--- On Mon, 27/2/12, Francois Gouget <fgouget(a)free.fr> wrote: > On Mon, 27 Feb 2012, Hin-Tak Leung > wrote: > [...] > > - some of the changes are over-eager: i.e. it > "improves" on windows > > and tried to be more user-friendly, but not exactly how > windows does > > it. > > > > I think there should be a notes on the translation FAQ: > one is not > > looking to be "better than" windows, but > bug-for-bug-compatible. > > Therefore translation is preferably what > regional/localized windows > > (whatever version) does. > > > > 20% of the world's population is Chinese, I am sure it > is easy enough > > to do a few screenshots of localized windows (be in > traditional or > > simplied) and show how those behave. > > > > There is a definitive answer (or "definition answers") > to most of > > these translation strings: what localized windows (some > version) does. > > It is not up to individual or group opinions, really. I > mean, public > > libraries, etc have windows in the far east, there is > no excuse to be > > wrong, or on the opposite extreme, "try to improve on > windows", even > > if one does not want to get one's hand dirty and own a > windows box. > > The dialog labels and error messages are an area where we > don't need to > and don't want to be word for word identical to Windows. > > We should definitely follow the Windows User Experience > Interaction > Guidelines: > http://msdn.microsoft.com/en-us/library/aa511258.aspx > > The Windows GUI is certainly be a valuable resource to > determine which > terms the users are going to be familiar with (e.g. will > they more > readily understand 'directory' or 'folder'). That said Wine > runs on > Linux and Mac OS X so Wine's users will likely be somewhat > accustomed to > the terms used by these platforms too. > > But in any case blindly copying all the strings from the > Windows GUI > would be a very bad idea. but wine is supposed to be bug-for-bug compatible with windows, (just as a joke, or not), surely that includes poor user experience? :-). that aside, I think you are quite wrong in trying to "improve user experience". That's a matter of opinion - and unfortunately, I have already pointed out, some of the changes are just opinions, and therefore subject to churns - i.e. some will disagree and want the older version of a translation of a particular phrase back, etc.

Feb. 27, 2012

Re: Translators wanted!

by Hin-Tak Leung

--- On Mon, 27/2/12, Francois Gouget <fgouget(a)free.fr> wrote: > On Mon, 27 Feb 2012, Hin-Tak Leung > wrote: > [...] > > One should *not* be creative and does one's own thing - > the localized > > message files should be (some version of) what > localized windows > > shows. Anything else is wrong. > > Do not do that. That would be copyright infrigement. That's > not what we > want. This would get your contributions removed from Wine. claiming copyright on short phrases like 'loading dlls failed' (in whatever language) seems very far-fetched.

Feb. 27, 2012

Re: Major mmdevapi and winmm audio bugs

by Maarten Lankhorst

Hey Joerg, Op 27-02-12 19:22, Joerg-Cyril.Hoehle(a)t-systems.com schreef: > Hi, > > Maarten Lankhorst wrote (partly in a former thread): > >>> R. thread priority -- no "Pro Audio" / Real-Time priority >> Not going to happen, ever. AJ nuked all my attempts at it, >> [...] >> Or just fix things properly and use rtkit for time critical threads > and now: >> I would say using rtkit for setting threads to realtime would be an aid for this. > I can understand AJ's reluctance to RT code in Wine. I wouldn't feel > comfortable either. I believe few people realize that RT is a gifted > gift. Bear in mind that RT processes work at a priority above any > root or user process. Do something wrong there, consume 100% CPU and > you can press the single core machine's power down button. I would > not accept RT code in a system without a very careful code review and > think twice about the consequences, and require a design that keeps > the RT part of the app as small as possible, better separated. > > OTOH, RT is the means to provide reliable ticks, and that's why PA as > a sound server wants that. Now one can argue that Wine's mmdevapi > plays sound server for all w32 apps, so it has the same needs. Agreed, I've tried to keep it as small as possible for the thread itself, the mainloop thread calls very few functions, I need to add a bit more, but the only source of problems could come from the pulseaudio lib itself. At this point my winepulse driver is very reliable for rendering, and capture should be the same once I add the queue stuff, it would also be the only driver to actually pass the tests. For capture I plan to just add 2 queues, one for readable packets, and one for packets that can be filled for reading. With that approach I should be able to pass all tests in the most efficient way while keeping the metadata mmdevapi adds for capture. >> I'm just using a simple mainloop thread > That's my plan for past 1.4 too. Get rid of CreateTimerQueue as > callback source in mmdevapi, use a thread for the feeder and poll() to > wait 10ms, like all devices used to do. > I believe that's too big a change for code freeze. > > W.r.t. to 1.4.0, I believe the following path should be taken: > - Write CreateTimerQueue tests to verify whether native behaves like: > a) sleep(Xms) /* what Wine does now */ or > b) sleep(Xms - elapsed) /* what winmm:timeSetEvent does */ > - If b), fix CreateTimerQueue. > - If a), CreateTimerQueue is unusable for the purposes of Wine's mmdevapi > and something else must be sought... Even if so, it is unneeded for the pulse driver, I'm using the auto timing update feature and the callback for when rendering is not running. When the buffer is not underflowed, I'm using the write callback to signal more data is available. Timerqueue would be a lie, the driver should schedule when data can actually be written and not based purely on ticks. Pulseaudio allows this and I'm using this feature in my driver. It passes all the render tests now except the volume related ones (they're a reminder, and a nop on other drivers anyhow), and I'm working to complete capture in a similar fashion as well. I believe the event should be triggered when there is actual data available, at least that's how I understood the event is supposed to work. Doing it based on a timer that isn't tied to the state in any way feels wrong. Having 2 threads for pulse feels wrong too, especially since it can be done with just using the one pulse provides, because you can set callbacks for when more data can be read or written. ~Maarten

Feb. 27, 2012

Re: Translators wanted!

by Francois Gouget

On Mon, 27 Feb 2012, Hin-Tak Leung wrote: [...] > One should *not* be creative and does one's own thing - the localized > message files should be (some version of) what localized windows > shows. Anything else is wrong. Do not do that. That would be copyright infrigement. That's not what we want. This would get your contributions removed from Wine. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.

Feb. 27, 2012

Re: po: zh_TW translation updates

by Francois Gouget

On Mon, 27 Feb 2012, Hin-Tak Leung wrote: [...] > - some of the changes are over-eager: i.e. it "improves" on windows > and tried to be more user-friendly, but not exactly how windows does > it. > > I think there should be a notes on the translation FAQ: one is not > looking to be "better than" windows, but bug-for-bug-compatible. > Therefore translation is preferably what regional/localized windows > (whatever version) does. > > 20% of the world's population is Chinese, I am sure it is easy enough > to do a few screenshots of localized windows (be in traditional or > simplied) and show how those behave. > > There is a definitive answer (or "definition answers") to most of > these translation strings: what localized windows (some version) does. > It is not up to individual or group opinions, really. I mean, public > libraries, etc have windows in the far east, there is no excuse to be > wrong, or on the opposite extreme, "try to improve on windows", even > if one does not want to get one's hand dirty and own a windows box. The dialog labels and error messages are an area where we don't need to and don't want to be word for word identical to Windows. We should definitely follow the Windows User Experience Interaction Guidelines: http://msdn.microsoft.com/en-us/library/aa511258.aspx The Windows GUI is certainly be a valuable resource to determine which terms the users are going to be familiar with (e.g. will they more readily understand 'directory' or 'folder'). That said Wine runs on Linux and Mac OS X so Wine's users will likely be somewhat accustomed to the terms used by these platforms too. But in any case blindly copying all the strings from the Windows GUI would be a very bad idea. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ $live{free} || die "";

Feb. 27, 2012

bugzilla: show the component, not "comp" and not the assignee

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Somehow I discovered that bugzilla can display the component in a search result list. Now I'm using that instead of the useless "assignee" field. Here's part of the URL I'm using: &columnlist=bug_severity%2Cop_sys%2Ccomponent%2Cbug_status%2Cshort_desc& Unfortunately, the column named "Comp" only holds 8 characters, causing ugly names like: directx- : you don't know which one out of ten directx-YZ winmm&mc : one missing letter looks rather stupid It would be nice if some bugzilla admin would enlarge that column BTW, I recently suggested replacing the mostly useless "assignee" column in the default search result list by the component. No answer. What do you think? Thank you, Jörg Höhle

Feb. 27, 2012

Re: Major mmdevapi and winmm audio bugs

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Maarten Lankhorst wrote (partly in a former thread): >> R. thread priority -- no "Pro Audio" / Real-Time priority >Not going to happen, ever. AJ nuked all my attempts at it, >[...] >Or just fix things properly and use rtkit for time critical threads and now: >I would say using rtkit for setting threads to realtime would be an aid for this. I can understand AJ's reluctance to RT code in Wine. I wouldn't feel comfortable either. I believe few people realize that RT is a gifted gift. Bear in mind that RT processes work at a priority above any root or user process. Do something wrong there, consume 100% CPU and you can press the single core machine's power down button. I would not accept RT code in a system without a very careful code review and think twice about the consequences, and require a design that keeps the RT part of the app as small as possible, better separated. OTOH, RT is the means to provide reliable ticks, and that's why PA as a sound server wants that. Now one can argue that Wine's mmdevapi plays sound server for all w32 apps, so it has the same needs. >I'm just using a simple mainloop thread That's my plan for past 1.4 too. Get rid of CreateTimerQueue as callback source in mmdevapi, use a thread for the feeder and poll() to wait 10ms, like all devices used to do. I believe that's too big a change for code freeze. W.r.t. to 1.4.0, I believe the following path should be taken: - Write CreateTimerQueue tests to verify whether native behaves like: a) sleep(Xms) /* what Wine does now */ or b) sleep(Xms - elapsed) /* what winmm:timeSetEvent does */ - If b), fix CreateTimerQueue. - If a), CreateTimerQueue is unusable for the purposes of Wine's mmdevapi and something else must be sought... Regards, Jörg Höhle

Feb. 27, 2012

Re: Testbot and changes to multiple tests

by Joerg-Cyril.Hoehle＠t-systems.com

Stefan Dösinger wrote: >When I manually submit a patch to the Wine testbot, it refuses to test it if >the patch changes multiple tests. I know that and live with it as follows: - I usually keep changes to separate tests as distinct commits in my git, so I can send them separately to testbot. I merge them just prior to submission to wine-patches. - Alternatively, I edit the patch file in an editor and change it so that only one test file is modified, then edit again, saving the second test. >Why are they refused when I submit them via the testbot web interface? Perhaps to keep the web interface clean? (e.g. page 3 where it's asking you for the command line arguments) Regards, Jörg Höhle

Feb. 27, 2012

Re: po: zh_TW translation updates

by Hin-Tak Leung

--- On Mon, 27/2/12, 盧瑞元 <rueiyuan.lu(a)gmail.com> wrote: <snipped> > >> msgid "Finished searching the document." > >> -msgstr "檔案搜尋結束。" > >> +msgstr "檔案查找結束." > > "查找" is used in zh_CN, not zh_TW. > > > The older version is preferred. (may be it is just my > opinion). > > > >> msgid "Failed to load the RichEdit library." > >> -msgstr "RichEdit 載入失敗。" > >> +msgstr "RichEdit 裝載失敗." > > Same as above. > > > ditto here. The older version is preferred. That's two of us, saying those two changes are questionable. I think quite a few other changes in that patch is of this opinion. Here is the patch, BTW, http://www.winehq.org/pipermail/wine-patches/attachments/20120225/a9133e28/… for those of us who can read chinese.

Feb. 27, 2012

Re: msvcrt/file.c: file mode T (temporary file) (try 3)

by Marvin

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=17117 Your paranoid android. === WNT4WSSP6 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W2KPROSP4 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === WXPPROSP3 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W2K3R2SESP2 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === WVISTAADM (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W2K8SE (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W7PRO (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W7PROX64 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === TEST64_W7SP1 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W7PROX64 (64 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === TEST64_W7SP1 (64 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed.

Feb. 27, 2012

Re: ntdll: Fix the file mapping view leak in the case of module loading failure. Take 2.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > I don't see any evidence that you are addressing the issues that caused > us to not do that in the first place. Because the only thing I want to see fixed at this point is a view leak, it's still better than current state of things. Without this fix Wine shows exactly the same broken behaviour as NT4 does in the loader test when LoadLibrary is called on an already mapped image: dangling/leaked file handle, inability to overwrite/delete an executable file. -- Dmitry.

Feb. 27, 2012

Re: Hungarian translation patch 2

by Nagy Zoltán

I would like to send a translation patch again. I am sending the file attached with the mail. Best regards,Zoltan Nagy Francois Gouget <fgouget(a)free.fr> írta: > >Thanks. That first patch made quite a big difference already. Hungarian >is now in the 90% range :-) > >I noticed some issues though: > >-#, fuzzy > msgid "&Modify/Remove" > msgstr "&Módosítás/Eltávolítás..." > >You should remove the ellipsis here. > > > msgctxt "Saturation" > msgid "&Sat:" >-msgstr "" >+msgstr "&Telítettség:" > > msgctxt "Luminance" > msgid "&Lum:" >-msgstr "" >+msgstr "&Fényerő" > >These two may be too long, hence why they are truncated in English. You >can check in winecfg. Go to Desktop Integration, pick an Item, click on >Color and click on Define Custom Colors. They should also have a >trailing colon. > > > msgctxt "All key" > msgid "A" >-msgstr "" >+msgstr "A" > >Given that 'All' is translated into 'Mind', this should most likely be >an 'M'. > > >-#, fuzzy > msgid "Certificate &status:" >-msgstr "Tanusítvány beszerzés" >+msgstr "Tanusítvány &állapot" > >-#, fuzzy > msgid "&Friendly name:" > msgstr "Keresztnév" > >More missing colons... Also the second one looks like it's supposed to >have a keyboard shortcut. > > > msgid "Connection is active.\n" >-msgstr "Kapcsolat aktív" >+msgstr "Kapcsolat aktív\n" > >This one should probably have a trailing full stop. > > > >You'll find more issues like this on the Wine PO site. >http://fgouget.free.fr/wine-po/ > > >Specifically: >http://fgouget.free.fr/wine-po/hu-errors.html > > >-- >Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > La terre est une bêta...

Feb. 27, 2012

Re: ntdll: Fix the file mapping view leak in the case of module loading failure. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> I don't see any evidence that you are addressing the issues that caused >> us to not do that in the first place. > > Because the only thing I want to see fixed at this point is a view leak, > it's still better than current state of things. I don't think that deleting an object that may have references is making things better. -- Alexandre Julliard julliard(a)winehq.org

Feb. 27, 2012

Re: ntdll: Fix the file mapping view leak in the case of module loading failure. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -1548,6 +1549,11 @@ static NTSTATUS load_native_dll( LPCWSTR load_path, LPCWSTR name, HANDLE file, > *pwm = wm; > status = STATUS_SUCCESS; > done: > + if (status) > + { > + if (wm) free_modref( wm ); > + else if (module) NtUnmapViewOfSection( NtCurrentProcess(), module ); > + } I don't see any evidence that you are addressing the issues that caused us to not do that in the first place. -- Alexandre Julliard julliard(a)winehq.org

Feb. 27, 2012

Re: dsound: Small fixes to IDirectSoundCaptureBuffer

by Andrew Eikum

This patch looks sane and fixes the tests on my machine, but causes no changes to dsound capture behavior in Audacity. I don't have much of an opinion on if it should go in for 1.4. On Tue, Feb 21, 2012 at 05:33:35PM +0100, Maarten Lankhorst wrote: > --- > I suspect a lot more AUDCLNT_E_* calls will have to be mapped > correctly, but at least this is enough to pass the dsound:capture > tests again on wine. > > dlls/dsound/capture.c | 8 +++++--- > dlls/dsound/tests/capture.c | 24 +++++++++++++++--------- > 2 files changed, 20 insertions(+), 12 deletions(-) > > diff --git a/dlls/dsound/capture.c b/dlls/dsound/capture.c > index 90cddb7..7ceddfc 100644 > --- a/dlls/dsound/capture.c > +++ b/dlls/dsound/capture.c > @@ -456,13 +456,14 @@ static HRESULT WINAPI IDirectSoundCaptureBufferImpl_Start(IDirectSoundCaptureBuf > > EnterCriticalSection(&(This->device->lock)); > > - This->flags = dwFlags; > - TRACE("old This->device->state=%s\n",captureStateString[This->device->state]); > if (This->device->state == STATE_STOPPED) > This->device->state = STATE_STARTING; > else if (This->device->state == STATE_STOPPING) > This->device->state = STATE_CAPTURING; > + else > + goto out; > TRACE("new This->device->state=%s\n",captureStateString[This->device->state]); > + This->flags = dwFlags; > > if (This->device->buffer) > FillMemory(This->device->buffer, This->device->buflen, (This->device->pwfx->wBitsPerSample == 8) ? 128 : 0); > @@ -474,6 +475,7 @@ static HRESULT WINAPI IDirectSoundCaptureBufferImpl_Start(IDirectSoundCaptureBuf > return hres; > } > > +out: > LeaveCriticalSection(&This->device->lock); > > TRACE("returning DS_OK\n"); > @@ -705,7 +707,7 @@ static HRESULT IDirectSoundCaptureBufferImpl_Create( > HeapFree(GetProcessHeap(), 0, This->pdscbd); > This->device->capture_buffer = 0; > HeapFree( GetProcessHeap(), 0, This ); > - return err; > + return err == AUDCLNT_E_UNSUPPORTED_FORMAT ? DSERR_BADFORMAT : err; > } > > err = IAudioClient_GetService(device->client, &IID_IAudioCaptureClient, > diff --git a/dlls/dsound/tests/capture.c b/dlls/dsound/tests/capture.c > index 96fb417..2040f3f 100644 > --- a/dlls/dsound/tests/capture.c > +++ b/dlls/dsound/tests/capture.c > @@ -393,15 +393,18 @@ static void test_capture_buffer(LPDIRECTSOUNDCAPTURE dsco, > ok(ref==0,"IDirectSoundNotify_Release(): has %d references, should have " > "0\n",ref); > > - if (record) { > - rc=IDirectSoundCaptureBuffer_Start(dscbo,DSCBSTART_LOOPING); > - ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Start() failed: %08x\n", rc); > + rc=IDirectSoundCaptureBuffer_Start(dscbo,DSCBSTART_LOOPING); > + ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Start() failed: %08x\n", rc); > + > + rc=IDirectSoundCaptureBuffer_Start(dscbo,0); > + ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Start() failed: %08x\n", rc); > > - rc=IDirectSoundCaptureBuffer_GetStatus(dscbo,&status); > - ok(rc==DS_OK,"IDirectSoundCaptureBuffer_GetStatus() failed: %08x\n", rc); > - ok(status==(DSCBSTATUS_CAPTURING|DSCBSTATUS_LOOPING), > - "GetStatus: bad status: %x\n",status); > + rc=IDirectSoundCaptureBuffer_GetStatus(dscbo,&status); > + ok(rc==DS_OK,"IDirectSoundCaptureBuffer_GetStatus() failed: %08x\n", rc); > + ok(status==(DSCBSTATUS_CAPTURING|DSCBSTATUS_LOOPING), > + "GetStatus: bad status: %x\n",status); > > + if (record) { > /* wait for the notifications */ > for (i = 0; i < (NOTIFICATIONS * 2); i++) { > rc=WaitForMultipleObjects(NOTIFICATIONS,state.event,FALSE,3000); > @@ -416,9 +419,12 @@ static void test_capture_buffer(LPDIRECTSOUNDCAPTURE dsco, > break; > } > > - rc=IDirectSoundCaptureBuffer_Stop(dscbo); > - ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Stop() failed: %08x\n", rc); > } > + rc=IDirectSoundCaptureBuffer_Stop(dscbo); > + ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Stop() failed: %08x\n", rc); > + > + rc=IDirectSoundCaptureBuffer_Stop(dscbo); > + ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Stop() failed: %08x\n", rc); > } > > static BOOL WINAPI dscenum_callback(LPGUID lpGuid, LPCSTR lpcstrDescription, > -- > 1.7.7.6 > > > > >

Feb. 27, 2012

Re: ntdll: Fix the file mapping view leak in the case of module loading failure.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -1548,6 +1548,8 @@ static NTSTATUS load_native_dll( LPCWSTR load_path, LPCWSTR name, HANDLE file, > *pwm = wm; > status = STATUS_SUCCESS; > done: > + if (status && module) > + NtUnmapViewOfSection( NtCurrentProcess(), module ); It doesn't make sense to free the module as long as we don't free the associated modref. -- Alexandre Julliard julliard(a)winehq.org

Feb. 27, 2012

Testbot and changes to multiple tests

by Stefan Dösinger

Hi, When I manually submit a patch to the Wine testbot, it refuses to test it if the patch changes multiple tests. As a workaround I usually test a precompiled .exe and submit it once for each modified test[1]. In the case of the ddraw patch I sent today this missed test failures in 64 bit ddraw[2]. Apparently patches changing multiple tests work just fine when submitted via wine-patches. Why are they refused when I submit them via the testbot web interface? Cheers, Stefan 1: https://testbot.winehq.org/JobDetails.pl?Key=17113 2: https://testbot.winehq.org/JobDetails.pl?Key=17115

Feb. 27, 2012

Re: [PATCH 2/2] ddraw/tests: Add pitch alignment tests (try 2)

by Stefan Dösinger

Please ignore this patch for now, it looks like 64 bit ddraw.dll behaves differently. It probably doesn't matter for real games, since they're all 32 bit, but I'll have to investigate this closer. Am Montag, 27. Februar 2012, 12:11:16 schrieb Stefan Dösinger: > This patch is a side product of my attempts to debug bug 21238. It > confirms that the 8 byte aligned pitches are correct for all pools. > > try 2: Don't fail and crash if video memory surfaces are not available > --- > dlls/ddraw/tests/ddraw1.c | 77 ++++++++++++++++++++++++++++++++++++++++++ > dlls/ddraw/tests/ddraw2.c | 81 > ++++++++++++++++++++++++++++++++++++++++++++ dlls/ddraw/tests/ddraw4.c | > 82 +++++++++++++++++++++++++++++++++++++++++++++ dlls/ddraw/tests/ddraw7.c > | 82 +++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 322 > insertions(+), 0 deletions(-) > > diff --git a/dlls/ddraw/tests/ddraw1.c b/dlls/ddraw/tests/ddraw1.c > index 5d0d6da..8fa813b 100644 > --- a/dlls/ddraw/tests/ddraw1.c > +++ b/dlls/ddraw/tests/ddraw1.c > @@ -1121,6 +1121,82 @@ static void test_zenable(void) > DestroyWindow(window); > } > > +static void test_pitch_alignment(void) > +{ > + IDirectDraw *ddraw; > + IDirectDrawSurface *surface; > + HRESULT hr; > + static const struct > + { > + DWORD caps; > + UINT align; > + LONG pitch; > + const char *name; > + } > + pools[] = > + { > + { > + DDSCAPS_OFFSCREENPLAIN | DDSCAPS_VIDEOMEMORY, > + 8, 0, "D3DPOOL_DEFAULT" > + }, > + { > + DDSCAPS_OFFSCREENPLAIN | DDSCAPS_SYSTEMMEMORY, > + 8, 16, "D3DPOOL_SYSTEMMEM" > + }, > + }; > + unsigned int i; > + DDSURFACEDESC ddsd; > + > + if (!(ddraw = create_ddraw())) > + { > + skip("Failed to create a ddraw object, skipping test.\n"); > + return; > + } > + > + hr = IDirectDraw_SetCooperativeLevel(ddraw, NULL, DDSCL_NORMAL); > + ok(SUCCEEDED(hr), "Failed to set cooperative level, hr %#x.\n", hr); > + > + for (i = 0; i < (sizeof(pools) / sizeof(*pools)); i++) > + { > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT | > DDSD_PIXELFORMAT; + ddsd.dwWidth = 5; > + ddsd.dwHeight = 5; > + ddsd.ddpfPixelFormat.dwSize = sizeof(ddsd.ddpfPixelFormat); > + ddsd.ddpfPixelFormat.dwFlags = DDPF_RGB; > + U1(ddsd.ddpfPixelFormat).dwRGBBitCount = 16; > + U2(ddsd.ddpfPixelFormat).dwRBitMask = 0xF800; > + U3(ddsd.ddpfPixelFormat).dwGBitMask = 0x07E0; > + U4(ddsd.ddpfPixelFormat).dwBBitMask = 0x001F; > + ddsd.ddsCaps.dwCaps = pools[i].caps; > + > + hr = IDirectDraw_CreateSurface(ddraw, &ddsd, &surface, NULL); > + ok(SUCCEEDED(hr) || hr == DDERR_UNSUPPORTEDFORMAT || hr == > DDERR_NODIRECTDRAWHW, + "%s: Failed to create surface, hr > %#x.\n", pools[i].name, hr); + if (!surface) > + { > + skip("%s: Failed to create surface, skipping pitch alignment > test\n", pools[i].name); + continue; > + } > + > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + hr = IDirectDrawSurface_GetSurfaceDesc(surface, &ddsd); > + ok(SUCCEEDED(hr), "Failed to get surface desc, hr %#x.\n", hr); > + > + ok(!(ddsd.lPitch & (pools[i].align - 1)), "%s: Pitch %d is not %u > byte aligned.\n", + pools[i].name, ddsd.lPitch, > pools[i].align); > + if (pools[i].pitch) > + ok(ddsd.lPitch == pools[i].pitch, "%s: Expected pitch %d, got > %d.\n", + pools[i].name, pools[i].pitch, ddsd.lPitch); > + > + IDirectDrawSurface_Release(surface); > + } > + > + IDirectDraw_Release(ddraw); > +} > + > START_TEST(ddraw1) > { > test_coop_level_create_device_window(); > @@ -1130,4 +1206,5 @@ START_TEST(ddraw1) > test_coop_level_threaded(); > test_viewport_interfaces(); > test_zenable(); > + test_pitch_alignment(); > } > diff --git a/dlls/ddraw/tests/ddraw2.c b/dlls/ddraw/tests/ddraw2.c > index ba8d3b6..348cbfc 100644 > --- a/dlls/ddraw/tests/ddraw2.c > +++ b/dlls/ddraw/tests/ddraw2.c > @@ -1383,6 +1383,86 @@ static void test_zenable(void) > DestroyWindow(window); > } > > +static void test_pitch_alignment(void) > +{ > + IDirectDraw2 *ddraw; > + IDirectDrawSurface *surface1; > + IDirectDrawSurface2 *surface; > + HRESULT hr; > + static const struct > + { > + DWORD caps; > + UINT align; > + LONG pitch; > + const char *name; > + } > + pools[] = > + { > + { > + DDSCAPS_OFFSCREENPLAIN | DDSCAPS_VIDEOMEMORY, > + 8, 0, "D3DPOOL_DEFAULT" > + }, > + { > + DDSCAPS_OFFSCREENPLAIN | DDSCAPS_SYSTEMMEMORY, > + 8, 16, "D3DPOOL_SYSTEMMEM" > + }, > + }; > + unsigned int i; > + DDSURFACEDESC ddsd; > + > + if (!(ddraw = create_ddraw())) > + { > + skip("Failed to create a ddraw object, skipping test.\n"); > + return; > + } > + > + hr = IDirectDraw2_SetCooperativeLevel(ddraw, NULL, DDSCL_NORMAL); > + ok(SUCCEEDED(hr), "Failed to set cooperative level, hr %#x.\n", hr); > + > + for (i = 0; i < (sizeof(pools) / sizeof(*pools)); i++) > + { > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT | > DDSD_PIXELFORMAT; + ddsd.dwWidth = 5; > + ddsd.dwHeight = 5; > + ddsd.ddpfPixelFormat.dwSize = sizeof(ddsd.ddpfPixelFormat); > + ddsd.ddpfPixelFormat.dwFlags = DDPF_RGB; > + U1(ddsd.ddpfPixelFormat).dwRGBBitCount = 16; > + U2(ddsd.ddpfPixelFormat).dwRBitMask = 0xF800; > + U3(ddsd.ddpfPixelFormat).dwGBitMask = 0x07E0; > + U4(ddsd.ddpfPixelFormat).dwBBitMask = 0x001F; > + ddsd.ddsCaps.dwCaps = pools[i].caps; > + > + hr = IDirectDraw2_CreateSurface(ddraw, &ddsd, &surface1, NULL); > + ok(SUCCEEDED(hr) || hr == DDERR_UNSUPPORTEDFORMAT || hr == > DDERR_NODIRECTDRAWHW, + "%s: Failed to create surface, hr > %#x.\n", pools[i].name, hr); + if (!surface1) > + { > + skip("%s: Failed to create surface, skipping pitch alignment > test\n", pools[i].name); + continue; > + } > + hr = IDirectDrawSurface_QueryInterface(surface1, > &IID_IDirectDrawSurface2, (void **) &surface); + ok(SUCCEEDED(hr), > "%s: Failed to get DirectDrawSurace2 interface, hr %#x.\n", pools[i].name, > hr); + IDirectDrawSurface_Release(surface1); > + > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + hr = IDirectDrawSurface2_GetSurfaceDesc(surface, &ddsd); > + ok(SUCCEEDED(hr), "Failed to get surface desc, hr %#x.\n", hr); > + > + ok(!(ddsd.lPitch & (pools[i].align - 1)), "%s: Pitch %d is not %u > byte aligned.\n", + pools[i].name, ddsd.lPitch, > pools[i].align); > + if (pools[i].pitch) > + ok(ddsd.lPitch == pools[i].pitch, "%s: Expected pitch %d, got > %d.\n", + pools[i].name, pools[i].pitch, ddsd.lPitch); > + > + IDirectDrawSurface2_Release(surface); > + } > + > + IDirectDraw2_Release(ddraw); > +} > + > START_TEST(ddraw2) > { > test_coop_level_create_device_window(); > @@ -1394,4 +1474,5 @@ START_TEST(ddraw2) > test_texture_load_ckey(); > test_viewport_interfaces(); > test_zenable(); > + test_pitch_alignment(); > } > diff --git a/dlls/ddraw/tests/ddraw4.c b/dlls/ddraw/tests/ddraw4.c > index d9ed90d..c19ba3a 100644 > --- a/dlls/ddraw/tests/ddraw4.c > +++ b/dlls/ddraw/tests/ddraw4.c > @@ -1490,6 +1490,87 @@ static void test_zenable(void) > DestroyWindow(window); > } > > +static void test_pitch_alignment(void) > +{ > + IDirectDraw4 *ddraw; > + IDirectDrawSurface4 *surface; > + HRESULT hr; > + static const struct > + { > + DWORD caps, caps2; > + UINT align; > + LONG pitch; > + const char *name; > + } > + pools[] = > + { > + { > + DDSCAPS_OFFSCREENPLAIN | DDSCAPS_VIDEOMEMORY, 0, > + 8, 0, "D3DPOOL_DEFAULT" > + }, > + { > + DDSCAPS_OFFSCREENPLAIN | DDSCAPS_SYSTEMMEMORY, 0, > + 8, 16, "D3DPOOL_SYSTEMMEM" > + }, > + { > + DDSCAPS_TEXTURE, DDSCAPS2_TEXTUREMANAGE, > + 8, 16, "D3DPOOL_MANAGED" > + } > + }; > + unsigned int i; > + DDSURFACEDESC2 ddsd; > + > + if (!(ddraw = create_ddraw())) > + { > + skip("Failed to create a ddraw object, skipping test.\n"); > + return; > + } > + > + hr = IDirectDraw4_SetCooperativeLevel(ddraw, NULL, DDSCL_NORMAL); > + ok(SUCCEEDED(hr), "Failed to set cooperative level, hr %#x.\n", hr); > + > + for (i = 0; i < (sizeof(pools) / sizeof(*pools)); i++) > + { > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT | > DDSD_PIXELFORMAT; + ddsd.dwWidth = 5; > + ddsd.dwHeight = 5; > + U4(ddsd).ddpfPixelFormat.dwSize = sizeof(U4(ddsd).ddpfPixelFormat); > + U4(ddsd).ddpfPixelFormat.dwFlags = DDPF_RGB; > + U1(U4(ddsd).ddpfPixelFormat).dwRGBBitCount = 16; > + U2(U4(ddsd).ddpfPixelFormat).dwRBitMask = 0xF800; > + U3(U4(ddsd).ddpfPixelFormat).dwGBitMask = 0x07E0; > + U4(U4(ddsd).ddpfPixelFormat).dwBBitMask = 0x001F; > + ddsd.ddsCaps.dwCaps = pools[i].caps; > + ddsd.ddsCaps.dwCaps2 = pools[i].caps2; > + > + hr = IDirectDraw4_CreateSurface(ddraw, &ddsd, &surface, NULL); > + ok(SUCCEEDED(hr) || hr == DDERR_UNSUPPORTEDFORMAT || hr == > DDERR_NODIRECTDRAWHW, + "%s: Failed to create surface, hr > %#x.\n", pools[i].name, hr); + if (!surface) > + { > + skip("%s: Failed to create surface, skipping pitch alignment > test\n", pools[i].name); + continue; > + } > + > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + hr = IDirectDrawSurface4_GetSurfaceDesc(surface, &ddsd); > + ok(SUCCEEDED(hr), "Failed to get surface desc, hr %#x.\n", hr); > + > + ok(!(ddsd.lPitch & (pools[i].align - 1)), "%s: Pitch %d is not %u > byte aligned.\n", + pools[i].name, ddsd.lPitch, > pools[i].align); > + if (pools[i].pitch) > + ok(ddsd.lPitch == pools[i].pitch, "%s: Expected pitch %d, got > %d.\n", + pools[i].name, pools[i].pitch, ddsd.lPitch); > + > + IDirectDrawSurface4_Release(surface); > + } > + > + IDirectDraw4_Release(ddraw); > +} > + > START_TEST(ddraw4) > { > test_process_vertices(); > @@ -1502,4 +1583,5 @@ START_TEST(ddraw4) > test_texture_load_ckey(); > test_viewport_interfaces(); > test_zenable(); > + test_pitch_alignment(); > } > diff --git a/dlls/ddraw/tests/ddraw7.c b/dlls/ddraw/tests/ddraw7.c > index 2ea77fe..4425ad4 100644 > --- a/dlls/ddraw/tests/ddraw7.c > +++ b/dlls/ddraw/tests/ddraw7.c > @@ -1277,6 +1277,87 @@ static void test_zenable(void) > DestroyWindow(window); > } > > +static void test_pitch_alignment(void) > +{ > + IDirectDraw7 *ddraw; > + IDirectDrawSurface7 *surface; > + HRESULT hr; > + static const struct > + { > + DWORD caps, caps2; > + UINT align; > + LONG pitch; > + const char *name; > + } > + pools[] = > + { > + { > + DDSCAPS_OFFSCREENPLAIN | DDSCAPS_VIDEOMEMORY, 0, > + 8, 0, "D3DPOOL_DEFAULT" > + }, > + { > + DDSCAPS_OFFSCREENPLAIN | DDSCAPS_SYSTEMMEMORY, 0, > + 8, 16, "D3DPOOL_SYSTEMMEM" > + }, > + { > + DDSCAPS_TEXTURE, DDSCAPS2_TEXTUREMANAGE, > + 8, 16, "D3DPOOL_MANAGED" > + } > + }; > + unsigned int i; > + DDSURFACEDESC2 ddsd; > + > + if (!(ddraw = create_ddraw())) > + { > + skip("Failed to create a ddraw object, skipping test.\n"); > + return; > + } > + > + hr = IDirectDraw7_SetCooperativeLevel(ddraw, NULL, DDSCL_NORMAL); > + ok(SUCCEEDED(hr), "Failed to set cooperative level, hr %#x.\n", hr); > + > + for (i = 0; i < (sizeof(pools) / sizeof(*pools)); i++) > + { > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT | > DDSD_PIXELFORMAT; + ddsd.dwWidth = 5; > + ddsd.dwHeight = 5; > + U4(ddsd).ddpfPixelFormat.dwSize = sizeof(U4(ddsd).ddpfPixelFormat); > + U4(ddsd).ddpfPixelFormat.dwFlags = DDPF_RGB; > + U1(U4(ddsd).ddpfPixelFormat).dwRGBBitCount = 16; > + U2(U4(ddsd).ddpfPixelFormat).dwRBitMask = 0xF800; > + U3(U4(ddsd).ddpfPixelFormat).dwGBitMask = 0x07E0; > + U4(U4(ddsd).ddpfPixelFormat).dwBBitMask = 0x001F; > + ddsd.ddsCaps.dwCaps = pools[i].caps; > + ddsd.ddsCaps.dwCaps2 = pools[i].caps2; > + > + hr = IDirectDraw7_CreateSurface(ddraw, &ddsd, &surface, NULL); > + ok(SUCCEEDED(hr) || hr == DDERR_UNSUPPORTEDFORMAT || hr == > DDERR_NODIRECTDRAWHW, + "%s: Failed to create surface, hr > %#x.\n", pools[i].name, hr); + if (!surface) > + { > + skip("%s: Failed to create surface, skipping pitch alignment > test\n", pools[i].name); + continue; > + } > + > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + hr = IDirectDrawSurface7_GetSurfaceDesc(surface, &ddsd); > + ok(SUCCEEDED(hr), "Failed to get surface desc, hr %#x.\n", hr); > + > + ok(!(ddsd.lPitch & (pools[i].align - 1)), "%s: Pitch %d is not %u > byte aligned.\n", + pools[i].name, ddsd.lPitch, > pools[i].align); > + if (pools[i].pitch) > + ok(ddsd.lPitch == pools[i].pitch, "%s: Expected pitch %d, got > %d.\n", + pools[i].name, pools[i].pitch, ddsd.lPitch); > + > + IDirectDrawSurface7_Release(surface); > + } > + > + IDirectDraw7_Release(ddraw); > +} > + > START_TEST(ddraw7) > { > HMODULE module = GetModuleHandleA("ddraw.dll"); > @@ -1296,4 +1377,5 @@ START_TEST(ddraw7) > test_depth_blit(); > test_texture_load_ckey(); > test_zenable(); > + test_pitch_alignment(); > }

Feb. 27, 2012

Re: [PATCH 2/2] ddraw/tests: Add pitch alignment tests (try 2)

by Marvin

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=17115 Your paranoid android. === W7PROX64 (64 bit ddraw2) === ddraw2.c:1454: Test failed: D3DPOOL_SYSTEMMEM: Pitch 12 is not 8 byte aligned. ddraw2.c:1457: Test failed: D3DPOOL_SYSTEMMEM: Expected pitch 16, got 12. === TEST64_W7SP1 (64 bit ddraw2) === ddraw2.c:1454: Test failed: D3DPOOL_SYSTEMMEM: Pitch 12 is not 8 byte aligned. ddraw2.c:1457: Test failed: D3DPOOL_SYSTEMMEM: Expected pitch 16, got 12. === W7PROX64 (64 bit ddraw1) === ddraw1.c:1188: Test failed: D3DPOOL_SYSTEMMEM: Pitch 12 is not 8 byte aligned. ddraw1.c:1191: Test failed: D3DPOOL_SYSTEMMEM: Expected pitch 16, got 12. === TEST64_W7SP1 (64 bit ddraw1) === ddraw1.c:1188: Test failed: D3DPOOL_SYSTEMMEM: Pitch 12 is not 8 byte aligned. ddraw1.c:1191: Test failed: D3DPOOL_SYSTEMMEM: Expected pitch 16, got 12. === W7PROX64 (64 bit ddraw7) === ddraw7.c:1349: Test failed: D3DPOOL_SYSTEMMEM: Pitch 12 is not 8 byte aligned. ddraw7.c:1352: Test failed: D3DPOOL_SYSTEMMEM: Expected pitch 16, got 12. ddraw7.c:1336: Test failed: D3DPOOL_MANAGED: Failed to create surface, hr 0x80004002. ddraw7.c:1349: Test failed: D3DPOOL_MANAGED: Pitch 12 is not 8 byte aligned. ddraw7.c:1352: Test failed: D3DPOOL_MANAGED: Expected pitch 16, got 12. === TEST64_W7SP1 (64 bit ddraw7) === ddraw7.c:1349: Test failed: D3DPOOL_SYSTEMMEM: Pitch 12 is not 8 byte aligned. ddraw7.c:1352: Test failed: D3DPOOL_SYSTEMMEM: Expected pitch 16, got 12. ddraw7.c:1336: Test failed: D3DPOOL_MANAGED: Failed to create surface, hr 0x80004002. ddraw7.c:1349: Test failed: D3DPOOL_MANAGED: Pitch 12 is not 8 byte aligned. ddraw7.c:1352: Test failed: D3DPOOL_MANAGED: Expected pitch 16, got 12. === W7PROX64 (64 bit ddraw4) === ddraw4.c:1562: Test failed: D3DPOOL_SYSTEMMEM: Pitch 12 is not 8 byte aligned. ddraw4.c:1565: Test failed: D3DPOOL_SYSTEMMEM: Expected pitch 16, got 12. ddraw4.c:1562: Test failed: D3DPOOL_MANAGED: Pitch 12 is not 8 byte aligned. ddraw4.c:1565: Test failed: D3DPOOL_MANAGED: Expected pitch 16, got 12. === TEST64_W7SP1 (64 bit ddraw4) === ddraw4.c:1562: Test failed: D3DPOOL_SYSTEMMEM: Pitch 12 is not 8 byte aligned. ddraw4.c:1565: Test failed: D3DPOOL_SYSTEMMEM: Expected pitch 16, got 12. ddraw4.c:1562: Test failed: D3DPOOL_MANAGED: Pitch 12 is not 8 byte aligned. ddraw4.c:1565: Test failed: D3DPOOL_MANAGED: Expected pitch 16, got 12.

Feb. 27, 2012

Re: [PATCH] po: Update Swedish translation. (try 2)

by Lauri Kenttä

Please ignore this one, I missed a few bugs. -- Lauri Kenttä

Feb. 27, 2012

Re: Translators wanted!

by Hin-Tak Leung

--- On Mon, 27/2/12, Cheer Xiao <xiaqqaix(a)gmail.com> wrote: > 2012/2/17 Qian Hong <fracting(a)gmail.com>: > > Hello, > > > > On Fri, Feb 17, 2012 at 2:13 AM, Francois Gouget <fgouget(a)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 <snipped> > 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. In another thread, I wrote that some of the recent patch 'tries to improves on windows'. IMHO, this is really not a "translation" job, but just the rather tedious task of looking at what localized windows does in equivalent situations. One should *not* be creative and does one's own thing - the localized message files should be (some version of) what localized windows shows. Anything else is wrong. There are plenty of people running localized windows everywhere these days... shoud not be difficlt to find.

Feb. 27, 2012

Fw: Re: po: zh_TW translation updates

by Hin-Tak Leung

Strange bounces... --- On Mon, 27/2/12, Hin-Tak Leung <hintak_leung(a)yahoo.co.uk> wrote: > --- On Mon, 27/2/12, Francois Gouget > <fgouget(a)free.fr> > wrote: > > > Patches are posted to wine-patches(a)winehq.org: > > http://www.winehq.org/pipermail/wine-patches/2012-February/111804.html > > A quick look at it (it is a few hundred k) - says a few of > the problems I saw and suspected: > > - some of the changes are not improvements/corrections but > just opinionated changes > > - some changes are wrong (i.e. the older version is more > correct/natural and the change makes it worse, not better). > > - some of the changes are over-eager: i.e. it "improves" on > windows and tried to be more user-friendly, but not exactly > how windows does it. > > I think there should be a notes on the translation FAQ: one > is not looking to be "better than" windows, but > bug-for-bug-compatible. Therefore translation is preferably > what regional/localized windows (whatever version) does. > > 20% of the world's population is Chinese, I am sure it is > easy enough to do a few screenshots of localized windows (be > in traditional or simplied) and show how those behave. > > There is a definitive answer (or "definition answers") to > most of these translation strings: what localized windows > (some version) does. It is not up to individual or group > opinions, really. I mean, public libraries, etc have windows > in the far east, there is no excuse to be wrong, or on the > opposite extreme, "try to improve on windows", even if one > does not want to get one's hand dirty and own a windows > box. > > > > >

Feb. 27, 2012

Web based translation tool

by Miroslav Suchý

Hi, I just read: http://www.winehq.org/news/2012022001 and then http://wiki.winehq.org/Translating especially: > The Wine project would be very interested in making its PO files available on web-based community translations systems such as Pootle or Launchpad. Our hope is that this would make translating Wine even easier and engage new translators. > > The reason why it has not happened yet is that all Wine contributions, including for translations, must be attributable to a specific author and that these tools don't make that possible yet. For more details see the wine-devel discussion here and here. Any contributions that would solve this issue would be very welcome. which refer: http://www.winehq.org/pipermail/wine-devel/2012-January/093908.html I would like to point you to: https://www.transifex.net/ which can do the tracking. Latest version is probably not what you want, because it just add at the top of the file: # Translators: # Martin Minar <skulliq(a)gmail.com>, 2011. # Milan Kerslager <kerslage(a)linux.cz>, 2002, 2007. # Miloslav Trmac <mitr(a)volny.cz>, 2002. # Miroslav Suchý <msuchy(a)redhat.com>, 2011. msgid "" msgstr "" "Project-Id-Version: Spacewalk\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2011-12-21 13:07+0100\n" "PO-Revision-Date: 2011-12-14 09:21+0000\n" "Last-Translator: Miroslav Suchý <msuchy(a)redhat.com>\n" "Language-Team: Czech (http://www.transifex.net/projects/p/fedora/team/cs/)\n So you had overview of contributors, but you could not tell which one contributor done which string. But version 0.7 (IIRC) sent each contribution immediately to git. Under login (and email) of that contributor. That contributor was "Author" and commiter was some transifex user. So this way you allow git commit access to those contributors directly to git, but since it goes via that web interface, they could commit only to /po/ directory and even only to language, for which they had been granted. You can download it here: http://trac.transifex.org/files/ and setup your own instance. If is sufficient for you only tracking name of contributors, you can use that hosted solution at: https://www.transifex.net/ -- Miroslav Suchy Red Hat Satellite Engineering

Feb. 27, 2012

Re: Translators wanted!

by Qian Hong

Hi Cheer, On Sun, Feb 26, 2012 at 10:19 PM, Cheer Xiao <xiaqqaix(a)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/

Feb. 27, 2012

Re: po: zh_TW translation updates

by 盧瑞元

Hi all, 在 2012年2月27日上午2:49，Hin-Tak Leung <hintak_leung(a)yahoo.co.uk> 寫道： > --- On Sun, 26/2/12, Francois Gouget <fgouget(a)free.fr> wrote: > >> +#, fuzzy >> msgid "Connection unavailable.\n" >> -msgstr "" >> +msgstr "不可用; 。\n" > > meaning just 'useless/unavailable' - could be improved. > >> msgid "" >> "This program is free software; you can redistribute it >> and/or modify it " >> "under the terms of the GNU Lesser General Public License as >> published by the " >> "Free Software Foundation; either version 2.1 of the >> License, or (at your " >> "option) any later version." >> msgstr "" >> "這個程式是自由軟體﹐您可以遵照\n" >> "自由軟體基金會出版的 GNU LGPL 2.1\n" >> "版或新版的許可條款來修改和重新\n" >> "散佈這個程式。" > > "基金會" seems wrong. Are you sure that's FSF's chinese name? > >> msgid "Finished searching the document." >> -msgstr "檔案搜尋結束。" >> +msgstr "檔案查找結束." "查找" is used in zh_CN, not zh_TW. > The older version is preferred. (may be it is just my opinion). > >> msgid "Failed to load the RichEdit library." >> -msgstr "RichEdit 載入失敗。" >> +msgstr "RichEdit 裝載失敗." Same as above. > ditto here. The older version is preferred. > >> msgid "Overwrite %1? (Yes|No|All)\n" >> -msgstr "" >> +msgstr "是否覆蓋 %1？ >> （是｜否｜全部皆是）\n" > > This translation also looks dubious. > > BTW, where was the patch posted? I don't seem to have the very original patch submission (if it were posted to wine-devel). > > >

Feb. 27, 2012

Re: Translators wanted!

by Cheer Xiao

2012/2/17 Qian Hong <fracting(a)gmail.com>: > Hello, > > On Fri, Feb 17, 2012 at 2:13 AM, Francois Gouget <fgouget(a)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. 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. > > 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, Cheer Xiao aka. xiaq

Feb. 27, 2012

Re: po: fixed remaining Slovenian true positives in the winepo error report

by Francois Gouget

On Sun, 26 Feb 2012, Jaka Kranjc wrote: [...] > This is the reason we have some extra newlines in usage strings. I saw you > removed them as part of one of the patches today, but that's potentially a bad > idea. They use a placeholder for the file name and you know how long they can > get, especially if the dir name isn't stripped first. The extra newline saved a > few characters to make it less likely to wrap. Not in the Slovenian translation then? However in the places where I did the translation line length matched the English line to with a few characters so I'd say it's not a significant factor. But if you have specific concerns let me know. > Probably it is best to reword the original string to not use the filename in > the middle of a sentence and then put it into a separate line. The best is to not hardcode wrapping. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

Feb. 27, 2012

Re: [PATCH] po: Update Swedish translation.

by Frédéric Delanoy

On Sun, Feb 26, 2012 at 20:47, Francois Gouget <fgouget(a)free.fr> wrote: > On Sun, 26 Feb 2012, Lauri Kenttä wrote: > [...] >> >> +msgstr "Verifiera blev %1\n" >> >> By the way, what do you think about translating "Verify" in the first >> place? It's some kind of flag, and it's left untranslated in many other >> languages. (See VERIFY command in cmd.exe.) > > Verify is the name of a command. But here it does not refer to what the > user has to type to invoke the command so I think translation is ok. It's the name of a command, but arguably kind of the name of a flag, so should probably stay untranslated. However, to get a meaningful message, we probably should have something like "Verification mode is disabled" instead of "Verify is off" for instance, but that will have to wait till after 1.4 release. Frédéric

Feb. 27, 2012

Re: po: zh_TW translation updates

by Francois Gouget

On Sun, 26 Feb 2012, Hin-Tak Leung wrote: [...] > BTW, where was the patch posted? I don't seem to have the very > original patch submission (if it were posted to wine-devel). Patches are posted to wine-patches(a)winehq.org: http://www.winehq.org/pipermail/wine-patches/2012-February/111804.html -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ If you think the whole world revolves around you, quit staring at the GPS display while driving.

Feb. 27, 2012

Re: Wrong charcter encoding in winmm-tests

by Francois Gouget

On Sun, 26 Feb 2012, Julian Rüger wrote: [...] > Then shouldn't most or all of those CP_ACPs (and CP_UTF8s) be replaced > with CP_UNIXCP? No. As I said, all the functions that end with an 'A' are supposed to return ANSI strings and thus must use CP_ACP. Remember that Wine is a Win32 API reimplementation so there are a lot of these Ansi functions. Now the places where we actually have to deal with CP_UNIXCP are pretty rare. You'll have to dig deeper to find exactly why the wrong encoding is used in the winmm test. Maybe it is as simple as passing Ansi strings straight to the native printf implementation? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" -- Linus Torvalds

Feb. 27, 2012

Re: [PATCH] po: Update Swedish translation.

by Lauri Kenttä

On 2012-02-26 21:47, Francois Gouget wrote: > Verify is the name of a command. But here it does not refer to what > the > user has to type to invoke the command so I think translation is ok. The program prints ON or OFF anyway, and I'd personally rather see a message like "VERIFY är OFF" (or even "VERIFY = OFF") than "Verifiera är OFF". Maybe there should be two different messages so that ON and OFF could be translated as well. -- Lauri Kenttä

Feb. 26, 2012

Re: Wrong charcter encoding in winmm-tests

by Julian Rüger

> So I think it's the test that should be performing the apprpriate > conversion (assuming we really care) but I can't remember the details I suppose everyone running the tests should be able to figure it out and set $LANG to en_US or something for the test. But I think this is more widespread: $ grep -d recurse "WideCharToMultiByte(CP_ACP" wine-git|wc -l 662 $ grep -d recurse "WideCharToMultiByte(CP_UTF8" wine-git|wc -l 45 > right now. In particular I'm not sure if using CP_UNIXCP would be > appropriate here. It might depend on the API used to write to stdout. > > And starting from a Unicode string would be much much better too... > (in particular for languages like Japanese, etc.) > I guess UNIXCP is the current codepage the host os uses? Like nl_langinfo(CODESET) from langinfo.h? $ grep -d recurse "WideCharToMultiByte(CP_UNIXCP" wine-git|wc -l 72 Then shouldn't most or all of those CP_ACPs (and CP_UTF8s) be replaced with CP_UNIXCP? Best regards, Julian

Feb. 26, 2012

Re: [PATCH 2/2] ddraw/tests: Add pitch alignment tests

by Marvin

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=17108 Your paranoid android. === WNT4WSSP6 (32 bit ddraw2) === ddraw2.c:1438: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw2: unhandled exception c0000005 at 00420FAD === W2KPROSP4 (32 bit ddraw2) === ddraw2.c:1438: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw2: unhandled exception c0000005 at 00420FAD === WXPPROSP3 (32 bit ddraw2) === ddraw2.c:1438: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw2: unhandled exception c0000005 at 00420FAD === W2K3R2SESP2 (32 bit ddraw2) === ddraw2.c:1438: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw2: unhandled exception c0000005 at 00420FAD === WVISTAADM (32 bit ddraw2) === ddraw2.c:1438: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw2: unhandled exception c0000005 at 00420FAD === W2K8SE (32 bit ddraw2) === ddraw2.c:1438: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw2: unhandled exception c0000005 at 00420FAD === W7PRO (32 bit ddraw2) === ddraw2.c:1438: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw2: unhandled exception c0000005 at 00420FAD === W7PROX64 (32 bit ddraw2) === ddraw2.c:1438: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw2: unhandled exception c0000005 at 00420FAD === TEST64_W7SP1 (32 bit ddraw2) === ddraw2.c:1438: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw2: unhandled exception c0000005 at 00420FAD === W7PROX64 (64 bit ddraw2) === ddraw2.c:1438: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. Timeout === TEST64_W7SP1 (64 bit ddraw2) === ddraw2.c:1438: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. Timeout === WNT4WSSP6 (32 bit ddraw1) === ddraw1.c:1175: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw1: unhandled exception c0000005 at 0041A3A5 === W2KPROSP4 (32 bit ddraw1) === ddraw1.c:1175: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw1: unhandled exception c0000005 at 0041A3A5 === WXPPROSP3 (32 bit ddraw1) === ddraw1.c:1175: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw1: unhandled exception c0000005 at 0041A3A5 === W2K3R2SESP2 (32 bit ddraw1) === ddraw1.c:1175: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw1: unhandled exception c0000005 at 0041A3A5 === WVISTAADM (32 bit ddraw1) === ddraw1.c:1175: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw1: unhandled exception c0000005 at 0041A3A5 === W2K8SE (32 bit ddraw1) === ddraw1.c:1175: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw1: unhandled exception c0000005 at 0041A3A5 === W7PRO (32 bit ddraw1) === ddraw1.c:1175: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw1: unhandled exception c0000005 at 0041A3A5 === W7PROX64 (32 bit ddraw1) === ddraw1.c:1175: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw1: unhandled exception c0000005 at 0041A3A5 === TEST64_W7SP1 (32 bit ddraw1) === ddraw1.c:1175: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw1: unhandled exception c0000005 at 0041A3A5 === W7PROX64 (64 bit ddraw1) === ddraw1.c:1175: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. Timeout === TEST64_W7SP1 (64 bit ddraw1) === ddraw1.c:1175: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. Timeout === W2KPROSP4 (32 bit ddraw7) === ddraw7.c:1336: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw7: unhandled exception c0000005 at 0042E3E1 === WXPPROSP3 (32 bit ddraw7) === ddraw7.c:1336: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw7: unhandled exception c0000005 at 0042E3E1 === W2K3R2SESP2 (32 bit ddraw7) === ddraw7.c:1336: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw7: unhandled exception c0000005 at 0042E3E1 === WVISTAADM (32 bit ddraw7) === ddraw7.c:1336: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw7: unhandled exception c0000005 at 0042E3E1 === W2K8SE (32 bit ddraw7) === ddraw7.c:1336: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw7: unhandled exception c0000005 at 0042E3E1 === W7PRO (32 bit ddraw7) === ddraw7.c:1336: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw7: unhandled exception c0000005 at 0042E3E1 === W7PROX64 (32 bit ddraw7) === ddraw7.c:1336: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw7: unhandled exception c0000005 at 0042E3E1 === TEST64_W7SP1 (32 bit ddraw7) === ddraw7.c:1336: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw7: unhandled exception c0000005 at 0042E3E1 === W7PROX64 (64 bit ddraw7) === ddraw7.c:1336: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. Timeout === TEST64_W7SP1 (64 bit ddraw7) === ddraw7.c:1336: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. Timeout === W2KPROSP4 (32 bit ddraw4) === ddraw4.c:1549: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw4: unhandled exception c0000005 at 00427CC1 === WXPPROSP3 (32 bit ddraw4) === ddraw4.c:1549: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw4: unhandled exception c0000005 at 00427CC1 === W2K3R2SESP2 (32 bit ddraw4) === ddraw4.c:1549: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw4: unhandled exception c0000005 at 00427CC1 === WVISTAADM (32 bit ddraw4) === ddraw4.c:1549: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw4: unhandled exception c0000005 at 00427CC1 === W2K8SE (32 bit ddraw4) === ddraw4.c:1549: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw4: unhandled exception c0000005 at 00427CC1 === W7PRO (32 bit ddraw4) === ddraw4.c:1549: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw4: unhandled exception c0000005 at 00427CC1 === W7PROX64 (32 bit ddraw4) === ddraw4.c:1549: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw4: unhandled exception c0000005 at 00427CC1 === TEST64_W7SP1 (32 bit ddraw4) === ddraw4.c:1549: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw4: unhandled exception c0000005 at 00427CC1 === W7PROX64 (64 bit ddraw4) === ddraw4.c:1549: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. Timeout === TEST64_W7SP1 (64 bit ddraw4) === ddraw4.c:1549: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. Timeout

Feb. 26, 2012

Re: Wrong charcter encoding in winmm-tests

by Francois Gouget

On Sun, 26 Feb 2012, Julian Rüger wrote: > OK, I think I finally found out what's going on here: > > in waveform.c waveOutGetErrorTextA() calls > WideCharToMultiByte(CP_ACP,.... with the ANSI codepage. > When I change that to CP_UTF8, it works as expected. > > Is this fix OK, or does that break anything? Should I send a patch? waveOutGetErrorTextA() is correct. As its name indicates it's supposed to return an ANSI string. So I think it's the test that should be performing the apprpriate conversion (assuming we really care) but I can't remember the details right now. In particular I'm not sure if using CP_UNIXCP would be appropriate here. It might depend on the API used to write to stdout. And starting from a Unicode string would be much much better too... (in particular for languages like Japanese, etc.) -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !

Feb. 26, 2012

Re: [PATCH] po: Update Swedish translation.

by Francois Gouget

On Sun, 26 Feb 2012, Lauri Kenttä wrote: [...] > >> +msgstr "Verifiera blev %1\n" > > By the way, what do you think about translating "Verify" in the first > place? It's some kind of flag, and it's left untranslated in many other > languages. (See VERIFY command in cmd.exe.) Verify is the name of a command. But here it does not refer to what the user has to type to invoke the command so I think translation is ok. Also note that whichever policy is selected here should also apply to the 'echo' command and maybe others: #, fuzzy msgid "Echo is %1\n" msgstr "Ekot är %s\n" -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

Feb. 26, 2012

Re: shlwapi: Implemented StrToInt64ExA/W

by Jacek Caban

Hi Carlo, On 2/26/12 12:56 PM, carlo.bramix(a)libero.it wrote: > I improved the patch according to the suggestions that I received: > 1) Removed the C++ style comment > 2) Removed the WARN message > 3) Added the tests for the new functions. The test has been run successfully > on Ubuntu 11.10. > > Sincerely Thanks for fixing those. This version looks better, but still could use some improvements (mostly for failing tests on win2k). BOOL WINAPI StrToIntExA(LPCSTR lpszStr, DWORD dwFlags, LPINT lpiRet) { + LARGE_INTEGER li; + BOOL bRes; + + TRACE("(%s,%08X,%p)\n", debugstr_a(lpszStr), dwFlags, lpiRet); + + if (!lpiRet) + return FALSE; In previous patch you mentioned that Windows crashes in this situation. Thus there is no point in having this check on Wine. int str_to_int; int str_to_int_ex; int str_to_int_hex; + LONGLONG str_to_int64_ex; + LONGLONG str_to_int64_hex; AFAICS int str_to_int* always matches str_to_int64* values except for overflows. It means that you could simply change str_to_int_* to be LONGLONG and simply cast it to int before using it in existing tests. + { "0x44ff", 0, 0, 0x44ff, 0, 0x44ff }, + { "0x2bdc546291f4b1", 0, 0, 0x6291f4b1, 0, 0x2bdc546291f4b1 }, 64-bit literals are not portable. Something like ((ULONGLONG)0x2bdc54<<32) | (ULONGLONG)0x6291f4b1 would do the trick. + while (result->string) + { + return_val = -1; + bRet = StrToInt64ExA(result->string,0,&return_val); This function is not available on win2k (http://testbot.winehq.org/JobDetails.pl?Key=17105&scrshot_202=1#k202) so it needs to be loaded dynamically via GetProcAddress. See how other functions are handled. Cheers, Jacek

Feb. 26, 2012

Re: po: zh_TW translation updates

by Hin-Tak Leung

--- On Sun, 26/2/12, Francois Gouget <fgouget(a)free.fr> wrote: > +#, fuzzy > msgid "Connection unavailable.\n" > -msgstr "" > +msgstr "不可用; 。\n" meaning just 'useless/unavailable' - could be improved. > msgid "" > "This program is free software; you can redistribute it > and/or modify it " > "under the terms of the GNU Lesser General Public License as > published by the " > "Free Software Foundation; either version 2.1 of the > License, or (at your " > "option) any later version." > msgstr "" > "這個程式是自由軟體﹐您可以遵照\n" > "自由軟體基金會出版的 GNU LGPL 2.1\n" > "版或新版的許可條款來修改和重新\n" > "散佈這個程式。" "基金會" seems wrong. Are you sure that's FSF's chinese name? > msgid "Finished searching the document." > -msgstr "檔案搜尋結束。" > +msgstr "檔案查找結束." The older version is preferred. (may be it is just my opinion). > msgid "Failed to load the RichEdit library." > -msgstr "RichEdit 載入失敗。" > +msgstr "RichEdit 裝載失敗." ditto here. The older version is preferred. > msgid "Overwrite %1? (Yes|No|All)\n" > -msgstr "" > +msgstr "是否覆蓋 %1？ > （是｜否｜全部皆是）\n" This translation also looks dubious. BTW, where was the patch posted? I don't seem to have the very original patch submission (if it were posted to wine-devel).

Feb. 26, 2012

Re: po: fixed remaining Slovenian true positives in the winepo error report

by Jaka Kranjc

On Saturday 25 of February 2012 18:54:15 Francois Gouget wrote: > On Wed, 22 Feb 2012, Jaka Kranjc wrote: > [...] > > This brings up another can of worms though; capitalisation. We don't use > > title case at all, so these translation have the wrong case. Well, except > > for the first one being printed, but that is runtime knowledge, so we > > can't really fix it well. Gettext has no provisions for this (or gender > > or ...), so all that comes to mind is autocapitalisation depending on the > > locale, but that is probably ugly and I doubt it would work with more > > exotic scripts (but not sure if any would need it). > > I don't think we really care about capitalization in this specific case > (or that it can be handled right anyway). > > So would the attached patch work? Sure. > > Re usage strings: is there no 80 column limit imposed? I saw even some > > original strings were longer. > > If no line feed is hardcoded then the line will wrap at the 80th column. > The line feeds are only there to ensure words are not cut in the middle. > I suspect the authors of the command line tools did not care about that. > Or they did not want to hardcode line wrapping at 80 columns when the > terminal may be wider or narrower. And that issue was probably > overlooked in a number of cases too. So these are probably all > contributing factors to the current situation. This is the reason we have some extra newlines in usage strings. I saw you removed them as part of one of the patches today, but that's potentially a bad idea. They use a placeholder for the file name and you know how long they can get, especially if the dir name isn't stripped first. The extra newline saved a few characters to make it less likely to wrap. Probably it is best to reword the original string to not use the filename in the middle of a sentence and then put it into a separate line. LP -- To err is humor

Feb. 26, 2012

RE: msvcrt/file.c: file mode T (temporary file) (try 2)

by Robert van Herk

> > + case 'T': > > + FIXME("Implement T flag (temporary file, i.e. delete on close, don't flush to disk if possible)"); > > + break; > So what actually prevents you from properly implementing this? Especially > that Wine already supports temporary files. Search for MSVCRT__O_TEMPORARY My lack of knowledge of what was already implemented, I guess :-). Plus: I was already so happy that my Win32 application didn't crash any more :-). But OK, I try implementing it properly. Then I'll map as follows: 'T' -> MSVCRT__O_SHORT_LIVED 'D' -> MSVCRT__O_TEMPORARY I'll try to send a new version (try 3) tomorrow. By the way, 'R' also doesn't follow the MS spec: 'R' is supposed to mean "_O_RANDOM_" but the current Wine implementation maps it like 'r', which is "read". I find it scary to blindly change that, cause there may be some risky cases like "R+", etc. If I have time I'll try to investigate that too, but it'll have to go in a later patch... Regards, Robert

Feb. 26, 2012

Re: [PATCH] po: Update Swedish translation.

by Lauri Kenttä

Thanks, I'll do the corrections. I mostly trusted the previous translator and only changed the parts that were causing the "fuzzy" comments. On 2012-02-26 14:07, Jan-Peter Nilsson wrote: > I would assume 'Luminance' to be translated to 'Luminans', so Lum as > abbreviation makes sense to me. I translated it as 'Valör' (misled by the "V" in GIMP). GIMP actually uses 'Värde'. According to Wikipedia, HSV = NMI, where the I stands for 'Intensitet'. Which one would be best? What does Windows use? >> +msgstr "Verifiera blev %1\n" By the way, what do you think about translating "Verify" in the first place? It's some kind of flag, and it's left untranslated in many other languages. (See VERIFY command in cmd.exe.) > To me 'val' reads more like 'selection' than 'option'. You're probably right. Does 'flagga' sound any better? >> msgid "Wine File Manager" >> -msgstr "Winefile" >> +msgstr "Wine Filhanteraren" > > "Wine Filhanterare", unless we want definite form "The Wine File > Manager". Are you sure? I believe Windows used to have "Filhanteraren" and now has "Utforskaren". Also, Wine already has "Registereditorn". They're program names, so it makes sense to use the definite forms. -- Lauri Kenttä

Feb. 26, 2012

Spaces in the Korean translation.

by Francois Gouget

I noticed some leading and trailing space issues in the Korean translation. I think these are probably safe to change. However I then noticed that there was a lot of sentences mixed single and double spaces. So I wonder if that's normal, maybe tied to a Korean typography rule related to half vs. full width characters; or if only single or double spaces should be present. Here are a few examples: "주의: 이 파일 형식은 아마도 하나 이상의 인증서,인증서 파기 목록,인증서 신뢰 " ^^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ "목록을 가지고 있을 수 있음:" ^ ^ ^ ^ msgstr "'여기로부터'엔트리는 여기까지'엔트리에 도달 할 수 없습니다." ^^ ^ ^ ^ ^ msgstr "대기열에는 %d의 문서가 존재합니다" ^^ ^ ^ -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

Feb. 26, 2012

Re: Wrong charcter encoding in winmm-tests

by Julian Rüger

OK, I think I finally found out what's going on here: in waveform.c waveOutGetErrorTextA() calls WideCharToMultiByte(CP_ACP,.... with the ANSI codepage. When I change that to CP_UTF8, it works as expected. Is this fix OK, or does that break anything? Should I send a patch? Thanks, Julian

Feb. 26, 2012

Re: msvcrt/file.c: file mode T (temporary file) (try 2)

by Vitaliy Margolen

On 02/25/2012 05:30 AM, Robert van Herk wrote: > Try 2 fixes some blatant memory bug in the conformance test > --------------------------------------------------------------------------- > > Windows fopen has some fancy file modes 'T' and 'D'. > Currently, wine wrongly interprets 'T' as 't'. They should be interpreted > differently though: 't' is text file, and 'T' is temporary file. > > I've fixed this, and added a conformance test. > + case 'T': > + FIXME("Implement T flag (temporary file, i.e. delete on close, don't flush to disk if possible)"); > + break; So what actually prevents you from properly implementing this? Especially that Wine already supports temporary files. Search for MSVCRT__O_TEMPORARY Vitaliy.

Feb. 26, 2012

Re: Wrong charcter encoding in winmm-tests

by Julian Rüger

> waveOutGetErrorTextA() if I am not mistaken. Forget that part please ;) So, the .po is UTF-8, the terminal is UTF-8 and my $LANG is de_DE.UTF-8, but somewhere it is converted to 8859-1...

Feb. 26, 2012

Re: sk.po

by Francois Gouget

Thanks for the translation updates. I noticed some potential issues while proofreading it: "to modify its installed components, select it from the list and click Change/" "Remove." msgstr "" +"Nasledujúci program môže byť automaticky odinštalovaný. K odstráneniu programu " +"alebo k modifukácii jeho inštalovaných súčastí, zvoľte možnosť zo zoznamu a kliknite " +"Zmeniť/Odstrániť" There should probably be a trailing full stop. msgid "Publisher:" -msgstr "" +msgstr "Vydavateľ" msgid "Version:" -msgstr "" +msgstr "Verzia" These are missing the trailing colon (these are likely field labels in a dialog). msgid "&Settings..." -msgstr "" +msgstr "&Nastavenia" #, fuzzy msgid "&Modify..." -msgstr "Modifikovaný" +msgstr "&Zmeniť" #, fuzzy msgid "&Install" -msgstr "&Skomentovať..." +msgstr "&Inštalovať..." These are either missing the trailing ellipsis or have one that should not be there. Ellipses are very important because, for instance, they make all the difference between a 'Print' button that will send the page to the default printer right away, and a 'Print...' button that will first display a dialog that will let you choose the destination printer or cancel before anything happens. Note that I did not list all ellipsis issues here. Also this is one of the points that my script checks so you'll see any ellipsis issue in Wine's PO file there: http://fgouget.free.fr/wine-po/sk-errors.html #, fuzzy msgid "Unexpected network error.\n" -msgstr "Nedefinovaná externá chyba." +msgstr "Nedefinovaná sieťová chyba." This translation should have a trailing linefeed. Also I notice that you did not remove the 'fuzzy' flag, not only here but also for quite a few other translations, including two others above. The fuzzy flag indicates that the translation is potentially incomplete or incorrect and thus requires more work or a review. So as long as it is present the translation will not be used. Keep up the good work. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

Feb. 26, 2012

Wrong charcter encoding in winmm-tests

by Julian Rüger

Hello everyone, I ran the winmm-tests in wine today, with a german locale, and noticed that the umlauts are displayed incorrectly. My terminal is in UTF-8 and wine outputs ISO 8859-1. I looked into the code and found out that ie. in wave.c, wave_out_error() declares the strings as static char, and thus uses waveOutGetErrorTextA() if I am not mistaken. Should this be fixed or doesn't it matter in the tests? Best regards, Julian

Feb. 26, 2012

Re: po: zh_TW translation updates

by Franklin Weng

Hi, Thank you for your notification. I'll fix it in a few days and provide the patch again. Tuesday or Wednesday the latest I think, since I have some important things to do these days. If it can't catch the release schedule of wine 1.4 please tell me and I'll send it as soon as possible. Thanks, Franklin 在 2012年2月26日下午10:14，Francois Gouget <fgouget(a)free.fr> 寫道： > > It's great seeing lots of progress being made on the Taiwanese > translation. > > There are a few changes that look a bit strange to me though: > > msgid "Theme files (*.msstyles; *.theme)" > -msgstr "佈景主題檔案 (*.msstyles；*.theme)" > +msgstr "佈景主題檔案 (*.msstyles; *.theme)" > > msgid "TypeLib files (*.tlb; *.olb; *.dll; *.ocx; *.exe)" > -msgstr "TypeLib 檔案 (*.tlb；*.olb；*.dll；*.ocx；*.exe)" > +msgstr "TypeLib 檔案 (*.tlb;*.olb;*.dll;*.ocx;*.exe)" > > So half width semicolons seem to be preferred to full width ones which > is fine to me. But in the first patch it's followed by a space, like in > English, and not in the second one which seems inconsistent. > > > msgid "Wine Programs (*.exe; *.exe.so)" > -msgstr "Wine 程式 (*.exe；*.exe.so)" > +msgstr "Wine 程式 (*.exe,*.exe.so)" > > Here the semicolon was replaced by a comma (and no space), which is > probably wrong. > > > msgid "Programs (*.exe)" > -msgstr "程式 (*.exe)" > +msgstr "程式(*.exe) " > > The previous changes all preserved the space before the opening > parenthesis. If I add the fact that this introduces a space after > the closing parenthesis I'd guess this was unintentional. > > > msgid "Printer files (*.prn)" > -msgstr "列印檔案 (*.prn)" > +msgstr "列印檔案 (*.PRN)" > > All other strings of this type use lower case for the extension so I'm > not sure about this change. > > > +#, fuzzy > msgid "The device door is open.\n" > -msgstr "" > +msgstr "印表機蓋是打開的; 。\n" > > +#, fuzzy > msgid "Connection unavailable.\n" > -msgstr "" > +msgstr "不可用; 。\n" > > The combination of the semicolon and full width full stop seems wrong. I > suspect the fuzzy translations were from the printer common dialog > English strings that ended in a semicolon which escaped removal. > > > msgid "" > "This program is free software; you can redistribute it and/or modify it " > "under the terms of the GNU Lesser General Public License as published by the " > "Free Software Foundation; either version 2.1 of the License, or (at your " > "option) any later version." > msgstr "" > "這個程式是自由軟體﹐您可以遵照\n" > "自由軟體基金會出版的 GNU LGPL 2.1\n" > "版或新版的許可條款來修改和重新\n" > "散佈這個程式。" > > This string is not supposed to be explicitly wrapped. Is the wrapping > made necessary for Taiwanese because of a Wine bug? > > > msgid "Finished searching the document." > -msgstr "檔案搜尋結束。" > +msgstr "檔案查找結束." > > msgid "Failed to load the RichEdit library." > -msgstr "RichEdit 載入失敗。" > +msgstr "RichEdit 裝載失敗." > > Everywhere else full width full stops are used so this change looks > strange to me. > > > msgid "Overwrite %1? (Yes|No|All)\n" > -msgstr "" > +msgstr "是否覆蓋 %1？（是｜否｜全部皆是）\n" > > Note that in English the 'Yes' implies one should use the 'Y' key, > etc. So this set of strings is tied to the following translations: > > msgctxt "Yes key" > msgid "Y" > msgstr "" > > msgctxt "No key" > msgid "N" > msgstr "" > > msgctxt "All key" > msgid "A" > msgstr "" > > So depending on the keyboard layout it may be necessary to do something > like '（是(Y)｜否(N)｜全部皆是(A)）' > > > There's another translation which works the same way, look for > "(F - File, D - Directory)" > > > -- > Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

Feb. 26, 2012

Re: po: zh_TW translation updates

by Francois Gouget

It's great seeing lots of progress being made on the Taiwanese translation. There are a few changes that look a bit strange to me though: msgid "Theme files (*.msstyles; *.theme)" -msgstr "�Ѿ��}�n�� (*.msstyles��*.theme)" +msgstr "�Ѿ��}�n�� (*.msstyles; *.theme)" msgid "TypeLib files (*.tlb; *.olb; *.dll; *.ocx; *.exe)" -msgstr "TypeLib �n�� (*.tlb��*.olb��*.dll��*.ocx��*.exe)" +msgstr "TypeLib �n�� (*.tlb;*.olb;*.dll;*.ocx;*.exe)" So half width semicolons seem to be preferred to full width ones which is fine to me. But in the first patch it's followed by a space, like in English, and not in the second one which seems inconsistent. msgid "Wine Programs (*.exe; *.exe.so)" -msgstr "Wine ��ʽ (*.exe��*.exe.so)" +msgstr "Wine ��ʽ (*.exe,*.exe.so)" Here the semicolon was replaced by a comma (and no space), which is probably wrong. msgid "Programs (*.exe)" -msgstr "��ʽ (*.exe)" +msgstr "��ʽ(*.exe) " The previous changes all preserved the space before the opening parenthesis. If I add the fact that this introduces a space after the closing parenthesis I'd guess this was unintentional. msgid "Printer files (*.prn)" -msgstr "��ӡ�n�� (*.prn)" +msgstr "��ӡ�n�� (*.PRN)" All other strings of this type use lower case for the extension so I'm not sure about this change. +#, fuzzy msgid "The device door is open.\n" -msgstr "" +msgstr "ӡ��C�w�Ǵ��_��; ��\n" +#, fuzzy msgid "Connection unavailable.\n" -msgstr "" +msgstr "��; ��\n" The combination of the semicolon and full width full stop seems wrong. I suspect the fuzzy translations were from the printer common dialog English strings that ended in a semicolon which escaped removal. msgid "" "This program is free software; you can redistribute it and/or modify it " "under the terms of the GNU Lesser General Public License as published by the " "Free Software Foundation; either version 2.1 of the License, or (at your " "option) any later version." msgstr "" "�@��ʽ��ܛ�w�o��\n" "��ܛ�w�� GNU LGPL 2.1\n" "��°��S�ɗl��޸ĺ��\n" "ɢ��@��ʽ��" This string is not supposed to be explicitly wrapped. Is the wrapping made necessary for Taiwanese because of a Wine bug? msgid "Finished searching the document." -msgstr "�n��ь��Y��" +msgstr "�n��ҽY��." msgid "Failed to load the RichEdit library." -msgstr "RichEdit �d��ʧ��" +msgstr "RichEdit �b�dʧ��." Everywhere else full width full stops are used so this change looks strange to me. msgid "Overwrite %1? (Yes|No|All)\n" -msgstr "" +msgstr "�Ƿ��w %1�� ǣ��ȫ��ǣ�\n" Note that in English the 'Yes' implies one should use the 'Y' key, etc. So this set of strings is tied to the following translations: msgctxt "Yes key" msgid "Y" msgstr "" msgctxt "No key" msgid "N" msgstr "" msgctxt "All key" msgid "A" msgstr "" So depending on the keyboard layout it may be necessary to do something like '��(Y)��(N)��ȫ��(A)��' There's another translation which works the same way, look for "(F - File, D - Directory)" -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

Feb. 26, 2012

Re: [PATCH] po: Update Swedish translation.

by Jan-Peter Nilsson

Hi I have a few questions/comments/suggestions on/for the change in the Swedish translation. On -28163-01--10 20:59, Lauri Kenttä wrote: > #: comdlg32.rc:292 > -#, fuzzy > msgctxt "Luminance" > msgid "&Lum:" > -msgstr "&Lum:" > +msgstr "&Val:" Can you explain 'Val' here? I don't understand it. I would assume 'Luminance' to be translated to 'Luminans', so Lum as abbreviation makes sense to me. > #: ieframe.rc:78 > -#, fuzzy > msgid "Searching for %s" > -msgstr "Egenskaper för %s" > +msgstr "Söker för %s" "Söker efter" would probably be better. > #: shell32.rc:215 > -#, fuzzy > msgid "Common Files" > -msgstr "Kopierar filer..." > +msgstr "" Perhaps 'Delade Filer'? > #: cmd.rc:331 > -#, fuzzy > msgid "Verify is %1\n" > -msgstr "Verifiera blev %s\n" > +msgstr "Verifiera blev %1\n" I would use 'är', 'blev' is more 'became' than 'is'. > #: cmd.rc:335 > -#, fuzzy > msgid "Volume label (11 characters, <Enter> for none)?" > -msgstr "Diskvolymens namn (11 karaktärer, tryck enter för inget)?" > +msgstr "Diskvolymens namn (11 karaktärer, tryck <Enter> för inget)?" 'Karaktärer' is the other kind of characters, the word here is 'tecken'. > #: explorer.rc:29 > #, fuzzy > @@ -10042,9 +9949,8 @@ msgid "Usage: hostname\n" > msgstr "" > > #: hostname.rc:28 > -#, fuzzy > msgid "Error: Invalid option '%c'.\n" > -msgstr "Fel: ogiltigt nyckelnamn\n" > +msgstr "Fel: Ogiltigt val '%c'.\n" I'm not sure about 'val' here. To me 'val' reads more like 'selection' than 'option'. > #: net.rc:41 > msgid "There are no entries in the list.\n" > @@ -10215,14 +10110,12 @@ msgstr "" > "---------------------------------------------------------------\n" > > #: net.rc:43 > -#, fuzzy > msgid "%1 %2 %3 Open resources: %4!u!\n" > -msgstr "%s %s %s Öppna resurser: %lu\n" > +msgstr "%1 %1 %1 Öppna resurser: %4!u!\n" I suppose that should be %1 %2 %3. > #: regedit.rc:88 > -#, fuzzy > msgid "Modify Binary Data..." > -msgstr "Ändra binärt data" > +msgstr "Ändra binärt data..." 'binärdata' is one word. > #: taskkill.rc:31 > -#, fuzzy > msgid "Error: Option %1 expects a command line parameter.\n" > -msgstr "Fel: Valet %s kräver en kommandoradsparameter.\n" > +msgstr "Fel: Valet %1 kräver en kommandoradsparameter.\n" > > #: taskkill.rc:32 > msgid "Error: Options /im and /pid are mutually exclusive.\n" > msgstr "Fel: Valen /im och /pid kan inte användas tillsammans.\n" > Val again. I don't really have any better suggestion, but it sounds strange to me. > #: winecfg.rc:146 > -#, fuzzy > msgid "" > "Wine can mimic different Windows versions for each application. This tab is " > "linked to the Libraries and Graphics tabs to allow you to change systemwide " > "or per-application settings in those tabs as well." > msgstr "" > -"Wine kan imitera olika Windows-versioner för varje program. Den här fliken " > +"Wine kan imitera olika Windows-versioner för varje program. Den här fliken " > "är länkad till flikarna Bibliotek och Grafik för att låta dig ändra " > "inställningar i de flikarna också, antingen systembreda eller per program." > I believe 'systemövergripande' would be better than 'systembreda'. > > #: winecfg.rc:83 > -#, fuzzy > msgid "Audio test failed!" > -msgstr "Återställning av hårddisk misslyckades\n" > +msgstr "" Maybe "Ljudtest misslyckades!" ? > > #: winecfg.rc:85 > -#, fuzzy > msgid "(System default)" > -msgstr "Systemsökväg" > +msgstr "" Maybe "(Systemstandard)" ? > #: winefile.rc:197 > msgctxt "accelerator Fullscreen" > @@ -13528,9 +13355,8 @@ msgid "Error while selecting new font." > msgstr "Ett fel uppstod när ett nytt teckensnitt valdes." > > #: winefile.rc:95 > -#, fuzzy > msgid "Wine File Manager" > -msgstr "Winefile" > +msgstr "Wine Filhanteraren" "Wine Filhanterare", unless we want definite form "The Wine File Manager". > #: wordpad.rc:188 > -#, fuzzy > msgid "OLE storage documents are not supported." > -msgstr "Utökade attribut ej stödda\n" > +msgstr "" Maybe "OLE lagringsdokument stöds ej." ? //Jan-Peter

Feb. 26, 2012

Re: shlwapi: Implemented StrToInt64ExA/W

by Marvin

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=17105 Your paranoid android. === W2KPROSP4 (32 bit string) === Timeout

Feb. 26, 2012

Re: RFT: Use Greek semicolons for comdlg32's printer status enumeration?

by Jerome Leclanche

2012/2/25 Francois Gouget <fgouget(a)free.fr> > > So I would expect the Greek translation to use ano teleia characters as > the separator but instead it uses plain semicolons: > > msgid "Paused; " > msgstr "Σταματημένος; " > > msgid "Error; " > msgstr "Σφάλμα; " > > msgid "Busy; " > msgstr "Απασχολημένος; " > > > So I'm hoping some Greek-speaking Wine hacker or user can enlighten me > on the following points: > * Did I understand Wikipedia wrong? Do both English semicolons and > question marks translate to a semicolon in Greek? > > * Is this a special case that justifies not following the standard > rule? If so why? > > * Does the attached patch replacing semicolons with ano teleia > characters make sense? > (Greek is my second native language) - You understood Wikipedia correctly, a latin semicolon character is always interpreted as a questionmark. - You will never find a semicolon used as anything else in (proper) Greek. There are no special cases. Though you'll commonly find people using a latin questionmark instead of a semicolon online. - I don't think an ano telia would be appropriate for this. To be honest I don't even find a semicolon appropriate in English here. I don't build with printing support but it sounds to me like it would be more appropriate to use a comma, or a dash. J. Leclanche

Feb. 25, 2012

Re: po: fixed remaining Slovenian true positives in the winepo error report

by Francois Gouget

On Wed, 22 Feb 2012, Jaka Kranjc wrote: [...] > So if I understand correctly, parts of this composite get choped and > concatenated and then printed as a sequence. Lacking full sentences, > semicolons *are* a good choice for Slovenian in this case too. Commas would be > fitting for proper "etc" lists. > > This brings up another can of worms though; capitalisation. We don't use title > case at all, so these translation have the wrong case. Well, except for the > first one being printed, but that is runtime knowledge, so we can't really fix > it well. Gettext has no provisions for this (or gender or ...), so all that > comes to mind is autocapitalisation depending on the locale, but that is > probably ugly and I doubt it would work with more exotic scripts (but not sure > if any would need it). I don't think we really care about capitalization in this specific case (or that it can be handled right anyway). So would the attached patch work? [...] > Re usage strings: is there no 80 column limit imposed? I saw even some > original strings were longer. If no line feed is hardcoded then the line will wrap at the 80th column. The line feeds are only there to ensure words are not cut in the middle. I suspect the authors of the command line tools did not care about that. Or they did not want to hardcode line wrapping at 80 columns when the terminal may be wider or narrower. And that issue was probably overlooked in a number of cases too. So these are probably all contributing factors to the current situation. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.

Feb. 25, 2012

Re: shlwapi: Implemented StrToInt64ExA/W

by Nikolay Sivov

On 2/25/2012 17:49, carlo.bramix(a)libero.it wrote: > I tried to implement StrToInt64ExA/W as a reply to bug #27633 > I also corrected the comment in functions FormatInt() and FormatDouble() > because, according to MSDN, GetNumberFormat() returns the number of characters > written (or required) and not the number of bytes emitted: > http://msdn.microsoft.com/en-us/library/windows/desktop/dd318110%28v=vs.85%…. > aspx > I hope my first patch to WINE is correct and it could be useful. > Sincerely, > > Carlo Bramini. > > > > BOOL WINAPI StrToIntExA(LPCSTR lpszStr, DWORD dwFlags, LPINT lpiRet) > { > + LARGE_INTEGER li; > + BOOL bRes; > + > + TRACE("(%s,%08X,%p)\n", debugstr_a(lpszStr), dwFlags, lpiRet); > + > + // Test on lpszStr is done into StrToInt64ExA No cpp comments please. Also this comment is a bit redundant for a function that small. > + if (!lpiRet) > + { > + WARN("Invalid lpiRet would crash under Win32!\n"); > + return FALSE; > + } You don't need to WARN on that, especially with such message. > + > + bRes = StrToInt64ExA(lpszStr, dwFlags,&li.QuadPart); > + if (bRes) > + *lpiRet = li.u.LowPart; > + > + return bRes; > +} This needs tests, take a look at shlwapi/tests for some examples.

Feb. 25, 2012

RFT: Use Greek semicolons for comdlg32's printer status enumeration?

by Francois Gouget

Request For Translators<g> So what I've gathered from Wikipedia is that the Greek language does not use semicolons as a separator for enumerations: http://en.wikipedia.org/wiki/Semicolon#Greek_and_Church_Slavonic | In Greek and Church Slavonic, a semicolon indicates a question, | similar to a Latin question mark.[2] To indicate a long pause or | separate sections, each with commas (the semicolon's purpose in | English), Greek uses an ano teleia ( · ). Wine uses semicolons as a separator in one place, for comdlg32's printer status enumeration. It's a list of status indicators separated by semicolons and looks like this: Error; Paper jam; or Initialising; Default Printer; I/O Active; So I would expect the Greek translation to use ano teleia characters as the separator but instead it uses plain semicolons: msgid "Paused; " msgstr "Σταματημένος; " msgid "Error; " msgstr "Σφάλμα; " msgid "Busy; " msgstr "Απασχολημένος; " So I'm hoping some Greek-speaking Wine hacker or user can enlighten me on the following points: * Did I understand Wikipedia wrong? Do both English semicolons and question marks translate to a semicolon in Greek? * Is this a special case that justifies not following the standard rule? If so why? * Does the attached patch replacing semicolons with ano teleia characters make sense? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.

Feb. 25, 2012

Re: msvcrt/file.c: file mode T (temporary file)

by Nikolay Sivov

On 2/25/2012 00:19, Robert van Herk wrote: > Windows fopen has some fancy file modes 'T' and 'D'. > Currently, wine wrongly interprets 'T' as 't'. They should be > interpreted differently though: 't' is text file, and 'T' is temporary > file. > > I've fixed this, and added a conformance test. > > Test ran on Windows 7 Home Premium. > > Kind regards, > Robert > > dlls/msvcrt/file.c | 8 +++++- > dlls/msvcrt/tests/Makefile.in | 1 + > dlls/msvcrt/tests/filemodeT.c | 61 +++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 69 insertions(+), 1 deletions(-) > create mode 100644 dlls/msvcrt/tests/filemodeT.c You clearly don't need a new file for that, please place it into existing file.c.

Feb. 25, 2012