- wine-devel - winehq.org

bugzilla: show the component, not "comp" and not the assignee
by Joerg-Cyril.Hoehle＠t-systems.com 01 Mar '12

01 Mar '12

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

2 1

Debugging WINE 1.3.24 with GDB
by louis＠museresearch.com 29 Feb '12

29 Feb '12

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

1 0

Re: po: Spanish translation update for cmd.rc (almost complete)
by Eduardo García 29 Feb '12

29 Feb '12

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. > > > > >

1 0

Re: po: Spanish translation update for cmd.rc (almost complete)
by Eduardo García 29 Feb '12

29 Feb '12

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. > > > > > > >

1 0

Re: Fix references to the LGPL
by Alexandre Julliard 29 Feb '12

29 Feb '12

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

1 0

Major mmdevapi and winmm audio bugs
by Joerg-Cyril.Hoehle＠t-systems.com 29 Feb '12

29 Feb '12

Hi, instead of Wine Weekly News (WWN, any taker?) you get monthly audio news. The surprising thing is: it looks like most audio bugs remaining in bugzilla are from the pre-mmdevapi era and have not been updated since mid-2011. - Using devices other than "default" (dmix or pulse): #29294 no sound with ALSA loopback -- are they duplicates of each other #28781 loopback to Jack -- or is one about DSound only? We have are several issues about crackling sound: - One definitely is caused by CreateTimerQueue which is not regular enough or does not deliver 10ms, but 12ms callbacks. This is in #28723 which includes a work-around in comment #130 That may affect the Solaris machine on test.winehq.org too. - One is caused by a mmdevapi design error: the audio buffer we use is simply too small, and Linux can't bear a regular 10ms rate. Things got worse since the introduction of the Completely Fair Scheduler. It can't even guarantee a regular 50ms one. There's a need for a much larger buffer. That's why wine < 1.3.25 is giving steadier sound. #29531 may be caused by this. - Mac OS X 10.5.8 crackles constantly with dlls/mmdevapi/tests/render I'd like somebody with 10.6 or .7 to perform the interactive test. rm -f render.ok; WINETEST_INTERACTIVE=1 make render.ok - Lastly, there's PulseAudio #28856 among others I don't understand why I couldn't find bugs in PA's bugzilla, so I wrote some: - https://bugs.freedesktop.org/show_bug.cgi?id=46296 About the need to restart the PA server from time to time - https://bugs.freedesktop.org/show_bug.cgi?id=46297 PA's huge buffering causes issues with winmm - https://bugs.freedesktop.org/show_bug.cgi?id=46412 How to obtain PA's typical 44100 rate? Feel free to contribute if you know apps outside Wine with similar issues. Surprisingly, users have reported improvements in the latest wine-1.4rcX even when nothing changed, but also mentioned updates on the PA and alsa_plugins side. Perhaps that improved the situation. I was pleased to see Wine's testsuite help find bugs in Pulse: http://lists.freedesktop.org/archives/pulseaudio-discuss/2012-February/0128… There are issues not always associated with a bug entry: - #29472 comment #12 DSound GetDevicePosition is not how it should be - Check OSS4 with and without vmix #28056 #28790 - winmm handling huge latency (such as PA's) & when to send notifications - Issues with microphone capture? - DSound mixing and buffer sizes & padding vs. GetPosition - Deal with intermittent errors from ALSA etc. in mmdevapi, winmm and dsound - Device enumeration and PA preventing access to the underlying device Is this known to cause no sound in an app (or only in our wave tests?) - various missing trailing sound with DSound #21209 - #29369 strange issue involving PA and perhaps messaging - misc. losing sound: #28319 #25164 #28770 - lead-out needed with dmix - Use lock-less design to reduce contention, cf. #29531, comment #7 - multi-channel, 5:1 etc. in mmdevapi and DSound - Bugs in the quartz or winegstreamer area that I don't have on my radar Of course there are more bugs than this. Regards, Jörg Höhle

6 11

Re: gdiplus: Create a GDI brush only when needed.
by Vincent Povirk 29 Feb '12

29 Feb '12

This won't work. We create gdi32 brushes for hatch brushes based on temporary bitmaps that won't exist at the time brush_fill_path is called. On Wed, Feb 15, 2012 at 2:44 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > This patch fixes the problem reported in the bug 29894. > --- > dlls/gdiplus/brush.c | 19 ------------------- > dlls/gdiplus/gdiplus_private.h | 1 - > dlls/gdiplus/graphics.c | 13 ++++++++++++- > 3 files changed, 12 insertions(+), 21 deletions(-) > > diff --git a/dlls/gdiplus/brush.c b/dlls/gdiplus/brush.c > index d1af903..e0c400e 100644 > --- a/dlls/gdiplus/brush.c > +++ b/dlls/gdiplus/brush.c > @@ -55,7 +55,6 @@ GpStatus WINGDIPAPI GdipCloneBrush(GpBrush *brush, GpBrush **clone) > > memcpy(*clone, brush, sizeof(GpSolidFill)); > > - (*clone)->gdibrush = CreateBrushIndirect(&(*clone)->lb); > fill->bmp = ARGB2BMP(fill->color); > break; > } > @@ -123,8 +122,6 @@ GpStatus WINGDIPAPI GdipCloneBrush(GpBrush *brush, GpBrush **clone) > > memcpy(dest, src, sizeof(GpLineGradient)); > > - dest->brush.gdibrush = CreateSolidBrush(dest->brush.lb.lbColor); > - > count = dest->blendcount; > dest->blendfac = GdipAlloc(count * sizeof(REAL)); > dest->blendpos = GdipAlloc(count * sizeof(REAL)); > @@ -142,7 +139,6 @@ GpStatus WINGDIPAPI GdipCloneBrush(GpBrush *brush, GpBrush **clone) > GdipFree(dest->blendpos); > GdipFree(dest->pblendcolor); > GdipFree(dest->pblendpos); > - DeleteObject(dest->brush.gdibrush); > GdipFree(dest); > return OutOfMemory; > } > @@ -295,7 +291,6 @@ GpStatus WINGDIPAPI GdipCreateHatchBrush(HatchStyle hatchstyle, ARGB forecol, AR > (*brush)->brush.lb.lbStyle = BS_PATTERN; > (*brush)->brush.lb.lbColor = 0; > (*brush)->brush.lb.lbHatch = (ULONG_PTR)hbmp; > - (*brush)->brush.gdibrush = CreateBrushIndirect(&(*brush)->brush.lb); > > DeleteObject(hbmp); > } > @@ -307,7 +302,6 @@ GpStatus WINGDIPAPI GdipCreateHatchBrush(HatchStyle hatchstyle, ARGB forecol, AR > (*brush)->brush.lb.lbStyle = BS_SOLID; > (*brush)->brush.lb.lbColor = fgcol; > (*brush)->brush.lb.lbHatch = 0; > - (*brush)->brush.gdibrush = CreateBrushIndirect(&(*brush)->brush.lb); > } > > if (stat == Ok) > @@ -351,7 +345,6 @@ GpStatus WINGDIPAPI GdipCreateLineBrush(GDIPCONST GpPointF* startpoint, > (*line)->brush.lb.lbStyle = BS_SOLID; > (*line)->brush.lb.lbColor = col; > (*line)->brush.lb.lbHatch = 0; > - (*line)->brush.gdibrush = CreateSolidBrush(col); > (*line)->brush.bt = BrushTypeLinearGradient; > > (*line)->startpoint.X = startpoint->X; > @@ -387,7 +380,6 @@ GpStatus WINGDIPAPI GdipCreateLineBrush(GDIPCONST GpPointF* startpoint, > { > GdipFree((*line)->blendfac); > GdipFree((*line)->blendpos); > - DeleteObject((*line)->brush.gdibrush); > GdipFree(*line); > *line = NULL; > return OutOfMemory; > @@ -624,7 +616,6 @@ GpStatus WINGDIPAPI GdipCreatePathGradient(GDIPCONST GpPointF* points, > (*grad)->brush.lb.lbColor = col; > (*grad)->brush.lb.lbHatch = 0; > > - (*grad)->brush.gdibrush = CreateSolidBrush(col); > (*grad)->brush.bt = BrushTypePathGradient; > (*grad)->centercolor = 0xffffffff; > (*grad)->wrap = wrap; > @@ -719,7 +710,6 @@ GpStatus WINGDIPAPI GdipCreatePathGradientFromPath(GDIPCONST GpPath* path, > (*grad)->brush.lb.lbColor = col; > (*grad)->brush.lb.lbHatch = 0; > > - (*grad)->brush.gdibrush = CreateSolidBrush(col); > (*grad)->brush.bt = BrushTypePathGradient; > (*grad)->centercolor = 0xffffffff; > (*grad)->wrap = WrapModeClamp; > @@ -753,7 +743,6 @@ GpStatus WINGDIPAPI GdipCreateSolidFill(ARGB color, GpSolidFill **sf) > (*sf)->brush.lb.lbColor = col; > (*sf)->brush.lb.lbHatch = 0; > > - (*sf)->brush.gdibrush = CreateSolidBrush(col); > (*sf)->brush.bt = BrushTypeSolidColor; > (*sf)->color = color; > (*sf)->bmp = ARGB2BMP(color); > @@ -898,7 +887,6 @@ GpStatus WINGDIPAPI GdipCreateTextureIA(GpImage *image, > (*texture)->brush.lb.lbColor = 0; > (*texture)->brush.lb.lbHatch = (ULONG_PTR)hbm; > > - (*texture)->brush.gdibrush = CreateBrushIndirect(&(*texture)->brush.lb); > (*texture)->brush.bt = BrushTypeTextureFill; > (*texture)->image = new_image; > > @@ -1036,7 +1024,6 @@ GpStatus WINGDIPAPI GdipDeleteBrush(GpBrush *brush) > break; > } > > - DeleteObject(brush->gdibrush); > GdipFree(brush); > > return Ok; > @@ -1578,9 +1565,6 @@ GpStatus WINGDIPAPI GdipSetPathGradientCenterColor(GpPathGradient *grad, > grad->centercolor = argb; > grad->brush.lb.lbColor = ARGB2COLORREF(argb); > > - DeleteObject(grad->brush.gdibrush); > - grad->brush.gdibrush = CreateSolidBrush(grad->brush.lb.lbColor); > - > return Ok; > } > > @@ -1775,9 +1759,6 @@ GpStatus WINGDIPAPI GdipSetSolidFillColor(GpSolidFill *sf, ARGB argb) > sf->color = argb; > sf->brush.lb.lbColor = ARGB2COLORREF(argb); > > - DeleteObject(sf->brush.gdibrush); > - sf->brush.gdibrush = CreateSolidBrush(sf->brush.lb.lbColor); > - > return Ok; > } > > diff --git a/dlls/gdiplus/gdiplus_private.h b/dlls/gdiplus/gdiplus_private.h > index 9afe15b..b597511 100644 > --- a/dlls/gdiplus/gdiplus_private.h > +++ b/dlls/gdiplus/gdiplus_private.h > @@ -170,7 +170,6 @@ struct GpGraphics{ > }; > > struct GpBrush{ > - HBRUSH gdibrush; > GpBrushType bt; > LOGBRUSH lb; > }; > diff --git a/dlls/gdiplus/graphics.c b/dlls/gdiplus/graphics.c > index 65a3815..35aa504 100644 > --- a/dlls/gdiplus/graphics.c > +++ b/dlls/gdiplus/graphics.c > @@ -723,10 +723,21 @@ static void brush_fill_path(GpGraphics *graphics, GpBrush* brush) > /* else fall through */ > } > default: > - SelectObject(graphics->hdc, brush->gdibrush); > + { > + HBRUSH gdibrush, old_brush; > + > + if (brush->lb.lbStyle == BS_SOLID) > + gdibrush = CreateSolidBrush(brush->lb.lbColor); > + else > + gdibrush = CreateBrushIndirect(&brush->lb); > + > + old_brush = SelectObject(graphics->hdc, gdibrush); > FillPath(graphics->hdc); > + SelectObject(graphics->hdc, old_brush); > + DeleteObject(gdibrush); > break; > } > + } > } > > static INT brush_can_fill_pixels(GpBrush *brush) > -- > 1.7.8.4 > > >

2 3

Re: [PATCH] wined3d: Do not use double-buffered dynamic buffers (try 2)
by Henri Verbeet 29 Feb '12

29 Feb '12

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.

2 2

Re: [PATCH] winepulse: Add pulse driver, v8
by Chris Robinson 29 Feb '12

29 Feb '12

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?

3 2

RFT: Use Greek semicolons for comdlg32's printer status enumeration?
by Francois Gouget 29 Feb '12

29 Feb '12

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.

2 3

Remove an obsolete string chunk fom the Swedish translation?
by Francois Gouget 29 Feb '12

29 Feb '12

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.

1 0

Re: doc: Update Italian README
by Frédéric Delanoy 29 Feb '12

29 Feb '12

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

2 1

Re: [PATCH] winepulse: Add pulse driver, v8
by Dmitry Timoshkov 28 Feb '12

28 Feb '12

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.

2 1

Re: [PATCH 1/4] ddraw: Make D3DVBCAPS_WRITEONLY vertex buffers dynamic
by Henri Verbeet 28 Feb '12

28 Feb '12

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.

2 3

Re: [PATCH 2/4] wined3d: Do not use double-buffered dynamic buffers
by Henri Verbeet 28 Feb '12

28 Feb '12

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.

2 3

Re: A small cs.po file update
by Francois Gouget 28 Feb '12

28 Feb '12

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.

1 0

Re: po: zh_TW translation updates
by Francois Gouget 28 Feb '12

28 Feb '12

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 "";

2 2

Translators wanted!
by Francois Gouget 28 Feb '12

28 Feb '12

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 Here's the proposed news message for the website: > Translators wanted! > > Wine is looking for translators for the 1.4 release! > > Wine's translation <a href="http://fgouget.free.fr/wine-po/">status > page</a> shows only 12 complete translations. We'd like to do better > for 1.4. > > Luckily, starting with 1.4 Wine uses PO files, thus making > translations easier than ever before. So check out how to <a > href="http://wiki.winehq.org/Translating">get started</a> and help us > make Wine usable in your country. And here is the proposed wine-users message: > Wine 1.4 is making good progress. Unfortunately we still have a lot of > translations that are quite incomplete and have no active translators, > thus making Wine unusable in many countries. You track progress on > this page: > > http://fgouget.free.fr/wine-po/ > > As you can see we currently have 12 pretty complete translations and 5 > others that are advanced too. But that still leaves 25 languages > without much, not counting those that are not in the list. This page > also lists some suspected issues that would make easy targets for a > translator short on time. > > The good news is that Wine now uses standard PO files for localization > which makes translation easier than ever before. You even get to > choose between working straight on Wine's source or just editing the > one PO file for your language. So check out the instructions below and > make Wine usable for users in your country! > > http://wiki.winehq.org/Translating Of course if you can help translating Wine, you can also consider this your call to action<g>. -- 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...

12 29

Re: po: zh_TW translation updates
by Franklin Weng 28 Feb '12

28 Feb '12

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. > > > >

1 0

Re: msvcrt/file.c: file mode T (temporary file) (try 3)
by Frédéric Delanoy 28 Feb '12

28 Feb '12

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

1 0

Re: Testbot and changes to multiple tests
by Joerg-Cyril.Hoehle＠t-systems.com 27 Feb '12

27 Feb '12

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

1 0

Re: po: zh_TW translation updates
by Francois Gouget 27 Feb '12

27 Feb '12

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

4 5

Re: msvcrt/file.c: file mode T (temporary file) (try 3)
by Marvin 27 Feb '12

27 Feb '12

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.

1 0

Re: ntdll: Fix the file mapping view leak in the case of module loading failure. Take 2.
by Alexandre Julliard 27 Feb '12

27 Feb '12

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

2 2

Re: dsound: Small fixes to IDirectSoundCaptureBuffer
by Andrew Eikum 27 Feb '12

27 Feb '12

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 > > > > >

1 0

Re: ntdll: Fix the file mapping view leak in the case of module loading failure.
by Alexandre Julliard 27 Feb '12

27 Feb '12

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

1 0

Testbot and changes to multiple tests
by Stefan Dösinger 27 Feb '12

27 Feb '12

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

1 0

Re: [PATCH 2/2] ddraw/tests: Add pitch alignment tests (try 2)
by Stefan Dösinger 27 Feb '12

27 Feb '12

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(); > }

1 0

Re: [PATCH 2/2] ddraw/tests: Add pitch alignment tests (try 2)
by Marvin 27 Feb '12

27 Feb '12

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.

1 0

Re: [PATCH] po: Update Swedish translation. (try 2)
by Lauri Kenttä 27 Feb '12

27 Feb '12

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

1 0

Fw: Re: po: zh_TW translation updates
by Hin-Tak Leung 27 Feb '12

27 Feb '12

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. > > > > >

1 0

Re: po: fixed remaining Slovenian true positives in the winepo error report
by Jaka Kranjc 27 Feb '12

27 Feb '12

On Wednesday 22 of February 2012 18:16:20 Francois Gouget wrote: > On Wed, 22 Feb 2012, Jaka Kranjc wrote: > [...] > > > > You mean that all the 'not translated' strings are actually translated > > > and just happen to be the same as in English, right? I can add them. > > > > Exactly. > > Done. Great. I also swapped wine-patches with wine-devel to keep the noise down. > So in English you'd end up with something like this: > > Error; Paper jam; > or > Initialising; Default Printer; I/O Active; > > > So what you're saying is that: > * There is no systematic conversion of semicolons to commas in > Slovenian. > * In Slovenian the strings above should definitely use a comma > because it's used as a list separator. > * The English string should maybe use a comma too? This may require > some supporting arguments... 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). > > So no, in general we do not substitute semicolons, but it depends on the > > original msgid context. Most translators are serious grammar nazis, so > > they/we tend to ignore mistakes in the original string. > > Don't! > > At least for Wine any issue in the English string should be fixed or > reported so it can be fixed as early as possible (preferably before it > has been translated into 20 other languages). Of course I'm saying that > but being in string freeze we would not be able to fix strings right > now. But if I saw such reports on wine-devel I'd make sure they are > acted upon after the release. Oh, I know, didn't mean to suggest inaction. But in a lot of cases, it comes down to preference, style or language perception. Plus the fact that inspecting the original's validity almost always requires the ability to read code, which most translators lack and which is hard to access if they work via online translation tools. Re usage strings: is there no 80 column limit imposed? I saw even some original strings were longer. LP -- To err is humor

2 3

Re: [PATCH] po: Update Swedish translation.
by Jan-Peter Nilsson 27 Feb '12

27 Feb '12

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

4 4

Wrong charcter encoding in winmm-tests
by Julian Rüger 27 Feb '12

27 Feb '12

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

2 5

Re: [PATCH 2/2] ddraw/tests: Add pitch alignment tests
by Marvin 26 Feb '12

26 Feb '12

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

1 0

Re: shlwapi: Implemented StrToInt64ExA/W
by Jacek Caban 26 Feb '12

26 Feb '12

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

1 0

Re: msvcrt/file.c: file mode T (temporary file) (try 2)
by Vitaliy Margolen 26 Feb '12

26 Feb '12

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.

2 1

Spaces in the Korean translation.
by Francois Gouget 26 Feb '12

26 Feb '12

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.

1 0

Re: sk.po
by Francois Gouget 26 Feb '12

26 Feb '12

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

1 0

Re: shlwapi: Implemented StrToInt64ExA/W
by Marvin 26 Feb '12

26 Feb '12

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

1 0

Re: shlwapi: Implemented StrToInt64ExA/W
by Nikolay Sivov 25 Feb '12

25 Feb '12

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.

1 0

Re: msvcrt/file.c: file mode T (temporary file)
by Nikolay Sivov 25 Feb '12

25 Feb '12

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.

1 0

Re: msvcrt/file.c: file mode T (temporary file)
by Marvin 25 Feb '12

25 Feb '12

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=17097 Your paranoid android. === WNT4WSSP6 (32 bit filemodeT) === filemodeT: unhandled exception c0000005 at 780109BF === WXPPROSP3 (32 bit filemodeT) === filemodeT: unhandled exception c0000005 at 77C41165

1 0

Re: po: Update Chinese (Taiwan) translation.
by Francois Gouget 24 Feb '12

24 Feb '12

Thanks for the translation update. It's a big one. There are pretty few issues given the size: msgid "&Modify..." -msgstr "" +msgstr "�޸�(&M)" The translation is missing the ellipsis here. msgid "" "This value does not lie within the page range.\n" "Please enter a value between %1!d! and %2!d!." msgstr "" -"�@��ֵ��퓔��\n" -"Ոݔ��һ�� %d �� %d ֮�g�Ĕ��" +"ݔ��ֵ��퓔��ȡ�\n" +"Ոݔ��һ�� %d �� %d ֮�g��ֵ��" The formatting directives should match. There's been quite a few changes of that type that had the goal of making it possible to reorder them so there may be other places with the same issue. #, fuzzy msgid "Write fault.\n" -msgstr "Ĭ�J��\n" +msgstr "�A�O��\n" #, fuzzy msgid "Read fault.\n" -msgstr "Ĭ�J��\n" +msgstr "�A�O��\n" ... Is it normal that you did not remove the fuzzy on this series of messages? (Maybe they need further review?) -#, fuzzy msgid "By &Type" msgstr "��" #: shell32.rc:52 -#, fuzzy msgid "By &Size" msgstr "��С" Should preserve the keyboard shortcut? -#, fuzzy msgid "LoadTypeLib( %1 ) failed ($%2!x!)" msgstr "LoadTypeLib( %s ) ʧ�� ($%x)" The format directives also need an update on this one. msgid "&New override for library:" -msgstr "��ʽ��(&N)��" +msgstr "��ʽ�츲�d(&N):" msgid "Existing &overrides:" -msgstr "��еĺ�ʽ��(&o)��" +msgstr "��еĺ�ʽ�츲�d(&O)��" I see that you replaced some full width colons with their half-width equivalent but not everywhere. What is the common practice there? As far as I know for full stops it's the full-width character that is used. However for characters like colons, question marks and exclamation points I don't know (looking at Windows 7 dialogs did not help there). msgid "Full &Path:" -msgstr "" +msgstr "��·��(P):" This one is missing the ampersand. That's the only such case as far as I can tell. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Dieu dit: "M-x Lumi��re". Et la lumi��re fut.

2 1

Removing 'all' platform/os from bugzilla
by Austin English 23 Feb '12

23 Feb '12

Howdy, We seem to discourage use of the use of 'all' platform/os on bugzilla. While I personally am not opposed to it, in cases where it's obviously true (e.g., http://bugs.winehq.org/show_bug.cgi?id=29901), changing these fields causes unnecessary spam. It would be easier, imho to remove them. Does anyone have any opposition to this? I'm intending to leave 'other', of course. -- -Austin

2 2

Obscure texts and invalid translations
by Lauri Kenttä 23 Feb '12

23 Feb '12

Hi, Wine has many texts, especially error messages, that are almost impossible to translate without knowing what they're really about. Some are also easy to misunderstand. An example from dlls/kernel32/winerror.mc: msgid "Notify change request in progress.\n" Some interpretations: de, nb: "A request for notifications about changes is in progress." fr, sv: "A request to change a notification is in progress." it, pt: Both have their own versions, I think. There are many more such cases, although the difference is usually in only one or two languages. (Unfortunately it didn't occur to me to put them down from the beginning, so I can't give you a list. I'll just mention "Challenge Password" before I forget that, too.) 1) What should I do if I wanted to clarify a msgid? Just change the original .rc file? 2) Is there a way to add helpful comments to all language files at once without changing the msgid? 3) What should I do if I spot a suspicious translation? Spam the Bugzilla, contact the Last-Translator personally, or send patches to add #fuzzy comments and hope I'm right? And if it's wrong in many of the languages I can read, it's probably wrong in some others as well; who would check them all? 4) There has been discussions about some translation websites. Is there a chance that such a website would allow easy tagging of potential errors? -- Lauri Kenttä

3 5

Re: Alexandre Julliard : gdi32: Avoid overflows for invalid coordinates in line clipping.
by Charles Davis 22 Feb '12

22 Feb '12

On Feb 22, 2012, at 1:27 PM, Alexandre Julliard wrote: > --- a/dlls/gdi32/dibdrv/objects.c > +++ b/dlls/gdi32/dibdrv/objects.c > @@ -372,7 +372,8 @@ static inline DWORD calc_outcode(const POINT *pt, const RECT *clip) > int clip_line(const POINT *start, const POINT *end, const RECT *clip, > const bres_params *params, POINT *pt1, POINT *pt2) > { > - int m, n; > + > + INT64 m, n; /* 64-bit to avoid overflows (FIXME: find a more efficient way) */ What about MulDiv()? As I recall, this is the sort of situation for which it was designed. Or is that not efficient? Chip

2 1

Re: po: Spanish translation update for appwiz.rc and comdlg32.rc
by Francois Gouget 22 Feb '12

22 Feb '12

On Wed, 22 Feb 2012, Eduardo Garcia wrote: > This is the first patch of a series of patches aiming to update and complete > the Spanish interface in current Wine. This patch covers appwiz.rc and > comdlg32.rc. Cool. Thanks! I noticed some issues though: msgid "Publisher:" -msgstr "Editor:" +msgstr "Fabricante" You should not remove the colon here. msgctxt "Saturation" msgid "&Sat:" -msgstr "&Sat.:" +msgstr "&Saturaci??n:" msgctxt "Luminance" msgid "&Lum:" -msgstr "&Lum.:" +msgstr "&Luminancia:" These two are likely to be too long, hence why it's truncated. -#, fuzzy msgid "Files of type:" -msgstr "Archivos de &tipo:" +msgstr "&Tipo de archivo:" Apparently that one is not meant to have a key shortcut. -- 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.

1 0

Re: po: fixed remaining Slovenian true positives in the winepo error report
by Francois Gouget 22 Feb '12

22 Feb '12

On Wed, 22 Feb 2012, Jaka Kranjc wrote: [...] > > Also in my previous email I forgot to mention that the /Unix line is > > missing from both start.exe usage strings, not just the one I mentionned > > before. Hopefully you will have noticed that already. > Too bad, I missed it. The two usage strings are identical though, so why not > split the formalities away after the strings are thawed? Translators that > don't use tools with translation memory will just have more work this way. That's what should happen eventually. In fact start's messages need a thorough rework because it's a pain to work with right now. Also there's probably improvements to be made for all command line tools with regards to line wrapping. But it's going to take some work and that will all have to wait after the 1.4 release as we are in a string freeze right now. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, it's computer science.

2 1

winealsa.drv patch to enum all software devices from .asoundrc
by Joerg-Cyril.Hoehle＠t-systems.com 22 Feb '12

22 Feb '12

Hi, There's no $HOME/.asoundrc on any of my systems, yet I'd like to use "plug:dmix" with Wine, e.g. on systems with PulseAudio installed. I can use speaker-test -Dplug:dmix with no trouble. Will your patch make that appear in the list? Нискородов Серёжа wrote: >To check whether the device is a hardware, I can call a function >snd_pcm_type. But first I need to get handle of pcm device using the >snd_pcm_open. Okay, but then I have to cancel calling the function >alsa_try_open and rewrite checking availability of the device to not >to opening it twice. Avoiding snd_pcm_open is important. Right now, we already have tests that fail randomly because unfriendly devices like PulseAudio cling to the underlying resource ("hw:0") for a couple of seconds, preventing Wine from inspecting it (bug #28048), causing Wine IIRC to eliminate "hw:0" from the list of available devices. :-( That is not satisfying at all. Perhaps one easy shoot at it would be to access "default" last? That's still much like crossing fingers. Thank you, Jörg Höhle

5 27

Re: [PATCH] README: updated Linux and FreeBSD kernels
by Francois Gouget 22 Feb '12

22 Feb '12

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_… -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

2 1

Re: gdi32: pOS2->xAvgCharWidth can be negative however tmAvgCharWidth needs a positive value
by Dmitry Timoshkov 21 Feb '12

21 Feb '12

Aric Stewart <aric(a)codeweavers.com> wrote: > - TM.tmAveCharWidth = (pFT_MulFix(pOS2->xAvgCharWidth, x_scale) + 32) >> 6; > + TM.tmAveCharWidth = (pFT_MulFix(abs(pOS2->xAvgCharWidth), x_scale) + 32) >> 6; Did you test what Windows does in that case? -- Dmitry.

2 8

Re: kernel32/tests: DeviceIoControl: verify IOCTL_DVD_READ_STRUCTURE outputs same buffer as IOCTL_SCSI_PASS_THROUGH_DIRECT f
by Marvin 21 Feb '12

21 Feb '12

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=17047 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: kernel32/tests: DeviceIoControl.IOCTL_DVD_READ_STRUCTURE.DvdPhysicalDescriptor: check output buffer byte order (try 6)
by Marvin 21 Feb '12

21 Feb '12

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=17046 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

[PATCH] mmdevapi: Fix exclusive test.
by Joerg-Cyril.Hoehle＠t-systems.com 21 Feb '12

21 Feb '12

Maarten, what does the patch fix? I did leave nChannels equal to what GetMixFormat returns based on the following reasoning: - It'll probably suggest a mono format on an old machine that handles mono only, so leave as is. - It may suggest 6 channels on a 5:1 card (we had a few such reports on test.winehq.org), so presumably, exclusive mode on such machines would accept 6 channels too, so keep it. Why do you force 2 channels? There's one fix that I envision: the old WAVE_FORMAT_PCM should only be used with mono or stereo, says MSDN. I used it to avoid having to deal with a channel mask. So for 5:1, it would be preferable to keep WAVE_FORMAT_EXTENSIBLE and simply switch pwfx to linear 16bit PCM instead of FLOAT. IIRC, MSDN advises to try out exclusive mode with both WAVE_FORMAT_PCM and FORMAT_EX, arguing that some devices recognize one but not the other format... (what a mess!) Thank you, Jörg Höhle

1 0

Re: [2/2] winefile: Get rid of _wsplitpath duplication
by Alexandre Julliard 21 Feb '12

21 Feb '12

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -1,10 +1,9 @@ > EXTRADEFS = -D__WINE__ > MODULE = winefile.exe > -APPMODE = -mwindows -municode > +APPMODE = -mwindows -municode -mno-cygwin You can't do that, winefile wants Unix filesystem calls. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/3] Minimal fix for IOCTL_DVD_READ_STRUCTURE output format
by Dan Kegel 20 Feb '12

20 Feb '12

On Fri, Feb 17, 2012 at 12:32 AM, Dan Kegel <dank(a)kegel.com> wrote: > This is a minimal patch that should fix Dragon Age disc detection, > http://bugs.winehq.org/show_bug.cgi?id=29669 > > The remaining problems can be dealt with after release. > > Test passes on Linux and Windows with the Dragon Age disc in the drive. This is missing a level of indirection on mac. I'll send a corrected patch.

1 0

Re: kernel32: CreateMemoryResourceNotification stub should return a waitable handle
by Dan Kegel 20 Feb '12

20 Feb '12

On Mon, Feb 20, 2012 at 6:38 AM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: >>>>> + return CreateEventA(NULL, FALSE, FALSE, "Fake >>>>> MemoryResourceNotification"); >>>> >>>> I don't think you want a named event here. Anonymous would be better, in >>>> case the program will ask for another event. >>> >>> Oh, right. Anonymous it is, then. >> >> Hang on - those events will never fire, so what does it matter if >> the same event gets two handles? > > My bad. Was just trying to make sure it won't conflict with anything. > > Re-read description of this function on MSDN which indicates it's a system > wide event. So you should be good with the named event. Good, the patch stands then. - Dan

1 0

know more about Win API's
by prateek papriwal 20 Feb '12

20 Feb '12

hello, can anyone suggest me how to get knowledge of windows API's and Wine Internals. I am reading the documentation provided on the site but i am finding it hard to grasp the things .. if u can suggest me some good readings or moreover a structured way of reading things it would be helpful for me ...

3 2

Re: windowscodecs: Make MetadataReader_Create() static.
by Vincent Povirk 20 Feb '12

20 Feb '12

This function will be used from other files in the future. On Sun, Feb 19, 2012 at 4:32 PM, Francois Gouget <fgouget(a)free.fr> wrote: > --- > dlls/windowscodecs/metadatahandler.c | 2 +- > dlls/windowscodecs/wincodecs_private.h | 1 - > 2 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/dlls/windowscodecs/metadatahandler.c b/dlls/windowscodecs/metadatahandler.c > index afcff21..53aa22a 100644 > --- a/dlls/windowscodecs/metadatahandler.c > +++ b/dlls/windowscodecs/metadatahandler.c > @@ -317,7 +317,7 @@ static const IWICPersistStreamVtbl MetadataHandler_PersistStream_Vtbl = { > MetadataHandler_SaveEx > }; > > -HRESULT MetadataReader_Create(const MetadataHandlerVtbl *vtable, IUnknown *pUnkOuter, REFIID iid, void** ppv) > +static HRESULT MetadataReader_Create(const MetadataHandlerVtbl *vtable, IUnknown *pUnkOuter, REFIID iid, void** ppv) > { > MetadataHandler *This; > HRESULT hr; > diff --git a/dlls/windowscodecs/wincodecs_private.h b/dlls/windowscodecs/wincodecs_private.h > index 691b1ec..9cbeaa1 100644 > --- a/dlls/windowscodecs/wincodecs_private.h > +++ b/dlls/windowscodecs/wincodecs_private.h > @@ -83,7 +83,6 @@ typedef struct _MetadataHandlerVtbl > ULARGE_INTEGER *size); > } MetadataHandlerVtbl; > > -extern HRESULT MetadataReader_Create(const MetadataHandlerVtbl *vtable, IUnknown *pUnkOuter, REFIID iid, void** ppv) DECLSPEC_HIDDEN; > > extern HRESULT UnknownMetadataReader_CreateInstance(IUnknown *pUnkOuter, REFIID iid, void** ppv) DECLSPEC_HIDDEN; > > -- > 1.7.9 > > >

1 0

Re: kernel32: CreateMemoryResourceNotification stub should return a waitable handle
by Vitaliy Margolen 19 Feb '12

19 Feb '12

On 02/19/2012 09:26 AM, Dan Kegel wrote: > Otherwise jqs spins. > Fixes http://bugs.winehq.org/show_bug.cgi?id=29936 > > + return CreateEventA(NULL, FALSE, FALSE, "Fake MemoryResourceNotification"); I don't think you want a named event here. Anonymous would be better, in case the program will ask for another event. Vitaliy.

2 1

Re: [user32] quiet two noisy fixmes
by Dan Kegel 19 Feb '12

19 Feb '12

On Sun, Feb 19, 2012 at 1:47 AM, Dan Kegel <dank(a)kegel.com> wrote: > Since Java 6 SE 10, Java installs a "Java Quick Start" service which calls > these two functions multiple times per second. Please ignore this patch. Even with the messages suppressed, JQS burns CPU. The console spew is a useful reminder of http://bugs.winehq.org/show_bug.cgi?id=29936

1 0

Re: [1/3] comdlg32: Adjust the size of CHOOSE_COLOR dialog.
by Dmitry Timoshkov 19 Feb '12

19 Feb '12

Gustavo Henrique Milaré <gugamilare(a)gmail.com> wrote: > Adjusting size for the translation to fit. You can't do that, read the comment in that file slightly before all common dialog templates. -- Dmitry.

4 11

Re: [PATCH] quartz: fixed sizeof()s to IsBadReadPtr (Coverity)
by Marvin 18 Feb '12

18 Feb '12

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=17015 Your paranoid android. === WNT4WSSP6 (32 bit filtermapper) === filtermapper.c:96: Test failed: CoCreateInstance failed with 80040154 filtermapper.c:233: Test failed: CoCreateInstance failed with 80040154 filtermapper.c:347: Test failed: CoCreateInstance failed with 80040154 filtermapper.c:405: Test failed: CoCreateInstance failed with 80040154

1 0

kernel32/tests: initial tests for cdrom.c
by Joerg-Cyril.Hoehle＠t-systems.com 18 Feb '12

18 Feb '12

Dan Kegel wrote: >These require a DVD in the drive, so they are skipped without >WINETEST_INTERACTIVE=1. I don't see the causality. Presumably the tests require no human intervention. winmm/tests/mcicda also skips tests if no CD-ROM is in the bay. However, even a regular winetest.exe run *will* run as many tests as it can should it find a CD-ROM. Users are invited to submit test results to test.winehq with audio and/or mixed data CD-ROMs in the drive. There's no need for winetest_interactive here. Regards, Jörg Höhle

3 3

Re: OpenGL child windows (SketchUp)
by Roderick Colenbrander 17 Feb '12

17 Feb '12

Re-adding wine-devel. On Wed, Feb 8, 2012 at 2:42 PM, Brian Bloniarz <brian.bloniarz(a)gmail.com> wrote: > On Wed, Feb 8, 2012 at 12:33 PM, Roderick Colenbrander > <thunderbird2k(a)gmail.com> wrote: >> >> On Wed, Feb 8, 2012 at 6:31 PM, Matteo Bruni <matteo.mystral(a)gmail.com> >> wrote: >> > I'm not really such an expert in the area, but I think both (1) and >> > (2) make sense. I'm not sure in (1) case about the glXWaitGL call, as >> > technically glXSwapBuffers is not a GL call, but given that it works >> > for you (while XSync doesn't) on Nvidia, I guess it's fine... Make >> > sure it works correctly on all the drivers you mentioned, or even that >> > e.g. it doesn't cause excessive slowdowns. >> > >> > > > ... >> >> glXWaitGL and friends were intended for syncing GLX and X, so this may >> >> be the most reliable way. As you pointed out there may be bugs in DRI, >> but this needs a careful read of the specs (will try to look at it). >> As you said the damage extension can be used as well, but I think I >> would lean to using the classic glX/X synchronization features first. > > > Thanks for looking, both of you! > > I'm looking at the GLX1.3 spec at: > http://www.lri.fr/~mbl/ENS/IG2/docs/glx1.3.pdf > > "Sequentiality" has: > "glXSwapBuffers is in the OpenGL stream if and only if > the display and drawable are those belonging to the calling thread's > current context; otherwise it is in the X stream." > > That would put our glXSwapBuffers in the OpenGL stream, > and hence something that should be serialized by a call > to glXWaitGL(). I wouldn't test it in court though :) > > Whatever the approach, I'd be happy to test and/or benchmark > on the 4 renderers I have access to. > > Thanks, > -Brian A patch like this is what should do the job. I'm not sure what the penalty will be. Remember glXSwapBuffers already performs a glFlush, so a glXWaitGL on top of that may not be too bad. I can't quickly think of a good test application. You would like a game or some benchmark, but I can't think of anything stressful now which uses a child window (an application which has a menu bar, doesn't use a child window). Google Earth always was a good test. We need to figure out if the DRI drivers are indeed buggy. I will see if I have time to look at it, but my time is very limited these days :( Roderick

2 2

"Known" DLLs
by Adam Kłobukowski 17 Feb '12

17 Feb '12

Hello I've been a Wine user for a long time alreadey, since all Wine could do was running winesweper very slowly ;) I'd like to propose a feature that could be implemented in Wine. Wine does not implement all Windows APIs (yet ;)) and big parts of existing implementations are only stubs. Therefore, it could be usefull if Wine would be able to detect when a program tries to use a DLL that is not implememnted, but is easily available for download. .NET, MSXML, VCRUN* comes in mind. Instead of just failing, Wine could offer advice to the user how to deal with that. This could also help with APIs that are mostly stubbed, work for some use cases, but are expected to fail in other - they could detect if an app is trying to use unsuported case and take action. Adam Klobukowski

5 5

[PATCH 1/2] winmm: Avoid using SuspendThread, it can hang Wine.
by Joerg-Cyril.Hoehle＠t-systems.com 17 Feb '12

17 Feb '12

Hi, >this Fixes bug #28388 I think it is not a good idea to defer this patch until after 1.4.0. Every app using midiStreamOpen eventually calls SuspendThread which is simply a time bomb on a dual core machine. There are many more multi-core machines now, so the situation degrades. Dan Kegel wrote: >With WINEDEBUG=warn+heap, it happens a lot sooner (first run: first try; >second run: sixth try). As noted in the bug report, SuspendThread can hit Wine amid memory management, breaking havoc. Users won't know who to blame for random lock-ups and complain like I did that Wine isn't able to generate a backtrace. Patch 1/2 can be applied stand alone. It gets rid of SuspendThread. It's been a pleasure to use patch 2/2 and hear apps play midiStream music without trouble. I wouldn't mind if you defer that for 1.4.1. After all, this is a feature that has been lacking in Wine for the last 10 years, so people can wait a little more... Regards, Jörg Höhle

3 3

weirdly large filesize of winegcc generated shared object
by Pengyu CHEN 17 Feb '12

17 Feb '12

Hello everyone, I'm new here, and if I did/said something wrong, please point out instead of throwing stones at me :-) I'm currently developing stuffs with winelibs, and when building a shared lib with winegcc, I find the generated file is weirdly large. The example below illustrates my problem. // this is a.c __attribute__((cdecl)) void *test() { return 0; } // and this is a.spec @ cdecl test() Then I compiled them using 'winegcc a.c a.spec -shared -fPIC -m32', and then found the resulting file a.out.so is about 70KB in size: [pengyu@pengyu-Studio-1747 tmp]$ls a.out.so -l -rwxr-xr-x 1 pengyu users 75893 Feb 17 19:16 a.out.so By analyzing the file I found in a.out.so there is an extremely large section .init with size of nearly 70KB. That's weird since a normal .init section is quite small. Though I know wine would do its initialization here, but 70KB is still too large I think. And after disassembling and also viewing the file with hexadecimal viewer, I found nearly all contents of .init section of a.out.so is filled with zero bits. Is this a bug or feature? Since .init section is read/execute only, I didn't see any benefit from these filling zeros. Can anybody make some explanations please? And, is there any methods to remove these zeros in the generated shared object and get a smaller file? Regards, Pengyu -- * [A very large, very cold, and extremely isolated planet.] [ApertureScience][Grow Old or Die Trying] [ZJU/ComputerScience][Archer/Googler/kind of geek] [C/Python/Mathematica/CommonLisp/Assembly] [CpyPrefersYou/HjrJustifiablyReturns] [AboutMe <http://about.me/cpy>] *

2 4

Re: po: Add and fix a few Finnish translations.
by Lauri Kenttä 17 Feb '12

17 Feb '12

"Thai" is right, "Thain" is wrong. Please don't mess with Finnish if you don't know it. As I've said, I'm working on it. If you feel I'm too slow, feel free to hire me and I'll do it faster. ;) I'm currently away from my computer, but I'll send my patch this weekend. It will have almost everything except some of the more difficult winerror and crypt* texts. -- Lauri Kenttä

2 2

Re: [2/2] kernel32/tests: DeviceIoControl.IOCTL_DVD_READ_STRUCTURE.DvdPhysicalDescriptor: check output buffer byte order (try 4)
by Dan Kegel 17 Feb '12

17 Feb '12

On Wed, Feb 15, 2012 at 4:35 PM, Dan Kegel <dank(a)kegel.com> wrote: >> Change since last try: >> - moved back to kernel32 per AJ's remark on irc >> - runs even if dvd in 2nd... drive >> - simplified >> >> Passes on Wine/Linux, Wine/Mac (according to Charles), and Win7. > > Here's the same patch with the wayward utf-8 char removed from the > standards comment. Please ignore this patch. I simplified too far; it has a structure packing problem that only shows up in crosstest on windows. I sent an updated series to Charles for testing.

1 0

Re: [PATCH] server: Add sessions directory and 0 session symlink
by Vitaliy Margolen 17 Feb '12

17 Feb '12

On 02/16/2012 08:37 PM, Vitaliy Margolen wrote: > > Fixes bug 29905. > --- Please ignore this. Didn't read the last bug comment. Vitaliy.

1 0

Problems with translatable strings
by Gustavo Henrique Milaré 17 Feb '12

17 Feb '12

Hello, I've encountered some issues while translating Wine to Brazilian Portuguese. The first one is in string number 24 (line 150 in wine.pot) which is related to wine control. When you open "wine control" and select the icon "Add/remove programs", the status bar shows "Allows you to install new software, or remove existing software" while the string in wine.pot file reads "Allows you to install new software, or remove existing software from your computer." Is there any reason for limiting the number of visible characters in wine control's status bar? If there is, then it would be better to use a smaller string instead. There are also problems in strings number 119 (line 547) and number 494 (line 2075). The resource file doesn't allow enough space for the appropriate translations ("Vermelho:" and "Adicionar Propósito...", respectively). Gustavo Henrique Milaré

3 5

re: "Known" DLLs
by Dan Kegel 16 Feb '12

16 Feb '12

This has been discussed off and on over the years, e.g. http://www.winehq.org/pipermail/wine-devel/2009-September/078441.html http://www.winehq.org/pipermail/wine-devel/2010-September/086465.html http://www.winehq.org/pipermail/wine-devel/2010-September/086469.html There is a kind of notification system in place, the winediag debug channel. I think the intent of that was to make it possible for distros to show those messages to the user (maybe with a dialog), and hide all the other log messages. At the moment, the dll load failure message doesn't go to +winediag. Maybe it should (although there are probably times when it's safe to ignore them, so I'm not sure). Anyway, +winediag or not, one can imagine a wrapper outside wine that notices events like this and offers to assist the user in those few cases (mfc42? vb6run?) where there's a high likelihood of success. Here's a crude example: wine "$@" 2>&1 | tee foo.log if grep -i "Library MFC42.DLL" foo.log then zenity --warning --text "This app seems to need mfc42. Try running winetricks mfc42." fi It would take a bunch of work to get something worth deploying, but if you're interested, go for it...

1 0

Re: msxml3: Fix varargs handling in libxml2 error callback implementation
by Marcus Meissner 16 Feb '12

16 Feb '12

On Thu, Feb 16, 2012 at 01:55:44AM +0300, Nikolay Sivov wrote: > The problem is that vsnprintf() was called multiple times with same > va_list. Ti fix that it was necessary to get rid of some tracing > bits like macro-defined callback calls and a single function for all > kinds of error types. > > As far as I understand this problem it leads to a stack corruption > when va_list is used multiple time without va_start/va_end around > it, so it's critical to fix. If I remember correctly, you can even process a va_list only once on some platforms. If you need to process it multiple times, you need to create a copy with va_copy() first. Ciao, Marcus > From d75433c8ff34e125c7db1fb665bdb9271991b9f5 Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <nsivov(a)codeweavers.com> > Date: Thu, 16 Feb 2012 01:06:16 +0300 > Subject: [PATCH 1/1] Fix varargs handling in libxml2 error callback implementation > > --- > dlls/msxml3/domdoc.c | 50 +++++------------------- > dlls/msxml3/main.c | 49 +++++++++++++++++------- > dlls/msxml3/msxml_private.h | 18 ++------- > dlls/msxml3/schema.c | 90 ++++++++++++++----------------------------- > dlls/msxml3/selection.c | 4 +- > 5 files changed, 80 insertions(+), 131 deletions(-) > > diff --git a/dlls/msxml3/domdoc.c b/dlls/msxml3/domdoc.c > index 64122ce..9bcecdd 100644 > --- a/dlls/msxml3/domdoc.c > +++ b/dlls/msxml3/domdoc.c > @@ -425,23 +425,7 @@ static void sax_characters(void *ctx, const xmlChar *ch, int len) > xmlSAX2Characters(ctxt, ch, len); > } > > -static void LIBXML2_LOG_CALLBACK sax_error(void* ctx, char const* msg, ...) > -{ > - va_list ap; > - va_start(ap, msg); > - LIBXML2_CALLBACK_ERR(doparse, msg, ap); > - va_end(ap); > -} > - > -static void LIBXML2_LOG_CALLBACK sax_warning(void* ctx, char const* msg, ...) > -{ > - va_list ap; > - va_start(ap, msg); > - LIBXML2_CALLBACK_WARN(doparse, msg, ap); > - va_end(ap); > -} > - > -static void sax_serror(void* ctx, xmlErrorPtr err) > +static void libxml2_sax_structerror(void* ctx, xmlErrorPtr err) > { > LIBXML2_CALLBACK_SERROR(doparse, err); > } > @@ -472,9 +456,9 @@ static xmlDocPtr doparse(domdoc* This, char const* ptr, int len, xmlCharEncoding > sax_characters, /* ignorableWhitespace */ > xmlSAX2ProcessingInstruction, /* processingInstruction */ > xmlSAX2Comment, /* comment */ > - sax_warning, /* warning */ > - sax_error, /* error */ > - sax_error, /* fatalError */ > + libxml2_warn_callback, /* warning */ > + libxml2_error_callback, /* error */ > + libxml2_error_callback, /* fatalError */ > xmlSAX2GetParameterEntity, /* getParameterEntity */ > xmlSAX2CDataBlock, /* cdataBlock */ > xmlSAX2ExternalSubset, /* externalSubset */ > @@ -482,10 +466,12 @@ static xmlDocPtr doparse(domdoc* This, char const* ptr, int len, xmlCharEncoding > NULL, /* _private */ > xmlSAX2StartElementNs, /* startElementNs */ > xmlSAX2EndElementNs, /* endElementNs */ > - sax_serror /* serror */ > + libxml2_sax_structerror /* serror */ > }; > xmlInitParser(); > > + TRACE("(%p)->(%p %d %d)\n", This, ptr, len, encoding); > + > pctx = xmlCreateMemoryParserCtxt(ptr, len); > if (!pctx) > { > @@ -2634,22 +2620,6 @@ static inline BOOL is_wellformed(xmlDocPtr doc) > #endif > } > > -static void LIBXML2_LOG_CALLBACK validate_error(void* ctx, char const* msg, ...) > -{ > - va_list ap; > - va_start(ap, msg); > - LIBXML2_CALLBACK_ERR(domdoc_validateNode, msg, ap); > - va_end(ap); > -} > - > -static void LIBXML2_LOG_CALLBACK validate_warning(void* ctx, char const* msg, ...) > -{ > - va_list ap; > - va_start(ap, msg); > - LIBXML2_CALLBACK_WARN(domdoc_validateNode, msg, ap); > - va_end(ap); > -} > - > static HRESULT WINAPI domdoc_validateNode( > IXMLDOMDocument3* iface, > IXMLDOMNode* node, > @@ -2695,11 +2665,11 @@ static HRESULT WINAPI domdoc_validateNode( > if (get_doc(This)->intSubset || get_doc(This)->extSubset) > { > xmlValidCtxtPtr vctx = xmlNewValidCtxt(); > - vctx->error = validate_error; > - vctx->warning = validate_warning; > + vctx->error = libxml2_error_callback; > + vctx->warning = libxml2_warn_callback; > ++validated; > > - if (!((node == (IXMLDOMNode*)iface)? > + if (!((node == (IXMLDOMNode*)iface) ? > xmlValidateDocument(vctx, get_doc(This)) : > xmlValidateElement(vctx, get_doc(This), get_node_obj(node)->node))) > { > diff --git a/dlls/msxml3/main.c b/dlls/msxml3/main.c > index 464ef90..4f9b020 100644 > --- a/dlls/msxml3/main.c > +++ b/dlls/msxml3/main.c > @@ -60,28 +60,47 @@ HINSTANCE MSXML_hInstance = NULL; > > #ifdef HAVE_LIBXML2 > > -void wineXmlCallbackLog(char const* caller, xmlErrorLevel lvl, char const* msg, va_list ap) > +#define LIBXML2_LOG_CALLBACK __WINE_PRINTF_ATTR(2,3) > + > +void LIBXML2_LOG_CALLBACK libxml2_error_callback(void *ctxt, const char *msg, ...) > { > - char* buf = NULL; > int len = 32, needed; > - enum __wine_debug_class dbcl = __WINE_DBCL_ERR; > - switch (lvl) > + char* buf = NULL; > + va_list ap; > + > + do > { > - case XML_ERR_NONE: > - dbcl = __WINE_DBCL_TRACE; > - break; > - case XML_ERR_WARNING: > - dbcl = __WINE_DBCL_WARN; > - break; > - default: > - break; > + heap_free(buf); > + buf = heap_alloc(len); > + va_start(ap, msg); > + needed = vsnprintf(buf, len, msg, ap); > + va_end(ap); > + if (needed == -1) > + len *= 2; > + else if (needed >= len) > + len = needed + 1; > + else > + needed = 0; > } > + while (needed); > + > + wine_dbg_log(__WINE_DBCL_ERR, &__wine_dbch_msxml, "libxml2", "%s", buf); > + heap_free(buf); > +} > + > +void LIBXML2_LOG_CALLBACK libxml2_warn_callback(void *ctxt, const char *msg, ...) > +{ > + int len = 32, needed; > + char* buf = NULL; > + va_list ap; > > do > { > heap_free(buf); > buf = heap_alloc(len); > + va_start(ap, msg); > needed = vsnprintf(buf, len, msg, ap); > + va_end(ap); > if (needed == -1) > len *= 2; > else if (needed >= len) > @@ -91,11 +110,13 @@ void wineXmlCallbackLog(char const* caller, xmlErrorLevel lvl, char const* msg, > } > while (needed); > > - wine_dbg_log(dbcl, &__wine_dbch_msxml, caller, "%s", buf); > + wine_dbg_log(__WINE_DBCL_WARN, &__wine_dbch_msxml, "libxml2", "%s", buf); > heap_free(buf); > } > > -void wineXmlCallbackError(char const* caller, xmlErrorPtr err) > +#undef LIBXML2_LOG_CALLBACK > + > +void libxml2_structured_error(const char* caller, xmlErrorPtr err) > { > enum __wine_debug_class dbcl; > > diff --git a/dlls/msxml3/msxml_private.h b/dlls/msxml3/msxml_private.h > index e51501b..66c3b89 100644 > --- a/dlls/msxml3/msxml_private.h > +++ b/dlls/msxml3/msxml_private.h > @@ -289,21 +289,11 @@ extern xmlNodePtr xmldoc_unlink_xmldecl(xmlDocPtr doc) DECLSPEC_HIDDEN; > > extern HRESULT XMLElement_create( IUnknown *pUnkOuter, xmlNodePtr node, LPVOID *ppObj, BOOL own ) DECLSPEC_HIDDEN; > > -extern void wineXmlCallbackLog(char const* caller, xmlErrorLevel lvl, char const* msg, va_list ap) DECLSPEC_HIDDEN; > -extern void wineXmlCallbackError(char const* caller, xmlErrorPtr err) DECLSPEC_HIDDEN; > +extern void libxml2_structured_error(const char* caller, xmlErrorPtr err) DECLSPEC_HIDDEN; > +extern void libxml2_error_callback(void *ctxt, const char *msg, ...) DECLSPEC_HIDDEN; > +extern void libxml2_warn_callback(void *ctxt, const char *msg, ...) DECLSPEC_HIDDEN; > > -#define LIBXML2_LOG_CALLBACK __WINE_PRINTF_ATTR(2,3) > - > -#define LIBXML2_CALLBACK_TRACE(caller, msg, ap) \ > - wineXmlCallbackLog(#caller, XML_ERR_NONE, msg, ap) > - > -#define LIBXML2_CALLBACK_WARN(caller, msg, ap) \ > - wineXmlCallbackLog(#caller, XML_ERR_WARNING, msg, ap) > - > -#define LIBXML2_CALLBACK_ERR(caller, msg, ap) \ > - wineXmlCallbackLog(#caller, XML_ERR_ERROR, msg, ap) > - > -#define LIBXML2_CALLBACK_SERROR(caller, err) wineXmlCallbackError(#caller, err) > +#define LIBXML2_CALLBACK_SERROR(caller, err) libxml2_structured_error(#caller, err) > > extern BOOL is_preserving_whitespace(xmlNodePtr node) DECLSPEC_HIDDEN; > extern BOOL is_xpathmode(const xmlDocPtr doc) DECLSPEC_HIDDEN; > diff --git a/dlls/msxml3/schema.c b/dlls/msxml3/schema.c > index 253f901..c06bb69 100644 > --- a/dlls/msxml3/schema.c > +++ b/dlls/msxml3/schema.c > @@ -230,85 +230,53 @@ static const BYTE hash_assoc_values[] = > 116, 116, 116, 116, 116, 116 > }; > > -static void LIBXML2_LOG_CALLBACK parser_error(void* ctx, char const* msg, ...) > -{ > - va_list ap; > - va_start(ap, msg); > - LIBXML2_CALLBACK_ERR(Schema_parse, msg, ap); > - va_end(ap); > -} > - > -static void LIBXML2_LOG_CALLBACK parser_warning(void* ctx, char const* msg, ...) > -{ > - va_list ap; > - va_start(ap, msg); > - LIBXML2_CALLBACK_WARN(Schema_parse, msg, ap); > - va_end(ap); > -} > - > #ifdef HAVE_XMLSCHEMASSETPARSERSTRUCTUREDERRORS > -static void parser_serror(void* ctx, xmlErrorPtr err) > +static void libxml2_schema_structerror(void* ctx, xmlErrorPtr err) > { > - LIBXML2_CALLBACK_SERROR(Schema_parse, err); > + LIBXML2_CALLBACK_SERROR(schema_parse, err); > } > #endif > > -static inline xmlSchemaPtr Schema_parse(xmlSchemaParserCtxtPtr spctx) > +static inline xmlSchemaPtr schema_parse(xmlSchemaParserCtxtPtr ctxt) > { > - TRACE("(%p)\n", spctx); > + TRACE("(%p)\n", ctxt); > > - xmlSchemaSetParserErrors(spctx, parser_error, parser_warning, NULL); > + xmlSchemaSetParserErrors(ctxt, libxml2_error_callback, libxml2_warn_callback, NULL); > #ifdef HAVE_XMLSCHEMASSETPARSERSTRUCTUREDERRORS > - xmlSchemaSetParserStructuredErrors(spctx, parser_serror, NULL); > + xmlSchemaSetParserStructuredErrors(ctxt, libxml2_schema_structerror, NULL); > #endif > > - return xmlSchemaParse(spctx); > -} > - > -static void LIBXML2_LOG_CALLBACK validate_error(void* ctx, char const* msg, ...) > -{ > - va_list ap; > - va_start(ap, msg); > - LIBXML2_CALLBACK_ERR(Schema_validate_tree, msg, ap); > - va_end(ap); > -} > - > -static void LIBXML2_LOG_CALLBACK validate_warning(void* ctx, char const* msg, ...) > -{ > - va_list ap; > - va_start(ap, msg); > - LIBXML2_CALLBACK_WARN(Schema_validate_tree, msg, ap); > - va_end(ap); > + return xmlSchemaParse(ctxt); > } > > #ifdef HAVE_XMLSCHEMASSETVALIDSTRUCTUREDERRORS > -static void validate_serror(void* ctx, xmlErrorPtr err) > +static void libxml2_validate_structerror(void* ctx, xmlErrorPtr err) > { > - LIBXML2_CALLBACK_SERROR(Schema_validate_tree, err); > + LIBXML2_CALLBACK_SERROR(schema_validate_tree, err); > } > #endif > > -static inline HRESULT Schema_validate_tree(xmlSchemaPtr schema, xmlNodePtr tree) > +static inline HRESULT schema_validate_tree(xmlSchemaPtr schema, xmlNodePtr tree) > { > - xmlSchemaValidCtxtPtr svctx; > + xmlSchemaValidCtxtPtr ctxt; > int err; > > TRACE("(%p, %p)\n", schema, tree); > /* TODO: if validateOnLoad property is false, > * we probably need to validate the schema here. */ > - svctx = xmlSchemaNewValidCtxt(schema); > - xmlSchemaSetValidErrors(svctx, validate_error, validate_warning, NULL); > + ctxt = xmlSchemaNewValidCtxt(schema); > + xmlSchemaSetValidErrors(ctxt, libxml2_error_callback, libxml2_warn_callback, NULL); > #ifdef HAVE_XMLSCHEMASSETVALIDSTRUCTUREDERRORS > - xmlSchemaSetValidStructuredErrors(svctx, validate_serror, NULL); > + xmlSchemaSetValidStructuredErrors(ctxt, libxml2_validate_structerror, NULL); > #endif > > if (tree->type == XML_DOCUMENT_NODE) > - err = xmlSchemaValidateDoc(svctx, (xmlDocPtr)tree); > + err = xmlSchemaValidateDoc(ctxt, (xmlDocPtr)tree); > else > - err = xmlSchemaValidateOneElement(svctx, tree); > + err = xmlSchemaValidateOneElement(ctxt, tree); > > - xmlSchemaFreeValidCtxt(svctx); > - return err? S_FALSE : S_OK; > + xmlSchemaFreeValidCtxt(ctxt); > + return err ? S_FALSE : S_OK; > } > > static DWORD dt_hash(xmlChar const* str, int len /* calculated if -1 */) > @@ -599,11 +567,11 @@ HRESULT dt_validate(XDR_DT dt, xmlChar const* content) > > if (!datatypes_schema) > { > - xmlSchemaParserCtxtPtr spctx; > + xmlSchemaParserCtxtPtr ctxt; > assert(datatypes_src != NULL); > - spctx = xmlSchemaNewMemParserCtxt((char const*)datatypes_src, datatypes_len); > - datatypes_schema = Schema_parse(spctx); > - xmlSchemaFreeParserCtxt(spctx); > + ctxt = xmlSchemaNewMemParserCtxt((char const*)datatypes_src, datatypes_len); > + datatypes_schema = schema_parse(ctxt); > + xmlSchemaFreeParserCtxt(ctxt); > } > > switch (dt) > @@ -656,7 +624,7 @@ HRESULT dt_validate(XDR_DT dt, xmlChar const* content) > xmlSetNs(node, ns); > xmlDocSetRootElement(tmp_doc, node); > > - hr = Schema_validate_tree(datatypes_schema, (xmlNodePtr)tmp_doc); > + hr = schema_validate_tree(datatypes_schema, (xmlNodePtr)tmp_doc); > xmlFreeDoc(tmp_doc); > } > else > @@ -844,7 +812,7 @@ static BOOL link_datatypes(xmlDocPtr schema) > static cache_entry* cache_entry_from_xsd_doc(xmlDocPtr doc, xmlChar const* nsURI, MSXML_VERSION v) > { > cache_entry* entry = heap_alloc(sizeof(cache_entry)); > - xmlSchemaParserCtxtPtr spctx; > + xmlSchemaParserCtxtPtr ctxt; > xmlDocPtr new_doc = xmlCopyDoc(doc, 1); > > link_datatypes(new_doc); > @@ -853,9 +821,9 @@ static cache_entry* cache_entry_from_xsd_doc(xmlDocPtr doc, xmlChar const* nsURI > * do we need to do something special here? */ > entry->type = CacheEntryType_XSD; > entry->ref = 0; > - spctx = xmlSchemaNewDocParserCtxt(new_doc); > + ctxt = xmlSchemaNewDocParserCtxt(new_doc); > > - if ((entry->schema = Schema_parse(spctx))) > + if ((entry->schema = schema_parse(ctxt))) > { > xmldoc_init(entry->schema->doc, v); > entry->doc = entry->schema->doc; > @@ -868,7 +836,7 @@ static cache_entry* cache_entry_from_xsd_doc(xmlDocPtr doc, xmlChar const* nsURI > heap_free(entry); > entry = NULL; > } > - xmlSchemaFreeParserCtxt(spctx); > + xmlSchemaFreeParserCtxt(ctxt); > return entry; > } > > @@ -884,7 +852,7 @@ static cache_entry* cache_entry_from_xdr_doc(xmlDocPtr doc, xmlChar const* nsURI > entry->ref = 0; > spctx = xmlSchemaNewDocParserCtxt(xsd_doc); > > - if ((entry->schema = Schema_parse(spctx))) > + if ((entry->schema = schema_parse(spctx))) > { > entry->doc = new_doc; > xmldoc_init(entry->schema->doc, version); > @@ -1443,7 +1411,7 @@ HRESULT SchemaCache_validate_tree(IXMLDOMSchemaCollection2* iface, xmlNodePtr tr > /* TODO: if the ns is not in the cache, and it's a URL, > * do we try to load from that? */ > if (schema) > - return Schema_validate_tree(schema, tree); > + return schema_validate_tree(schema, tree); > else > WARN("no schema found for xmlns=%s\n", get_node_nsURI(tree)); > > diff --git a/dlls/msxml3/selection.c b/dlls/msxml3/selection.c > index ba173f9..61e7f24 100644 > --- a/dlls/msxml3/selection.c > +++ b/dlls/msxml3/selection.c > @@ -738,7 +738,7 @@ static void XSLPattern_OP_IGEq(xmlXPathParserContextPtr pctx, int nargs) > xmlFree(arg2); > } > > -static void query_serror(void* ctx, xmlErrorPtr err) > +static void libxml2_selection_structerror(void* ctx, xmlErrorPtr err) > { > LIBXML2_CALLBACK_SERROR(domselection_create, err); > } > @@ -767,7 +767,7 @@ HRESULT create_selection(xmlNodePtr node, xmlChar* query, IXMLDOMNodeList **out) > init_dispex(&This->dispex, (IUnknown*)&This->IXMLDOMSelection_iface, &domselection_dispex); > xmldoc_add_ref(This->node->doc); > > - ctxt->error = query_serror; > + ctxt->error = libxml2_selection_structerror; > ctxt->node = node; > registerNamespaces(ctxt); > > -- > 1.5.6.5 > >

3 3

Re: gdi32: Make output of dumping GDI objects more compact.
by Dmitry Timoshkov 16 Feb '12

16 Feb '12

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > --- > dlls/gdi32/gdiobj.c | 6 ++++-- > 1 files changed, 4 insertions(+), 2 deletions(-) What's the reason for the 'rejected' status? -- Dmitry.

2 8

Re: [1/2] msxml3: Use static buffer when tracing libxml2 error messages
by Alexandre Julliard 16 Feb '12

16 Feb '12

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > Use static buffer when tracing libxml2 error messages I don't think it's necessary to rename all the functions. Please keep patches small, especially during code freeze. -- Alexandre Julliard julliard(a)winehq.org

1 0

re: How program are Loaded to wine
by Dan Kegel 16 Feb '12

16 Feb '12

Have you read the documentation, e.g. http://www.winehq.org/docs/winedev-guide/architecture ? Have you tried stepping through the source of CreateProcess by hand? http://source.winehq.org/source/dlls/kernel32/process.c#L2389 If you need more background, I hear "Windows Internals" is useful, http://www.amazon.com/windows-internals-5-rainbow-pony/dp/0735625301

1 0

Re: winmm: Allow new sounds to interrupt previous PlaySound invocations.
by Andrew Eikum 16 Feb '12

16 Feb '12

On Thu, Feb 16, 2012 at 10:10:09AM +0100, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > this fixes bug #28413. > Thanks Jörg, looks sane to me and I can confirm it fixes the problem. Andrew

1 0

Re: advapi32/tests: Marked some tests that fail on Wine as todo_wine.
by Johan Gill 16 Feb '12

16 Feb '12

Now I ran the tests on another Linux system with wine, and there the failing tests are skipped, so it seems I did not fully understand what's going on here and why the tests are run on my system.

1 0

Re: msxml3: Fix varargs handling in libxml2 error callback implementation
by Alexandre Julliard 16 Feb '12

16 Feb '12

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > The problem is that vsnprintf() was called multiple times with same > va_list. Ti fix that it was necessary to get rid of some tracing bits > like macro-defined callback calls and a single function for all kinds > of error types. Actually there's no need to call vsnprintf multiple times. The debug buffer has a limited size anyway, so we might as well use a limited stack buffer here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: comctl32: Fix TB_SETEXTENDEDSTYLE to use mask passed in wParam
by Marvin 16 Feb '12

16 Feb '12

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=16982 Your paranoid android. === WNT4WSSP6 (32 bit toolbar) === toolbar.c:1898: Test failed: 1: got style 0x00000008, expected 0x00000099 toolbar.c:1898: Test failed: 7: got style 0x00000008, expected 0x00000000 toolbar.c:1898: Test failed: 8: got style 0x00000010, expected 0x00000000 toolbar.c:1898: Test failed: 9: got style 0x00000008, expected 0x00000000

1 0

Re: po: Fix a couple of typography issues in the Finnish translation.
by Lauri Kenttä 16 Feb '12

16 Feb '12

"Avankuvan väli:" has this colon on purpose. It's the best way to make this translation meaningful in the context (Avainkuvan väli: [BOX] kuvaa). I've already discussed this with you in private. My opinion is that the original text should be in one piece or at least have a msgctxt to allow better translations. -- Lauri Kenttä

1 0

How program are Loaded to wine
by Shanuka Wijekoon 16 Feb '12

16 Feb '12

hello I am developing the project related to wine. so I have no idea how the programs are loaded and run by wine, what are the files initially loaded to the memory ,what are the files loaded to the memory on demand of the program.Is there any particular pattern of loading programs to memory file wise? I am new to wine so can I have good explanation about that? if there any related references and code segments it will helpful to me. Thank you

1 0

Re: advapi32: Correct tests under WOW64
by Alexandre Julliard 15 Feb '12

15 Feb '12

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -1455,9 +1455,11 @@ static void test_token_attr(void) > Size = 0; > ret = GetTokenInformation(Token, TokenGroups, Groups, Size2, &Size); > ok(Size > 1, "got %d\n", Size); > - ok(!ret && GetLastError() == ERROR_INSUFFICIENT_BUFFER, > - "%d with error %d\n", ret, GetLastError()); > - ok(*((BYTE*)Groups) == 0xcc, "buffer altered\n"); > + /* WoW64 return TRUE with the LastError set */ > + ok(GetLastError() == ERROR_INSUFFICIENT_BUFFER, "%d with error %d\n", ret, GetLastError()); > + if(!ret) > + ok(*((BYTE*)Groups) == 0xcc, "buffer altered\n"); Testing last error on success is in general not useful. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: gdiplus: GdipTranslateLineTransform: make stub lie and return Ok
by Dan Kegel 15 Feb '12

15 Feb '12

On Sat, Feb 11, 2012 at 3:29 PM, Dan Kegel <dank(a)kegel.com> wrote: > This lets many .net apps run, see bug 23759. I see this patch is marked pending. Since tweaking the stub to lie and return success lets a bunch of .net apps run, it's tempting to say the benefits of the patch outweigh the risk... wine has done this kind of hack before, though maybe not during code freeze. Can someone who knows more about gdiplus comment? - Dan

2 2

Re: [PATCH 2/2] winealsa.drv: Optionally load extra ALSA device names from the registry
by Alexandre Julliard 14 Feb '12

14 Feb '12

Andrew Eikum <aeikum(a)codeweavers.com> writes: > + while(*p){ > + if(alsa_try_open(p, stream)){ > + if(ids && keys){ > + len = MultiByteToWideChar(CP_UNIXCP, 0, p, -1, NULL, 0); > + ids[*num] = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); > + MultiByteToWideChar(CP_UNIXCP, 0, p, -1, ids[*num], len); The registry is stored in Unicode, the conversion should be the other way around. -- Alexandre Julliard julliard(a)winehq.org

1 0

Windows-on-Arm won't support win32
by Dan Kegel 14 Feb '12

14 Feb '12

According to http://www.zdnet.com/blog/perlow/the-long-kiss-goodbye-for-x86-desktop-wind… Microsoft is not letting developers use win32 on arm (although Microsoft is probably using it themselves for Office on arm). Instead, native apps have to use WinRT, a C++-based class library. According to http://en.wikipedia.org/wiki/Windows_Runtime, the WinRT libraries are built on top of win32 internally. If it takes off, and someone feels like supporting it in Wine, they would probably have to start by implementing the first bits in C like wine's msvcp support. Eventually, if and when llvm gets Visual C++ ABI support, maybe wine could start allowing C++ source code. (FWIW, I see Charles Davis was working on that, http://code.google.com/p/google-summer-of-code-2010-llvm/updates/list http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-March/014305.html https://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/MicrosoftCXXABI.… ).

4 6

Wine Gecko 1.5-beta1
by Jacek Caban 13 Feb '12

13 Feb '12

Hi all, It's time for another Gecko update. I've uploaded builds to SourceForge [1], so anyone willing to test it may grab an MSI file from there and apply the attached patch to Wine. Mozilla releases Firefox 11, which this package is based on, in four weeks. The plan is to do Wine Gecko release a bit later (and, obviously, not sooner than Wine 1.4 release). Any help with testing will be appreciated! Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.5-beta1/

1 0

Re: gdi32: rebuild the internal SystemLink every time.
by Alexandre Julliard 13 Feb '12

13 Feb '12

Aric Stewart <aric(a)codeweavers.com> writes: > Our registry or settings may have changed since initial start, > especially on prefix creation, so rebuilg the internal system link > each time. I don't think you can do that. Other processes may be reading or writing the keys at the same time. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msxml3: Use debugstr_a() to trace
by Alexandre Julliard 13 Feb '12

13 Feb '12

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > This fixes printf overflow in error callback that I get sometimes with > Outlook 2010, patch also changes a couple of similar cases. > > That's safe enough to include now. Apparently not... ../../../tools/runtest -q -P wine -M msxml3.dll -T ../../.. -p msxml3_test.exe.so domdoc.c && touch domdoc.ok wine_dbg_vprintf: debugstr buffer overflow (contents: 'err:msxml:doparse "XML declaration allowed only at the start of the document\n""XML declaration allowed only at the start of the document\n""XML declaration allowed only at the start of the document\n""XML declaration allowed only at the start of the document\n""XML declaration allowed only at the start of the document\n""XML declaration allowed only at the start of the document\n""XML declaration allowed only at the start of the document\n""XML declaration allowed only at the start of the document\n""XML declaration allowed only at the start of the document\n""XML declaration allowed only at the start of the document\n""XML declaration allowed only at the start of the document\n""XML declaration allowed only at the start of the document\n""XML declaration allowed only at the start of the document\n""XML declaration allowed only at the start of the document\n""XML declaration allowed only at the start of the document\n""XML declaration allowed only at the start of the document\n""XML declaration allowed only') wine: Assertion failed at address 0x68000822 (thread 0009), starting debugger... -- Alexandre Julliard julliard(a)winehq.org

1 0

half transparent window titles?
by Joerg-Cyril.Hoehle＠t-systems.com 13 Feb '12

13 Feb '12

Hi, did anyone else notice that since a few weeks, window titles are somehow not refreshed and/or half transparent? I'm typically using virtual desktop mode in Ubuntu Linux. This is observable with winecfg, the "update .wine" requester, winetest as well as Wine's crash dialog. A search for "transparent" found nothing related in bugzilla. Regards, Jörg Höhle

2 1

Re: [PATCH 3/7] ntdll: fix endianness of three fields in DVD_LAYER_DESCRIPTOR (resend)
by Charles Davis 13 Feb '12

13 Feb '12

On Feb 10, 2012, at 1:30 PM, Dan Kegel wrote: > --- > dlls/ntdll/cdrom.c | 12 +++++++++--- > 1 files changed, 9 insertions(+), 3 deletions(-) > > diff --git a/dlls/ntdll/cdrom.c b/dlls/ntdll/cdrom.c > index 802782b..6b64203c 100644 > --- a/dlls/ntdll/cdrom.c > +++ b/dlls/ntdll/cdrom.c > @@ -144,6 +144,12 @@ WINE_DEFAULT_DEBUG_CHANNEL(cdrom); > # define CD_FRAMES 75 /* frames per second */ > #endif > > +#ifdef WORDS_BIGENDIAN > +#define GET_BE_DWORD(x) (x) > +#else > +#define GET_BE_DWORD(x) RtlUlongByteSwap(x) > +#endif > + > static const struct iocodexs > { > DWORD code; > @@ -2568,9 +2574,9 @@ static NTSTATUS DVD_ReadStructure(int dev, const DVD_READ_STRUCTURE *structure, > p->Reserved1 = 0; > p->TrackDensity = l->track_density; > p->LinearDensity = l->linear_density; > - p->StartingDataSector = l->start_sector; > - p->EndDataSector = l->end_sector; > - p->EndLayerZeroSector = l->end_sector_l0; > + p->StartingDataSector = GET_BE_DWORD(l->start_sector); > + p->EndDataSector = GET_BE_DWORD(l->end_sector); > + p->EndLayerZeroSector = GET_BE_DWORD(l->end_sector_l0); I don't know about this. To make your original patch work right on Mac, one of the things I had to do was get rid of the OSReadBigInt32() calls that swapped the endianness of the sector fields from big to host. Chip > p->Reserved5 = 0; > p->BCAFlag = l->bca; > p->Reserved6 = 0; > -- > 1.7.9 > > >

2 3

Re: cryptnet/tests: Fix test failures on older NT4
by Marvin 13 Feb '12

13 Feb '12

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=16947 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: cryptnet/tests: Fix test failures on older NT4
by Marvin 13 Feb '12

13 Feb '12

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=16947 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: cryptnet/tests: Fix test failures on older NT4
by Marvin 13 Feb '12

13 Feb '12

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=16947 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: cryptnet/tests: Fix test failures on older NT4
by Marvin 13 Feb '12

13 Feb '12

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=16947 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: advapi32/tests: Fix a test failure on older NT4
by Marvin 13 Feb '12

13 Feb '12

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=16946 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Fwd: Google Summer of Code 2012 DEADLINE: 2012-02-27
by Jeremy White 12 Feb '12

12 Feb '12

Hi Folks, It's that time of year again - summer of code is going to start up soon. Maarten, you've been coordinating things for us for a while now - are you still game? Would you like help? Anyone else willing to volunteer to help admin the process? Cheers, Jeremy --- Conservancy Projects, I want to draw your attention to the fact that Google's Summer of Code program for 2012 is now accepting applications. Carol Smith wrote at 11:43 (EST) on Saturday: > We're pleased to announce that Google Summer of Code will be happening > for its eighth year this year: > > [1] - http://google-opensource.blogspot.com/2012/02/google-summer-of-code-2012-is… > [2] - http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc20… > [3] - http://www.google-melange.com/gsoc/events/google/gsoc2012 In particular, take a look at [3], which has the calendar for the SoC 2012 program.

6 7

Re: [PATCH 4/7] kernel32/tests: initial tests for cdrom.c (try 2)
by Charles Davis 10 Feb '12

10 Feb '12

On Feb 10, 2012, at 1:30 PM, Dan Kegel wrote: > +START_TEST(cdrom) > +{ [...] > + /* GENERIC_WRITE because without it, passthrough doesn't work on win7 */ But with it, you can't open the device at all on Mac. As I explained on bug 29669, the device file only has 0440 access. Chip

1 0

The audio GetPosition dilemma (long)
by Joerg-Cyril.Hoehle＠t-systems.com 10 Feb '12

10 Feb '12

Hi, mmdevapi's GetPosition returns "the stream position of the sample that is currently playing through the speakers", says MSDN. This is exactly what apps ought to use that want to synchronize audio & video (lip synchronisation). MSDN's wording about winmm's GetPosition is not exactly the same: "the current playback position of the given waveform-audio output device." However there's no other winmm function that could be used for lip-sync. Tests in winmm/tests/wave.c tend to show that WHDR_DONE notifications are only received after a position corresponding to the written number of bytes has been reached -- IOW the buffer has been played. Now look at winmm's PlaySound and mciwave code: /* make it so that 3 buffers per second are needed */ Both then proceed to play ping pong with two 1/3 second buffers. Every time WHDR_DONE is received, one of the two is empty, refilled and resubmitted using waveOutWrite. Now consider a system such as PulseAudio that wants to buffer 2 seconds of an audio stream internally. That scheme will fail completely. - If WHDR_DONE is based on GetPosition, notifications will only be sent after 2 seconds or an underrun. Neither PlaySound nor MCIWAVE buffer 2 seconds. They continuously hit an underrun as PA signals that it drained the tiny 40ms ALSA buffer we supplied. Is that PlaySound's fault? - If WHDR_DONE is instead based on buffer usage, it could be sent following snd_pcm_write and let PA buffer as much as it wants. But then our wave tests fail if GetPosition returns something like the position currently playing through the speakers, which is 2s late. Should we have GetPosition lie? And suffer loss of lip sync? DSound's GetCurrentPosition suffers from the exact same issue. For instance, playing an audio CD-ROM with mcicda in recent Wine causes constant underruns from DSound when Pulseaudio is involved. What's the root cause of the issue? 15 years ago, the audio HW would likely receive a pointer to the winmm header data and play that. Once played, the buffer was no more needed and returned to the app. Also, there was nothing sitting behind the audio HW causing significant latency (I mean DAC -> electronic -> speaker -> acoustic had latency negligible to the human brain). Equating GetPosition with the sample seen by the DAC was and is reasonable -- ALSA does exactly this with hw:0. DSound's model is that of a circular buffer from which the DAC is fed. No different. These days with mmdevapi, w7 users report a latency of 30-40ms introduced by the native mixer. Native's winmm might account for that in its GetPosition reports. This limit is below the threshold that my mmdevapi tests would notice. It is well below the approximately 100ms that matter to human perception when correlating visible and audible events. Note that native's mixer is the last in an audio graph before the HW. What happens in Linux with Wine? ALSA's dmix is known to introduce some latency as it operates in period-size chunks. However ALSA's periods are typically very small, e.g. 21.333ms and ALSA's dmix is typically connected to hw:0, immediately playing audio to the speakers. There's hardly a difference between audible GetPosition and a buffer position derived from snd_pcm_write (and old Wine mixed the two in the past). The picture looks a lot like with native's mmdevapi mixer. PulseAudio is entirely different. With PA, the wine mixer is no more near the end of the audio graph, rather than in front of a 2 second latency introducing element. A position derived from snd_pcm_write is 2s ahead of the true speaker position. How did we react? winealsa tried: 1. Using a small ALSA buffer so as to signal PA that large latencies are not ok. PA seems to ignore that hint. It still appears to buffer a lot somewhere internally (I've no experience with PA 1.0 or 1.1, please check). Even worse, small ALSA buffers like 40ms increased the risk of underruns and resulted in a worse audio experience to all users of wineALSA, whereas old wine would typically use a 100ms buffer. Small buffers are no issue to native's mixer. It's using "Pro Audio" priority, which is the highest priority on a native system AFAIK. By contrast, Wine is running at normal user priority. 2. Rate-Limiting. We currently believe we are doing it because we write no more than 3 periods at a time. But we're not. Nothing can prevent PA or any other device from filling its 2s buffer over time. It'll eventually do it, just slowly. We can't use our own clock to limit our writes because that would introduce clock skew issues with the audio HW clock. What if it runs faster than the system's interpretation of 48000fps? We can't second-guess the audio HW clock. IOW, we can't win a rate-limiting game. If the back-end signals via snd_pcm_avail that it has space, then we must feed it. Now we know the reason of our troubles. What can we do? 0. Ignore the issue. Equate GetPosition with Released_frames - GetCurrentPadding 1. Consider lip-sync important and strive to support audio & video applications. 2. mmdevapi appears to have a reasonable separation of concerns between buffering and speaker position. Leave as is. (It may happen though that apps built upon the assumption that they are no more than 40ms apart break when latencies like PA's enter the loop. Here it would be interesting to see whether native has some similar situation, like a remote desktop & audio environment). 3. Protect DSound from a too large delta between padding and position. The maximum is given by the DSound primary buffer size, since DSound's circular GetCurrentPosition abstraction breaks down completely should they be further apart. IOW, don't rate limit DSound writes, but lie about the position if the wineXYZ device says it's too far behind. Having this right may fix some of the bugs currently in bugzilla. That way, we'll get lip-sync with back-ends that don't introduce an unbearable latency. And we won't enter an underrun because the driver or the app never wait too much for the position to increase. 3. Protect winmm from a too large delta between padding and position. As there's no buffer limit to guide us, we must introduce an arbitrary one, around 100-200ms. I don't know whether a dynamic limit based on average supplied WHDR buffers would work. Regarding WHDR_DONE, I don't know whether we should then relax the tests. That feels unsafe, because an app may well wait for WHDR_DONE before calling waveOutReset or Close. WHDR_DONE should not come too early, or we may lose trailing sounds. Perhaps we should not delay the position when playing the last buffer in the list. Our winmm/tests/wave.c tests prove nothing more than that: at the end, the position corresponds to the sum of written samples. Perhaps a similar reflection on MS' side explains why in my tests native's mmdevapi GetPosition may stay 17 samples below the sum of written samples with some USB headsets (or is it just a bug in their driver?). 4. Observe the behaviour of libraries that target mmdevapi, winmm and DSound, e.g. OpenAL, XAudio2, bink, smack, SDL, FMOD and learn. Actually, thinking about what may happen to trailing samples in a system that introduces 2s latencies still gives headaches. If we issue snd_pcm_reset prior to snd_pcm_close, sound will be killed for sure. It looks like the device should remain open for some time. This applies to all wineXYZ devices, not just ALSA with PA. Some future OSS device may too introduce unforeseen latencies. Now I'll go and fix winmm as suggested above. Thank you for reading this far, Jörg Höhle

1 0

Re: [PATCH 3/3] ieframe: Added IProvideClassInfo::GetClassInfo tests
by Marvin 10 Feb '12

10 Feb '12

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=16906 Your paranoid android. === WNT4WSSP6 (32 bit webbrowser) === webbrowser.c:3189: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3189: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3189: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3189: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3304: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3281: Test failed: Could not get WebBrowserV1 instance: 80040154 webbrowser: unhandled exception c0000005 at 0040A9DE === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2539: Test failed: expected GetOverridesKeyPath webbrowser.c:2543: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2544: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:2153: Test failed: put_Resizable failed: 80004001 webbrowser.c:2154: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2158: Test failed: put_Resizable failed: 80004001 webbrowser.c:2159: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2539: Test failed: expected GetOverridesKeyPath webbrowser.c:2543: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2544: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:410: Test failed: unexpected call Exec_SETDOWNLOADSTATE_0 webbrowser.c:2153: Test failed: put_Resizable failed: 80004001 webbrowser.c:2154: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2158: Test failed: put_Resizable failed: 80004001 webbrowser.c:2159: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2539: Test failed: expected GetOverridesKeyPath webbrowser.c:2543: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2544: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:469: Test failed: unexpected nCmdID 29 webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:2702: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2829: Test failed: expected TranslateUrl webbrowser.c:2830: Test failed: expected Invoke_BEFORENAVIGATE2 webbrowser.c:2832: Test failed: expected Invoke_PROPERTYCHANGE webbrowser.c:2838: Test failed: ReadyState = 1, expected 4 webbrowser.c:2648: Test failed: ReadyState = 1, expected 4 webbrowser.c:839: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:855: Test failed: unexpected call Invoke_BEFORENAVIGATE2 webbrowser.c:862: Test failed: ReadyState = 1, expected 4 webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:617: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL webbrowser.c:621: Test failed: unexpected call Invoke_AMBIENT_USERAGENT webbrowser.c:625: Test failed: unexpected call Invoke_AMBIENT_PALETTE webbrowser.c:1557: Test failed: unexpected call GetOptionKeyPath webbrowser.c:359: Test failed: unexpected call QueryStatus_SETPROGRESSTEXT webbrowser.c:839: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:839: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:839: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:839: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:469: Test failed: unexpected nCmdID 26 webbrowser.c:469: Test failed: unexpected nCmdID 29 webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:791: Test failed: ReadyState = 1, expected 4 webbrowser.c:1568: Test failed: unexpected call GetDropTarget webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:2702: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:3225: Test failed: doc != doc2 webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:617: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL webbrowser.c:621: Test failed: unexpected call Invoke_AMBIENT_USERAGENT webbrowser.c:625: Test failed: unexpected call Invoke_AMBIENT_PALETTE webbrowser.c:1557: Test failed: unexpected call GetOptionKeyPath webbrowser.c:359: Test failed: unexpected call QueryStatus_SETPROGRESSTEXT webbrowser.c:469: Test failed: unexpected nCmdID 26 webbrowser.c:469: Test failed: unexpected nCmdID 29 webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:1568: Test failed: unexpected call GetDropTarget webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:2695: Test failed: expected TranslateUrl webbrowser.c:2702: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:3232: Test failed: doc != doc2 webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:617: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL webbrowser.c:621: Test failed: unexpected call Invoke_AMBIENT_USERAGENT webbrowser.c:625: Test failed: unexpected call Invoke_AMBIENT_PALETTE webbrowser.c:1557: Test failed: unexpected call GetOptionKeyPath webbrowser.c:359: Test failed: unexpected call QueryStatus_SETPROGRESSTEXT webbrowser.c:469: Test failed: unexpected nCmdID 26 webbrowser.c:469: Test failed: unexpected nCmdID 29 webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:1568: Test failed: unexpected call GetDropTarget webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:2695: Test failed: expected TranslateUrl webbrowser.c:2702: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2829: Test failed: expected TranslateUrl webbrowser.c:2830: Test failed: expected Invoke_BEFORENAVIGATE2 webbrowser.c:2838: Test failed: ReadyState = 1, expected 4 webbrowser.c:2648: Test failed: ReadyState = 1, expected 4 webbrowser.c:855: Test failed: unexpected call Invoke_BEFORENAVIGATE2 webbrowser.c:862: Test failed: ReadyState = 1, expected 4 webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:617: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL webbrowser.c:621: Test failed: unexpected call Invoke_AMBIENT_USERAGENT webbrowser.c:625: Test failed: unexpected call Invoke_AMBIENT_PALETTE webbrowser.c:1557: Test failed: unexpected call GetOptionKeyPath webbrowser.c:359: Test failed: unexpected call QueryStatus_SETPROGRESSTEXT webbrowser.c:469: Test failed: unexpected nCmdID 26 webbrowser.c:469: Test failed: unexpected nCmdID 29 webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:791: Test failed: ReadyState = 1, expected 4 webbrowser.c:1568: Test failed: unexpected call GetDropTarget webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:2702: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2648: Test failed: ReadyState = 1, expected 4 webbrowser.c:839: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:855: Test failed: unexpected call Invoke_BEFORENAVIGATE2 webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:617: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL webbrowser.c:621: Test failed: unexpected call Invoke_AMBIENT_USERAGENT webbrowser.c:625: Test failed: unexpected call Invoke_AMBIENT_PALETTE webbrowser.c:1557: Test failed: unexpected call GetOptionKeyPath webbrowser.c:359: Test failed: unexpected call QueryStatus_SETPROGRESSTEXT webbrowser.c:469: Test failed: unexpected nCmdID 26 webbrowser.c:469: Test failed: unexpected nCmdID 16 webbrowser.c:469: Test failed: unexpected nCmdID 15 webbrowser.c:469: Test failed: unexpected nCmdID 29 webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:791: Test failed: ReadyState = 1, expected 4 webbrowser.c:1568: Test failed: unexpected call GetDropTarget webbrowser.c:1007: Test failed: unexpected call GetContainer webbrowser.c:517: Test failed: unexpected call webbrowser.c:2702: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2943: Test failed: expected RequestUIActivate webbrowser.c:3035: Test failed: Got 0x80004002 webbrowser.c:3130: Test failed: QueryService failed: 80004002 webbrowser: unhandled exception c0000005 at 0040D5A2

1 0

winealsa.drv patch to enum all software devices from .asoundrc
by Нискородов Серёжа 10 Feb '12

10 Feb '12

Hi, all. I'm not so good at programming. I just was looking for a way to make possible play sound from WINE to ALSA software device other than "default". I wrote a patch that allows you to select the ALSA software device from control panel, along with the hardware devices. Perhaps the code is not so clear and beautiful, but it works for me, and maybe someone wants to send it to the repository, or to correct and send a corrected.

2 5

[PATCH 1/6] include: new file ddk/scsi.h
by Dan Kegel 09 Feb '12

09 Feb '12

Only adds the minimum definitions needed to use SCSIOP_READ_DVD_STRUCTURE.

1 0

winetest can't remove its temp directory
by Joerg-Cyril.Hoehle＠t-systems.com 09 Feb '12

09 Feb '12

Hi, does anybody else see a message from winetest.exe about not being able to clean up at the end? This happened with e.g. winetest-1.4-rc2 and some earlier ones. Indeed, a temp directory with all the extracted *_test.exe is left half-full. It looks like files got deleted in alphabetical order starting with 'a'. mmdevapi_test.exe is the first one left, up to x*_test.exe Today's "[PATCH 2/4] mmdevapi/tests" adds a missing IAudioClock_Release(acl); Perhaps that prevented mmdevapi from cleaning up? How to explain such an effect? How to allow winetest to clean up and exit properly? That does not seem to be issue #12801. Thank you for your help, Jörg Höhle

2 1

Add a trailing full stop to the kernel32 error messages
by Francois Gouget 09 Feb '12

09 Feb '12

Translators: This may concern you! See the (*) below. (hence the post to wine-devel) It was discovered that the kernel32 error messages are supposed to all end with a full stop. This is a lot of strings and impacts a lot of translations. http://www.winehq.org/pipermail/wine-devel/2012-January/093969.html So this fix is not provided as a patch but as a set of two scripts. * mcfix adds a trailing full stop if needed to the kernel32 error messages. * pofix does the matching changes to the specified PO file both on the English and translated strings (taking into account the full-width for Chinese and Japanese translations). The advantage is that this can update everything with no fuzzying and without risking conflicts when applying it to Wine(*). To update Wine, simply run: ./mcfix dlls/kernel32/winerror.mc; for i in po/*.po;do ./pofix $i;done (*) As a translator if you have a local PO file that you took before this change and you modified some kernel32 error translations you patch will conflict. But that's easy to solve, simply run: ./pofix myfile.po -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ 145 = 1! + 4! + 5!

1 0

Re: [PATCH 1/2] winmm: Avoid using SuspendThread, it can hang Wine.
by Alexandre Julliard 09 Feb '12

09 Feb '12

Joerg-Cyril.Hoehle(a)t-systems.com writes: > @@ -1006,7 +1008,9 @@ static BOOL MMSYSTEM_MidiStream_MessageHandler(WINE_MIDIStream* lpMidiStrm, LPWI > LPMIDIHDR lpMidiHdr; > LPMIDIHDR* lpmh; > LPBYTE lpData; > + BOOL paused = FALSE; > > +still_paused: > switch (msg->message) { > case WM_QUIT: > SetEvent(lpMidiStrm->hEvent); > @@ -1028,6 +1032,16 @@ static BOOL MMSYSTEM_MidiStream_MessageHandler(WINE_MIDIStream* lpMidiStrm, LPWI > } > lpMidiStrm->lpMidiHdr = 0; > SetEvent(lpMidiStrm->hEvent); > + return TRUE; > + case WINE_MSM_RESUME: > + /* FIXME: send out cc64 0 (turn off sustain pedal) on every channel */ > + lpMidiStrm->dwStartTicks = GetTickCount() - lpMidiStrm->dwPositionMS; > + SetEvent(lpMidiStrm->hEvent); > + return TRUE; > + case WINE_MSM_PAUSE: > + /* FIXME: send out cc64 0 (turn off sustain pedal) on every channel */ > + paused = TRUE; > + SetEvent(lpMidiStrm->hEvent); > break; > case WINE_MSM_HEADER: > /* sets initial tick count for first MIDIHDR */ > @@ -1114,6 +1128,10 @@ static BOOL MMSYSTEM_MidiStream_MessageHandler(WINE_MIDIStream* lpMidiStrm, LPWI > FIXME("Unknown message %d\n", msg->message); > break; > } > + if (paused) { > + GetMessageA(msg, 0, 0, 0); > + goto still_paused; > + } Please stop abusing goto, write a proper loop instead. -- Alexandre Julliard julliard(a)winehq.org

3 4

Re: [PATCH 2/2] urlmon: Added more mk: combining tests
by Marvin 09 Feb '12

09 Feb '12

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=16890 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH 4/4] mmdevapi/tests: Check GetService's output parameter.
by Marvin 09 Feb '12

09 Feb '12

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=16888 Your paranoid android. === WVISTAADM (32 bit render) === render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 === W2K8SE (32 bit render) === render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 === W7PRO (32 bit render) === render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 === W7PROX64 (32 bit render) === render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 === TEST64_W7SP1 (32 bit render) === render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 === W7PROX64 (64 bit render) === render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 === TEST64_W7SP1 (64 bit render) === render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007 render.c:990: Test failed: ReleaseBuffer failed: 80070057 render.c:1013: Test failed: Position 0 vs. last 0 render.c:1076: Test failed: Reset failed: 8889000b render.c:1080: Test failed: Reset on a resetted stream returns 8889000b render.c:1089: Test failed: GetBuffer failed: 88890007 render.c:1094: Test failed: ReleaseBuffer failed: 80070057 render.c:1115: Test failed: Position 0 vs. last 0 render.c:1147: Test failed: Reset failed: 8889000b render.c:1154: Test failed: Reset on a resetted stream returns 8889000b render.c:1162: Test failed: GetBuffer failed: 88890007

1 0

Re: [PATCH 3/4] mmdevapi/tests: Perform renderer padding & position tests.
by Marvin 09 Feb '12

09 Feb '12

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=16887 Your paranoid android. === WVISTAADM (32 bit render) === render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 === W2K8SE (32 bit render) === render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 === W7PRO (32 bit render) === render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 === W7PROX64 (32 bit render) === render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 === TEST64_W7SP1 (32 bit render) === render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 === W7PROX64 (64 bit render) === render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 === TEST64_W7SP1 (64 bit render) === render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007

1 0

Re: winecfg: Center main window on the screen.
by Dmitry Timoshkov 09 Feb '12

09 Feb '12

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > For bug 21645. What is this pending for? -- Dmitry.

1 0

libgcrypt thread safety
by Adam Martinson 08 Feb '12

08 Feb '12

I've been looking into bug 27036 <http://bugs.winehq.org/show_bug.cgi?id=27036> , and it's due to the lack of thread safety by default in libgcrypt (in this case via libgnutls in secur32.dll). To be thread safe, libgcrypt requires a call to gcry_control(GCRYCTL_SET_THREAD_CBS) before any libgcrypt initialization is done. However, libgcrypt is used by a lot of different libs, one of which is being used by some other dll that's loading before secur32.dll. My question is, is it acceptable to do the gcry_control() call in ntdll's DllMain()? The alternative seems to be tracking down every lib used by wine that uses libgcrypt and doing it in each of those dlls. What's the best way to handle this?

3 2

Re: Profiing windows apps
by Ralph Little 08 Feb '12

08 Feb '12

Hi, > Also please attach a full +ddraw log to the bug report. If it is too big > compress it. bzip2 should do a pretty decent job, if all fails try lrzip. OK, done! > If the testing doesn't reveal anything, look out for IDirectDraw::GetCaps > calls in the logs or IDirect3Dx::EnumZBufferFormats. IDirectDraw::GetCaps > returns a DDCAPS structure which has dwZBufferBitDepths containing some flags > for z buffer bit depths. EnumZBufferFormats calls a callback multiple times > with available DDPIXELFORMAT structures. The application may not like some > flags we set there. The Sims calls EnumDevices and I presume calls EnumZBufferFormats within the callback for each device: trace:ddraw:d3d3_EnumDevices Enumerating WineD3D D3DDevice interface. trace:ddraw:d3d3_EnumZBufferFormats iface 0x13d04c, device_iid {a4665c60-2673-11cf-a31a-00aa00b93356}, callback 0x586a7d, context 0xabc198. trace:ddraw:d3d7_EnumZBufferFormats iface 0x13d048, device_iid {a4665c60-2673-11cf-a31a-00aa00b93356}, callback 0x586a7d, context 0xabc198. trace:ddraw:d3d7_EnumZBufferFormats Asked for SW device. trace:ddraw:PixelFormat_WineD3DtoDD Converting wined3d format 0x52 to DDRAW. trace:ddraw:PixelFormat_WineD3DtoDD Returning: ( DDPF_ZBUFFER , Z bits : 16) trace:ddraw:d3d7_EnumZBufferFormats Enumerating wined3d format 0x52. trace:ddraw:d3d7_EnumZBufferFormats Format enumeration cancelled by application. trace:ddraw:d3d3_EnumDevices Enumerating HAL Direct3D device. trace:ddraw:d3d3_EnumZBufferFormats iface 0x13d04c, device_iid {84e63de0-46aa-11cf-816f-0000c020156e}, callback 0x586a7d, context 0xabc198. trace:ddraw:d3d7_EnumZBufferFormats iface 0x13d048, device_iid {84e63de0-46aa-11cf-816f-0000c020156e}, callback 0x586a7d, context 0xabc198. trace:ddraw:d3d7_EnumZBufferFormats Asked for HAL device. trace:ddraw:PixelFormat_WineD3DtoDD Converting wined3d format 0x52 to DDRAW. trace:ddraw:PixelFormat_WineD3DtoDD Returning: ( DDPF_ZBUFFER , Z bits : 16) trace:ddraw:d3d7_EnumZBufferFormats Enumerating wined3d format 0x52. trace:ddraw:d3d7_EnumZBufferFormats Format enumeration cancelled by application. trace:ddraw:d3d3_EnumDevices End of enumeration. I don't know if this looks sensible, though. I see from the code that there are a lot of "gotchas" (both in d3d7_EnumZBufferFormats and d3d3_EnumDevices) for a number of games expecting things to happen in specific sequences and containing specific responses. I wonder if the Sims is going to turn out to be another. Cheers, Ralph

1 0

OpenGL child windows (SketchUp)
by Brian Bloniarz 08 Feb '12

08 Feb '12

Hi all, I could use a little help fixing a window lag and screen corruption issue in SketchUp: http://bugs.winehq.org/show_bug.cgi?id=25912 Long story short, I think the implementation of OpenGL child rendering needs a small update. As a reminder, this is how an OpenGL child window is setup: static BOOL set_win_format( HWND hwnd, XID fbconfig_id ) { gl_drawable = XCreateWindow(...); // offscreen window XCompositeRedirectWindow(..., gl_drawable, CompositeRedirectManual); } Here XComposite extension is render into an offscreen window. When it's time to display, the contents of that window are copied into the visible onscreen parent window (physDev is the onscreen window, gl_drawable is the offscreen window): BOOL X11DRV_SwapBuffers(PHYSDEV dev) { ... glXSwapBuffers(gdi_display, gl_drawable); ... /* The GL drawable may be lagged behind if we don't flush first, so * flush the display make sure we copy up-to-date data */ XFlush(gdi_display); XCopyArea(gdi_display, gl_drawable, physDev...); } The XFlush() is the problem; the buffer swap must happen before the copy, and accelerated renderers wouldn't guarantee to do that on an X queue flush. So how do you wait for a buffer swap? I wrote a test program, can you say "undefined behavior"? I tested on a few drivers: 1) ATI fglrx binary driver: glXSwapBuffers is instantaneous, existing code works fine. 2) NVidia binary driver: glXSwapBuffers is asynchronous, neither XFlush() nor XSync() is enough. Calling glXWaitGL or glFinish works. 3) Mesa DRI driver (Intel i915): glXSwapBuffers is asynchronous. None of XFlush/XSync/glXWaitX/glXWaitGL is enough. glFinish works. 4) r600g (Open Source accelerated ATI) driver: glXSwapBuffers is asynchronous. None of the flush calls wait for it (XFlush/XSync/glXWaitGL/glXWaitX/glFinish). The last one is the tricky part -- this driver is also based on the DRI, so I'm guessing it may appear on other open-source accelerated drivers (looking at http://www.x.org/releases/current/doc/dri2proto/dri2proto.txt suggests that this is new behavior as of 1.99.2) So how to come up with a common fix? I could think of 3 possibilities: 1) Use the GLX_OML_sync_control extension, it has an explicit call to wait for a buffer swap. Not supported by NV or fglrx, but we could fallback to glXWaitGL on those drivers. Probably simplest. 2) Use the X Damage extension, wait for an XDamageNotify event before copying. This should work everywhere, all drivers probably implement damage so that compositing window managers can use it. 3) Talk to the DRI people, maybe glXWaitGL should't return when there's a pending a buffer swap. The GLX spec seems to say it should wait, but it's a grey area and the Composite extension was designed much later. Not a quick fix. Any ideas or thoughts? If I hear nothing, I can code up a patch that does (1), but it'd be great to hear from some people who know this area well. Thanks, Brian Bloniarz

3 2

Re: gdi32: Consider whether the logical font face is vertical when selecting.
by Marvin 08 Feb '12

08 Feb '12

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=16876 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: winecfg: Center main window on the screen.
by Vitaliy Margolen 08 Feb '12

08 Feb '12

Please don't! I want my window manager decide based on how I configured it where to position new windows. And not every program open in the middle of the screen just because it things it's the most important thing on my screen. Vitaliy.

4 3

winmm: TRACE unhandled messages
by Joerg-Cyril.Hoehle＠t-systems.com 08 Feb '12

08 Feb '12

Andrew, it's good that you log these now. I had a question in mind since your winmm rewrite: Your rewrite no more maps WOD_XYZ* messages to waveOut functions. I believe that it is possible that an old app entirely uses the generic SendDriverMessage function (esp. in the mciavi/msvfw area, cf. ICSendMessage) instead of the specific wave/midi* ones. Can you be sure that this is not supported by native, esp. w9x? If Wine does not map these, all we'll get to "hear" in AppDB is that attentive people miss sound or music that they remember listening to 10 years ago on native. Regards, Jörg Höhle

2 1

Re: [1/2] user32: Add a bunch of RealChildWindowFromPoint tests.
by Alexandre Julliard 08 Feb '12

08 Feb '12

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > win.c:6753: Test failed: FlashWindowEx succeeded > win.c:6764: Test failed: FlashWindowEx failed with -559038737 > > are intermittent, and have nothing to do with these tests. Maybe not directly, but the failures are clearly caused by your change, and they look pretty bad on the test results. Please fix that. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: po: Remove untranslated English strings from the Romanian translation
by Michael Stefaniuc 07 Feb '12

07 Feb '12

Hello Frédéric, the patch is wrong. Frédéric Delanoy wrote: > --- > po/ro.po | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/po/ro.po b/po/ro.po > index a0912c2..c9375c4 100644 > --- a/po/ro.po > +++ b/po/ro.po > @@ -11803,11 +11803,11 @@ msgstr "Bază" > > #: regedit.rc:282 > msgid "Hexadecimal" > -msgstr "Hexadecimal" > +msgstr "" > > #: regedit.rc:283 > msgid "Decimal" > -msgstr "Decimal" > +msgstr "" Those aren't untranslated but the Romanian words match the English ones. > #: regedit.rc:290 > msgid "Edit Binary" > @@ -13243,7 +13243,7 @@ msgstr "Afișează opțiunile a&vansate" > > #: winecfg.rc:240 > msgid "De&vice:" > -msgstr "De&vice:" > +msgstr "" > > #: winecfg.rc:242 > msgid "Bro&wse..." bye michael

3 3

Re: po: Fix some trailing ellipses errors in Catalan translation
by Alex Henrie 07 Feb '12

07 Feb '12

#: ieframe.rc:68 winhlp32.rc:66 msgid "Print..." -msgstr "Imprimeix" +msgstr "Imprimeix..." I intentionally left the ellipse off of the word "Imprimeix" in Internet Explorer so that the text would fit on the toolbar button. Any suggestions? -Alex

3 2

Re: po: Update finnish locales
by Lauri Kenttä 07 Feb '12

07 Feb '12

On 2012-02-06 23:00, Olli-Pekka Wallin wrote: > +msgstr "KB/s" > ... > +msgstr "Yksi sivua" > ... > +msgstr "Wordpad ojelman kÃƒÂ¤ynnistys epÃƒÂ¤onnistui" I'm sorry to say this, but these translations are really bad. I suggest you either have someone check your translations thoroughly before submitting or leave the whole job for others. (I'm already working on it.) The patch is also based on an old revision and changes a msgid. -- Lauri Kenttä

1 0

SourceForge forbids download
by Aidin Gharibnavaz 07 Feb '12

07 Feb '12

Dear Wine developers, SourceForge blocked download for some countries by default, such as Iran. (More detail can be found here<https://sourceforge.net/blog/some-good-news-SourceForge-removes-blanket-blo…> ) So, if it's not illegal to you to let Iranians download your software, please go to the SourceForge's ProjectAdmin, and set the ExportControl option, to let us enjoy the great work of yours. Thanks.

3 2

Re: po: Update finnish locales
by Francois Gouget 07 Feb '12

07 Feb '12

On Mon, 6 Feb 2012, Olli-Pekka Wallin wrote: > po: Update finnish locales > > #: appwiz.rc:49 > msgid "Installing..." > -msgstr "" > +msgstr "Asennetaan.." It looks like there's a missing dot here. But thanks a lot for the patch. Feel free to tackle any other issue in: http://fgouget.free.fr/wine-po/fi-errors.html Also don't hesitate to let me know about false positives so I can silence them. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

1 0

Re: ID3DXBaseEffect::SetValue
by luis.busquets＠ilidium.com 07 Feb '12

07 Feb '12

For the textures point, it is judt that the implemenyation is just the change of one pointer ----- Reply message ----- De: "Rico Schüller" <kgbricola(a)web.de> Para: "Luis Carlos Busquets Pérez" <luis.busquets(a)ilidium.com> CC: <wine-devel(a)winehq.org> Asunto: ID3DXBaseEffect::SetValue Fecha: mar., feb. 7, 2012 10:03 Am 07.02.2012 06:02, schrieb Luis Carlos Busquets Pérez: > 1. If the functions returns E_FAIL for a sample then > test_effect.c:1917: Test failed: Got result 80004005, expected 0 (D3D_OK) I'll have a look at those. > 2. For D3DXPT_VERTEXSHADER and D3DXPT_PIXELSHADER replying with E_FAIL > avoids > test_effect.c:1812: Test failed: Got result 0, expected 0x80004005 > (E_FAIL) > test_effect.c:1814: Test failed: Got result 0, expected 0x80004005 > (E_FAIL) > test_effect.c:1881: Test failed: Got result 0, expected 0x80004005 > (E_FAIL) Sure, that's not implemented, yet. You should get a FIXME for those cases. > 3. If the function just sets the memory with the data for a bool then > test_effect.c:969: Test failed: Got 46, expected 1 In this case it may be required, that the input has to be converted before it is put into data. A solution would be to use Set*Array to set the values. In general, I think it's also fine to convert the values in get_int() and get_float() in the case of D3DXPT_BOOL with get_bool(data) - I'll send a patch for this. But I also think a test to show, that the value is converted while it is set, is still the way to go. Well SetValue isn't complete, yet. > 5. Concerning textures, the compiler does not accept arrays of textures, > so any change to a texture type should be just a change of the pointer > to the texture at param->data (or NULL) I didn't got the point. Only that it is impossible to declare texture arrays in effect files, which I could confirm. Do you mean, that the HeapAlloc for the additional pointer for textures should be avoided? This could be done, it just needs separate handling for textures. As it is now, it mostly uses the same handling together with the shaders (e.g. IUnknown_Release(*(IUnknown **)param->data)). Cheers Rico

1 0

Re: ID3DXBaseEffect::SetValue
by luis.busquets＠ilidium.com 07 Feb '12

07 Feb '12

Concerning the vertrd a picel shadet, the truth is that sin e very soon in the history of d3dx the functions ID3DXEffect::SetPixelShader and ID3DXEffect::DetVertexShader wete removed. So actually it does not seem that you can change them. Because of that, the MS implementation replies with D3DERR_INVALIDCALL and their implementation in SetValue is straight. ----- Reply message ----- De: "Rico Schüller" <kgbricola(a)web.de> Para: "Luis Carlos Busquets Pérez" <luis.busquets(a)ilidium.com> CC: <wine-devel(a)winehq.org> Asunto: ID3DXBaseEffect::SetValue Fecha: mar., feb. 7, 2012 10:03 Am 07.02.2012 06:02, schrieb Luis Carlos Busquets Pérez: > 1. If the functions returns E_FAIL for a sample then > test_effect.c:1917: Test failed: Got result 80004005, expected 0 (D3D_OK) I'll have a look at those. > 2. For D3DXPT_VERTEXSHADER and D3DXPT_PIXELSHADER replying with E_FAIL > avoids > test_effect.c:1812: Test failed: Got result 0, expected 0x80004005 > (E_FAIL) > test_effect.c:1814: Test failed: Got result 0, expected 0x80004005 > (E_FAIL) > test_effect.c:1881: Test failed: Got result 0, expected 0x80004005 > (E_FAIL) Sure, that's not implemented, yet. You should get a FIXME for those cases. > 3. If the function just sets the memory with the data for a bool then > test_effect.c:969: Test failed: Got 46, expected 1 In this case it may be required, that the input has to be converted before it is put into data. A solution would be to use Set*Array to set the values. In general, I think it's also fine to convert the values in get_int() and get_float() in the case of D3DXPT_BOOL with get_bool(data) - I'll send a patch for this. But I also think a test to show, that the value is converted while it is set, is still the way to go. Well SetValue isn't complete, yet. > 5. Concerning textures, the compiler does not accept arrays of textures, > so any change to a texture type should be just a change of the pointer > to the texture at param->data (or NULL) I didn't got the point. Only that it is impossible to declare texture arrays in effect files, which I could confirm. Do you mean, that the HeapAlloc for the additional pointer for textures should be avoided? This could be done, it just needs separate handling for textures. As it is now, it mostly uses the same handling together with the shaders (e.g. IUnknown_Release(*(IUnknown **)param->data)). Cheers Rico

1 0

Re: comctl32: Remove an obsolete resource attribute.
by Marvin 07 Feb '12

07 Feb '12

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=16849 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

2 1

ID3DXBaseEffect::SetValue
by Luis Carlos Busquets Pérez 07 Feb '12

07 Feb '12

The functin returns D3DERR_INVALIDCALL whenever it is tried on a parameter with elements. A check should be included. Luis

2 3

Re: user32: Only call SetWindowPos() in UpdateLayeredWindowIndirect() if needed. (try 5)
by Dmitry Timoshkov 07 Feb '12

07 Feb '12

Adam Martinson <adam.r.martinson(a)gmail.com> wrote: > (We should not be calling SetWindowPos() in UpdateLayeredWindowIndirect() at all.) > Fixes bug 26924. Much better now, thanks. -- Dmitry.

1 0

Re: user32: Fix a couple of typos.
by Marvin 07 Feb '12

07 Feb '12

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=16847 Your paranoid android. === TEST64_W7SP1 (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === TEST64_W7SP1 (64 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737

1 0

Re: user32: Only call SetWindowPos() in UpdateLayeredWindowIndirect() if needed. (try 5)
by Marvin 07 Feb '12

07 Feb '12

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=16845 Your paranoid android. === WVISTAADM (32 bit msg) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation === TEST64_W7SP1 (32 bit win) === win.c:6825: Test failed: FlashWindowEx succeeded win.c:6836: Test failed: FlashWindowEx failed with -559038737 === TEST64_W7SP1 (64 bit win) === win.c:6825: Test failed: FlashWindowEx succeeded win.c:6836: Test failed: FlashWindowEx failed with -559038737

1 0

ID3DXEffect::SetValue
by Luis Carlos Busquets Pérez 06 Feb '12

06 Feb '12

The current implementation includes a check on param->bytes >= bytes specifically: if (data && param->bytes >= bytes) { ... } So if bytes<param->bytes returns D3DERR_INVALIDCALL. However, the MS version does not act that way: If the parameter is shorter than the length of the data, then the data that fits in the parameter is put and returns D3D_OK Therefore, the check of the size should be eliminated and in memcpy instead of referring to bytes, it should refer to min(bytes, param->bytes) Luis

3 2

Re: (try2) quartz: AMFilterData_ParseFilterData returns a pointer to a pointer to filter data
by Marvin 06 Feb '12

06 Feb '12

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=16838 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: [2/2] user32: RealChildWindowFromPoint should skip invisible windows.
by Marvin 06 Feb '12

06 Feb '12

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=16834 Your paranoid android. === W2KPROSP4 (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === WXPPROSP3 (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === W2K3R2SESP2 (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === WVISTAADM (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === W2K8SE (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === W7PRO (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === W7PROX64 (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === TEST64_W7SP1 (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === W7PROX64 (64 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === TEST64_W7SP1 (64 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737

1 0

Re: [1/2] user32: Add a bunch of RealChildWindowFromPoint tests.
by Marvin 06 Feb '12

06 Feb '12

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=16833 Your paranoid android. === W2KPROSP4 (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === WXPPROSP3 (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === W2K3R2SESP2 (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === WVISTAADM (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === W2K8SE (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === W7PRO (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === W7PROX64 (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === TEST64_W7SP1 (32 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === W7PROX64 (64 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737 === TEST64_W7SP1 (64 bit win) === win.c:6753: Test failed: FlashWindowEx succeeded win.c:6764: Test failed: FlashWindowEx failed with -559038737

1 0

Re: user32: Only call SetWindowPos() in UpdateLayeredWindowIndirect() if needed. (try 4)
by Dmitry Timoshkov 06 Feb '12

06 Feb '12

Adam Martinson <adam.r.martinson(a)gmail.com> wrote: > (We should not be calling SetWindowPos() in UpdateLayeredWindowIndirect() at all.) > Fixes bug 26924. That's not what I was asking about (a bunch of message tests with various parameters). Your current version essentially tests nothing. You should call UpdateLayeredWindowIndirect with a buch of differnt parameters, and check what message sequence they produce and how they change window state. See dlls/user32/tests/msg.c how to create a message test. -- Dmitry.

2 2

Re: [PATCH] [Kernel32]: added a couple of tests about console creation through CreateFile, and fix some corner cases
by Marvin 05 Feb '12

05 Feb '12

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=16816 Your paranoid android. === W7PRO (32 bit console) === console.c:1173: Test failed: Expected CreateFileW to succeed for index 0 console.c:1173: Test failed: Expected CreateFileW to succeed for index 2 console.c:1173: Test failed: Expected CreateFileW to succeed for index 7 console.c:1173: Test failed: Expected CreateFileW to succeed for index 9 === W7PROX64 (32 bit console) === console.c:1173: Test failed: Expected CreateFileW to succeed for index 0 console.c:1173: Test failed: Expected CreateFileW to succeed for index 2 console.c:1173: Test failed: Expected CreateFileW to succeed for index 7 console.c:1173: Test failed: Expected CreateFileW to succeed for index 9 === TEST64_W7SP1 (32 bit console) === console.c:1173: Test failed: Expected CreateFileW to succeed for index 0 console.c:1173: Test failed: Expected CreateFileW to succeed for index 2 console.c:1173: Test failed: Expected CreateFileW to succeed for index 7 console.c:1173: Test failed: Expected CreateFileW to succeed for index 9 === W7PROX64 (64 bit console) === console.c:1173: Test failed: Expected CreateFileW to succeed for index 0 console.c:1173: Test failed: Expected CreateFileW to succeed for index 2 console.c:1173: Test failed: Expected CreateFileW to succeed for index 7 console.c:1173: Test failed: Expected CreateFileW to succeed for index 9 === TEST64_W7SP1 (64 bit console) === console.c:1173: Test failed: Expected CreateFileW to succeed for index 0 console.c:1173: Test failed: Expected CreateFileW to succeed for index 2 console.c:1173: Test failed: Expected CreateFileW to succeed for index 7 console.c:1173: Test failed: Expected CreateFileW to succeed for index 9

1 0

Skype support status
by Artem S. Tashkinov 05 Feb '12

05 Feb '12

Hello everyone, It's not a secret that Skype was bought by Microsoft a few months back and that there's a great chance that its native Linux version will get even fewer updates in the future because I doubt that Microsoft is even remotely endorse the existence of Linux and open source, thus Skype may easily become a "burden" they don't want to bear. Another quite important fact to consider is that the Linux version of Skype has fewer features than its Windows counterpart and that there are multiple issues regarding Skype, like the absence of a native 64bit version and a number of quite serious bugs (crashes, exclusive sound card access preventing other applications from working, 100% CPU usage after hibernation/sleep). Currently under Wine 1.4-rc2 I wasn't able to even run any version of Skype even in a simple chat mode. Very old versions of Skype cannot get online, more recent ones crash when trying to get online, or crash when you just start them, the last few releases (5.5-5.8) use MSHTML as their logon form and the way it behaves under Wine you cannot make use of it. I know that Codeweavers resources are very limited and that your priorities and the priority of other programmers hacking Wine are mostly concerned about getting proper support for core Windows applications like MS Office, Adobe products and other crucial programs, but I think it would be wise to make even basic Skype functionality work, because there are operating systems other than Windows, MacOS (iOS), and Linux (Android) and many people are left without one of the most popular messengers in the world. In short this message is a cry for getting Skype to work _at all_, because now it's totally unusable. With respect, Artem S. Tashkinov

1 0

Re: kernel32: Add LCMapStringEx implementation and test it reusing tests from LCMapStringW (try 2)
by Dmitry Timoshkov 05 Feb '12

05 Feb '12

André Hentschel <nerv(a)dawncrow.de> wrote: > +@ stdcall LCMapStringEx(long long wstr long ptr long ptr ptr long) ... > +INT WINAPI LCMapStringEx(LPCWSTR name, DWORD flags, LPCWSTR src, INT srclen, LPWSTR dst, INT dstlen, > + LPNLSVERSIONINFO version, LPVOID reserved, LPARAM lparam) .spec file entry doesn't match the implementation. -- Dmitry.

1 0

Re: kernel32: Add LCMapStringEx implementation and test it reusing tests from LCMapStringW
by Dmitry Timoshkov 05 Feb '12

05 Feb '12

André Hentschel <nerv(a)dawncrow.de> wrote: > +/* Locale name special values */ > +#define LOCALE_NAME_INVARIANT L"" > +#define LOCALE_NAME_MAX_LENGTH 85 > +#define LOCALE_NAME_SYSTEM_DEFAULT L"!sys-default-locale" > +#define LOCALE_NAME_USER_DEFAULT NULL Have a look how unicode constants are defined in other header files, the above version can't work in Wine. Also just duplicating LCMapString tests is not a very good idea, it would be better to find a way to share the test data. -- Dmitry.

2 2

Re: ntdll: Remove dead code
by Marcus Meissner 05 Feb '12

05 Feb '12

On Sun, Feb 05, 2012 at 03:59:44PM +0100, André Hentschel wrote: > --- > dlls/ntdll/signal_x86_64.c | 4 ---- > 1 files changed, 0 insertions(+), 4 deletions(-) > > diff --git a/dlls/ntdll/signal_x86_64.c b/dlls/ntdll/signal_x86_64.c > index 0fc53c7..e9cefb8 100644 > --- a/dlls/ntdll/signal_x86_64.c > +++ b/dlls/ntdll/signal_x86_64.c > @@ -2629,10 +2629,6 @@ static BOOL is_inside_epilog( BYTE *pc ) > > for (;;) > { > - BYTE rex = 0; > - > - if ((*pc & 0xf0) == 0x40) rex = *pc++ & 0x0f; /* rex prefix */ > - This is not OK I think. The pc++ side effect is removed ... and is not handled in the switch() below. Ciao, Marcus

1 0

Re: user32: Only call SetWindowPos() in UpdateLayeredWindowIndirect() if needed. (try 3)
by Dmitry Timoshkov 04 Feb '12

04 Feb '12

Adam Martinson <adam.r.martinson(a)gmail.com> wrote: > +static HDC (WINAPI *pGetWindowDC)(HWND hWnd); > +static int (WINAPI *pReleaseDC)(HWND hWnd,HDC hDC); There is no need to dynamically import these APIs, they are always available. > +static DWORD WINAPI test_ulw_thread(void *data) > +{ > + struct test_ulw_tdata *tdata = data; > + DWORD res; > + > + res = WaitForSingleObject( tdata->hSem, 1000 ); > + ok( !res, "wait for semaphore failed: %08x\n", res ); > + if (!res) > + { > + HDC hdc = pGetWindowDC( tdata->hwnd ); > + res = pUpdateLayeredWindow( tdata->hwnd, 0, NULL, tdata->psz, hdc, tdata->ppt, 0, NULL, ULW_OPAQUE ); > + ok( res, "UpdateLayeredWindow failed: %08x\n", GetLastError() ); > + pReleaseDC( tdata->hwnd, hdc ); > + } > + > + return res; > +} I don't see how this is supposed to test what you presumably are trying to fix. A bunch of message tests that calls UpdateLayeredWindow with various flags and parameters and compares window extents before and after the call would be more convincing IMO. -- Dmitry.

1 0

re: Wine automated testing update
by Dan Kegel 03 Feb '12

03 Feb '12

Jeremy wrote: > the VMWare folks are not willing to provide a permanent license for VMWare to us. > > So, we've shifted gears, and are exploring whether something like qemu + > kvm would be a sufficient alternate. What's the plan for automated MacOSX testing? I hear 10.7 supports running in a VM...

3 2

Re: [2/3] msi: Use the return value of IXMLDOMNode_get_text (clang).
by Juan Lang 03 Feb '12

03 Feb '12

Hi Hans, hr = IXMLDOMNode_get_text( node, &s ); IXMLDOMNode_Release( node ); - if (!strcmpW( s, product_code )) r = ERROR_SUCCESS; - SysFreeString(s); + if (hr == S_OK && !strcmpW( s, product_code )) r = ERROR_SUCCESS; + SysFreeString( s ); Is it really safe to free s if IXMLDOMNode_get_text failed? --Juan

1 0

Re: quartz: AMFilterData_ParseFilterData returns a pointer to a pointer to filter data
by Dmitry Timoshkov 03 Feb '12

03 Feb '12

Aric Stewart <aric(a)codeweavers.com> wrote: > - REGFILTER2 *prf2; > + static REGFILTER2 *prf2; What's the point of this change? -- Dmitry.

3 2

Re: gdi32/tests: Add tests for default font selection.
by Marvin 03 Feb '12

03 Feb '12

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=16799 Your paranoid android. === W2KPROSP4 (32 bit font) === font.c:4145: Test failed: expected vertical face, got System === WXPPROSP3 (32 bit font) === font.c:4145: Test failed: expected vertical face, got System === W2K3R2SESP2 (32 bit font) === font.c:4145: Test failed: expected vertical face, got System

1 0

Profiing windows apps
by Ralph Little 02 Feb '12

02 Feb '12

Hi, I'm looking at bug #9672 again in the The Sims. The app crashes early on during initialisation in DirectDraw. The problem occurs after CreateSurface returns an error, since it would appear that the DDSURFACEDESC passed into the call is foobar. This would lead me to conclude that something on the lead up to that call is precipitating that rogue call. I have a legal Windows XP and I wish to trace the calls leading up to this point with real Windows/DirectX to compare with what is happening to Wine so that I can assess what is upsetting the application, since I can't see anything in the Wine trace prior to that that looks suspicious. Does anyone have any experience with tracing apps in real Windows in the context of Wine development? Should I use a profiler or is there a simpler method? Cheers, Ralph

3 5

Re: [PATCH 1/2] ddraw/tests: Add some IDirect3DViewport interface tests (try 2)
by Henri Verbeet 02 Feb '12

02 Feb '12

On 2 February 2012 14:57, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +static ULONG get_refcount(IUnknown *test_iface) > +{ > + IUnknown_AddRef(test_iface); > + return IUnknown_Release(test_iface); > +} ... > + LONG ref; ... > + ref = get_refcount((IUnknown *)d3d); > + ok(ref == 2, "IDirect3D refcount is %d\n", ref); Well yeah, get_refcount() returns ULONG now, but you should fix the type of "ref" and the format strings as well.

2 1

Re: [PATCH 1/2] ddraw/tests: Add some IDirect3DViewport interface tests (try 2)
by Marvin 02 Feb '12

02 Feb '12

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=16784 Your paranoid android. === WNT4WSSP6 (32 bit ddraw2) === ddraw2.c:421: Test failed: Got unexpected count 3. ddraw2.c:430: Test failed: Got unexpected clip rect {14, 33, 646, 237}, expected {14, 33, 646, 486}.

1 0

Re: [PATCH] ddraw/tests: Add some IDirect3DViewport interface tests
by Henri Verbeet 02 Feb '12

02 Feb '12

On 2 February 2012 12:56, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +static LONG get_refcount(IUnknown *test_iface) > +{ > + IUnknown_AddRef(test_iface); > + return IUnknown_Release(test_iface); > +} Release is supposed to return a ULONG. > + hr = IDirect3DViewport_QueryInterface(viewport, &IID_IDirect3DViewport2, (void **)&viewport2); > + ok(SUCCEEDED(hr) || broken(hr == E_FAIL), "Failed to QI IDirect3DViewport2, hr %#x.\n", hr); I think this would make the test fail on old versions of ddraw that simply don't know about IDirect3DViewport2. > + hr = IDirect3DViewport3_QueryInterface(viewport2, &IID_IUnknown, (void **)&unknown); This looks like it was intended to be called on viewport3. > + /* FIXME: This test suggests that IDirect3D, IDirect3D2 and IDirect3D3 are linked > + * to IDirectDraw. However, they are linked to whatever interface is used to QI the > + * first IDirect3D? interface. If DDraw1 is replaced with DDraw4 here the tests break */ Makes sense. I'm not sure it really should be part of this patch though.

1 0

please test native behaviour with (un)pluggable audio devices
by Joerg-Cyril.Hoehle＠t-systems.com 02 Feb '12

02 Feb '12

Hi, please run the mmdevapi render and capture testsuites while unplugging (or deactivating) audio HW. I'd like to hear how native behaves prior to implementing error handling in Wine's drivers. One way to run the testsuites is as follows: 1. Download winetest-xyz.exe from test.winehq; 2. winetest-xyz.exe /x will extract all exes into some directory; 3. set WINETEST_DEBUG=2 4. set WINETEST_INTERACTIVE=1 (not used yet, but soon) 5. mmdevapi_test.exe render 6. mmdevapi_test.exe capture Esp., I'd like to know whether ReleaseBuffer ever signals an error or if it's always the job of GetBuffer to do so. Then I'd like to know whether primitives such as GetBufferSize fail too when the device is unplugged. Note that the testsuite may crash because it doesn't expect loosing devices mid-way. Thank you, Jörg Höhle

1 0

Re: dinput: Support INFINITE as number of effect iterations (try 2)
by Vitaliy Margolen 02 Feb '12

02 Feb '12

On 01/28/2012 05:56 PM, Marcel Hasler wrote: > According to the DirectX reference, IDirectInputEffect::Start accepts > INFINITE (aka -1) for the number of iterations. However, passing -1 to > Linux via input_event results in no effect being played at all. This > patch sets the number of iterations to the maximum signed value > allowed if INFINITE is passed. > > This fixes bug 29712. > > This patch supersedes patch 83233. It does the same thing but adds a > comment and should be easier to understand. In general looks good. Would be nice to point out that linux/input.h says that any durations should not exceed 0x7fff as a maximum value. Please don't make code "easier to read" by adding needless if / else. Your first patch was fine. Vitaliy.

2 5

Re: [PATCH] winealsa: snd_card_get_name uses strdup (Valgrind).
by Christian Costa 01 Feb '12

01 Feb '12

In that case you don't need the if (!err) condition to free the buffer otherwise you leak the string return by strdup. Christian 2012/2/1 Lauri Kenttä <lauri.kentta(a)gmail.com> > --- > dlls/winealsa.drv/mmdevdrv.c | 10 +++++++--- > 1 files changed, 7 insertions(+), 3 deletions(-) > > diff --git a/dlls/winealsa.drv/mmdevdrv.c b/dlls/winealsa.drv/mmdevdrv.c > index 0bedcc5..e434038 100644 > --- a/dlls/winealsa.drv/mmdevdrv.c > +++ b/dlls/winealsa.drv/mmdevdrv.c > @@ -363,7 +363,7 @@ static HRESULT alsa_enum_devices(EDataFlow flow, WCHAR > **ids, char **keys, > for(err = snd_card_next(&card); card != -1 && err >= 0; > err = snd_card_next(&card)){ > char cardpath[64]; > - const char *cardname; > + char *cardname; > WCHAR *cardnameW; > snd_ctl_t *ctl; > DWORD len; > @@ -376,16 +376,18 @@ static HRESULT alsa_enum_devices(EDataFlow flow, > WCHAR **ids, char **keys, > continue; > } > > - if((err = snd_card_get_name(card, (char **)&cardname)) < 0){ > + if((err = snd_card_get_name(card, &cardname)) < 0){ > WARN("Unable to get card name for ALSA device %s: %d (%s)\n", > cardpath, err, snd_strerror(err)); > /* FIXME: Should be localized */ > - cardname = "Unknown soundcard"; > + cardname = strdup("Unknown soundcard"); > } > > len = MultiByteToWideChar(CP_UNIXCP, 0, cardname, -1, NULL, 0); > cardnameW = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); > if(!cardnameW){ > + if(!err) > + free(cardname); > snd_ctl_close(ctl); > return E_OUTOFMEMORY; > } > @@ -394,6 +396,8 @@ static HRESULT alsa_enum_devices(EDataFlow flow, WCHAR > **ids, char **keys, > alsa_get_card_devices(stream, ids, keys, num, ctl, card, > cardnameW); > > HeapFree(GetProcessHeap(), 0, cardnameW); > + if(!err) > + free(cardname); > > snd_ctl_close(ctl); > } > -- > 1.7.9 > > > >

3 2

snd_card_get_name uses strdup (Valgrind).
by Joerg-Cyril.Hoehle＠t-systems.com 01 Feb '12

01 Feb '12

Hi there's a small memory leak in winealsa, tentatively plugged by patches #83353, #83334 and #82900. It would be nice if somebody who feels like struggling with const warnings in gcc would get a fix accepted in git. The dilemma: a literal "foo" is a const char*, free() does not want a const and casts are the root of all evil in C. Thank you, Jörg Höhle

2 1

Re: [PATCH 2/3] winecoreaudio: Implement the lock-free callback design.
by Andrew Eikum 01 Feb '12

01 Feb '12

On Mon, Jan 30, 2012 at 11:37:17AM +0100, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Fixes bug #29657 > While I like the idea of this patch and how you implemented it, I wonder if it's appropriate for code freeze. The main problem in that bug is that the CA driver can deadlock, or release memory out of order. When working on this patch, were you able to identify specifically where the contention is? The idea of the InTransition state was to handle the lock release in mid-call. Can we add a check for that state in the callbacks to solve this problem less intrusively? The first patch seems fine. Andrew

4 6

Updated clang-static-analyzer results (just in time for 1.4 ;))
by Austin English 01 Feb '12

01 Feb '12

Enjoy: http://www.mediafire.com/?aiomfk1cr9bc61y Using: wine-1.4-rc1-34-g01947e0 LLVM commit 683d1e1d449e6e790ff4c0b6340a4bbf144ff919 / git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@149340 91177308-0d34-0410-b5e6-96231b3b80d8 austin@aw21 ~ $ sha1sum scan-build-2012-01-30-1.tar.bz2 8b3b2573c3595c805431b2ab40c6958805f37497 scan-build-2012-01-30-1.tar.bz2 -- -Austin

2 2

Re: quartz: If the MediaSeeking is not implemented all the way up the passthru chain fall back to the filtergraph's clock to find position.
by Alexandre Julliard 31 Jan '12

31 Jan '12

Aric Stewart <aric(a)codeweavers.com> writes: > Resolves bug Bug 25606 > --- > dlls/quartz/filtergraph.c | 6 +++++- > 1 files changed, 5 insertions(+), 1 deletions(-) It doesn't work: ../../../tools/runtest -q -P wine -M quartz.dll -T ../../.. -p quartz_test.exe.so filtergraph.c && touch filtergraph.ok wine: Unhandled page fault on read access to 0x00000000 at address 0x690fff17 (thread 0066), starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x690fff17). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:690fff17 ESP:0032fc70 EBP:0032fcd8 EFLAGS:00010246( R- -- I Z- -P- ) EAX:00000000 EBX:69195fa4 ECX:0032fcb8 EDX:0012cc0c ESI:0032fd28 EDI:0012c878 Stack dump: 0x0032fc70: 0032fd28 69195fa4 0032fcd8 690fb648 0x0032fc80: 0012c878 0000000d 00000000 00000000 0x0032fc90: 0032fd34 0032fd3c 00000000 6877a314 0x0032fca0: 6877418e 0012c7c0 80004001 6877a314 0x0032fcb0: 6877418e 0032fd28 00000000 00000000 0x0032fcc0: 00000001 6877428a 690fb58b 6877a314 Backtrace: =>0 0x690fff17 MediaSeeking_GetCurrentPosition+0x137(iface=0x12c7c8, pCurrent=0x32fd28) [/home/julliard/wine/wine/dlls/quartz/filtergraph.c:2460] in quartz (0x0032fcd8) 1 0x6876ddea func_filtergraph+0x3a9() [/home/julliard/wine/wine/dlls/quartz/tests/filtergraph.c:284] in quartz_test (0x0032fd58) 2 0x68767392 main+0x3a1(argc=0, argv=(nil)) [/home/julliard/wine/wine/dlls/quartz/tests/../../../include/wine/test.h:556] in quartz_test (0x0032fe28) 3 0x68773865 __wine_spec_exe_entry+0x74(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in quartz_test (0x0032fe70) 4 0x6848cc4c call_process_entry+0xb() in kernel32 (0x0032fe88) 5 0x6848ddcf start_process+0x5e(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/kernel32/process.c:1083] in kernel32 (0x0032fec8) 6 0x6837a0b0 call_thread_func_wrapper+0xb() in ntdll (0x0032fed8) 7 0x6837cd9d call_thread_func+0x7c(entry=0x6848dd70, arg=0x7ffdf000, frame=0x32ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2532] in ntdll (0x0032ffa8) 8 0x6837a08e call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 9 0x6835219e start_process+0x1d(kernel_start=0x6848dd70) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2612] in ntdll (0x0032ffe8) 10 0x68028a9d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 0x690fff17 MediaSeeking_GetCurrentPosition+0x137 [/home/julliard/wine/wine/dlls/quartz/filtergraph.c:2460] in quartz: movl 0x0(%eax),%edx 2460 IReferenceClock_GetTime(This->refClock, &time); -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: crypt32: Only accept trailing NULLs in a certificate common name.
by Erich E. Hoover 31 Jan '12

31 Jan '12

On Tue, Jan 31, 2012 at 10:23 AM, Erich E. Hoover <ehoover(a)mines.edu> wrote: > On Tue, Jan 31, 2012 at 10:04 AM, Juan Lang <juan.lang(a)gmail.com> wrote: >> Sorry I didn't spot this earlier. Without this, someone who registers >> a certificate common name with an embedded NULL, like >> "codeweavers.com\0.badguy", could fool crypt32 into accepting it for a >> domain it isn't registered to, codeweavers.com in my example. > > It looks like you've just changed it to allow more than one NULL at > the end... It seems to me that the matching code already handles the > case of an embedded NULL, since it goes through the allowed_len > characters and manually checks each byte (rather than using a routine > like strcmp() which stops at NULLs). Please forgive the "Reply to all" fail. Erich Hoover ehoover(a)mines.edu

2 3

Warning report for wine-1.4-rc1
by Jerome Leclanche 31 Jan '12

31 Jan '12

Some new warnings. Inlining it instead of attaching it this time, I hope that's ok. ========== 32-bit ========== ccache gcc -msse4 -O3 -Wall -m32 -c -I../../../tools/wrc -I. -I../../../include -I../../include -D__WINESRC__ -DINCLUDEDIR="\"/usr/include/wine\"" -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -fno-omit-frame-pointer -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o newstruc.o ../../../tools/wrc/newstruc.c ccache gcc -msse4 -O3 -Wall -m32 -c -I../../../tools/wrc -I. -I../../../include -I../../include -D__WINESRC__ -DINCLUDEDIR="\"/usr/include/wine\"" -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -fno-omit-frame-pointer -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o po.o ../../../tools/wrc/po.c ../../../tools/wrc/po.c:127:12: warning: ‘string_has_context’ defined but not used [-Wunused-function] ========== 64-bit ========== ccache gcc -msse4 -O3 -Wall -c -I../../../tools/wrc -I. -I../../../include -I../../include -D__WINESRC__ -DINCLUDEDIR="\"/usr/include/wine\"" -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o newstruc.o ../../../tools/wrc/newstruc.c ccache gcc -msse4 -O3 -Wall -c -I../../../tools/wrc -I. -I../../../include -I../../include -D__WINESRC__ -DINCLUDEDIR="\"/usr/include/wine\"" -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o po.o ../../../tools/wrc/po.c ../../../tools/wrc/po.c:127:12: warning: ‘string_has_context’ defined but not used [-Wunused-function] -- ccache gcc -msse4 -O3 -Wall -c -I../../../dlls/dbghelp -I. -I../../../include -I../../include -D__WINESRC__ -D_IMAGEHLP_SOURCE_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o cpu_x86_64.o ../../../dlls/dbghelp/cpu_x86_64.c ../../../dlls/dbghelp/cpu_x86_64.c: In function ‘is_inside_epilog’: ../../../dlls/dbghelp/cpu_x86_64.c:341:14: warning: variable ‘rex’ set but not used [-Wunused-but-set-variable] -- ccache gcc -msse4 -O3 -Wall -c -I../../../dlls/ntdll -I. -I../../../include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o signal_x86_64.o ../../../dlls/ntdll/signal_x86_64.c ../../../dlls/ntdll/signal_x86_64.c: In function ‘is_inside_epilog’: ../../../dlls/ntdll/signal_x86_64.c:2632:14: warning: variable ‘rex’ set but not used [-Wunused-but-set-variable] -- ccache gcc -msse4 -O3 -Wall -c -I../../../dlls/oleaut32 -I. -I../../../include -I../../include -D__WINESRC__ -D_OLEAUT32_ -DCOM_NO_WINDOWS_H -DENTRY_PREFIX=OLEAUTPS_ -DPROXY_DELEGATION -DWINE_REGISTER_DLL -DPROXY_CLSID=CLSID_PSFactoryBuffer -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o safearray.o ../../../dlls/oleaut32/safearray.c ccache gcc -msse4 -O3 -Wall -c -I../../../dlls/oleaut32 -I. -I../../../include -I../../include -D__WINESRC__ -D_OLEAUT32_ -DCOM_NO_WINDOWS_H -DENTRY_PREFIX=OLEAUTPS_ -DPROXY_DELEGATION -DWINE_REGISTER_DLL -DPROXY_CLSID=CLSID_PSFactoryBuffer -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o tmarshal.o ../../../dlls/oleaut32/tmarshal.c ../../../dlls/oleaut32/tmarshal.c:426:3: warning: #warning You need to implement stubless proxies for your architecture [-Wcpp] ../../../dlls/oleaut32/tmarshal.c: In function ‘serialize_param’: ../../../dlls/oleaut32/tmarshal.c:717:279: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ../../../dlls/oleaut32/tmarshal.c:793:73: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ../../../dlls/oleaut32/tmarshal.c:794:56: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ../../../dlls/oleaut32/tmarshal.c:800:50: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ../../../dlls/oleaut32/tmarshal.c:802:7: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ../../../dlls/oleaut32/tmarshal.c:802:41: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ../../../dlls/oleaut32/tmarshal.c:807:51: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ../../../dlls/oleaut32/tmarshal.c:809:7: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ../../../dlls/oleaut32/tmarshal.c:809:41: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ../../../dlls/oleaut32/tmarshal.c:895:92: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ../../../dlls/oleaut32/tmarshal.c: In function ‘deserialize_param’: ../../../dlls/oleaut32/tmarshal.c:1076:12: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] ../../../dlls/oleaut32/tmarshal.c:1079:78: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ../../../dlls/oleaut32/tmarshal.c:1086:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] ../../../dlls/oleaut32/tmarshal.c:1181:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] ../../../dlls/oleaut32/tmarshal.c:1189:16: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ../../../dlls/oleaut32/tmarshal.c: In function ‘init_proxy_entry_point’: ../../../dlls/oleaut32/tmarshal.c:1699:17: warning: unused variable ‘xasm’ [-Wunused-variable] ../../../dlls/oleaut32/tmarshal.c: At top level: ../../../dlls/oleaut32/tmarshal.c:1317:1: warning: ‘xCall’ defined but not used [-Wunused-function] -- ccache gcc -msse4 -O3 -Wall -c -I../../../dlls/setupapi -I. -I../../../include -I../../include -D__WINESRC__ -D_SETUPAPI_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o devinst.o ../../../dlls/setupapi/devinst.c ../../../dlls/setupapi/devinst.c: In function ‘SETUPDI_AllocateDeviceInfo’: ../../../dlls/setupapi/devinst.c:470:26: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] ../../../dlls/setupapi/devinst.c: In function ‘SETUPDI_FreeDeviceInfo’: ../../../dlls/setupapi/devinst.c:527:16: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ../../../dlls/setupapi/devinst.c: In function ‘SetupDiGetDeviceRegistryPropertyA’: ../../../dlls/setupapi/devinst.c:3106:278: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] ../../../dlls/setupapi/devinst.c: In function ‘SetupDiGetDeviceRegistryPropertyW’: ../../../dlls/setupapi/devinst.c:3167:278: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] ../../../dlls/setupapi/devinst.c: In function ‘CM_Get_Device_IDA’: ../../../dlls/setupapi/devinst.c:3940:45: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ../../../dlls/setupapi/devinst.c: In function ‘CM_Get_Device_IDW’: ../../../dlls/setupapi/devinst.c:3958:45: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ../../../dlls/setupapi/devinst.c:3970:18: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ../../../dlls/setupapi/devinst.c: In function ‘CM_Get_Device_ID_Size’: ../../../dlls/setupapi/devinst.c:3982:47: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ../../../dlls/setupapi/devinst.c:3993:18: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] -- ccache gcc -msse4 -O3 -Wall -c -I../../../dlls/winmm -I. -I../../../include -I../../include -D__WINESRC__ -D_WINMM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o winmm.o ../../../dlls/winmm/winmm.c ../../../dlls/winmm/winmm.c: In function ‘MMSYSTEM_GetMidiStream’: ../../../dlls/winmm/winmm.c:975:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ../../../dlls/winmm/winmm.c: In function ‘MMSYSTEM_MidiStream_MessageHandler’: ../../../dlls/winmm/winmm.c:1092:43: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] ../../../dlls/winmm/winmm.c: In function ‘midiStreamOpen’: ../../../dlls/winmm/winmm.c:1304:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] -- ccache gcc -msse4 -O3 -Wall -c -I../../../programs/winedbg -I. -I../../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o be_x86_64.o ../../../programs/winedbg/be_x86_64.c ../../../programs/winedbg/be_x86_64.c: In function ‘be_x86_64_is_func_call’: ../../../programs/winedbg/be_x86_64.c:346:11: warning: variable ‘segment’ set but not used [-Wunused-but-set-variable] ========== system ========== Operating System Linux azura 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21 20:28:43 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux Configuration (32-bit) '--prefix=/usr' '--libdir=/usr/lib32' '--disable-tests' '--with-alsa' '--with-freetype' '--without-gstreamer' '--with-jpeg' '--with-ldap' '--with-openal' '--with-opengl' '--with-openssl' '--with-png' '--with-x' '--with-xinerama' '--with-xinput2' '--with-xml' '--with-xrandr' '--without-capi' '--without-cms' '--without-cups' '--without-curses' '--without-fontconfig' '--without-gettextpo' '--without-gnutls' '--without-gphoto' '--without-gsm' '--without-hal' '--without-mpg123' '--without-opencl' '--without-oss' '--without-sane' '--without-tiff' '--without-v4l' '--without-xslt' '--without-xxf86vm' 'CC=ccache gcc -msse4 -O3 -Wall' Configuration (64-bit) '--prefix=/usr' '--libdir=/usr/lib' '--enable-tests' '--enable-win64' '--with-alsa' '--with-freetype' '--without-gstreamer' '--with-jpeg' '--with-ldap' '--with-openal' '--with-opengl' '--with-openssl' '--with-png' '--with-x' '--with-xinerama' '--with-xinput2' '--with-xml' '--with-xrandr' '--without-capi' '--without-cms' '--without-cups' '--without-curses' '--without-fontconfig' '--without-gettextpo' '--without-gnutls' '--without-gphoto' '--without-gsm' '--without-hal' '--without-mpg123' '--without-opencl' '--without-oss' '--without-sane' '--without-tiff' '--without-v4l' '--without-xslt' '--without-xxf86vm' 'CC=ccache gcc -msse4 -O3 -Wall' Warning report for wine-1.4-rc1 generated on Tue Jan 31 12:38:27 GMT 2012 J. Leclanche

2 2

Re: [PATCH 3/4] ddraw/tests: Add an IDirect3DTexture2::Load color key test
by Marvin 31 Jan '12

31 Jan '12

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=16746 Your paranoid android. === W7PROX64 (64 bit ddraw4) === ddraw4.c:1247: Test failed: Failed to get Direct3DTexture2 interface, hr 0x80004002. ddraw4.c:1249: Test failed: Failed to get Direct3DTexture2 interface, hr 0x80004002. Timeout === TEST64_W7SP1 (64 bit ddraw4) === ddraw4.c:1247: Test failed: Failed to get Direct3DTexture2 interface, hr 0x80004002. ddraw4.c:1249: Test failed: Failed to get Direct3DTexture2 interface, hr 0x80004002. Timeout

1 0

Re: [PATCH 2/4] ddraw/tests: Add an IDirect3DTexture::Load color key test
by Marvin 31 Jan '12

31 Jan '12

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=16745 Your paranoid android. === WNT4WSSP6 (32 bit ddraw2) === ddraw2.c:1117: Test failed: Got unexpected hr 0x88760064. ddraw2.c:1129: Test failed: Got unexpected hr 0x88760064. ddraw2.c:1131: Test failed: Got unexpected hr 0x887600d7. ddraw2.c:1140: Test failed: Got unexpected hr 0x88760064. ddraw2.c:1143: Test failed: dwColorSpaceLowValue is 0xff. ddraw2.c:1144: Test failed: dwColorSpaceHighValue is 0xff. ddraw2.c:1152: Test failed: Got unexpected hr 0x88760064. ddraw2.c:1155: Test failed: dwColorSpaceLowValue is 0xff. ddraw2.c:1156: Test failed: dwColorSpaceHighValue is 0xff. === W7PROX64 (64 bit ddraw2) === ddraw2.c:1111: Test failed: Failed to get Direct3DTexture interface, hr 0x80004002. ddraw2.c:1113: Test failed: Failed to get Direct3DTexture interface, hr 0x80004002. Timeout === TEST64_W7SP1 (64 bit ddraw2) === ddraw2.c:1111: Test failed: Failed to get Direct3DTexture interface, hr 0x80004002. ddraw2.c:1113: Test failed: Failed to get Direct3DTexture interface, hr 0x80004002. Timeout

1 0

Re: [PATCH 2/2] urlmon: Properly handle relative URIs with specified host in combine_uri
by Marvin 31 Jan '12

31 Jan '12

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=16738 Your paranoid android. === W7PROX64 (64 bit uri) === uri.c:10092: Test failed: Error: IUri_GetPropertyDWORD returned 0x00000001, expected 0x00000000 on uri_combine_tests[31].dword_props[1]. uri.c:10095: Test failed: Error: Expected 80, but got 0 instead on uri_combine_tests[31].dword_props[1]. uri.c:10092: Test failed: Error: IUri_GetPropertyDWORD returned 0x00000001, expected 0x00000000 on uri_combine_tests[32].dword_props[1]. uri.c:10095: Test failed: Error: Expected 80, but got 0 instead on uri_combine_tests[32].dword_props[1]. uri.c:10408: Test failed: Error: IUri_GetPropertyDWORD returned 0x00000001, expected 0x00000000 on uri_combine_tests[31].dword_props[1]. uri.c:10411: Test failed: Error: Expected 80, but got 0 instead on uri_combine_tests[31].dword_props[1]. uri.c:10408: Test failed: Error: IUri_GetPropertyDWORD returned 0x00000001, expected 0x00000000 on uri_combine_tests[32].dword_props[1]. uri.c:10411: Test failed: Error: Expected 80, but got 0 instead on uri_combine_tests[32].dword_props[1].

2 1

Re: configure.ac: remove an extraneous semicolon (Clang)
by Ken Thomases 31 Jan '12

31 Jan '12

On Jan 30, 2012, at 10:09 PM, Austin English wrote: > @@ -1723,7 +1723,7 @@ then > saved_CFLAGS="$CFLAGS" > CFLAGS="$CFLAGS -Wlogical-op -Werror" > AC_CACHE_CHECK([for broken string.h that generates warnings with -Wlogical-op], ac_cv_c_logicalop_noisy, > - AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <string.h>]], [[char*f(const char *h,char n) {return strchr(h,n);}]])],[ac_cv_c_logicalop_noisy=no],[ac_cv_c_logicalop_noisy=yes])) > + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <string.h>]], [[char*f(const char *h,char n) {return strchr(h,n)}]])],[ac_cv_c_logicalop_noisy=no],[ac_cv_c_logicalop_noisy=yes])) > CFLAGS="$saved_CFLAGS" > if test "$ac_cv_c_logicalop_noisy" = "no" > then That doesn't look extraneous to me. Also, static analysis of the configure test programs seems like it would produce tons of noise. Those are often not sane programs by normal standards. Regards, Ken

2 1

Best way to overlay a filesystem for a Wine app?
by Scott Ritchie 30 Jan '12

30 Jan '12

Suppose someone wants to distribute a Windows application as a traditional package, such as via the Ubuntu Software Center App Store. Ubuntu requires these commercial packages: 1) Install into a unique namespace in /opt (icons/.desktop excepted) 2) Store their user configuration in ~/.packagename or ~/.config/packagename I have already packaged a super-simple Wine application this way. This was a single binary file that could be run from anywhere - all I had to do was copy it into its own /opt folder and make a .desktop file that declared a unique WINEPREFIX for it. More complicated Windows applications, however, won't be doable with this basic approach. Specifically, Windows applications might: 1) Be distributed as installer files 2) Have self-updating mechanisms 3) Expect their own folder to be user-writable One ugly not-quite-solution would be to just have the package put the installer in opt, provide a link to it, and expect the user to install like he would a downloaded application (and then use a different .desktop file to actually run the program). Slightly better is to just copy an entire /opt prefix template into user space on first run, and then let it go on its own way after that. An app which didn't self-update, however, would then be unable to benefit from an updated version of the system package. A more complete solution would have a prefix in the user space, but files inside it would actually be those residing in /opt. A system of symlinks might work, but if a package update introduced new files those would not be available without complicated scripting to add the links. To me, this sounds an awful lot like an overlay file system. Would unionfs-fuse be the correct solution here? The .desktop file that sets the Wine prefix and also launches the app could mount the FUSE filesystem, and the user-space Wine prefix's files could take priority over those in /opt. Stuff like user-modding and update/repair systems could work properly in that context as well. Or have I missed something? Thanks, Scott Ritchie

4 5

winecoreaudio.drv: Improve underrun handling
by Joerg-Cyril.Hoehle＠t-systems.com 30 Jan '12

30 Jan '12

Andrew, The good news is that your underrun patch prevents mmdevapi from writing less and less frames in mmdevapi/tests/render:test_worst_case http://test.winehq.org/data/f0cfa7cf46d7c832fb84555529d1a1b7c49c46c0/mac_jc… >render.c:1631: Released 86436=98x882 -0 frames at 44100 worth 1960ms in 2035ms >render.c:1631: Released 71442=81x882 -0 frames at 44100 worth 1620ms in 2037ms >render.c:1631: Released 56448=64x882 -0 frames at 44100 worth 1280ms in 2039ms That is abnormal behavior. + sc = AudioQueueEnqueueBufferWithParameters(This->aqueue, + This->public_buffer, 0, NULL, 0, 0, 0, NULL, &req_time, &start_time); I advise against setting req_time. This can only fragilize the system. What if req_time is miscomputed or there's a delay? NULL=ASAP is exactly what we want. We don't want ALSA/dmix behavior, where it'll silently skip over late frames in order to catch up (dunno if MacOSX does this but in my eyes that doesn't matter). If you need to memorize a time, I believe it's best stored in our AQBuffer struct. >if(list_count(...) == 0) I once wrote a patch to turn such a pattern into if(list_empty(...)) Regards, Jörg

2 3

Re: winealsa: snd_card_get_name uses strdup (Valgrind). (2nd)
by Alexandre Julliard 30 Jan '12

30 Jan '12

Joerg-Cyril.Hoehle(a)t-systems.com writes: > Perhaps that way, the relationship is obvious. > > Please choose whether to apply the original patch #82900 or this one. > It used instead "if(!err)" i.e. the 0 return code that ALSA documents. The previous one was better, but you need to get rid of that cast. -- Alexandre Julliard julliard(a)winehq.org

1 0

mmdevapi: Correctly convert UINT32 to INT64
by Joerg-Cyril.Hoehle＠t-systems.com 30 Jan '12

30 Jan '12

Andrew, thank you very much for finding a bug in my code. I'll have to meditate signed/unsigned conversions for the next months. Perhaps it's my lack of familiarity with the MS-Windows API that had me not find a signed equivalent of UINT32. Indeed there's none in windef.h. So I choose 'long'. But now I see basestd.h defines LONG32. INT64 is not appropriate. getbuf_last should be of the same size than the other frame holding types. I once wrote a patch to turn all #frame holding entities from UINT64 into 32. Please rewrite the patch to use the LONG32 type, then you'll need no surprising cast. If the loss of 1 bit worries you, the solution IMHO is not to go to INT64 rather than prevent a duration that large in Initialize. In shared mode, there's no 2s limit. My tests opened a 10s buffer. I've not tested anything larger. LONG32 leaves enough room for 10000 seconds at 200000fps. Regards, Jörg Höhle

3 3

comctl32: fix MSVC build in imagelist.c
by carlo.bramix＠libero.it 30 Jan '12

30 Jan '12

If I can say my opinion, I disagree on the usage of HeapAlloc/HeapFree for that known amount of memory. Instead, for granting compatibility with MSVC, I would continue to use a structure in stack memory by simply using _alloca() and something like this: LPBITMAPINFO bmi = (LPBITMAPINFO) _alloca(FIELD_OFFSET(BITMAPINFO, bmiColors[256])); or this: LPBITMAPINFO bmi = (LPBITMAPINFO) _alloca(sizeof(BITMAPINFO)+sizeof(RGBQUAD)*256); and leaving all other lines of code unchanged. Sincerely, Carlo Bramini. > Thomas Faber <thfabba at gmx.de> writes: > >> This removes the use of a Variable-Length Array in ImageList_CreateImage >> and replaces it with HeapAlloc/HeapFree, as it is done in several >> other functions in this file. >> Alas, FIELD_OFFSET is "not const enough" for ANSI C. > >Using sizeof instead would be preferable. > >-- >Alexandre Julliard >julliard at winehq.org >

1 0

Rules for code freeze
by Alexandre Julliard 30 Jan '12

30 Jan '12

Folks, We are now in code freeze, so all patches that are not obviously harmless need to have a justification as to why the patch should be applied. In most cases, that simply means pointing to the corresponding bug that is fixed by the patch. Patches that seem risky will be marked pending or deferred. If you still think they should go in, you should convince me that they fix something important that is worth the risk. Patches that only change the tests can't break apps so they will be accepted freely, at least until we get closer to release. Patches that require translation updates will only be accepted for the next two weeks, to give translators time to catch up afterwards. I'm planning to make rc releases every week until we run out of bugs. The release schedule may be a bit more random than usual because of travel constraints (not to mention skiing constraints ;-) -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: comctl32: fix MSVC build in imagelist.c
by Alexandre Julliard 30 Jan '12

30 Jan '12

Thomas Faber <thfabba(a)gmx.de> writes: > This removes the use of a Variable-Length Array in ImageList_CreateImage > and replaces it with HeapAlloc/HeapFree, as it is done in several > other functions in this file. > Alas, FIELD_OFFSET is "not const enough" for ANSI C. Using sizeof instead would be preferable. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] include: Handle rmxftmpl.x when needed by d3dx9 without the need to make all includes. (try 2)
by Rico Schüller 30 Jan '12

30 Jan '12

Please ignore this patch, it seems to break make crosstest. Cheers Rico Am 30.01.2012 09:00, schrieb Rico Schüller: > Hi, > > this is try 2 for fixing the build for d3dx9_36 without requiring to > make all includes. > > Improvements: > - don't use a generic rule, use a file specific one > > Cheers > Rico > > --- > Make.rules.in | 3 +++ > include/Makefile.in | 3 --- > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > >

1 0

Re: kernel32: add a stub for LCMapStringEx (try 2)
by Dmitry Timoshkov 30 Jan '12

30 Jan '12

Austin English <austinenglish(a)gmail.com> wrote: > Forgot the include changes. Forwarding it to LCMapString would be much better. -- Dmitry.

3 2

Re: [PATCH 4/5] ddraw/tests: Port the depth blit test to ddraw2
by Henri Verbeet 30 Jan '12

30 Jan '12

On 22 January 2012 16:32, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + /* FIXME: This is wrong, d3d2 does not have D3DRENDERSTATE_LIGHTING. D3DLVERTEX should > + * disable lighting. This needs more tests and fixes after Wine 1.4 */ > + hr = IDirect3DDevice2_SetRenderState(device, D3DRENDERSTATE_LIGHTING, FALSE); It probably makes sense to just skip this call and add a todo_wine for the failing tests. Also, if all that's needed for this is setting WINED3D_RS_LIGHTING in IDirect3DDeviceImpl_2_DrawPrimitive(), I think that should be ok to go in before 1.4.

2 1

Re: user32: Only call SetWindowPos() in UpdateLayeredWindowIndirect() if needed. (try 2)
by Dmitry Timoshkov 30 Jan '12

30 Jan '12

Adam Martinson <adam.r.martinson(a)gmail.com> wrote: > Fixes bug 26924. Please add the tests. -- Dmitry.

1 0

re: Best way to overlay a filesystem for a Wine app?
by Dan Kegel 30 Jan '12

30 Jan '12

Hi Scott, I agree with what Vrit said. Here's what I recall learning from helping package Picasa: - don't package the installer - rely on the system's update manager to pull updated versions of the package from the repository - install everything read-only into /opt/companyname/appname - start the app using a shell script that creates a wineprefix on 1st run - The wineprefix should have real directories (so the app can create files in Program Files, ugh), should symlink to all the readonly files in /opt, and have real copies of any files that can't be read-only As Vrit said, the script that creates the wineprefix is very app-specific, but once you write one, it's probably easy to write the next one. - If you are running your own repo, you should put exactly one app per repo. Otherwise you run into trouble because Canonical would want to review all the apps in the repo every time you update any one of them. So no overlay filesystem needed, symlinks should usually suffice. (Picasa also went further and bundled a snapshot of wine, too, and modified the app slightly to display unix paths, which required adding one little extension to wine. I'm sure the wine patch is around if someone wants it. And since it was in a non-ubuntu repo, it had to do a strange song and dance to avoid autoupdates being disabled when the user upgraded to a new version of ubuntu. This was considered safe because picasa was fairly well self-contained and maintained, and was unlikely to break on system updates.) In case you want to look at picasa's scripts, the download page seems to be gone, but the repo seems to still be there: http://dl.google.com/linux/deb/pool/non-free/p/picasa/picasa_3.0-current_i3… http://dl.google.com/linux/deb/pool/non-free/p/picasa/picasa_3.0-current_am… 4ecf30186ce76430a7791cee2608f47e07b015e6 picasa_3.0-current_amd64.deb fe8e83b29a10b5d663e87861d85512faea036c06 picasa_3.0-current_i386.deb Still installs and runs ok on 11.10.

2 2

Re: patch msvcrt.dll file.c MSVCRT_tmpfile() open_flags --> stream_flags
by Vitaliy Margolen 29 Jan '12

29 Jan '12

On 01/29/2012 07:25 AM, fred wrote: > Hi Wine-Team > > A old bugfix on my system > You need to fix at least these issues with your e-mail: - One e-mail per patch. - All patches needs to be submitted using git format-patch.. - You have to specify your full name in From: address For more details see: http://wiki.winehq.org/SubmittingPatches Vitaliy.

1 0

Re: [po]updated korean resource(2012-1-28)
by Frédéric Delanoy 29 Jan '12

29 Jan '12

2012/1/28 Hwang YunSong(황윤성) <hys545(a)dreamwiz.com> > > fuzzy sections tranlated > > <http://www.dreamwiz.com/> http://www.dreamwiz.com/ > > <http://mall.shinsegae.com/display/display/planshop.do?disp_ctg_id=10049845&…> > > You should send your patch in plain text format (as all mails to wine-devel / wine-patches). Also, you shouldn't specify a date in the patch subject line (Change PO-Revision-Date in the po file instead for instance) so "[po]updated korean resource(2012-1-28)" should be sthg like "po: Update Korean translation" to conform to naming conventions (see http://wiki.winehq.org/SubmittingPatches). Frédéric

1 0

HRBlock error. Sure would like to do my taxes on Linux using Wine.
by Ken Stephens 29 Jan '12

29 Jan '12

I get the following error when trying to load HRBlock software: Error Messsage [kens@atlas HRBlock2011]$ wine tcauto.exe err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution. fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 32 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 32 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels err:ole:CoGetClassObject class {96749377-3391-11d2-9ee3-00c04f797396} not registered err:ole:CoGetClassObject class {96749377-3391-11d2-9ee3-00c04f797396} not registered err:ole:create_server class {96749377-3391-11d2-9ee3-00c04f797396} not registered fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported err:ole:CoGetClassObject no class object {96749377-3391-11d2-9ee3-00c04f797396} could be created for context 0x17 fixme:win:EnumDisplayDevicesW ((null),0,0x32f70c,0x00000000), stub! fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! fixme:urlmon:InternetBindInfo_GetBindString not supported string type 12 fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! fixme:wininet:InternetLockRequestFile STUB fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! Application tried to create a window, but no driver could be loaded. Unknown error (0). [kens@atlas HRBlock2011]$ err:ntdll:RtlDeleteResource Deleting active MRSW lock (0x111bf4), expect failure err:ntdll:RtlDeleteResource Deleting active MRSW lock (0x1124fc), expect failure [kens@atlas HRBlock2011]$ -- Ken Stephens, SV Aventura, Portland, OR

4 3

Re: wined3d: downgrade a noisy FIXME to a WARN
by Stefan Dösinger 29 Jan '12

29 Jan '12

Am Samstag, 28. Januar 2012, 14:19:22 schrieb Austin English: > Follow up to > http://www.winehq.org/pipermail/wine-patches/2012-January/110971.html. I > was hoping to get it in before 1.4, to reduce users asking about it in > #winehq/forums. > > I know Henri feels it should be properly fixed instead, but given > http://www.winehq.org/pipermail/wine-devel/2012-January/093977.html, I > don't see that happening, and certainly not before 1.4. No one has > sent a simple downgrade patch, instead opting to go with the > FIXME_once approach. Hopefully this is a fair compromise. We don't want to downgrade all flags. Most(all?) of the noise comes from the WRITEONLY usage flag. The other flags are more serious should an app use them.

1 0

Re: user32: Only call SetWindowPos() in UpdateLayeredWindowIndirect() if needed.
by Dmitry Timoshkov 29 Jan '12

29 Jan '12

Adam Martinson <adam.r.martinson(a)gmail.com> wrote: > Fixes bug 26924. This needs the tests. -- Dmitry.

1 0

NLS files and FONTSIGNATURE
by Pablo Saratxaga 28 Jan '12

28 Jan '12

Kaixo, I'm planning to create/fix/check all the possible NLS files. There is, however, an entry on those files that is problematic for me, namely the LOCALE_FONTSIGNATURE one. >From the Microsoft docs I understand it is made of 3 bitfields, one 128bit for unicode coverage, and two 64bit ones for codepage ("default" and "supported"). For those last two there is no problem, after the normal endianess switching I get an hex number with bits that make sens. eg for rus.nls file I have a fontsignature being: L"\x0203\x8000\x3848\x0000\x0000\x0000\x0000\x0000\x0004\x0000\x0000\x0002\x0004\x0000\x0000\x0202" the default and supported codepage parts are respectively: \x0004\x0000\x0000\x0002 \x0004\x0000\x0000\x0202 after switching \x(1)\x(2)\x(3)\x(4) to 0x(4)(3)(2)(1) I get: 0x0002000000000004 and 0x0202000000000004 which perfectly match bits 2, 49, 57; code pages 1250, 866, 855 But for the unicode coverage part I'm lost... In the LOCALE_FONTSIGNATURE it is: \x00a3\x8000\x7878\x38c9\x0016\x0000\x0000\x0000 In order to get a 128 bit number that makes sense I had to do the following switching: \x(1)\x(2)\x(3)\x(4)\x(5)\x(6)\x(7)\x(8) to 0x(2)(7)(6)(5)(4)(3)(8)(1) but it seems strange to me. Also, font signatures for other nls don't make sense with that substitution. So; how should I made the conversion between the format used in *.nls files and the 128 bit number used as bitfield to calculate the flags? Are the values in *.nls files trusty? Thanks -- Ki ça vos våye bén, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466

1 0

Save backtrace feature
by Bruno Jesus 28 Jan '12

28 Jan '12

I'm not sure what this console error means but it's always related to exceptions and crashes: err:seh:setup_exception_record stack overflow 848 bytes in thread 0009 eip 7bc79df6 esp 00230fe0 stack 0x230000-0x231000-0x330000 When an error like this happens during a crash the new error window with the save backtrace feature will keep "Loading detailed information" forever. I guess it should say something like "could not load required information". I looked in the list emails and it looks like this issue was not reported yet. I'm sorry if it already was discussed and I missed it. Best wishes, Bruno

2 1

Re: [PATCH] winecoreaudio.drv: Improve underrun handling
by Ken Thomases 28 Jan '12

28 Jan '12

On Jan 27, 2012, at 3:46 PM, Andrew Eikum wrote: > + if(list_count(&This->queued_bufinfos) == 0){ > + sc = AudioQueueGetCurrentTime(This->aqueue, NULL, &req_time, NULL); This isn't quite the same as the next start time. Even if there are no remaining queued buffers, the queue may still be playing some audio from the last of them. In that case, the queue's current time would not be the actual desired start time of this buffer. Have you verified that the queue schedules it after whatever audio may be playing? Also, what about the fact that AudioQueueGetCurrentTime() seems to return an unreliable time when the queue is paused? > + if(req_time.mFlags & kAudioTimeStampSampleTimeValid){ > + sc = AudioQueueEnqueueBufferWithParameters(This->aqueue, > + This->public_buffer, 0, NULL, 0, 0, 0, NULL, &req_time, &start_time); > + if(sc != noErr){ > + OSSpinLockUnlock(&This->lock); > + WARN("Unable to enqueue buffer: %lx\n", sc); > + return E_FAIL; > + } > + }else{ > + sc = AudioQueueEnqueueBufferWithParameters(This->aqueue, > + This->public_buffer, 0, NULL, 0, 0, 0, NULL, NULL, &start_time); > + if(sc != noErr){ > + OSSpinLockUnlock(&This->lock); > + WARN("Unable to enqueue buffer: %lx\n", sc); > + return E_FAIL; > + } I would avoid duplicating those two branches just to change between &req_time or NULL. Either use a pointer variable to hold the argument you're going to pass, computed in an "if", or use the conditional ?: operator inline. -Ken

1 0

Re: Wine release 1.4-rc1
by James McKenzie 27 Jan '12

27 Jan '12

Alexandre: Congratulations to the Wine Team. Now to beat on it... James On Fri, Jan 27, 2012 at 12:58 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > The Wine development release 1.4-rc1 is now available. > -- > Alexandre Julliard > julliard(a)winehq.org >

1 0

brainstorm: what are the audio stumbling blocks?
by Joerg-Cyril.Hoehle＠t-systems.com 27 Jan '12

27 Jan '12

Hi, What are the areas that would have the most impact if fixed? You are invited to participate and share your thoughts. I believe we need to distinguish winmm/dsound/mmdevapi/OS. mmdevapi: A. lock-less timer callback design, bug #. But I don't think where we would get the most improvement from avoiding a few EnterCriticalSection. B. Stability of time base, bug #. Perhaps major. My render "worst case" test showed that CreateTimerQueue never invoked callbacks every 10ms as asked rather than 8 or 12ms. I don't know if that's the Linux jiffies we see here. C. too small ALSA buffer for the backend I've sketched a "hidden frames" design that would allow using a larger ALSA or OSS buffer, but that needs a reliable estimate of how much ALSA has buffered. Also, that's at odds with DSound and XAudio2 which want short latency and presumably don't send much data in advance. Every audio HW guy recommends using audio buffers as large as possible. Can't we just because of the f**ing 10ms period? D. timer frequency Is it really important to match native's 10ms period? The UNIX world is trying to decrease the number of interrupts in order to preserve battery life, but we go backwards and move from a model which dynamically computed the next wake-up based on the number of submitted frames to a tiny fixed period. Are we crazy? E. lead-in aka. "ALSA won't start", bug # F. lead-out aka. finish playing trailing frames not modulo period size, bug # G. other mmdevapi winmm: H. GetPosition is not (yet) == mmdevapi's GetPosition I. other winmm DSound: J. time base? It uses timeSetEvent. What if using mmdevapi's event? K. buffer size too small or not matching whatever needs? L. issues with GetCurrentPadding/GetPosition The "true position" may be too far away from the write pointer, e.g. PA's typical 2s latency. Deal with that, matching DSound's and the apps' expectations as well as Linux/BSD/OSX sound systems. M. DSound's underlying model is a ring buffer. This does not match mmdevapi's. Should we bypass mmdevapi because all it adds is latency? Reinvent HW acceleration? Provide a hidden API in mmdevapi? N. other DSound XAudio2: Modern apps will use that because mmdevapi is too low-level, presumably DSound usage will decrease. O. XAudio2 appears to use the "worst case small period size writes" known from the Rage bug # P. other Capture: Q. whatever capture issues UNIX host: R. thread priority -- no "Pro Audio" / Real-Time priority S. reliability of event/interrupt delivery over sustained intervals (hours, not minutes). T. Wine SetEvent & server round-trip times Other: U. FMOD & whatever, any particular constraints? V. other? Thanks for your contribution, Jörg Höhle

2 4

Re: Wine release 1.4-rc1
by Alexandre Julliard 27 Jan '12

27 Jan '12

Alexandre Julliard <julliard(a)winehq.org> writes: > The source is available from the following locations: > > http://ibiblio.org/pub/linux/system/emulators/wine/wine-1.3.38.tar.bz2 > http://prdownloads.sourceforge.net/wine/wine-1.3.38.tar.bz2 Of course, that should read http://ibiblio.org/pub/linux/system/emulators/wine/wine-1.4-rc1.tar.bz2 http://prdownloads.sourceforge.net/wine/wine-1.4-rc1.tar.bz2 Hopefully my release scripts will be bug-free by 1.4 final ;-) -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/1] crypt32: Fix domain component length check.
by Austin English 27 Jan '12

27 Jan '12

On Fri, Jan 27, 2012 at 10:11, Erich E. Hoover <ehoover(a)mines.edu> wrote: > Real Name: > Erich Hoover > > Description: > This patch fixes an issue where the domain component in > match_domain_component will not match when the allowed_component is > NULL terminated. This currently affects the Battle.net System Checker > (Bug #28162), which passes a server_component of "net" and an > allowed_component of "net\000". > > Changelog: > crypt32: Fix domain component length check. Forgot the patch. -- -Austin

3 2

Re: [PATCH 1/2] itss: Enlarge buffer to include space for a catenated value.
by Jacek Caban 27 Jan '12

27 Jan '12

Hi Erich, On 01/27/12 04:58, Erich E. Hoover wrote: > --- a/dlls/itss/storage.c > +++ b/dlls/itss/storage.c > @@ -418,7 +418,7 @@ static HRESULT WINAPI ITSS_IStorageImpl_OpenStorage( > if( !chmfile ) > return E_FAIL; > > - len = strlenW( This->dir ) + strlenW( pwcsName ) + 1; > + len = strlenW( This->dir ) + strlenW( pwcsName ) + strlenW( szRoot ) + 1; szRoot is a constant string, so there is no need to call strlenW on it. IMO it would be best to get rid of szRoot and use character assignment instead. Cheers, Jacek

1 0

Re: [PATCH 2/2] winmm: Restore useful MMSYSERR_* codes at open time.
by Andrew Eikum 27 Jan '12

27 Jan '12

On Fri, Jan 27, 2012 at 02:02:22PM +0100, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > + case S_FALSE: /* as in IsFormatSupported */ > + case AUDCLNT_E_UNSUPPORTED_FORMAT: > + return WAVERR_BADFORMAT; I think I'd rather special-case how we handle IsFormatSupported, rather than put S_FALSE->BADFORMAT into the generic conversion. Andrew

1 0

Re: vbscript: Get rid of unused SET_CALLED macro
by Marvin 27 Jan '12

27 Jan '12

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=16686 Your paranoid android. === WNT4WSSP6 (32 bit createobj) === createobj.c:731: Test failed: CoCreateInstance failed: 80040154 createobj: unhandled exception c0000005 at 00402A21

1 0

mmdevapi/tests: Perform renderer padding & position tests.
by Joerg-Cyril.Hoehle＠t-systems.com 27 Jan '12

27 Jan '12

Alexandre, You wrote: >It doesn't work here: Backtrace: =>0 get_audio_session+0xbd() in winealsa 1 AudioClient_Initialize+0x5ae(iface=0x30c80, mode=AUDCLNT_SHAREMODE_SHARED, flags=0, duration=<is not available>, period=0x186a0, fmt=0x30f00, sessionguid=0x22fa00) [dlls/winealsa.drv/mmdevdrv.c:1075] in winealsa 2 test_session+0x114() [dlls/mmdevapi/tests/render.c:1298] in mmdevapi_test Could you please investigate this? The crash happens in test_session, before the one change to this function by my patch. The tests have been running thousands of iterations on my dual core MacOS (with my wip lock-free patches) and a single core Linux ALSA/dmix box. Several people have run the tests on native, including 64bit MS-Windows. I can't rule out that one of my latest additions may have introduced a bug, but so far I'd rather believe that my renderer tests have uncovered a bug in mmdevapi that shows up in your environment only. Why? On my side, I think I'll add ok(ref=0) checks around every IAC_Release. Thank you, Jörg Höhle

2 1

Re: mmdevapi/tests: Perform renderer padding & position tests.
by Alexandre Julliard 26 Jan '12

26 Jan '12

Joerg-Cyril.Hoehle(a)t-systems.com writes: > Hi, > > this again fixes a few flaky failures on testbot but has potential > to introduce more flaky failures, esp. with PulseAudio. It doesn't work here: ../../../../wine/tools/runtest -q -P wine -M mmdevapi.dll -T ../../.. -p mmdevapi_test.exe.so ../../../../wine/dlls/mmdevapi/tests/render.c && touch render.ok render.c:1081: Tests skipped: Rerun with WINETEST_DEBUG=2 for GetPosition tests. render.c:1081: Tests skipped: Rerun with WINETEST_DEBUG=2 for GetPosition tests. wine: Unhandled page fault on read access to 0xffffffffffffffb8 at address 0x2adef8d7577d (thread 003f), starting debugger... Unhandled exception: page fault on read access to 0xffffffffffffffb8 in 64-bit code (0x00002adef8d7577d). Register dump: rip:00002adef8d7577d rsp:000000000022f830 rbp:000000000022fa00 eflags:00010283 ( R- -- I S - - -C) rax:0000000000000000 rbx:0000000000030af0 rcx:000000000022fa00 rdx:0000000000000000 rsi:00002adef8b53cb0 rdi:000000000022fa00 r8:0000000000000020 r9:000000000022f700 r10:0000000000000010 r11:000000000022f730 r12:0000000000000002 r13:ffffffffffffff98 r14:00002adef8f870f0 r15:0000000000030d90 Stack dump: 0x000000000022f830: 0000000000030f28 0000000000030c80 0x000000000022f840: 000000008007000e 0000000000000000 0x000000000022f850: 000000000022fa00 0000000000000000 0x000000000022f860: 0000000000000000 00002adef8d78e4f 0x000000000022f870: 0000000000000000 00002adef3fdcce1 0x000000000022f880: 000000000022fa48 0000000000030d68 0x000000000022f890: 0000000000000000 00002adef8d77f2f 0x000000000022f8a0: 0000000000031080 00002ade0000000e 0x000000000022f8b0: 000000000022f8e8 0000000000030d68 0x000000000022f8c0: 0000bb800022fa00 0000000400005355 0x000000000022f8d0: 5b5b5b5b5b5b5b5b 5b5b5b5b5b5b5b5b 0x000000000022f8e0: 2020202020202020 2020202020202020 Backtrace: =>0 0x00002adef8d7577d get_audio_session+0xbd() in winealsa (0x000000000022fa00) 1 0x00002adef8d78e4f AudioClient_Initialize+0x5ae(iface=0x30c80, mode=AUDCLNT_SHAREMODE_SHARED, flags=0, duration=<is not available>, period=0x186a0, fmt=0x30f00, sessionguid=0x22fa00) [/home/julliard/wine/build/obj-elf64/dlls/winealsa.drv/../../../wine/dlls/winealsa.drv/mmdevdrv.c:1075] in winealsa (0x000000008007000e) 2 0x00002adef3fd6fb5 test_session+0x114() [/home/julliard/wine/build/obj-elf64/dlls/mmdevapi/tests/../../../../wine/dlls/mmdevapi/tests/render.c:1298] in mmdevapi_test (0x0000000000000000) 3 0x00002adef3fda2d3 func_render+0x292() [/home/julliard/wine/build/obj-elf64/dlls/mmdevapi/tests/../../../../wine/dlls/mmdevapi/tests/render.c:2150] in mmdevapi_test (0x000000000022fb38) 4 0x00002adef3fcc429 main+0x308(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/build/obj-elf64/dlls/mmdevapi/tests/../../../../wine/include/wine/test.h:556] in mmdevapi_test (0x000000000001079c) 5 0x00002adef3fdd8c2 __wine_spec_exe_entry+0xa1(peb=<is not available>) [/home/julliard/wine/build/obj-elf64/dlls/winecrt0/../../../wine/dlls/winecrt0/exe_entry.c:36] in mmdevapi_test (0x00002adef2285a30) 6 0x00002adef3278404 start_process+0xb3(peb=0x7fffffbef000) [/home/julliard/wine/build/obj-elf64/dlls/kernel32/../../../wine/dlls/kernel32/process.c:1053] in kernel32 (0x00002adef3fdd820) 7 0x00002adef2ae328b call_thread_func+0x6a(entry=0x2adef3278350, arg=0x7fffffbef000, frame=0x0(nil)) [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/signal_x86_64.c:3189] in ntdll (0x00007fff3177aa50) 8 0x00002adef2adcbb6 call_thread_entry_point+0x29() in ntdll (0x00007fff3177aa50) 9 0x00002adef2aaf1d6 start_process+0x15(kernel_start=<is not available>) [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/loader.c:2612] in ntdll (0x00007fff3177aa50) 10 0x00002adef1f5f3a3 wine_call_on_stack+0x12() in libwine.so.1 (0x00007fff3177aa50) 11 0x00002adef1f5f3f9 wine_switch_to_stack+0x8(func=<is not available>, arg=<is not available>, stack=<is not available>) [/home/julliard/wine/build/obj-elf64/libs/wine/../../../wine/libs/wine/port.c:59] in libwine.so.1 (0x00007fffffbef000) 12 0x00002adef2ab4f10 LdrInitializeThunk+0x45f(kernel_start=0x2adef3278350, unknown2=<is not available>, unknown3=<is not available>, unknown4=<is not available>) [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/loader.c:2668] in ntdll (0x00007fffffbef000) 13 0x00002adef327e885 __wine_kernel_init+0x8f4() [/home/julliard/wine/build/obj-elf64/dlls/kernel32/../../../wine/dlls/kernel32/process.c:1254] in kernel32 (0x00007fff3177bce0) 14 0x00002adef2ab5874 __wine_process_init+0x273() [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/loader.c:2877] in ntdll (0x0000000000000400) 15 0x00002adef1f5d325 wine_init+0x294(argc=<is not available>, argv=0x7fff3177c4b8, error="", error_size=0x400) [/home/julliard/wine/build/obj-elf64/libs/wine/../../../wine/libs/wine/loader.c:831] in libwine.so.1 (0x0000000000000400) 16 0x000000007bf00d41 main+0x70(argc=0x3, argv=0x7fff3177c4b8) [/home/julliard/wine/build/obj-elf64/loader/../../wine/loader/main.c:230] in <wine-loader> (0x0000000000000003) 17 0x00002adef24ebead __libc_start_main+0xfc(main=<is not available>, argc=<is not available>, ubp_av=<is not available>, init=<is not available>, fini=<is not available>, rtld_fini=<is not available>, stack_end=0x7fff3177c4a8) [/home/aurel32/eglibc/eglibc-2.13/csu/libc-start.c:228] in libc.so.6 (0x0000000000000000) 18 0x000000007bf00e3d _start+0x28() in <wine-loader> (0x0000000000000000) 0x00002adef8d7577d get_audio_session+0xbd in winealsa: cmpq 0x0000000000000020(%r13),%rbx -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winmm: Parse MCI colon notation as in T:MM:SS:F.
by Alexandre Julliard 26 Jan '12

26 Jan '12

Joerg-Cyril.Hoehle(a)t-systems.com writes: > + if (seen < 2) return FALSE; > + if (shift && (val >= 256 || (seen&1))) return FALSE; > + total |= val << shift; > + *data = (seen&1) ? -total : total; > + *ptr = ret; > + return TRUE; This is still fairly ugly. If you need two flags, declare two flag variables, instead of that sort of counter/flag mix. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/2] scrrun: Register Scripting interfaces
by Nikolay Sivov 26 Jan '12

26 Jan '12

On 1/25/2012 12:35, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > scrrun: Register Scripting interfaces Some of this are already used in wshom.ocx, I'm not sure which one should take precedence and implement that. Probably it changed in recent Windows versions?

3 6

fwd: winealsa: snd_card_get_name uses strdup (Valgrind).
by Joerg-Cyril.Hoehle＠t-systems.com 26 Jan '12

26 Jan '12

Hi, Andrew Eikum updated ALSA's documentation http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=226a34ac09e5d9c0… Now that free() is documented, the pending patch #82900 should be applied. Regards, Jörg Höhle

1 0

Re: shell32: Use simple helper for case insensitive strstr()
by Alexandre Julliard 26 Jan '12

26 Jan '12

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > Fix for http://bugs.winehq.org/show_bug.cgi?id=28087 You shouldn't need anything of the kind. If StrStrIW doesn't work right it should be fixed (plus of course there's no reason to even use strstr() here at all). -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: po: Remove extraneous full stops from the Japanese translation.
by Akihiro Sagawa 25 Jan '12

25 Jan '12

Hi Francois, On Tue, 24 Jan 2012 00:28:02 +0100 (CET), Francois Gouget wrote: > This is essentially the kernel32 error messages. > > po/ja.po | 1587 +++++++++++++++++++++++++++++++------------------------------- > 1 files changed, 792 insertions(+), 795 deletions(-) IMHO, the error message should be well-formed sentences. I confused a lot while translating because some messages are not sentence style. For such a reason, I translated the message into Japanese sentence. So full-stops are reasonable. Additionally, in Windows, a sentence with periods or full-stops is used for the error message. So a Japanese Wine user might feel something wrong with the message if I translate without full-stops. Best regards, Akihiro Sagawa

3 4

Re: [PATCH] wined3d: Reduce console flood with an Ogre3D Game
by Henri Verbeet 25 Jan '12

25 Jan '12

On 22 January 2012 19:44, Detlef Riekenberg <wine.dev(a)web.de> wrote: > - if (usage & ~handled) > + static DWORD reported_once; > + > + if (usage & ~(handled | reported_once)) > + { > + reported_once |= (usage & ~handled); > FIXME("Unhandled usage flags %#x.\n", usage & ~handled); > + } I don't think so.

6 7

Re: ieframe: Fixed a typo in IDocObjectService::FireNavigateComplete2
by Marvin 25 Jan '12

25 Jan '12

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=16644 Your paranoid android. === WNT4WSSP6 (32 bit webbrowser) === webbrowser.c:3152: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3152: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3152: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3152: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3245: Test failed: Creating WebBrowser object failed: 80040154 === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2502: Test failed: expected GetOverridesKeyPath webbrowser.c:2506: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2507: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:2116: Test failed: put_Resizable failed: 80004001 webbrowser.c:2117: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2121: Test failed: put_Resizable failed: 80004001 webbrowser.c:2122: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2502: Test failed: expected GetOverridesKeyPath webbrowser.c:2506: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2507: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:407: Test failed: unexpected call Exec_SETDOWNLOADSTATE_0 webbrowser.c:2116: Test failed: put_Resizable failed: 80004001 webbrowser.c:2117: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2121: Test failed: put_Resizable failed: 80004001 webbrowser.c:2122: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2502: Test failed: expected GetOverridesKeyPath webbrowser.c:2506: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2507: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:466: Test failed: unexpected nCmdID 29 webbrowser.c:986: Test failed: unexpected call GetContainer webbrowser.c:514: Test failed: unexpected call webbrowser.c:986: Test failed: unexpected call GetContainer webbrowser.c:514: Test failed: unexpected call webbrowser.c:2665: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2792: Test failed: expected TranslateUrl webbrowser.c:2793: Test failed: expected Invoke_BEFORENAVIGATE2 webbrowser.c:2795: Test failed: expected Invoke_PROPERTYCHANGE webbrowser.c:2801: Test failed: ReadyState = 1, expected 4 webbrowser.c:2611: Test failed: ReadyState = 1, expected 4 webbrowser.c:816: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:832: Test failed: unexpected call Invoke_BEFORENAVIGATE2 webbrowser.c:839: Test failed: ReadyState = 1, expected 4 webbrowser.c:611: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:611: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL webbrowser.c:618: Test failed: unexpected call Invoke_AMBIENT_USERAGENT webbrowser.c:622: Test failed: unexpected call Invoke_AMBIENT_PALETTE webbrowser.c:1536: Test failed: unexpected call GetOptionKeyPath webbrowser.c:356: Test failed: unexpected call QueryStatus_SETPROGRESSTEXT webbrowser.c:816: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:816: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:816: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:816: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:466: Test failed: unexpected nCmdID 26 webbrowser.c:466: Test failed: unexpected nCmdID 29 webbrowser.c:986: Test failed: unexpected call GetContainer webbrowser.c:514: Test failed: unexpected call webbrowser.c:788: Test failed: ReadyState = 1, expected 4 webbrowser.c:1547: Test failed: unexpected call GetDropTarget webbrowser.c:986: Test failed: unexpected call GetContainer webbrowser.c:514: Test failed: unexpected call webbrowser.c:2665: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:3188: Test failed: doc != doc2 webbrowser.c:611: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:611: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL webbrowser.c:618: Test failed: unexpected call Invoke_AMBIENT_USERAGENT webbrowser.c:622: Test failed: unexpected call Invoke_AMBIENT_PALETTE webbrowser.c:1536: Test failed: unexpected call GetOptionKeyPath webbrowser.c:356: Test failed: unexpected call QueryStatus_SETPROGRESSTEXT webbrowser.c:466: Test failed: unexpected nCmdID 26 webbrowser.c:466: Test failed: unexpected nCmdID 29 webbrowser.c:986: Test failed: unexpected call GetContainer webbrowser.c:514: Test failed: unexpected call webbrowser.c:1547: Test failed: unexpected call GetDropTarget webbrowser.c:986: Test failed: unexpected call GetContainer webbrowser.c:514: Test failed: unexpected call webbrowser.c:2658: Test failed: expected TranslateUrl webbrowser.c:2665: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:3195: Test failed: doc != doc2 webbrowser.c:611: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:611: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL webbrowser.c:618: Test failed: unexpected call Invoke_AMBIENT_USERAGENT webbrowser.c:622: Test failed: unexpected call Invoke_AMBIENT_PALETTE webbrowser.c:1536: Test failed: unexpected call GetOptionKeyPath webbrowser.c:356: Test failed: unexpected call QueryStatus_SETPROGRESSTEXT webbrowser.c:466: Test failed: unexpected nCmdID 26 webbrowser.c:466: Test failed: unexpected nCmdID 29 webbrowser.c:986: Test failed: unexpected call GetContainer webbrowser.c:514: Test failed: unexpected call webbrowser.c:1547: Test failed: unexpected call GetDropTarget webbrowser.c:986: Test failed: unexpected call GetContainer webbrowser.c:514: Test failed: unexpected call webbrowser.c:2658: Test failed: expected TranslateUrl webbrowser.c:2665: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2792: Test failed: expected TranslateUrl webbrowser.c:2793: Test failed: expected Invoke_BEFORENAVIGATE2 webbrowser.c:2801: Test failed: ReadyState = 1, expected 4 webbrowser.c:2611: Test failed: ReadyState = 1, expected 4 webbrowser.c:832: Test failed: unexpected call Invoke_BEFORENAVIGATE2 webbrowser.c:839: Test failed: ReadyState = 1, expected 4 webbrowser.c:611: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:611: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:614: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL webbrowser.c:618: Test failed: unexpected call Invoke_AMBIENT_USERAGENT webbrowser.c:622: Test failed: unexpected call Invoke_AMBIENT_PALETTE webbrowser.c:1536: Test failed: unexpected call GetOptionKeyPath webbrowser.c:356: Test failed: unexpected call QueryStatus_SETPROGRESSTEXT webbrowser.c:466: Test failed: unexpected nCmdID 26 webbrowser.c:466: Test failed: unexpected nCmdID 29 webbrowser.c:986: Test failed: unexpected call GetContainer webbrowser.c:514: Test failed: unexpected call webbrowser.c:788: Test failed: ReadyState = 1, expected 4 webbrowser.c:1547: Test failed: unexpected call GetDropTarget Timeout

1 0

Resource accelerators discrepancies
by Frédéric Delanoy 25 Jan '12

25 Jan '12

Hi Alexandre, After your addition of accelerators to po file for winefile (among others) [fe021a44 winefile: Add message contexts for accelerators that can be translated], there seems to be some discrepancies: #: winefile.rc:202 msgctxt "accelerator Fullscreen" msgid "^S" vs #: winefile.rc:70 msgid "F&ull Screen\tCtrl+Shift+S" and #: winefile.rc:201 winemine.rc:99 msgctxt "accelerator Exit" msgid "X" vs #: winefile.rc:38 winemine.rc:46 msgid "E&xit\tAlt+X" winefile.rc contains: - "X", ID_FILE_EXIT, VIRTKEY, ALT - "S", ID_VIEW_FULLSCREEN, VIRTKEY, SHIFT, CONTROL + "#msgctxt#accelerator Exit#X", ID_FILE_EXIT, ALT + "#msgctxt#accelerator Fullscreen#^S", ID_VIEW_FULLSCREEN, SHIFT So, - is there a way/shouldn't the "label\tshortcut" menu entries be automated somehow? E.g. so the accelerator is automatically extracted - is only the Control modifier shown in msgids? E.g. "X" while the shortcut is Alt-X. That's a bit inconsistent IMHO Frédéric

2 1

Re: setupapi: add a stub for SetupAddToDiskSpaceListA/W
by Dmitry Timoshkov 25 Jan '12

25 Jan '12

Austin English <austinenglish(a)gmail.com> wrote: > +BOOL WINAPI SetupAddToDiskSpaceListA(HDSKSPC DiskSpace, PCSTR TargetFilespec, > + LONGLONG FileSize, UINT Operation, > + PVOID Reserved1, UINT Reserved2) I think it's been mentioned numerous times already about usage hungarian or capitalzed variable names in Wine code. -- Dmitry.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel