wine-devel April 2008

wine-devel@winehq.org

148 participants
402 discussions

Including Mono within a Wine package - should Wine expect this?
by Scott Ritchie 10 Apr '08

10 Apr '08

I'm trying to decide if it's a good idea to create wine-mono and wine-gecko packages depended on by the wine package. wine-gecko seems easy enough: we just install a local copy of the gecko engine, and then Wine grabs it as soon as it's needed. I'm even thinking of modifying wineprefixcreate to essentially do winetricks gecko at the end, unless someone can point out how that would have bad consequences. wine-mono would function similarly. Is there any reason not to install it around wineprefixcreate time? I'm assuming Microsoft .net or a later mono can be installed to replace mono afterwards (if not this is probably a bug). Even so, does this seem like a good idea? Have any other packagers thought of something like this? The biggest issue at this point seems to be dealing with the fact that gecko can only be built on Windows. I'm not sure how to build the Windows version of Mono either. Thanks, Scott Ritchie

1 0

Re: msvcrtd: add DllMain
by Louis. Lenders 10 Apr '08

10 Apr '08

----- Original Message ---- From: Alexandre Julliard <julliard(a)winehq.org> To: Louis. Lenders <xerox_xerox2000(a)yahoo.co.uk> Cc: wine-devel(a)winehq.org Sent: Thursday, 10 April, 2008 5:15:56 AM Subject: Re: msvcrtd: add DllMain "Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> writes: > Hi, this is for bug http://bugs.winehq.org/show_bug.cgi?id=5133 > > It looks like several apps (like Rubies, and Resolume and i guess > several others) are shipped with a copy of this dll (along with > msvcr71 and others). So i think it's ok to use this native dll then, > and that is what this patch does. In this way this patch fixes bug > #5133 It doesn't fix anything, it just hides the bug. -- Alexandre Julliard julliard(a)winehq.org Maybe "fix" wasn't the right word; on the other hand, if you call it hiding a bug, then we're hiding tons of bugs, like in gdiplus, that also loads the native gdiplus, if that is shipped with the application. Anyway, if you don't like it that way, just leave it ___________________________________________________________ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/

1 0

Re: msvcrtd: add DllMain
by Alexandre Julliard 10 Apr '08

10 Apr '08

"Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> writes: > Hi, this is for bug http://bugs.winehq.org/show_bug.cgi?id=5133 > > It looks like several apps (like Rubies, and Resolume and i guess > several others) are shipped with a copy of this dll (along with > msvcr71 and others). So i think it's ok to use this native dll then, > and that is what this patch does. In this way this patch fixes bug > #5133 It doesn't fix anything, it just hides the bug. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 14/22] gdiplus: add a stub for GdipSetImageAttributesRemapTable.
by Alexandre Julliard 10 Apr '08

10 Apr '08

"Lei Zhang" <thestig(a)google.com> writes: > @@ -62,6 +64,13 @@ typedef ImageAbort GetThumbnailImageAbort; > > #ifdef __cplusplus > > +/* FIXME: missing the methods. */ > +class Color > +{ > +public: > + ARGB color; > +}; > + I think this belong in gdipluscolor.h. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/2] winspool.drv: GetDefaultPrinterW reads the value from data in registry
by Detlef Riekenberg 10 Apr '08

10 Apr '08

On Di, 2008-04-08 at 15:39 +0400, Konstantin Kondratyuk wrote: > - if (!GetProfileStringW(windowsW, deviceW, emptyStringW, buffer, > len)) > + if(!RegOpenKeyW(HKEY_CURRENT_USER, user_default_reg_key, &hKey) > + && !RegQueryValueExW(hKey, keyname, NULL, &type, > (LPBYTE)buffer, &bufsize)) > + { > + TRACE("Get value from registry\n"); > + RegCloseKey( hKey ); > + } win3.x and win9.x use only "win.ini". We need to fix bug #4096, before we can switch to the Registry. > + else if (!GetProfileStringW(windowsW, deviceW, emptyStringW, > buffer, len)) There is no need for a Fallback, when bug #4096 is fixed. -- By by ... Detlef

2 1

Re: kernel32: Fix for WritePrivateProfileString Sharing Problem [1/2](ATTEMPT 2)
by Dmitry Timoshkov 10 Apr '08

10 Apr '08

"Erich Hoover" <ehoover(a)mines.edu> wrote: > + oldError = GetLastError(); > + /* Read and Write sharing are necessary if a flush is performed on an open file */ > + hFile = CreateFileW(CurProfile->filename, GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, CREATE_ALWAYS, > FILE_ATTRIBUTE_NORMAL, NULL); > if (hFile == INVALID_HANDLE_VALUE) > { > WARN("could not save profile file %s (error was %d)\n", debugstr_w(CurProfile->filename), GetLastError()); > return FALSE; > } > + /* The operation has succeed, do not over-write the error code */ > + SetLastError(oldError); It's been said many times that if you need to save/restore last error value you are doing something wrong. > + /* Get* routines set S_OK on success, Write* routines return last error */ > + SetLastError(S_OK); There is no point in setting or checking last error value on success in vast majority of cases, do you have an app that depends on this? Besides, S_OK is an OLE error code and can not be used in kernel. -- Dmitry.

2 1

Re: [PATCH] user32: on VK_RETURN, send WM_COMMAND to ancestor, not parent.
by Dmitry Timoshkov 10 Apr '08

10 Apr '08

"Lei Zhang" <thestig(a)google.com> wrote: > I noticed I can no longer install an application which uses the NSIS > installer by repeatedly hitting enter until it finished. I did some > testing and it looks like for VK_RETURN, we should be sending > WM_COMMAND to the ancestor, and not the parent. Was edit control reparented at some point? Perhaps WM_COMMAND should be sent to an original parent? -- Dmitry.

2 7

%ALLUSERSPROFILE%
by Austin English 10 Apr '08

10 Apr '08

Wanted to get clarification before going through the trouble of writing this patch. Where would you prefer this variable Alexandre? I've seen two responses: http://www.winehq.org/pipermail/wine-devel/2007-May/056555.html http://www.winehq.org/pipermail/wine-devel/2005-March/035004.html Trying to fix 7292 as well as a few others with this, but didn't want to waste time on the wrong approach. - Austin

2 1

New winetricks-20080409: new verb vista, don't get confused by WGETRC, use curl and openssl if needed
by Dan Kegel 10 Apr '08

10 Apr '08

Another day, another winetricks. Version 20080409 has the following changes: Added winver=vista, since I found an app that refuses to install if winnt <= 502. Use curl and openssl instead of wget and sha1sum if needed (e.g. on mac), as suggested by Ryan Schmidt Use -nd option with wget, as suggested by Hin-Tak Leung As always, winetricks is available at http://kegel.com/wine/winetricks

2 1

Re: [1/2] WineD3D: Do not activate CTXUSAGE_BLIT for fb -> texture reading
by Stefan Dösinger 09 Apr '08

09 Apr '08

Am Donnerstag, 10. April 2008 00:42:04 schrieb Stefan Dösinger: > This ActivateContext call slipped in with patch > ba90a740beb9ce9a839cc843db8d87f5a37becdd. Roderick, was there a particular > reason why you activate CTXUSAGE_BLIT here, or was it just a copypaste > mistake from the glReadPixels codepath? I see now why the ActivateContext call is there. If the LoadLocation is not called from the PreLoad readback then a different surface might be active. Also CTXUSAGE_BLIT seems to be necessary in some situations, but I don't know which yet. I guess more investigation is needed here So please do not apply the patches yet

1 0

← Newer
1
...
23
24
25
26
27
28
29
...
41
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel April 2008