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

RFC: test of 16 bit wine (DOS)

by Morten Rønne

Hi I have been working on creating tests for the 16 bit implementation of wine, and now I have come so far that I would like some comments on the way I have chosen to do it. 16 bit programs require a compiler that is able to create the old style address method in order to be able to test those parts of wine. I have been told by Dmitry Timoshkov that I should use OpenWatcom for that. So that is what I have done. OpenWatcom also supports building DOS32 (using a number of extenders) and WIN 3.x programs. Since the DOS program can't run in the current test enviroment, because that is new style 32 bit address method, I am using a wrapper program which start the old style program from the 32 bit environment. The wrapper also makes it possible to do a skip message in case the needed DOS program is missing (due to no OpenWatcom compiler). In order to be able to create a stand-alone DOS program I have modified the wine/test.h file so that certain parts got omitted, while others were added. This means that writing a DOS test will be the same as writing normal 32 bit tests, except that you include a different test include file. The current version uses the define __WINE_WINE_DOS16_TEST_H from the include file that defines the DOS environment, since I haven't been able to find a better name. Suggestions for a better name are most welcome. The DOS test it self, is only a very simple one because I consider this more a proof of concept than a full test. Also a full test will require a number of changes in the current 16 bit tree to move a number of definitions from .c files to .h files so the test can reference them. Once this have been commited work can start towards making more complete test of the 16 bit environment. I hope that the naming will make Wine Testbot able to detect changes to the test suite. As can be seen above the OpenWatcom compiler is needed to build the DOS 16 bit programs. Currently only Linux 32 bit platform is supported. The compiler can't be built on 64 bit yet, this includes Mac. The easiest way to install the compiler is to download the binary installer from: http://www.openwatcom.org/index.php/Download Select one of the mirrors and download the file: open-watcom-c-linux-1.9 Ignore the fact that the main download page points to other places to get the linux version. This is a binary program that you have to run. It will ask you were to install OpenWatcom and all files will be installed under that tree. After that you must add a definition of WATCOM to your shell profile, pointing it to the directory you selected. After that change PATH to search in $WATCOM/binl as the LAST thing. Watcom includes programs that are called the same as some wine programs (wrc for one), so be sure you don't find these by searching OpenWatcom last. As a note I can tell that Debian have rejected the Sybase license (under which OpenWatcom is released) as not being free, and therefore there will be no official debian packages of OpenWatcom. Best Regards Morten Rønne

Aug. 23, 2010

Wine Gecko 1.1.0 RC1

by Jacek Caban

HI all, (If you're not interested in details, please read the last paragraph). It's been over year since the last Gecko update. A lot has happen since then. I've been planning to update our build a bit later, with Firefox 4 codebase, but plans have changed. We had some serious problems with previous build (like bug 22157 and bug 24059, both should be fixed in the new build). Also there is *a lot* happening in Mozilla world. With upcoming Firefox 4, the backward compatibility is no longer supported and the code is changing with an impressive speed. I try to follow these changes, but I need a good solid base so that I can take care of our needs in Mozilla. This build is based on Firefox 4 beta 4 (that is expected to be released this week). It goes with massive improvements, but it's less interesting here. We finally have sane building procedure. Thanks to mingw-w64 project, we no longer have to maintain our own fixes to headers and libraries. Also I've fixed a bug so that moztools is no longer needed for crosscompiling. It means that we no longer need any binary files, which should make open source fanatics (in a good sense) happy. Well... almost. We still need to create .cab file, which I do via Filzip on Windows. That's something we can work around. We use .cab files, because that's the only archive format that Wine can deal with. We can teach Wine to use other formats, which would finally make it possible for Wine packagers to do their own builds, if they like. The new Gecko is also the first to support Win64. Not all tests pass yet, but failing ones are due to missing DispCallFunc implementation for Win64, so it's not a Gecko problem. It's not yet fully tested and I need help with this. I'd appreciate any help with testing. Almost all changes required by the new Gecko were possible to be committed to current Wine. The attached patch contains remaining bits. All you need to test it is current Wine Git (must be today's or later), the attached patch and a new Gecko build. You can find new builds [1] and win64 build [2]. Put .cab files according to generic instructions [3] (obviously with different file names due to different Gecko versions). Please let me know of any regressions. Thanks, Jacek [1] http://gerwazy.lo3.wroc.pl/~jcaban/wine_gecko-1.1.0-rc1-x86.cab [2] http://gerwazy.lo3.wroc.pl/~jcaban/wine_gecko-1.1.0-rc1-x86_64.cab [3] http://wiki.winehq.org/Gecko

Aug. 23, 2010

Re: Ongoing Debian package maintenance.

by Lei Zhang

On Fri, Aug 20, 2010 at 4:00 PM, Ben Klein <shacklein(a)gmail.com> wrote: > Hello everyone, > > My health has not improved at all since my last call for help with the > Debian package management. I really need someone to take over from me, or at > least some help to devise a new set of (semi-)automated build scripts. Any > volunteers? Hi Ben, Does the task basically involve building new .deb packages for every release? I can probably take over this if nobody else volunteered. Get better! - Lei

Aug. 23, 2010

How managing crashing tests ?

by GOUJON Alexandre

Hi guys, A patch has been committed today saying "Make .. crashing like it does on native". I know we have to follow (genuine) Windows behavior but I'm wondering how to handle these cases. For instance, how to add a test crashing on every Windows ? Is it useful ? I mean, none program can rely on it .. since it crashes. Anyway, I've seen mainly two approaches - if(0) - /* comment the crashing ok() */ What's the difference ? And why not #if 0 ? I maybe lack some basic C knowledges but I think that /**/ and #if 0 are not added to the executable (from preprocessing stage). If it's right, it means we can then 'enable' these blocks maybe with (gdb) edit something And what about a test crashing on a specific Windows ? I guess #ifdef CRASHES_ON_NT40 is not an elegant way (even if it's currently used). Commenting such tests prevent us to check wine behavior on 'working' Windows. I attempted to use __TRY ... __EXCEPT_PAGE_FAULT in a test but it got rejected. Any advice ? Thanks

Aug. 23, 2010

Re: Re : Re : d3dx9: Implement D3DXDeclaratorFromFVF.

by Henri Verbeet

On 23 August 2010 19:02, paulo lesgaz <jeremielapuree(a)yahoo.fr> wrote: > Both patches work very well (they passed the todo_wine tests) > But, I think that the second one does not answer to Julliard 's complain > about tons of if...then I'm not sure I remember reading that specific comment. I know there was one about the unnecessary BOOLs though.

Aug. 23, 2010

Re : Re : d3dx9: Implement D3DXDeclaratorFromFVF.

by paulo lesgaz

Both patches work very well (they passed the todo_wine tests) But, I think that the second one does not answer to Julliard 's complain about tons of if...then Or maybe there is no way to simplify the patch David ________________________________ De : Henri Verbeet <hverbeet(a)gmail.com> À : paulo lesgaz <jeremielapuree(a)yahoo.fr> Cc : wine-devel(a)winehq.org Envoyé le : Lun 23 août 2010, 14h 01min 01s Objet : Re: Re : d3dx9: Implement D3DXDeclaratorFromFVF. On 23 August 2010 13:49, paulo lesgaz <jeremielapuree(a)yahoo.fr> wrote: > I already sent such a patch. Julliard did not like the gazillions of > conditions if.... then. > I never found a way to avoid them. > The offset can be computed thanks to the function D3DXGetDeclVertexSize > You know, just give the attached patches a try. Untested, of course.

Aug. 23, 2010

Re: New winetricks 20100822: new verb lucida

by Jacek Caban

On 8/23/10 6:26 PM, Dan Kegel wrote: > Jacek wrote: >> I still hope that gecko will be removed from winetricks at some point. >> It clearly doesn't belong to winetricks. > That would be nice. Does every distro install wine-gecko yet? I don't know, but I think we may assume that yes. Otherwise distros would leave users with an ugly dialog box on every wineprefix creation. There was a plan to make a list on http://wiki.winehq.org/Gecko, but it doesn't seem to be updated. Jacek

Aug. 23, 2010

re: New winetricks 20100822: new verb lucida

by Dan Kegel

Jacek wrote: > I still hope that gecko will be removed from winetricks at some point. > It clearly doesn't belong to winetricks. That would be nice. Does every distro install wine-gecko yet? > Also fakeie6 doesn't make sense anymore. We set these registries > by default for over 2.5 years now. OK, deleted. - Dan

Aug. 23, 2010

Re: configure: Enable prelink on x86_64

by Stefan Dösinger

Am Montag 23 August 2010, 16:03:51 schrieb Alexandre Julliard: > Stefan Dösinger <stefan(a)codeweavers.com> writes: > > From 98e8cc5d0b5b2d397c1d904d2537c326ed36d43c Mon Sep 17 00:00:00 2001 > > From: =?UTF-8?q?Stefan=20D=C3=B6singer?= <stefan(a)codeweavers.com> > > Date: Sun, 22 Aug 2010 19:49:58 +0200 > > Subject: [PATCH 4/4] Enable prelink on x86_64 > > Which app needs this? Steam in a wow64 build.

Aug. 23, 2010

Re: avifil32: Removed sign comparison warning (sizeof expresions)

by Michael Stefaniuc

Marko Nikolic wrote: > Andrey Turkin wrote: > >> On Monday 23 August 2010 13:16:07 Michael Stefaniuc wrote: >>> IMHO gcc is *wrong* in emitting a warning there. sizeof(PCMWAVEFORMAT) >>> is a compile time constant and gcc can see that sizeof(PCMWAVEFORMAT) >>> falls well inside the number range expressible by a LONG. Logically >>> there is no difference between >>> formatsize <= sizeof(PCMWAVEFORMAT) >>> and >>> formatsize <= 16 >>> One gives a bogus warning and the other doesn't. >> C99 std (para 6.5.3.4.4) states following about sizeof operator: >> "...its type (an unsigned integer type) is size_t, deﬁned in <stddef.h> >> (and other headers)." >> >> sizeof result is a compile-time constant but, unlike numeric constants, >> its type must always be size_t so gcc does the correct thing here. > > The same is with C89, paragraph 3.3.3.4 from standard: > > The value of the result is implementation-defined, and its type (an > unsigned integral type) is size_t defined in the <stddef.h> header. > > So, the gcc is correct. In the example above, correct would be > > formatsize <= 16U > > which gives a warning, as expected. Yeah, sorry about that. I ASSumed the C spec would preserve the value and as sizeof(PCMWAVEFORMAT) is a constant expression it would be promoted to a LONG as that would preserve the values of both sides. gcc has no choice in this case then to follow the C standard. So I've read up on it and now I blame the C standard; especially after reading the "Coding guidelines" on page 7 of http://c0x.coding-guidelines.com/6.5.3.4.pdf aka the commentary to the changes proposed to sizeof() in the next C standard iteration. So much for the "principle of the least surprise" ... > What remains is how to correctly remove warning. In this case (and there are > many similar in the code), signed function parameter is comparing with > values that are natively unsigned. Changing type of the parameter is not > possible, the same if with sizeof operator. One possiblity is to add some > temporary variable, but in my opinioin it will just unncesary bloat the code > and is worse than casting return value of sizeof. > > Maybe better solution is to make signed_sizeof macro, which will always > return signed values and use it instead of sizeof; I will check if there is > possiblity for that. bye michael

Aug. 23, 2010

Re: avifil32: Removed sign comparison warning (sizeof expresions)

by Michael Stefaniuc

Alexandre Julliard wrote: > Marko Nikolic <grkoma(a)gmail.com> writes: > >> What remains is how to correctly remove warning. In this case (and there are >> many similar in the code), signed function parameter is comparing with >> values that are natively unsigned. Changing type of the parameter is not >> possible, the same if with sizeof operator. One possiblity is to add some >> temporary variable, but in my opinioin it will just unncesary bloat the code >> and is worse than casting return value of sizeof. > > In general a negative size would be an error too, so casting the sizeof > wouldn't do the right thing. Hmm ... gcc would still issue the warning even if we know that formatsize cannot be negative aka formatsize >= 0 && formatsize <= sizeof(PCMWAVEFORMAT) would still produce a warning. bye michael

Aug. 23, 2010

Re: avifil32: Removed sign comparison warning (sizeof expresions)

by Alexandre Julliard

Marko Nikolic <grkoma(a)gmail.com> writes: > What remains is how to correctly remove warning. In this case (and there are > many similar in the code), signed function parameter is comparing with > values that are natively unsigned. Changing type of the parameter is not > possible, the same if with sizeof operator. One possiblity is to add some > temporary variable, but in my opinioin it will just unncesary bloat the code > and is worse than casting return value of sizeof. In general a negative size would be an error too, so casting the sizeof wouldn't do the right thing. -- Alexandre Julliard julliard(a)winehq.org

Aug. 23, 2010

Re: [PATCH 1/3] msvcp90/tests: Added basic_string<char> tests (try2)

by testbot＠testbot.winehq.org

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

Aug. 23, 2010

Re: New winetricks 20100822: new verb lucida

by James Mckenzie

Scott Ritchie <scott(a)open-vote.org> wrote: >Sent: Aug 23, 2010 6:37 AM >To: Wine Devel <wine-devel(a)winehq.org> >Subject: Re: New winetricks 20100822: new verb lucida > >On 08/23/2010 05:01 AM, Jacek Caban wrote: >> Hi Dan, >> >> On 8/22/10 8:57 PM, Dan Kegel wrote: >>> Dan Kegel: >>> gecko: make it work even if WINE isn't set. (How did this get >>> through?) >> >> I still hope that gecko will be removed from winetricks at some point. >> It clearly doesn't belong to winetricks. >> >> Also fakeie6 doesn't make sense anymore. We set these registries by >> default for over 2.5 years now. >> > >Well on Ubuntu at least installing the Wine package will pull in the >wine-gecko package and all will be well in the world. This is the >ultimate path forward, I think. > Any word from the RedHat/CentOS/Fedora crowd? I have to fix the video on my laptop (it's just messed up) and then I can check if this happens on CentOS 5.5 as well. James McKenzie

Aug. 23, 2010

Re: [PATCH] ntdll: set correct protection flags on sections in builtin DLLs

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > So a call to change the protection without calling mprotect() in the end? > like VIRTUAL_SetProtData() or something? Something like that yes (and please do it all in virtual.c, that's not the sort of function you want to make global). -- Alexandre Julliard julliard(a)winehq.org

Aug. 23, 2010

Re: New winetricks 20100822: new verb lucida

by Marcus Meissner

On Mon, Aug 23, 2010 at 06:37:44AM -0700, Scott Ritchie wrote: > On 08/23/2010 05:01 AM, Jacek Caban wrote: > > Hi Dan, > > > > On 8/22/10 8:57 PM, Dan Kegel wrote: > >> Dan Kegel: > >> gecko: make it work even if WINE isn't set. (How did this get > >> through?) > > > > I still hope that gecko will be removed from winetricks at some point. > > It clearly doesn't belong to winetricks. > > > > Also fakeie6 doesn't make sense anymore. We set these registries by > > default for over 2.5 years now. > > > > Well on Ubuntu at least installing the Wine package will pull in the > wine-gecko package and all will be well in the world. This is the > ultimate path forward, I think. Same for openSUSE. Ciao, Marcus

Aug. 23, 2010

Re: [PATCH] ntdll: set correct protection flags on sections in builtin DLLs

by Marcus Meissner

On Mon, Aug 23, 2010 at 03:43:35PM +0200, Alexandre Julliard wrote: > Marcus Meissner <marcus(a)jet.franken.de> writes: > > > @@ -1406,7 +1409,18 @@ static void load_builtin_callback( void *module, const char *filename ) > > } > > virtual_create_system_view( module, nt->OptionalHeader.SizeOfImage, > > VPROT_SYSTEM | VPROT_IMAGE | VPROT_COMMITTED | > > - VPROT_READ | VPROT_WRITECOPY | VPROT_EXEC ); > > + VPROT_READ | VPROT_WRITECOPY | VPROT_EXEC, &view ); > > + > > + sec = (IMAGE_SECTION_HEADER*)((char*)&nt->OptionalHeader+nt->FileHeader.SizeOfOptionalHeader); > > + for (i=0;i<nt->FileHeader.NumberOfSections;i++) { > > + DWORD flags = VPROT_SYSTEM | VPROT_IMAGE | VPROT_COMMITTED; > > + > > + if (sec[i].Characteristics & IMAGE_SCN_MEM_EXECUTE) flags |= VPROT_EXEC; > > + if (sec[i].Characteristics & IMAGE_SCN_MEM_READ) flags |= VPROT_READ; > > + if (sec[i].Characteristics & IMAGE_SCN_MEM_WRITE) flags |= VPROT_WRITE; > > + if (sec[i].Characteristics & IMAGE_SCN_MEM_SHARED) flags |= VPROT_WRITECOPY; > > + VIRTUAL_SetProt( view, (char*)module + sec[i].VirtualAddress, sec[i].Misc.VirtualSize, flags ); > > I don't think you want to actually change the permissions, our headers > don't necessarily match the real ELF sections. So a call to change the protection without calling mprotect() in the end? like VIRTUAL_SetProtData() or something? > (BTW, could you please convince your mailer to set a valid Message-Id?) I am bouncing them from the "git format-patch origin" created files currently. Ciao, Macus

Aug. 23, 2010

Re: configure: Enable prelink on x86_64

by Alexandre Julliard

Stefan Dösinger <stefan(a)codeweavers.com> writes: > From 98e8cc5d0b5b2d397c1d904d2537c326ed36d43c Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Stefan=20D=C3=B6singer?= <stefan(a)codeweavers.com> > Date: Sun, 22 Aug 2010 19:49:58 +0200 > Subject: [PATCH 4/4] Enable prelink on x86_64 Which app needs this? -- Alexandre Julliard julliard(a)winehq.org

Aug. 23, 2010

Re: [PATCH] ntdll: set correct protection flags on sections in builtin DLLs

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > @@ -1406,7 +1409,18 @@ static void load_builtin_callback( void *module, const char *filename ) > } > virtual_create_system_view( module, nt->OptionalHeader.SizeOfImage, > VPROT_SYSTEM | VPROT_IMAGE | VPROT_COMMITTED | > - VPROT_READ | VPROT_WRITECOPY | VPROT_EXEC ); > + VPROT_READ | VPROT_WRITECOPY | VPROT_EXEC, &view ); > + > + sec = (IMAGE_SECTION_HEADER*)((char*)&nt->OptionalHeader+nt->FileHeader.SizeOfOptionalHeader); > + for (i=0;i<nt->FileHeader.NumberOfSections;i++) { > + DWORD flags = VPROT_SYSTEM | VPROT_IMAGE | VPROT_COMMITTED; > + > + if (sec[i].Characteristics & IMAGE_SCN_MEM_EXECUTE) flags |= VPROT_EXEC; > + if (sec[i].Characteristics & IMAGE_SCN_MEM_READ) flags |= VPROT_READ; > + if (sec[i].Characteristics & IMAGE_SCN_MEM_WRITE) flags |= VPROT_WRITE; > + if (sec[i].Characteristics & IMAGE_SCN_MEM_SHARED) flags |= VPROT_WRITECOPY; > + VIRTUAL_SetProt( view, (char*)module + sec[i].VirtualAddress, sec[i].Misc.VirtualSize, flags ); I don't think you want to actually change the permissions, our headers don't necessarily match the real ELF sections. (BTW, could you please convince your mailer to set a valid Message-Id?) -- Alexandre Julliard julliard(a)winehq.org

Aug. 23, 2010

Re: New winetricks 20100822: new verb lucida

by Scott Ritchie

On 08/23/2010 05:01 AM, Jacek Caban wrote: > Hi Dan, > > On 8/22/10 8:57 PM, Dan Kegel wrote: >> Dan Kegel: >> gecko: make it work even if WINE isn't set. (How did this get >> through?) > > I still hope that gecko will be removed from winetricks at some point. > It clearly doesn't belong to winetricks. > > Also fakeie6 doesn't make sense anymore. We set these registries by > default for over 2.5 years now. > Well on Ubuntu at least installing the Wine package will pull in the wine-gecko package and all will be well in the world. This is the ultimate path forward, I think. Thanks, Scott Ritchie

Aug. 23, 2010

Re: [PATCH 4/6] shell32: Implement IExplorerBrowser::Advise and IExplorerBrowser::Unadvise.

by Alexandre Julliard

David Hedberg <david.hedberg(a)gmail.com> writes: > +#define EBE_IMPL(iface) \ > + ((IExplorerBrowserEventsImpl*)iface) > [...] > +static ULONG WINAPI IExplorerBrowserEvents_fnAddRef(IExplorerBrowserEvents *iface) > +{ > + return InterlockedIncrement(&(EBE_IMPL(iface)->ref)); That's ugly, declare a proper This pointer instead. -- Alexandre Julliard julliard(a)winehq.org

Aug. 23, 2010

Re: avifil32: Removed sign comparison warning (sizeof expresions)

by Michael Stefaniuc

Andrey Turkin wrote: > On Monday 23 August 2010 13:16:07 Michael Stefaniuc wrote: >> IMHO gcc is *wrong* in emitting a warning there. sizeof(PCMWAVEFORMAT) >> is a compile time constant and gcc can see that sizeof(PCMWAVEFORMAT) >> falls well inside the number range expressible by a LONG. Logically >> there is no difference between >> formatsize <= sizeof(PCMWAVEFORMAT) >> and >> formatsize <= 16 >> One gives a bogus warning and the other doesn't. > > C99 std (para 6.5.3.4.4) states following about sizeof operator: > "...its type (an unsigned integer type) is size_t, deﬁned in <stddef.h> (and > other headers)." > > sizeof result is a compile-time constant but, unlike numeric constants, its > type must always be size_t so gcc does the correct thing here. That's actually not the problem but the "value preservation rule" especially the "unsigned preservation rule". As sizeof(LONG) <= sizeof(size_t) the formatsize will be promoted to an unsigned. Iff formatsize is negative it will produce a big unsigned integer. So I'll retract my critique of gcc (in this case as the compiler cannot know what values formatsize will hold) and blame the C standard instead. bye michael

Aug. 23, 2010

Re: New winetricks 20100822: new verb lucida

by Jacek Caban

Hi Dan, On 8/22/10 8:57 PM, Dan Kegel wrote: > Dan Kegel: > gecko: make it work even if WINE isn't set. (How did this get through?) I still hope that gecko will be removed from winetricks at some point. It clearly doesn't belong to winetricks. Also fakeie6 doesn't make sense anymore. We set these registries by default for over 2.5 years now. Jacek

Aug. 23, 2010

Re: Re : d3dx9: Implement D3DXDeclaratorFromFVF.

by Henri Verbeet

On 23 August 2010 13:49, paulo lesgaz <jeremielapuree(a)yahoo.fr> wrote: > I already sent such a patch. Julliard did not like the gazillions of > conditions if.... then. > I never found a way to avoid them. > The offset can be computed thanks to the function D3DXGetDeclVertexSize > You know, just give the attached patches a try. Untested, of course.

Aug. 23, 2010

Re : d3dx9: Implement D3DXDeclaratorFromFVF.

by paulo lesgaz

I already sent such a patch. Julliard did not like the gazillions of conditions if.... then. I never found a way to avoid them. The offset can be computed thanks to the function D3DXGetDeclVertexSize A+ David ________________________________ De : Henri Verbeet <hverbeet(a)gmail.com> À : wine-devel(a)winehq.org Envoyé le : Lun 23 août 2010, 12h 03min 16s Objet : Re: d3dx9: Implement D3DXDeclaratorFromFVF. On 20 August 2010 21:16, Misha Koshelev <misha680(a)gmail.com> wrote: > Thank you for your helpful feedback on my tests. > > This is based mostly on dlls/d3d9/vertexdeclaration.c with some > changes specific to D3DXDeclaratorFromFVF. > > Again, if there are any suggested changes please let me know. > As you already mentioned, this is pretty much another copy/paste implementation, including e.g. the useless macros and typedef.

Aug. 23, 2010