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

[msi OLE automation] Re: msi patches info pls

by Misha Koshelev

On Fri, 2007-03-09 at 17:27 +0100, Alexandre Julliard wrote: > Sorry for the lack of response, I'm currently waiting for our lawyers > to determine if it's ok to use code based on an oleview dump of a > native typelib, as that situation is not clear from a copyright > POV. I'm afraid I can't do more until they come to a conclusion on > that point. > So it looks like I will have some free time soon (hopefully) and will be able to redo the "IDL" file properly (also another Vector NTI/Linux user has offered up his help). However, I wanted to double check the "proper" way to make such a file as I know this is what is important in copyright (the process, such as dirty-clean room, vs the actual end result). From http://www.winehq.org/pipermail/wine-devel/2007-March/054589.html (posted by Rob Shearman) this is what I understand the correct process to be (I would like to understand the process in detail so I don't do something wrong to "taint" the wine copyright): As one is looking at the oleview output of the native IDL file, one starts a blank document and begins to make the wine IDL file. One defines all the appropriate interfaces, etc. using the UUID's, names, etc. from the native interface. All the function names and parameter types are declared the same, as well as function attributes, but I should use different names for the parameters and try to put the attributes in a different order (although if I understand correctly the order of these attributes comes from our oleview implementation and not from the interface per se so there shouldn't be any reason to change their order??). Also, what does one do for enums? It does not seem like there is anything that can be changed in this case, so it is alright just to re-create them verbatim (without copying and pasting, and of course the indentation will be prettier)? Thank you very much for your help. Misha

March 30, 2007

Release notes

by John Voltz

I have a question about the Wine release notes. Do the Wine developers work from bugzilla or do they usually just work on a specific application feature? Would it require too much extra effort on the release notes to associate a specific change with a bugzilla bug-fix or specific application/feature fix? I believe IMHO that this would make the release notes more relevant and useful to the end user. I never can tell what was actually fixed in a particular release because of the obscure developer notes. I've been lurking on the wine-devel list watching how development progresses, because at some point I would like to attempt joining in on the development effort. -- John Voltz

March 30, 2007

Jason Edmeades : xcopy: Add support for COPYCMD override and

by Ann & Jason Edmeades

>wouldn't it be nicer to use sizeof(copyCmd) here? >if (GetEnvironmentVariable(COPYCMD, copyCmd, MAXSTRING)) { >There are many spots like this in wcmdmain.c Yes... I'm blaming cut and paste as I didn't do all the wcmd ones :-) Once I get all my xcopy patches in I want to continue my rework of the cmd commands, finishing off some more inbuilt ones which I know are broken. I also want to extend your last patch to ensure all parts which process a command line are using the MAXSTRING length, and I'll do a patch for this while I am at it. Thanks, Jason

March 30, 2007

[PATCH 18/18] XCOPY: Add help

by Ann & Jason Edmeades

Er... I have just managed to get git send-email set up and working, and it would appear to be a feature of it. I do get one question which I answered n to, perhaps I should anser yes to it and see what happens :-) Anyone else using git send-email want to comment on how to avoid this? Thanks! Jason

March 30, 2007

RE: [PATCH 13/18] XCOPY: Add support for /EXCLUDELIST:file1+file2 etc

by Ann & Jason Edmeades

>> + if (wcsstr(copyFromUpper, pos->name) != NULL) { >wcsstr() doesn't seem the right way to compare file names. You >probably want to do a wcsicmp() of the end of the name or something >like that. It's not a file compare, it's a substring compare, eg if the file contains just the letter s, all files with s(/S) in either the directory, name or extension will not get copied. Because there is not a stristr / strstri type function, I uppercase the lines as read from the exclude file when I save them away, and then uppercase the source names when doing the search. Hence I can use strstr (wcsstr) to do the substring matching. So I think the patch was right... Until I started thinking harder about it... There is another unrelated bug, in that the matching should only occur in the new parts of the tree, not in the original stem. My patch would fail all files if you put eg, a ':' in there as I am strstr'ing against an expanded path. I'll fix that bit and resubmit. If there's anything wrong with the wcsstr logic though, please let me know. Thanks for the commits Jason

March 30, 2007

Re: Is Wine a platform for Codeweaver to make money?! Please help me understand.

by Jan Zerebecki

On Thu, Mar 29, 2007 at 03:17:35PM -0700, Sasan Iman wrote: > I don't know how much effort it would take to get Office > working on Wine but if getting it to work out-of-the-box means putting > it on many more systems (leading to more people getting interested, more > mileage leading to more bug reports, more people finding reason to get > involved to fix bugs, etc.) then the extra effort may well be worth it. I think the applications that would give Wine the most popularity are the current long term top games. I don't have any need for MS Office at all. It differs from person to person what they think is most needed in wine. And that is fine, because fixing wine properly for one application doesn't prevent fixing it properly for another one and one fix often helps many applications. If someone has the money to pay for MS Office, they certainly have the (comparably) peanuts to pay for CrossOver. Paying CX means paying someone to make wine better. Why wouldn't they want to do this? If many people are interested in getting MS Office to run on wine (in a turn key way or even only in a follow a how-to way) surely one of them is willing to work on it, right? With an application that already runs on CrossOver it's even something that doesn't need too much work as all the hard things were already done by CX. If anyone needs help on how to work on wine, I'll be happy to help anyone help wine (best done on IRC). How good an application is supported by the wine community obviously depends on how much work people put into it. You can see that there is a difference by e.g. comparing the appdb entries of World of Warcraft and MS Office. WoW has since some time details on the appdb on how to make it run in wine. There are none for MS Office and there aren't even detailed bug reports (on those versions I looked at). Working to get an application in wine running usually also has the benefit that sometimes people help achieving that, who don't have any specific interest in that application. So I expect you to follow up on what you said and scratch your personal wine itch. Free software is about sharing work. In the sense that when we put our effort together we get something that is more than what we would have when we didn't share. This can also mean paying someone to do the work for you. Jan

March 30, 2007

request to look into this bug

by Louis. Lenders

Hi, while working through the test reports in the appdb, i saw users submitting crashes with applications , all similar to bug 7380, so i decided to take it here. The applications that crash are *WinMerge (newest version) *BookWorms Adventures + several other PopCap games ( i tested them) *5 other applications listed under bug 7380. So i know of at least 10 applications that crash this way. They all start fine using the "buggy pointer" patch from Rein Klazes below. However, i think it's becoming rahter strange that all these (just released!) applications pass buggy pointers, so i'm beginning to think the problem must be somewhere else. I've sent in a patch to work around this bug by an exception handler a few weeks ago, but that's likely not the way to go either then. Anyone an idea how to tackle this problem? Thanks. diff --git a/dlls/winex11.drv/dib.c b/dlls/winex11.drv/dib.c index cec2058..4e61da4 100644 --- a/dlls/winex11.drv/dib.c +++ b/dlls/winex11.drv/dib.c @@ -3861,6 +3861,7 @@ INT X11DRV_SetDIBits( X11DRV_PDEVICE *ph X11DRV_DIB_IMAGEBITS_DESCR descr; BITMAP bitmap; LONG width, height, tmpheight; + int nrsrcbytes, dibpitch; INT result; descr.physDev = physDev; @@ -3880,6 +3881,17 @@ INT X11DRV_SetDIBits( X11DRV_PDEVICE *ph if (startscan + lines > height) lines = height - startscan; + + /* pointer check */ + dibpitch = ((width * descr.infoBpp + 23) &~23) / 8; + if( descr.compression) + nrsrcbytes = 1; + else { + nrsrcbytes = lines * dibpitch; + if( nrsrcbytes < 0) nrsrcbytes = - nrsrcbytes; + } + if( IsBadReadPtr( bits, nrsrcbytes)) return 0; + switch (descr.infoBpp) { case 1: @@ -3926,7 +3938,7 @@ INT X11DRV_SetDIBits( X11DRV_PDEVICE *ph descr.width = bitmap.bmWidth; descr.height = lines; descr.useShm = FALSE; - descr.dibpitch = ((descr.infoWidth * descr.infoBpp + 31) &~31) / 8; + descr.dibpitch = dibpitch; X11DRV_DIB_Lock( physBitmap, DIB_Status_GdiMod, FALSE ); result = X11DRV_DIB_SetImageBits( &descr ); X11DRV_DIB_Unlock( physBitmap, TRUE ); --------------------------------- New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes.

March 30, 2007

ExtTextOut with rotation and MM_ANISOTROPIC inverted coordinates

by Carl-Daniel Hailfinger

Hi, I have a problem with rotated Text displayed by ExtTextOut after SetMapMode(hdc, MM_ANISOTROPIC); SetWindowExtEx(hdc, 1000, -1000, NULL); Basically, giving one negative parameter to SetWindowExtEx should reverse the direction (clockwise/counterclockwise) in which rotation is done. It works in Windows, but has no effect in wine. The patch I created uses a side effect of the WMF file I had as test case, basically it sets lfClipPrecision = CLIP_LH_ANGLES and triggers direction inversion based on that instead of checking the WindowExtEx settings. That is of course wrong, but it is available almost everywhere in the text output paths and served me nicely as "inverse rotation" flag. Instead of abusing lfClipPrecision, what should we use? The SetWindowExtEx call sets some_matrix.eM11 to a negative value if its first argument is negative and eM22 to a negative value if its second argument is negative. So checking (eM11 * eM22 < 0) && (mapmode == MM_ANISOTROPIC) should be the correct solution. Problem: You can't always check these things because the dc is not available everywhere. In case you have a GdiFont, you can check (font->font_desc.matrix.eM11 * font->font_desc.matrix.eM22 < 0) or in case you have a LOGFONT (dc->xformWorld2Vport.eM11 * dc->xformWorld2Vport.eM22 < 0) I have not tested whether the parameters of the current dc, the parameters at the time CreateFontIndirect was run or the parameters at the time SelectObject(hdc, hfont) was run are responsible for the rotation inversion. What works? With the patch, lfClipPrecision = CLIP_LH_ANGLES has the effect SetWindowExtEx(hdc, positivevalue, negativevalue, NULL) should have. Exception: The text is clipped at the border, while Windows auto-extends the borders to avoid clipping. What doesn't work? SetWindowExtEx(hdc, positivevalue, negativevalue, NULL) still has no effect on the rotation angle. Attached are: create_mf.c: Testcase in C (thanks to Dmitry Timoshkov, who created the C code from a reduced WMF testcase I sent him) create_mf_generated.wmf: WMF file output by ./create_mf file.wmf wine-fontdirection-24.diff: Preliminary patch described above If somebody can take a look at the patch and mangle it so that it does the right thing, I'd be very grateful. Regards, Carl-Daniel -- http://www.hailfinger.org/ diff --git a/dlls/gdi32/font.c b/dlls/gdi32/font.c index ea2e66c..40d76c4 100644 --- a/dlls/gdi32/font.c +++ b/dlls/gdi32/font.c @@ -1944,6 +1944,10 @@ BOOL WINAPI ExtTextOutW( HDC hdc, INT x, { cosEsc = cos(lf.lfEscapement * M_PI / 1800); sinEsc = sin(lf.lfEscapement * M_PI / 1800); + if (lf.lfClipPrecision & CLIP_LH_ANGLES) + { + sinEsc = - sinEsc; + } } else { diff --git a/dlls/gdi32/freetype.c b/dlls/gdi32/freetype.c index f7b1220..730725a 100644 --- a/dlls/gdi32/freetype.c +++ b/dlls/gdi32/freetype.c @@ -2675,10 +2675,10 @@ GdiFont *WineEngCreateFontInstance(DC *d if (!GetObjectW( hfont, sizeof(lf), &lf )) return NULL; can_use_bitmap = GetDeviceCaps(dc->hSelf, TEXTCAPS) & TC_RA_ABLE; - TRACE("%s, h=%d, it=%d, weight=%d, PandF=%02x, charset=%d orient %d escapement %d\n", + TRACE("%s, h=%d, it=%d, weight=%d, PandF=%02x, charset=%d orient %d escapement %d clipprecision %d\n", debugstr_w(lf.lfFaceName), lf.lfHeight, lf.lfItalic, lf.lfWeight, lf.lfPitchAndFamily, lf.lfCharSet, lf.lfOrientation, - lf.lfEscapement); + lf.lfEscapement, lf.lfClipPrecision); /* check the cache first */ if((ret = find_in_cache(hfont, &lf, &dc->xformWorld2Vport, can_use_bitmap)) != NULL) { @@ -2946,6 +2946,10 @@ found: } ret->orientation = FT_IS_SCALABLE(ret->ft_face) ? lf.lfOrientation : 0; + if (lf.lfClipPrecision & CLIP_LH_ANGLES) + { + ret->orientation = FT_IS_SCALABLE(ret->ft_face) ? 3600 - (lf.lfOrientation % 3600) : 0; + } ret->name = strdupW(family->FamilyName); ret->underline = lf.lfUnderline ? 0xff : 0; ret->strikeout = lf.lfStrikeOut ? 0xff : 0; diff --git a/dlls/gdi32/path.c b/dlls/gdi32/path.c index af756b3..bc326ab 100644 --- a/dlls/gdi32/path.c +++ b/dlls/gdi32/path.c @@ -1363,6 +1363,10 @@ BOOL PATH_ExtTextOut(DC *dc, INT x, INT { cosEsc = cos(lf.lfEscapement * M_PI / 1800); sinEsc = sin(lf.lfEscapement * M_PI / 1800); + if (lf.lfClipPrecision & CLIP_LH_ANGLES) + { + sinEsc = - sinEsc; + } } else { cosEsc = 1; diff --git a/dlls/wineps.drv/font.c b/dlls/wineps.drv/font.c index 9e0ae39..7bfc53c 100644 --- a/dlls/wineps.drv/font.c +++ b/dlls/wineps.drv/font.c @@ -108,6 +108,10 @@ HFONT PSDRV_SelectFont( PSDRV_PDEVICE *p } physDev->font.escapement = lf.lfEscapement; + if (lf.lfClipPrecision & CLIP_LH_ANGLES) + { + physDev->font.escapement = lf.lfEscapement ? 3600 - (lf.lfEscapement % 3600) : 0; + } physDev->font.set = FALSE; if(gdiFont && !subst) { diff --git a/dlls/wineps.drv/text.c b/dlls/wineps.drv/text.c index 59ac7c7..f6bd58c 100644 --- a/dlls/wineps.drv/text.c +++ b/dlls/wineps.drv/text.c @@ -105,6 +105,10 @@ static BOOL PSDRV_Text(PSDRV_PDEVICE *ph if(lf.lfEscapement != 0) { cosEsc = cos(lf.lfEscapement * M_PI / 1800); sinEsc = sin(lf.lfEscapement * M_PI / 1800); + if (lf.lfClipPrecision & CLIP_LH_ANGLES) + { + sinEsc = - sinEsc; + } } else { cosEsc = 1; sinEsc = 0; diff --git a/dlls/winex11.drv/xfont.c b/dlls/winex11.drv/xfont.c index 60bd70d..3ecd3dc 100644 --- a/dlls/winex11.drv/xfont.c +++ b/dlls/winex11.drv/xfont.c @@ -944,6 +944,10 @@ static BOOL LFD_ComposeLFD( const fontOb if (fo->lf.lfEscapement) { /* escapement is in tenths of degrees, theta is in radians */ double theta = M_PI*fo->lf.lfEscapement/1800.; + if (fo->lf.lfClipPrecision & CLIP_LH_ANGLES) + { + theta = - theta; + } LFD_AngleMatrix(h_string, h, theta); } else diff --git a/dlls/winex11.drv/xrender.c b/dlls/winex11.drv/xrender.c index e03540e..76d4e04 100644 --- a/dlls/winex11.drv/xrender.c +++ b/dlls/winex11.drv/xrender.c @@ -1136,6 +1136,10 @@ BOOL X11DRV_XRender_ExtTextOut( X11DRV_P if(lf.lfEscapement != 0) { cosEsc = cos(lf.lfEscapement * M_PI / 1800); sinEsc = sin(lf.lfEscapement * M_PI / 1800); + if (lf.lfClipPrecision & CLIP_LH_ANGLES) + { + sinEsc = - sinEsc; + } } else { cosEsc = 1; sinEsc = 0;

March 30, 2007

Re: Excluding a Windows version from the tests

by Paul Vriens

Alexandre Julliard wrote: > Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > >> So if we only have crashes on win9x we don't care. If we can avoid >> crashes/failures on win9x (by skip or other means) we don't run them >> on win9x. And if they crash on something higher then win9x we disable >> them totally. >> >> Does that make sense? > > Sure; the thing we want to avoid is version checks in tests, because > then things don't get tested on Wine when the version is changed. But > as long as win98 is detected by its missing features then skipping > things is fine. > Ok, I've got an example attached. I'm currently cleaning up the registry tests before I can/will start doing stuff with RegDeleteTree. It turns out we had a lof of failures with this test on win98. It looks like win98 doesn't assign a new handle when the same registry key is opened. This means that the close test close the main handle and we thus have an issue in the first test after that (which assumes to have a valid handle). The attached file uses the GetVersion to check for win9x, is that acceptable in this case? Or is just an extra RegOpenKey (with comments) enough? The todo_wine is only there btw. to don't have an error when run in win9x emulated mode. That brings up another question. Should all test succeed in Wine regardless of the emulated mode? Cheers, Paul.

March 30, 2007

Cross-Library tests, tests using multiple processes

by Stefan Dösinger

Hi, Screen resolution setting in DirectX games is still a huge mess. I want to fix it properly finally. Write tests to find out what really happens in windows, then implement it. Unfortunately that fails at the tests already. Our test framework is mainly limited to test single DLLs, and all tests I have been used to so far were in one single process. I would have to test what happens if there is one process requesting exclusive ddraw access and once process requesting explusive d3d9 access at once, and maybe a third process doing a screen resolution change, etc. Is there a way to write a test accross multiple libraries? I guess it is not hard to do, but it would look a bit bad if a ddraw test started using d3d9 directly. And is there a prefered way to spawn new processes and do communication between them? (Windows IPC I guess).

March 30, 2007