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

Congratulations!
by Juan Lang March 30, 2010

March 30, 2010

Hi Matteo, just wanted to congratulate you on getting your DRDXAssembleShader patches accepted. I know it can take a fair amount of persistence to get something substantial committed, and it seems that many lack the patience. Well done! --Juan

2 1

Re: [PATCH 6/7] Use surface_is_offscreen instead of directly looking at the swapchain.
by Henri Verbeet March 30, 2010

March 30, 2010

On 30 March 2010 21:19, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > @@ -4062,7 +4062,7 @@ static HRESULT IWineD3DSurfaceImpl_BltOverride(IWineD3DSurfaceImpl *This, const > * Also beware that the front buffer's surface size is screen width x screen height, > * whereas the real gl drawable size is the size of the window. > */ > - if (dstSwapchain && (IWineD3DSurface *)This == dstSwapchain->frontBuffer) { > + if (!surface_is_offscreen((IWineD3DSurface *)This)) { > RECT windowsize; > POINT offset = {0,0}; > UINT h; This looks wrong, the code is checking if the surface is the front buffer, not if it's onscreen.

1 0

Summer of Code applicant with ambition!
by John Koelndorfer March 30, 2010

March 30, 2010

Hello wine-devel, My name is John and I'm a computer science major at the University of Minnesota, Twin Cities campus. I've made quite a bit of use of Wine before (and I have purchased Crossover) and I'm inspired to give something back to the project. I have fairly ambitious goals for myself (maybe too much so) so I wanted to let you guys know who I am and what I'd like to do, then hopefully gain some insight into whether or not what I am considering is reasonable. My experience is roughly as follows: * I am familiar with C. I'm not an expert developer by any stretch but I can certainly get by. I have some knowledge of Git. * I don't have any Windows development experience outside of some exposure to .NET a long time ago. * I have not submitted a patch to the Wine project. I hope to change this in the near future. I've looked at a little bit of the source code. * I have high standards for myself. Whether or not they are high enough to meet Alexandre's expectations... perhaps time will tell. :-) * I'm a really fast learner. Maybe this is my single most redeeming quality. All that being said, my goal for the summer would be to really dig into the D3D stuff, optimizing what is already completed and adding to what is not. I'm a gamer myself, so I have an arsenal of programs with which to test (and a Windows installation to compare to). Do you think this goal is reasonable? If not, I could start somewhere smaller and work my way up. I'm certainly open to suggestions. Thanks! John

2 2

Implementation of WIndows Gaming APIs as GSoC project
by Mariusz Pluciński March 30, 2010

March 30, 2010

Hello I'm Mariusz Pluciński, student of Information Technology in Gdańsk University of Technology (Poland). I decided to apply to Google Summer of Code in your project, cause I've been fascinated in Wine for a long time (without Wine, migration to open source OS would not be possible for me). In my opinion, one of the biggest problem for Wine is problems with support games written for MS Windows, so making progress in this area is something which I want to work on. I know C programming language very well, just as programming in Microsoft Windows APIs and Microsoft's COM technology. I also have some experience in working on open source - in Kdenlive project (video editor). I do a polish translation there, but I have also sent several patches to source code. In the past I was also reading some parts of Wine source code, so I know somewhat about how Wine's works and how it's code looks. In Google Summer of Code, I'm interested in implementation of new gaming APIs created by Microsoft for Windows Vista and enlarged in Windows 7. Main part of this is implementation of four COM interfaces: IGameExplorer, IGameExplorer2, IGameStatistics and IGameStatisticsMgr. In the bugzilla there's stub implementation of IGameExplorer interface, which may be good start point for me in development. Main parts of task will probably be creation of database to store games' data and parser of GDF files (Game Definition File). In favorable circumstances, if the APIs implementation is done fast enough, I will start work on simple equivalent of Windows Game Explorer application. It would be nice for Wine's users to control their games from one application, similar way as they do it in MS Windows. Also, application will use Game Statistics interfaces, so it will be good practical test for these interfaces. I hope my idea will get your acceptance. Thanks

1 0

Re: 10/10 wined3d: use RECT instead of WINED3DRECT in stretch_rect_fbo [try2]
by Alexandre Julliard March 30, 2010

March 30, 2010

Roderick Colenbrander <thunderbird2k(a)gmail.com> writes: > Hi, > > While working on some other patches, I spotted a small error in the > call to surface_get_rect for the source rectangle. I was passing > 'This' (destination) instead of Src. It doesn't work: ../../../tools/runtest -q -P wine -M ddraw.dll -T ../../.. -p ddraw_test.exe.so visual.c && touch visual.ok wine: Unhandled page fault on read access to 0x00000050 at address 0x68e87fc9 (thread 0024), starting debugger... Unhandled exception: page fault on read access to 0x00000050 in 32-bit code (0x68e87fc9). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:68e87fc9 ESP:0032f110 EBP:0032f248 EFLAGS:00010246( R- -- I Z- -P- ) EAX:00000001 EBX:68ed8d20 ECX:00000280 EDX:00000000 ESI:00000000 EDI:000001e0 Stack dump: 0x0032f110: 00146350 68ed2dbc 0032f228 00110014 0x0032f120: beef0202 7d7fb5c0 7bc4907b 68ed8d20 0x0032f130: 00147240 00000072 0032f198 68df9e66 0x0032f140: 00147240 00000080 00000080 00000001 0x0032f150: 0012fc70 00000000 00000072 00000000 0x0032f160: 00147000 686cb060 00000000 00010000 Backtrace: =>0 0x68e87fc9 IWineD3DSurfaceImpl_BltOverride+0x1529(This=<is not available>, DestRect=<is not available>, SrcSurface=(nil), SrcRect=(nil), Flags=0x1000400, DDBltFx=0x32fa9c, Filter=WINED3DTEXF_POINT) [/home/julliard/wine/wine/dlls/wined3d/surface.c:284] in wined3d (0x0032f248) 1 0x68e8b1e7 IWineD3DSurfaceImpl_Blt+0xb7(iface=<register ESI not in topmost frame>, DestRect=(nil), SrcSurface=<register EDI not in topmost frame>, SrcRect=(nil), Flags=0x1000400, DDBltFx=0x32fa9c, Filter=WINED3DTEXF_POINT) [/home/julliard/wine/wine/dlls/wined3d/surface.c:4271] in wined3d (0x0032f2d8) 2 0x686ae1bb IDirectDrawSurfaceImpl_Blt+0x1ab(iface=0x12b888, DestRect=<register ESI not in topmost frame>, SrcSurface=(nil), SrcRect=(nil), Flags=<register EDI not in topmost frame>, DDBltFx=0x32fa9c) [/home/julliard/wine/wine/dlls/ddraw/surface.c:806] in ddraw (0x0032f348) 3 0x686b0717 IDirectDrawSurface3Impl_Blt+0x47(This=0x12b88c, prcDst=(nil), pSrcSurf=(nil), prcSrc=(nil), dwFlags=0x1000400, pFX=0x32fa9c) [/home/julliard/wine/wine/dlls/ddraw/surface_thunks.c:113] in ddraw (0x0032f378) 4 0x68663213 D3D1_TextureMapBlendTest+0x263() [/home/julliard/wine/wine/dlls/ddraw/tests/visual.c:1302] in ddraw_test (0x0032fb88) 5 0x68669bb5 func_visual+0x1375() [/home/julliard/wine/wine/dlls/ddraw/tests/visual.c:2979] in ddraw_test (0x0032fd48) 6 0x6866a82e run_test+0x14e(name=<is not available>) [/home/julliard/wine/wine/dlls/ddraw/tests/../../../include/wine/test.h:543] in ddraw_test (0x0032fd98) 7 0x6866aa02 main+0x132(argc=<couldn't compute location>, argv=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ddraw/tests/../../../include/wine/test.h:592] in ddraw_test (0x0032fe58) 8 0x6866ab9c __wine_spec_exe_entry+0x7c(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:37] in ddraw_test (0x0032fea8) 9 0x7b8584c4 start_process+0x54(peb=<register ESI not in topmost frame>) [/home/julliard/wine/wine/dlls/kernel32/process.c:989] in kernel32 (0x0032fee8) 10 0x7bc71344 call_thread_func+0xc() in ntdll (0x0032fef8) 11 0x7bc71510 call_thread_entry_point+0x70(entry=0x7b858470, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2459] in ntdll (0x0032ffc8) 12 0x7bc4cfca in ntdll (+0x3cfca) (0x0032ffe8) 0x68e87fc9 IWineD3DSurfaceImpl_BltOverride+0x1529 [/home/julliard/wine/wine/dlls/wined3d/surface.c:284] in wined3d: movl 0x50(%edx),%eax 284 rect_out->right = This->currentDesc.Width; -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winmm: For MCI parsing, use 64bit compatible structures.
by Eric Pouech March 29, 2010

March 29, 2010

Joerg-Cyril.Hoehle(a)t-systems.com a écrit : > Hi, > > I believe this patch can stand on its own, regardless of whether > we discover an MCI_INTEGER64 type or similar later (cf. bug 22146). > > It is not all about Wine64. I have two others in my queue: > - One deals with HWND and the like in the MCI_XYZ_PARMS. > - Another adds more tests that do not depend on sound being configured. > These are not ready yet for submission. > > Yet this first patch is good enough to start gathering results on test.winehq. > André's machine basically passed the MCI tests no worse than Wine32 with it. > > This patch depends on the Sysinfo patch from earlier today. > > Regards, > Jörg Höhle > > ------------------------------------------------------------------------ > > > this patch is ugly as hell... and it still believe we can do the MCI parser without knowing about MCI structures internals A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

1 0

Re: [PATCH 1/5] winmm: Improve MCI's Sysinfo command.
by Eric Pouech March 29, 2010

March 29, 2010

Joerg-Cyril.Hoehle(a)t-systems.com a écrit : > Hi, > > this is the first of a series of patches I started writing last year. > It suffered from the typical "some patches are 100% complete but > follow others that are only 80%" syndrome. Now I filled in the missing parts. > > The fifth implements more tests to prove the pertinence of the code patches. > > Regards, > Jörg Höhle > > ------------------------------------------------------------------------ > > > did you test the 16 => 32 bit conversion for the MCI_ALL_DEVICE ? actually, I'd say it belongs to the 16=>32 mci message mapper, not in generic 32bit code A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

1 0

on most hated "OS" in the history of computing
by Saulius Krasuckas March 29, 2010

March 29, 2010

Hello, This article is about Windows 3.x history and "architecture": http://www.openwatcom.org/index.php/Exploring_Windows_3.x It was nice sunday reading :) for me. S.

3 5

Re: kernel32: Fix moving a file to the same one
by Alexandre Julliard March 29, 2010

March 29, 2010

André Hentschel <nerv(a)dawncrow.de> writes: > diff --git a/dlls/kernel32/path.c b/dlls/kernel32/path.c > index 2b69e8c..d34b3a7 100644 > --- a/dlls/kernel32/path.c > +++ b/dlls/kernel32/path.c > @@ -1031,6 +1031,9 @@ BOOL WINAPI MoveFileWithProgressW( LPCWSTR source, LPCWSTR dest, > if (flag & MOVEFILE_WRITE_THROUGH) > FIXME("MOVEFILE_WRITE_THROUGH unimplemented\n"); > > + if (!strcmpiW( source, dest )) > + return TRUE; /* we are done */ > + There's a lot more to this than simply comparing the specified paths. -- Alexandre Julliard julliard(a)winehq.org

1 0

Reorganizing msvcrt related dlls implementation
by Piotr Caban March 29, 2010

March 29, 2010

Hi, Recently I was working on some msvcrt/msvcr90 functions. I found few problems related to how the implementation is organized: - Some of the functions are invoking invalid_parameter, msvcrt is not allowing to change it, msvcr90 exports _set_invalid_parameter_handler. - create_locale (not available on msvcrt) needs almost exactly the same internal functions as set_locale. I see few ways of implementing this functions: - Copy implementations of functions that are invoking invalid_parameter_handler to msvcr90. This will introduce lots of code duplication in future (currently most of functions that should invoke invalid_parameter_handler are not implemented or are not calling it). Almost whole locale.c file will be copied. - Create wine specific dll, forward msvcrt and msvcr90 calls to it. - Move implementation of some functions from msvcrt to msvcr90. It'll probably introduce similar problems when newer msvcrXX appears. What solution is preferred? Any other ideas? Cheers, Piotr

2 1