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

Summer of Code applicant with ambition!

by John Koelndorfer

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

March 30, 2010

[PATCH 1/5] winmm: Improve MCI's Sysinfo command.

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

Hi, Eric Pouech wrote: >did you test the 16 => 32 bit conversion for the MCI_ALL_DEVICE ? Which ones do you have in mind? There are tests involving MCI_ALL_DEVICE_ID that pass on both win9x and later (also in patch #5). I wrote a few more MCI tests privately. Generally, I added (UINT16) casts in Wine when I saw test failures on Win9x platforms, then kept doing so (i.e. I'm not sure I've tested SYSINFO with a 0000FFFF deviceID on Win9x in particular or whether I simply use that pattern everywhere now after having been burnt once). There are a few patches already in git that fix a few MCI_ALL_DEVICE_ID here and there, but as you wrote yourself in the TODO header long ago, support for it is incomplete. Making "close all", "play all" etc. work is on my private TODO list, but I never started working on this particular item. >actually, I'd say it belongs to the 16=>32 mci message mapper, not in >generic 32bit code Do you mean dlls/mmsystem.dll16? I never looked at it but I don't think that's the correct place, see below. Do you mean the A/W (un)mapping? That's distinct, because it deals with string conversions only, as the name suggests, and it does not mogrify dwParam1. Current test results suggest that MCI_ALL_DEVICE_ID is not only a 16/32 issue -- at least when I equate 16 with MS-Windows 3.x -- Have a look at the mciGetDeviceID("all") test case, which returns a 16bit FFFF on Win9x, not FFFFFFFF. Therefore I believe Wine must be prepared for receiving 0000FFFF as ALL_ID from old Win9X apps or drivers -- possibly regardless of them using the A or W function entry points. Of course, a single (or few) central place(s) to convert wDeviceID=(MCIDEVICEID)(WORD)wDeviceID or wDeviceID= wDeviceID==0xFFFF ? MCI_DEVICE_ALL_ID : wDeviceID is a nice idea. That could be a distinct patch. I'm convinced this handle is truly a 16 bit entity, even after it has been upgraded to a UINT/DWORD type at some time in the past. Still, SYSINFO is a special case, as it receives a device ID not only as function argument but also in its PARMS structure. Regards, Jörg Höhle.

March 30, 2010

Re: winmm: For MCI parsing, use 64bit compatible structures.

by Eric Pouech

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)

March 29, 2010

Re: [PATCH 1/5] winmm: Improve MCI's Sysinfo command.

by Eric Pouech

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)

March 29, 2010

Re: on most hated "OS" in the history of computing

by David Gerard

On 29 March 2010 10:37, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > Why should Debian politics be a barrier to its adoption by Wine? It's not that, it's what the actual licence text says: http://opensource.org./licenses/sybase.php Read what you give away just by using the software ... - d.

March 29, 2010

Re: kernel32: Fix moving a file to the same one

by Alexandre Julliard

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

March 29, 2010

Re: Reorganizing msvcrt related dlls implementation

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > 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? For cases like this where half the functionality is already in msvcrt, I think it's OK to export the extra functions from msvcrt too. Hopefully they will get added by Microsoft sooner or later, since msvcrt is sort of a superset of all the msvcr* dlls. Just make a clear note that they are not officially exported yet. -- Alexandre Julliard julliard(a)winehq.org

March 29, 2010

Reorganizing msvcrt related dlls implementation

by Piotr Caban

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

March 29, 2010

Re: [TRY 4] [PATCH] user32: horizontal and vertical scrolling of selection in edit control

by Dmitry Timoshkov

Henry Kroll III <henry(a)comptune.com> wrote: > + if (es->region_posx < 0)EDIT_EM_LineScroll(es,-10,0); > + else if (es->region_posx > 0)EDIT_EM_LineScroll(es,10,0); > + if (es->region_posy < 0)EDIT_EM_LineScroll(es,0,-1); > + else if (es->region_posy > 0)EDIT_EM_LineScroll(es,0,1); Where do -/+10,-/+1 come from? A test case wouldn't hurt. Also please add some spacing and try to follow the indentation style of existing code. -- Dmitry.

March 29, 2010

Re: on most hated "OS" in the history of computing

by Damjan Jovanovic

On Mon, Mar 29, 2010 at 11:14 AM, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > Hello > > * On Sun, 28 Mar 2010, Damjan Jovanovic wrote: >> >> Out of interest, why were you visiting openwatcom.org? Are you also >> looking into Win16 tests for Wine? > > Kind of. I was looking into licensing problems preventing its inclusion > in Debian. Seems like I should try starting negotiation between OWC folks > and Debian-legal experts on slight license changes. > > > S. > Why should Debian politics be a barrier to its adoption by Wine? The installer from the openwatcom downloads page (version 1.8) works well - just stick to the official release and not the "Alternative Distributions" at the bottom of the page, which can't cross-compile. Then after you install it, it's a simple matter of: export WATCOM=/path/to/install/dir export PATH=$WATCOM/binl:$PATH export INCLUDE=$WATCOM/h/win export LIB=$WATCOM/lib386/win wcc -bt=windows hello.c wcl -l=windows hello.o wine hello.exe where hello.c has this: #include <windows.h> int PASCAL WinMain( HINSTANCE this_inst, HINSTANCE prev_inst, LPSTR cmdline, int cmdshow ) { MessageBox(NULL,"Hello world","Win16",MB_OK); return 0; } $ file hello.exe hello.exe: MS-DOS executable, NE for MS Windows 3.x :-) Damjan

March 29, 2010