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

Re: mshtml #2: Added warning if a wrong Wine Gecko package version was found.

by Jacek Caban

Alexandre Julliard wrote: > Jacek Caban <jacek(a)codeweavers.com> writes: > > >> @@ -212,8 +213,10 @@ static BOOL load_wine_gecko(PRUnichar *gre_path) >> if(res != ERROR_SUCCESS || type != REG_SZ) >> return FALSE; >> >> - if(TRACE_ON(mshtml)) >> - check_version(gre_path); >> + /* We may consider message box here */ >> + if(ERR_ON(mshtml) && !check_version(gre_path)) >> + MESSAGE("Found a version of Wine Gecko package that is not dedicated " >> + "to your Wine version. Reinstalation is recommended.\n"); >> > > If you want to check versions, there needs to be a way to specify in > the URL which version you want to download, and old versions need to > be kept available. Yes, that's my plan, but I'm not sure why it's important for this patch. Currently Wine downloads always the same Gecko version that was never updated, so this check should work with current Wine. It will change once we will switch to the new version. I have patches that will use query encoded in URL to specify the package version and it will use the same defined version string as version check in this patch, so switching to the new Gecko won't be much more than one line patch.. It requires changes both in Wine and redirecting php script. I have patches for both and this was the first patch in this direction. I only have to test the rest of patches and send them (hopefully I will find the time to do it tonight). > The target CPU should also be part of the URL so we > can support multiple platforms. > We are very far from being able to support other archs, so I thought it's not worth to care about it ATM. Thanks, Jacek

May 30, 2007

Re: crypt32: implement CryptSIPLoad (resend)

by Paul Vriens

On 5/30/07, Juan Lang <juan_lang(a)yahoo.com> wrote: > Hi Paul, > > > Please correct me if I'm wrong but aren't you filling pSipDispatch > > with the function pointers of the given dll (as indicated by the GUID) > > instead of the function pointers of crypt32 (as the tests show it > > should)? > > I am. I couldn't find any reason that the behavior needs to be that way, > so I do this until such time as a reason can be found. The tests don't > fail, as you check the function pointers from msisip.dll, which isn't > present on wine. > > If you know a good reason native does it that way (or an app that depends > on it,) by all means enlighten me. The implementation I sent allows > native wintrust to get a bit further. > > --Juan > Hi Juan, The tests check the returned functions pointers against the ones retrieved from a LoadLibrary/GetProcAddress of the crypt32.dll. These specific tests for the function pointers don't fail because they are inside a todo_wine :-). I must say I don't see a good reason why native does it like this but the tests show it does. Cheers, Paul.

May 30, 2007

Re: Pretty Build System (Take 3)

by Robert Shearman

Alexandre Julliard wrote: > Robert Shearman <rob(a)codeweavers.com> writes: > > >> Attached is a patch that reduces the verbosity of the build system by >> printing the build commands in one of two formats: >> COMMAND output_file >> or >> COMMAND input_file -> output_file >> >> I hope it meets Alexandre's requirements of not reducing portability >> of Wine to other platforms (including Windows). >> > > The MAKEFLAGS stuff is still not portable, and I still think this > belongs in make itself. > > Here's a quick proof of concept patch against GNU make. It needs a > better algorithm for extracting the command name, and some sort of > command-line option; this is left as an exercise for the reader. > Thanks, I'll take a look at this when I get a spare moment. -- Rob Shearman

May 30, 2007

Re: Pretty Build System (Take 3)

by Robert Shearman

Tom Spear wrote: > On 5/29/07, Robert Shearman <rob(a)codeweavers.com> wrote: >> Hi, >> >> Attached is a patch that reduces the verbosity of the build system by >> printing the build commands in one of two formats: >> COMMAND output_file >> or >> COMMAND input_file -> output_file >> >> I hope it meets Alexandre's requirements of not reducing portability of >> Wine to other platforms (including Windows). > Well, after applying the patch and doing like Kirill instructed me, it > looks pretty good. I just have a couple of nits, and they really can > be worked out later on. > > 1) make depend/make install/make uninstall/make test, etc does not > appear "pretty" make depend and make test should appear "pretty", but I haven't worked on make install/uninstall yet. > 2) is there any way to "prettify" the entering/leaving directory > messages, I think the 2.6 kernel has it that way, but I'm not 100% > sure You can use "make --no-print-directory". -- Rob Shearman

May 30, 2007

Looking for Dev to help with BSD Port

by Kris Moore

Hey all! We're looking for a Wine dev to assist us with some porting issues over to PC-BSD / FreeBSD. We've recently begun to embrace making packages with wine embedded, making the process of loading windows programs a snap. The end user only needs to double-click, insert their CD, and click next a few times. This allowed us to make some packages for programs such as PhotoShop & Dreamweaver which even a non-linux/BSD user could install. We really want to expand these packages, to include things such as games, and others, but there are a few problems with running Wine on BSD at the moment. If anybody is willing to help us out with this, please let me know! Here's a list of some of the porting issues were aware of: http://wiki.freebsd.org/Wine Thanks! -- Kris Moore PC-BSD Software http://www.pcbsd.com

May 30, 2007

Re: Ownerdraw listview font patch...

by Dimi Paun

On Wed, May 30, 2007 08:47, Markus Gömmel wrote: > Before sending this to wine.patches, I wanted to ask if anyone here can tell > me if the above is ok or total bullshit. Looks good to me. I wonder if we shouldn't set other things as well, but this would require testing to figure out. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

May 30, 2007

Re: Implement the WriteEnvironmentStrings standard action

by James Hawkins

On 5/29/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > "James Hawkins" <truiken(a)gmail.com> wrote: > > > + HKEY env, root = HKEY_CURRENT_USER; > ... > > + if (flags & ENV_MOD_MACHINE) > > + root = HKEY_LOCAL_MACHINE; > > It looks like root is not used. > Oops. Thanks for catching that, I'll resend. -- James Hawkins

May 30, 2007

Re: Pretty Build System (Take 3)

by Tom Spear

On 5/29/07, Robert Shearman <rob(a)codeweavers.com> wrote: > Hi, > > Attached is a patch that reduces the verbosity of the build system by > printing the build commands in one of two formats: > COMMAND output_file > or > COMMAND input_file -> output_file > > I hope it meets Alexandre's requirements of not reducing portability of > Wine to other platforms (including Windows). Well, after applying the patch and doing like Kirill instructed me, it looks pretty good. I just have a couple of nits, and they really can be worked out later on. 1) make depend/make install/make uninstall/make test, etc does not appear "pretty" 2) is there any way to "prettify" the entering/leaving directory messages, I think the 2.6 kernel has it that way, but I'm not 100% sure -- Thanks Tom

May 30, 2007

Re: crypt32: implement CryptSIPLoad (resend)

by Juan Lang

Hi Paul, > Please correct me if I'm wrong but aren't you filling pSipDispatch > with the function pointers of the given dll (as indicated by the GUID) > instead of the function pointers of crypt32 (as the tests show it > should)? I am. I couldn't find any reason that the behavior needs to be that way, so I do this until such time as a reason can be found. The tests don't fail, as you check the function pointers from msisip.dll, which isn't present on wine. If you know a good reason native does it that way (or an app that depends on it,) by all means enlighten me. The implementation I sent allows native wintrust to get a bit further. --Juan ____________________________________________________________________________________ Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

May 30, 2007

Ownerdraw listview font patch...

by Markus Gömmel

Hi, one of our windows application is using an OWNERDRAW_FIXED listview. With the current version of Wine I mentioned that when the listview is loosing its focus, the selected item will be repainted in a wrong front (System 12 instead of my MS Shell Dlg 11)... after the focus comes back, the item is redrawn again, now with correct font settings again. After searching for a while my idea is that the LISTVIEW_ShowFocusRect function is missing a SelectObject call to the font stored in the item-structure for this particular listview item. So the hdc transfered over WM_DRAWITEM to the application contains the wrong font. I created the attached patch, which looks like this: --- snipp --- diff -u -u -r1.485 listview.c --- dlls/comctl32/listview.c 25 May 2007 19:46:02 -0000 1.485 +++ dlls/comctl32/listview.c 30 May 2007 12:28:44 -0000 @@ -1770,6 +1770,9 @@ { DRAWITEMSTRUCT dis; LVITEMW item; + + HFONT hFont = infoPtr->hFont ? infoPtr->hFont : infoPtr->hDefaultFont; + HFONT hOldFont = SelectObject(hdc, hFont); item.iItem = infoPtr->nFocusedItem; item.iSubItem = 0; @@ -1788,6 +1791,8 @@ dis.itemData = item.lParam; SendMessageW(infoPtr->hwndNotify, WM_DRAWITEM, dis.CtlID, (LPARAM)&dis); + + SelectObject(hdc, hOldFont); } else { --- snipp --- Before sending this to wine.patches, I wanted to ask if anyone here can tell me if the above is ok or total bullshit. Thanks and regards Markus

May 30, 2007