February 2009 - Wine-Devel - list.winehq.org

Re: EVE online losing its Linux Client

by Chris Robinson

On Sunday 08 February 2009 6:17:38 pm Zachary Goldberg wrote: > http://games.slashdot.org/article.pl?sid=09/02/08/206252&from=rss > > It seems that a game studio found that Wine worked so well that they > have given up their efforts to maintain a native client. While > encouraging that Wine works so well, there is a very interesting > debate which could be had as to whether or not this kind of affect is > desirable. Their "native Linux client" was the Windows client on top of Cedega. They're stopping support for the official client running on Cedega, and instead recommending Wine.

Feb. 9, 2009

EVE online losing its Linux Client

by Zachary Goldberg

http://games.slashdot.org/article.pl?sid=09/02/08/206252&from=rss It seems that a game studio found that Wine worked so well that they have given up their efforts to maintain a native client. While encouraging that Wine works so well, there is a very interesting debate which could be had as to whether or not this kind of affect is desirable. -Zach

Feb. 9, 2009

Re: imagicos

by Ben Klein

2009/2/9 Remco <remco47(a)gmail.com>: > On Sat, Feb 7, 2009 at 11:12 PM, Hin-Tak Leung <hintak_leung(a)yahoo.co.uk> wrote: >> That's right - GPL allows you to charge for binaries, and any amount for that matter. GPL just means who ever received the binaries are also entitled to the source code, and *also* the right to sell both onward - and possibly as a competitor to you - so you cannot charge 'unreasonable' amounts. >> A few people have cleared this up. A misunderstanding of the terms on my part. > Exactly. I find this whole thread a bit weird. Isn't it great that > (commercial) Linux distributions are shipping Wine? Those exaggerated > claims of compatibility are just marketing talk. I've seen worse. Marketing? More like outright lies. If only they were based in Australia, where I know for a fact we have truth in advertising laws. I have no idea about other countries :) > Remco

Feb. 9, 2009

Re: New coverity run Feb 7, 14 new warnings

by Jacek Caban

Dan Kegel wrote: > Is it a bug? I don't know those flags well enough. It's not a bug, a constant 0 value is passed as flags to set_nsstyle_attr. I've marked it as FALSE in coverity. Jacek

Feb. 9, 2009

Re: New coverity run Feb 7, 14 new warnings

by Dan Kegel

Alistair wrote: >> 873 FORWARD_NULL HTMLStyle_put_fontWeight dlls/mshtml/htmlstyle.c > > NULL is a valid value to be passed though to gecko. Here's more of the error: dlls/mshtml/htmlstyle.c Event var_deref_model: Variable "v" tracked as NULL was passed to a function that dereferences it. [model] Also see events: [var_compare_op] 646 return set_nsstyle_attr(This->nsstyle, STYLEID_FONT_WEIGHT, v, 0); 647 } 648 htmlstyle.c: 216 HRESULT set_nsstyle_attr(nsIDOMCSSStyleDeclaration *nsstyle, styleid_t sid, LPCWSTR value, DWORD flags) 217 { 218 nsAString str_name, str_value, str_empty; 219 LPWSTR val = NULL; 220 nsresult nsres; 221 222 static const PRUnichar wszEmpty[] = {0}; 223 At conditional (1): "flags & 1 != 0" taking false path 224 if(flags & ATTR_FIX_PX) Event deref_parm_in_call: Dereferenced parameter "value" in the function "fix_px_value" [model] Also see events: [deref_parm_in_call] 225 val = fix_px_value(value); At conditional (2): "flags & 2 != 0" taking true path 226 if(flags & ATTR_FIX_URL) Event deref_parm_in_call: Dereferenced parameter "value" in the function "fix_url_value" [model] Also see events: [deref_parm_in_call] 227 val = fix_url_value(value); So it's not passing it to gecko, it's passing it to another mshtml function that maybe passes it to fix*value() which dereferences it. Is it a bug? I don't know those flags well enough. - Dan

Feb. 9, 2009

Re: New coverity run Feb 7, 14 new warnings

by Alistair Leslie-Hughes

Hi Dan, > 873 FORWARD_NULL HTMLStyle_put_fontWeight > dlls/mshtml/htmlstyle.c NULL is a valid value to be passed though to gecko. Best Regards Alistair Leslie-Hughes

Feb. 8, 2009

Re: imagicos

by Remco

On Sat, Feb 7, 2009 at 11:12 PM, Hin-Tak Leung <hintak_leung(a)yahoo.co.uk> wrote: > That's right - GPL allows you to charge for binaries, and any amount for that matter. GPL just means who ever received the binaries are also entitled to the source code, and *also* the right to sell both onward - and possibly as a competitor to you - so you cannot charge 'unreasonable' amounts. > Exactly. I find this whole thread a bit weird. Isn't it great that (commercial) Linux distributions are shipping Wine? Those exaggerated claims of compatibility are just marketing talk. I've seen worse. Remco

Feb. 8, 2009

Re: Question about redirection handles in wcmd

by Erich Hoover

On Sat, Feb 7, 2009 at 2:09 PM, Erich Hoover <ehoover(a)mines.edu> wrote: > I tracked down an issue where an application was running into a sharing > problem in WCMD_execute when it created redirects to the same file more than > once. I originally hacked around this issue by changing the sharing mode > for redirects, but I've now narrowed down the issue. I discovered that the > file handle is not being closed when a command has completed and that this > issue is caused by the "old handle" value being INVALID_HANDLE_VALUE: > http://source.winehq.org/source/programs/cmd/wcmdmain.c#L1562 > The "old handle" value is being set to this because of a call to > GetStdHandle (you see, GetStdHandle(STD_OUTPUT_HANDLE) == > INVALID_HANDLE_VALUE): > http://source.winehq.org/source/programs/cmd/wcmdmain.c#L1399 > > So, my question is whether the call to GetStdHandle is important. If not > then line 1399 can easily be simplified to: > old_stdhandles[handle] = idx_stdhandles[handle]; > Make this change resolves the sharing issue that I'm seeing, but if it is > important to use GetStdHandle there then instead the "cleanup" code located > near line 1562 needs to be more intelligent. > > Erich Hoover > ehoover(a)mines.edu > Looking at this a little more it appears that GetStdHandle(STD_OUTPUT_HANDLE) is not normally supposed to be INVALID_HANDLE_VALUE. This appears to be happening in this case because cmd.exe was launched in such a way that it has no input and output handles. So, it appears to me that when cmd.exe is launched without stdin and stdout handles that no handle cleanup occurs for redirects (causing the problem I've been experiencing). Does this sound right to anyone? Erich Hoover ehoover(a)mines.edu

Feb. 8, 2009

New coverity run Feb 7, 14 new warnings

by Dan Kegel

Congrats to everyone who's been cleaning up Coverity warnings, especially Marcus (http://marcusmeissner.livejournal.com/24466.html) Here are the yet-uninspected warnings that are in the Feb 7 run but not in the Jan 30 run: 884 REVERSE_INULL compile_file_regex dlls/dbghelp/symbol.c 883 RESOURCE_LEAK forward tools/winegcc/winegcc.c 882 RESOURCE_LEAK build tools/winegcc/winegcc.c 881 RESOURCE_LEAK build tools/winegcc/winegcc.c 880 RESOURCE_LEAK build tools/winegcc/winegcc.c 879 RESOURCE_LEAK compile tools/winegcc/winegcc.c 878 RESOURCE_LEAK compile tools/winegcc/winegcc.c 877 RESOURCE_LEAK compile tools/winegcc/winegcc.c 876 OVERRUN_STATIC DOSVM_outport dlls/winedos/ioports.c 875 NULL_RETURNS __wine_make_gdi_object_system dlls/gdi32/gdiobj.c 874 FORWARD_NULL merge_diff_row dlls/msi/database.c 873 FORWARD_NULL HTMLStyle_put_fontWeight dlls/mshtml/htmlstyle.c 872 FORWARD_NULL NTDLL__vsnprintf dlls/ntdll/printf.c 871 DEADCODE reg_delete programs/reg/reg.c If anyone wants access to the Coverity data, let me or one of the other coverity users know. - Dan

Feb. 8, 2009

Re: New Wine Gecko package

by Jacek Caban

Vitaliy Margolen wrote: > Jacek Caban wrote: > >> Hi all, >> >> The last release of Wine Gecko caused a few regressions. >> > > Yes it did and some are still not fixed. Flash does not work anymore on all > the pages. This really needs to be fixed. > I've been looking on it for a while and I didn't find the fix. I'm attaching a hack that might help if someone is interested in working on it. Jacek diff --git a/dlls/mshtml/nsio.c b/dlls/mshtml/nsio.c index 7c402b2..9d3b1c6 100644 --- a/dlls/mshtml/nsio.c +++ b/dlls/mshtml/nsio.c @@ -2165,10 +2165,26 @@ static nsresult NSAPI nsIOService_NewChannelFromURI(nsIIOService *iface, nsIURI nsIChannel *channel = NULL; nsChannel *ret; nsIWineURI *wine_uri; + nsACString schema_str; + const char *schema; + BOOL b; nsresult nsres; TRACE("(%p %p)\n", aURI, _retval); + /* + * Our wrapped nsChannel object doesn't work for Flash, so we use URI heuristic + * and return necko object for *.swf channels. + */ + nsACString_Init(&schema_str, NULL); + nsIURI_GetScheme(aURI, &schema_str); + nsACString_GetData(&schema_str, &schema); + b = !strstr(schema, ".swf"); + nsACString_Finish(&schema_str); + + if(b) + return nsIIOService_NewChannelFromURI(nsio, aURI, _retval); + nsres = nsIIOService_NewChannelFromURI(nsio, aURI, &channel); if(NS_FAILED(nsres) && nsres != NS_ERROR_UNKNOWN_PROTOCOL) { WARN("NewChannelFromURI failed: %08x\n", nsres);

Feb. 8, 2009