March 2011 - Wine-Devel - list.winehq.org

Re: [PATCH2/2] winmm: PlaySound concurrency cleanup.
by Eric Pouech March 28, 2011

March 28, 2011

sharing a global variable between threads without proper sync protection or atomic operation is the wrong thing to do moreover you're doing several unrelated changes in the same patch, please split up A+ 2011/3/28 <Joerg-Cyril.Hoehle(a)t-systems.com> > Hi, > > - PlaySound_Alloc does not call _Free anymore, so it does not use WINMM_cs > anymore, which makes it easier to reason about use of critical sections. > - psStopEvent was never used like an event rather than a boolean. > - No need to muck with WHDR_DONE. > - No need to keep the unused thread handle object around. > - Abort the playloop in case of error, like I did for mciwave. The error > may not be transient. > > - Free waveHdr and hEvent after closing hWave. Either you believe that > WAVERR_STILLPLAYING can happen, then obviously waveHdr is in use and must > not yet be freed, or you believe checking for STILLPLAYING is a waste of > code because waveOutReset must have done its job. > > I should have added an ERR() message. > > One should think again about what to do in such a case. Why/when would > sleep help? User-friendlier might be not to wait, not to free WaveHdr > and accept to leak resources in such a case. > > Actually, waveOutClose can fail with STILLPLAYING because waveOutReset > can fail. If you look at winealsa, you'll see it uses CreateEvent to > synchronously wait for acknowledge of the message. Now guess what > happens if CreateEvent fails because memory is tight? > What happens in the app when waveOutClose's CreateEvent fails? > It's always tough to reason about the many error paths. > > Regards, > Jörg Höhle > > > > -- -- Eric Pouech

2 1

w9x/ME users, please test (mciGet/SetYieldProc)
by Joerg-Cyril.Hoehle＠t-systems.com March 28, 2011

March 28, 2011

Hi, Testbot job #10124 contains a test that works perfectly on machines since w2k, but much to my surprise, mciGetYieldProc returns NULL,0 on testbot's win9x machines. If you have a w9x or a WinME machine, I'd appreciate if you could run the test too. Download & invoke winmm_test.exe midi http://testbot.winehq.org/GetFile.pl?JobKey=10124&StepKey=2 test & patch code: http://testbot.winehq.org/GetFile.pl?JobKey=10124&StepKey=1 If you happen to know why mciGet/SetYieldProc yield NULL/FALSE, please let me hear. NULL looks like an error status than a valid "old value is truly NULL" result. mciSetYieldProc returns FALSE as an error indicator, whereas I'd expect mciSetYieldProc(id,NULL,<any>) to be a valid call. Testbot's w9x machines return: mci.c:639: Test failed: original yieldproc 00000000 mci.c:640: Test failed: Break key is vkey 0 mci.c:643: Test failed: mciSetYieldProc NULL mci.c:648: Test failed: Break key changed to vkey 0 mci.c:664: Test failed: Break key changed to vkey 0 mci.c:674: Test failed: mciSetYieldProc restore Thank you, Jörg Höhle

1 0

Wine compatibility
by Adam Kłobukowski March 28, 2011

March 28, 2011

Hello I have a question for Wine developers, not 100% related to development, so: please excuse me for wasting your time. Officially sated, Wine wants to be 'bug-by-bug' implementation of Windows APIs. On the other hand, it is known that all (?) version of Windows contain 'hacks' to make important and not well behaving applications work (mostly workarounds for application bugs). This 'hacks' work by detecting that a faulty app is running, and turning special 'hack' mode for such app. Because of this, black box testing often used by Wine developers will not detect such workarounds, and applications that (seem to) work perfectly well under Windows, will not work under Wine. Is there a solution for this? What is Wine devs position on this matter? Side question: Windows could make a 'clean start' with 64 bit environment, did they? Thank you for your time. Adam Klobukowski

5 6

Re: d3dx9_36: Implement D3DXCreateBox
by Joris Huizer March 28, 2011

March 28, 2011

Hello, In this patch, one part seemed strange to me: You are declaring vertices as static memory: + static FLOAT vertices[144] But you are changing the values during the function: + + for(i = 0; i< 24; i++) + { + vertices[6 * i ] *= width; + vertices[6 * i + 1] *= height; + vertices[6 * i + 2] *= depth; + } + Given that original values are never restored, I think you can not mark the array as static, otherwise incorrect values are used after the first call. The other arrays are not adapted, so they are fine as static memory (And you may in fact mark those static const) HTH, Joris

4 5

RFC: Remove unimplemented application menus?
by Francois Gouget March 27, 2011

March 27, 2011

Some Wine programs, winefile in particular, have a lot of unimplemented menus. That is you can see the menu entry but clicking on it only gives you a 'Not yet implemented' error dialog (or does nothing in the case of iexplore). For instance just for the first two winefile menus none of the following are implemented: File -> Print... File -> Associate... File -> Search... File -> Select Files... Disk -> Share as... Disk -> Remove Share... Disk -> Select Drive... I think such a situation is bad: * Having tons of unimplemented menus looks amateurish. * It's very confusing. You see tons of menus except over 50% of them don't work. So it makes the GUI more complex with no benefit. * I suspect most of these menus have been unimplemented for years so there is little hope of seeing them improve any time soon. * For a number of them it's questionable whether it makes sense to implement them in Wine at all as they correspond to tasks that better belong to the native system facilities (Share as for instance). * I doubt they serve any significant compatibility purpose. * In the mean time they generate more work for translators and translation reviewers. * It generates more work for anyone checking whether the GUI is consistent / follows human interface guidelines (wrt. ellipses for instance). So I propose to simply remove unimplemented menus. When / if someone ever decides to implement some of the corresponding functionality, adding the corresponding code and GUI bits back should not be too hard. Objections? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ In a world without fences who needs Gates?

2 1

RFC: wined3d: Check for and use FBO blits early in BltOverride
by Chris Robinson March 27, 2011

March 27, 2011

IDirect3DDevice9::StretchRect is used to stretch-blit between video memory surfaces. It's implemented by calling IWineD3DSurfaceImpl_Blt, which itself will attempt IWineD3DSurfaceImpl_BltOverride to accelerate it. However, BltOverride will not accelerate the blit if neither surface is a swapchain or active render target 0, and will fall back to a sysmem->sysmem blit with possible conversions. This seems to happen in between every post-processing (screen-space shader) pass with Oblivion Graphics Extender and Morrowind Graphics Extender, which causes a severe loss in performance. After some testing and talking with Henri, it seems a number of checks aren't needed if FBO blits are available, particularly the swapchain/active render target checks. The attached patch makes BltOverride check for FBO blits earlier, which helps it catch more cases where blits can be accelerated. It provides a significant improvement with the aforementioned programs. I'm not sure of the full consequences of this move, however, particularly with earlier DX versions. Hence a request for comments.

3 3

Re: [1/4] wined3d/context: Track the number of render targets in FBO entries.
by Henri Verbeet March 27, 2011

March 27, 2011

On 21 March 2011 21:56, Adam Martinson <amartinson(a)codeweavers.com> wrote: > > Cuts CPU time in context_apply_fbo_state() in half. This is meaningless. Which applications, and how much time of the total is spent in context_apply_fbo_state()? How does this translate into concrete thing like frame time? More importantly, why does this change come before the one for tracking FBO dirty state? Avoiding redundant FBO entry comparisons completely is likely to have a much more significant effect than making the comparisons themselves slightly cheaper in very specific applications.

2 4

Re: d3dx10: Float16To32Array and Float32To16Array (GSoC)
by Stefan Dösinger March 27, 2011

March 27, 2011

On Sunday 20 March 2011 22:29:34 Joshua Beck wrote: > I erred on the side of caution because I didn't want to spend all summer > working on a project that I couldn't finish. Finding the right amount of work is certainly tricky. Luckily d3dx9 has many functions, so if you find out that you have plenty of time left you can include extra work in your project later on. You don't have to get the set of work perfect at the start - reevaluating the amount of work needed and adjusting the goals during the project is part of gsoc. However, finding a most likely doable, but not overly simple set of work does improve the application. We'll provide feedback on this(as I just did, I hope others who know the library better will jump in if I am telling you incorrect things) > However I do have other > ideas that I would also like to implement. For instance, I would be > willing to implement the D3DXSave[Surface/Texture]ToFile* functions for > all file formats currently supported by WINE. Wrt this specific function we already have some related infrastructure for D3DXLoadSurfaceFrom* . Also other parts of Wine(gdi32.dll, windowscodecs.dll) have functions for handling various on-disk file formats which can(and should) be used. (That's just some generic implementation hint, it doesn't mean that it makes the idea good or bad)

2 2

Re: [GSoC] Merge winecfg and Control Panel
by wine.dev＠web.de March 27, 2011

March 27, 2011

Dear Tony Welcome to Wine. > > After all the searches, I still do not have an overall idea of how to > create an control panel applet. From my current understanding, if I put the > cpl (dll) file in "~/.wine/drive_c/windows/system32/", wine control will > recognize it automatically, right? When you add a new cpl, the wine build system does this for you. > If so, is there any instructions on how to build a simple applet under wine > (even one that does nothing could work for me). I'd really like to try > create and build some test applet in order to understand it better. As always: Read the source. What you try to do (test applet) is how i started with inetcpl.cpl a while ago. git has a web interface with a history and the first commit for inetcpl.cpl is a minimalistic control applet. ( http://source.winehq.org/git/wine.git/history/HEAD:/dlls/inetcpl.cpl ) -- by by ... Detlef

3 2

Re: wined3d: check for ARB_fragment_program in arbfp_blit_supported
by Stefan Dösinger March 26, 2011

March 26, 2011

> <0001-wined3d-check-for-ARB_fragment_program-in-arbfp_blit.patch> Considering this statement in select_blit_implementation, directx.c: if ((ps_selected_mode == SHADER_ARB || ps_selected_mode == SHADER_GLSL) && gl_info->supported[ARB_FRAGMENT_PROGRAM]) return &arbfp_blit; else return &ffp_blit; How does wined3d end up using arbfp_blit?

2 2

Re: [2/2] comctl32/listview: Fix edit box text limit
by Marvin March 26, 2011

March 26, 2011

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=10152 Your paranoid android. === WNT4WSSP6 (32 bit listview) === listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259

1 0

Re: [1/2] comctl32/listview: Adjust dispinfo text buffer length
by Marvin March 26, 2011

March 26, 2011

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=10151 Your paranoid android. === WNT4WSSP6 (32 bit listview) === listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259

1 0

GSoC: Implement the Explorer
by Jay Yang March 26, 2011

March 26, 2011

Hello, Since my first proposal got no response at all, I thought I'd offer another possible project I'm interested in. I looked a little into the "Implement the Explorer" project idea listed on the Summer of Code page on the wine wiki. I have a few questions as to what parts need to be implemented. Clearly, as stated by the description on the Summer of Code page, we have winefile, which does some of the things expected of explorer, but how far is winefile from a correct explorer implementation? Also would implementing Shell Extensions be a good Summer of Code project? In particular, I think it would be nice to have things like TortiseSVN working in wine. Thanks -- Jay Yang

3 4

Re: ole32/tests: Test for correct storage creation.
by Dmitry Timoshkov March 26, 2011

March 26, 2011

Roman Dadkov <romand(a)etersoft.ru> wrote: > + IStorage_Commit(stg, STGC_DEFAULT); > + IStorage_Release(stg); > + GetHGlobalFromILockBytes(ilb, &hMem); It would be helpful to test the results of the above calls too. > + todo_wine > + ok(!memcmp((BYTE*)hMem, StandardMagic, 8), "Incorrect storage creation\n"); > + todo_wine > + ok(!memcmp(((BYTE*)hMem+8), NullableField, 16), "Incorrect storage creation. Field is not reset\n"); > + todo_wine > + ok(!memcmp(((BYTE*)hMem+34), NullableField, 10), "Incorrect storage creation. Field is not reset\n"); What is this supposed to show? -- Dmitry.

2 1

Re: Ubuntu's next release and raising hard ulimit on ubuntu
by Dan Kegel March 26, 2011

March 26, 2011

Nope, this isn't about the select() limit. The soft limit on file handles should stay at 1024 so apps that use select() don't break. Apps like wine that have already switched away from select should be able to raise their soft limit if they want more file desciptors. Wine already does this. But ubuntu is misconfigured by default with a hard limit identical to the soft limit. It's time for ubuntu to fix this by raising the default hard limit on file desciptors in /etc/security/limits.conf. Users who need this can edit that file to make their games work, but they shouldn't have to. (Topposted from my cellphone) On Mar 25, 2011 8:03 AM, "Paul Chitescu" <paulc(a)voip.null.ro> wrote: On Friday 25 March 2011 03:26:25 pm Dan Kegel wrote: > Scott, correct me if I'm wrong, but does Natt... This is not an Ubuntu limitation but rather of the (g)libc API implementation. At least on glibc it is possible to increase the FD_SETSIZE at build time. Been there, done that, got the T-shirt. No need for header patching. http://yate.null.ro/websvn/filedetails.php?repname=yate&path=%2Ftrunk%2Feng… Caveat: FD_... operations take longer if FD_SETSIZE is increased. On all relevant platforms it is possible to check if a fd is above the limit. The application code must do so. Best is to internally replace select() with poll() on platforms that support it.

1 1

Ubuntu's next release and raising hard ulimit on ubuntu
by Dan Kegel March 26, 2011

March 26, 2011

Scott, correct me if I'm wrong, but does Natty still have the hard limit of 1024 files open per process? If so, should be ask people to go vote for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/663090 ? Getting that limit raised might avoid increasing numbers of support requests from users who can't figure out why Wine can't run their p2p downloader ( http://bugs.winehq.org/show_bug.cgi?id=25015 ).

3 2

Re: urlmon: Use unescaped Urls for FTP actions (try 3)
by Nikolay Sivov March 25, 2011

March 25, 2011

On 3/26/2011 01:22, André Hentschel wrote: > Jacek gave me some advice and we made sure we have no other option to unescape the url. > --- > dlls/urlmon/ftp.c | 6 ++++++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/dlls/urlmon/ftp.c b/dlls/urlmon/ftp.c > index c9d43b8..5857818 100644 > --- a/dlls/urlmon/ftp.c > +++ b/dlls/urlmon/ftp.c > @@ -60,12 +60,18 @@ static HRESULT FtpProtocol_open_request(Protocol *prot, IUri *uri, DWORD request > { > FtpProtocol *This = impl_from_Protocol(prot); > BSTR url; > + DWORD len; > HRESULT hres; > > hres = IUri_GetAbsoluteUri(uri,&url); > if(FAILED(hres)) > return hres; > > + len = strlenW(url); No need to slow down with strlenW, it's a BSTR. > + hres = UrlUnescapeW((LPWSTR)url, NULL,&len, URL_UNESCAPE_INPLACE); > + if(FAILED(hres)) > + return hres; > + Leak! And why a cast by the way?

1 0

[GSoC] Continue work on Games Explorer
by Mariusz Pluciński March 25, 2011

March 25, 2011

Hello, wine-devel In the last year's GSoC, I was working on implementation of Games Explorer features under Wine. I have successfully created it's own interfaces and made them working. However, the task proved harder than I thought before, so I did not create a user-interface part of the library. My idea for this summer is to finish the implementation of gameux.dll - writing the Shell Extension for GE. It would behave almost exact as the Windows equivalent - it should be able to display registered games as shell items, with possibility to run them, see the statistics etc. Having this should give user-experience a great deal. However, in my opinion it would be also a good way to check and extend the existing implementation of shell32. As far as I know, there is currently no real shell extension being part of Wine, so the working one would increase compatibility a much. There will be probably a problem with making my extension usable for user, as there's no working explorer currently in Wine. However, as I see, the implementation of explorer is one of popular proposal this year. In my opinion, it would be good idea to cooperate my work on GE Shell Extension with the person who will implement explorer.exe (if both ideas will be selected for realization). This would probably improve the quality of both projects. Summarizing, my project assumes following things to do: - write testing set to run under Windows. Tests will read the data from GE using it's shell interfaces. - creating stubs for shell interfaces. This will include following interfaces IShellFolder(2/3?), IShellView, IPersistFolder, IEnumIDList, IContextMenu, and probably a few other. I have created some stubs at the end of last GSoC, but never committed them, as they were requiring a few improvements. - implementing interfaces using the existing infrastructure inside of gameux.dll. Routines giving access to list of installed games were written by me last year, but there are still some missing parts which must be filled to let shell interfaces return proper data. - extending and fixing parts of shell32 (or other libraries) if required. This is mostly undefined part of task, but I've listed it here, cause I suppose this could take significant part of project's time. If there will be still time after finishing the points above, I would like to add one feature from my last-year proposal: a legacy games support. When Microsoft introduced the Games Explorer in Vista, they provided a big set of definitions of currently existing games to make them visible in GE, without requirement of modifications in games. My idea is to extend Wine's Application Database to allow it serve as legacy games database for our GE. This would increment an user experience from using the tool. My name is Mariusz Pluciński. I'm 20 years old student of Information Technology in Gdańsk University of Technology in Poland. Last year I was successfully participating in GSoC in Wine project (project name was "Implementation of Windows Game Explorer equivalent "), so my knowledge seems to be enough to continue work with even better results. Comments are welcome -- Best regards Mariusz Pluciński

1 0

[GSoC] Implementing missing DirectInput8 features
by Lucas Zawacki March 25, 2011

March 25, 2011

Hello, I'm Lucas Fialho Zawacki a Computer Science undergrad at UFRGS university in Brazil. I'm very interested in working with Wine for the Google Summer of Code and have decided to approach the implementation of DirectInput8 missing features. I'm a long time Wine user, but I'd never looked at it from a developer point of view, so for the past few days I have been reading Wine's developer documentation and familiarizing myself with it's architecture and with the parts I intend to work on. At the moment, I don't have a clear understanding of how the implementation should be done so I'm reading a lot of material about dinput and dinput8 and building some documentation to help me. After some polishing I hope to be able to contribute it to Wine too. A little word about me. I've been using the C programming language for almost three years, so I'm very familiar with it. For the last two years I've worked on a research project as a C/C++ programmer, implementing a decision system for a F180 Small Size League Robot Soccer Team (see http://small-size.informatik.uni-bremen.de/) and http://code.google.com/p/robopet/ . I'm a heavy Linux user and I'm very comfortable with it's tools used for programming. That's it. I'm eager to get your feedback about this. My proposal will be ready in a few days. -- http://www.twitter.com/lfzawacki http://www.linesocode.wordpress.com

2 2

Re: [PATCH 07/15] d3dx9: Add ID3DXBaseEffect interface.
by Henri Verbeet March 25, 2011

March 25, 2011

2011/3/23 Rico Schüller <kgbricola(a)web.de>: > + FIXME("íface %p, desc %p stub\n", This, desc); Typo?

2 1

Re: [PATCH 03/15] d3dx9: Use size of variable instead of type.
by Nikolay Sivov March 25, 2011

March 25, 2011

On 3/23/2011 13:49, Rico Schüller wrote: > --- > dlls/d3dx9_36/effect.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > len = MultiByteToWideChar(CP_ACP, 0, srcfile, -1, NULL, 0); > - srcfileW = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, len * sizeof(WCHAR)); > + srcfileW = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, len * sizeof(*srcfileW)); > MultiByteToWideChar(CP_ACP, 0, srcfile, -1, srcfileW, len); No need to zero, if it will be filled with next call. This could a subject of next patch of course.

2 1

[GSoC] Merge winecfg and Control Panel
by Tony Zhang March 25, 2011

March 25, 2011

Hi everyone, I am a senior student double majoring in Computer Science and Math at Northern Illinois University (currently applying the CS Master Program at NIU) and I would like to participate in merging winecfg and control panel through the Google Summer of Code program. I have used wine since wine 0.9 and 'm now using wine 1.3. I like the idea that all config tools should be grouped and managed at one place, and it would be nice to have them similar to the classical windows control panel (like the control panel in wine 1.3). About my programming background, I believe I know (and love) C the best. I have not had any internships before, but I'm currently working as an undergraduate Research Assistant at NIU. It is a Proton Computed Tomography (Proton CT) project and the main language in use is C, so I do have some experience of using C in a large-scale project. I have briefly walked through Owen Rudge's code of splitting out the Desktop Integration tab into its own control panel, but have no luck in getting a decent understanding of it. So I'm hoping some of you can point me to some documents that related to this task so I can have an overall understanding of the challenges of this task. Sincerely, -- Tony (Chi Zhang)

3 5

wine 1.3.16: wrc compiler and LANGUAGE
by Gilles Depeyrot March 24, 2011

March 24, 2011

Hi, I am testing compiling an application that uses winelib with 1.3.16 (currently compiled with 1.2.2). I have an issue with the resource compiler (wrc) which doesn't understand the LANGUAGE line. When I compile resource files, I get errors resembling: file.rc:22:21: Error: syntax error The corresponding line in the file is: LANGUAGE LANG_FRENCH, SUBLANG_FRENCH If I comment the line, the compilation succeeds. Best regards, Gilles

4 7

Re: browseui/tests: COM cleanup in autocomplete.c.
by Marvin March 24, 2011

March 24, 2011

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=10131 Your paranoid android. === WNT4WSSP6 (32 bit autocomplete) === autocomplete.c:250: Test failed: CoCreateInstance(&CLSID_ACLMulti, NULL, CLSCTX_INPROC, &IID_IEnumString, (LPVOID *)&obj) failed: 80040154

1 0

Re: winex11.drv/opengl.c: add improved error handling to pglXMakeCurrent() call
by Chris Robinson March 24, 2011

March 24, 2011

On Wednesday, March 23, 2011 9:00:25 PM Joshua Beck wrote: > This patch was made against the origin, so if you've applied my previous > patch, remove that one before applying this one. > This patch makes the error message use ERR_(winediag) instead of just > ERR and is closer in style to the other error messages in opengl.c. There's some trailing whitespace in the patch.

1 0