wine-devel November 2010

wine-devel@winehq.org

100 participants
282 discussions

Re: xlive: add initial stub dll (1/3)
by Alexandre Julliard 03 Nov '10

03 Nov '10

Austin English <austinenglish(a)gmail.com> writes: > This dll is not a core part of windows (at least, not yet), but I > think it should be considered for inclusion in Wine. A bit of > explanation is necessary: > > xlive.dll comes from Games for Windows (1,2), whose installer depends > on .Net 3.5 (can be skipped with the /nodotnet parameter). Native > fails on wine, however, unless a native msasn1.dll is provided, > because xlive.dll is digitally signed (so implementing our own > msasn1.dll won't help). As it currently stands, users can't play any > 'Game for Windows' that doesn't have a Windows license. That's not a good enough reason, particularly considering how ugly the resulting code is. And it seems unlikely that this is ever going to move beyond the nasty hack stage, given the lack of documentation. -- Alexandre Julliard julliard(a)winehq.org

5 4

Re: [PATCH 01/14] [Msvcrt]: now using macro for parameters validation itoa_s (and updated the tests as well)
by Alexandre Julliard 03 Nov '10

03 Nov '10

Eric Pouech <eric.pouech(a)orange.fr> writes: > +/* As of today, native and builtin msvcr80, msvcr90, msvcr100 raise an exception on CRT > + * parameter checking on "secure" > + * As Wine forwards most of the APIs of those msvcrNN DLLs to msvcrt, builtin msvcrt does > + * raise an exception on those cases > + * Testing shows that native msvcrt doesn't > + * So we make this test always succeed under Windows > + */ That's not very useful. This should be tested in msvcr90, where we can properly check whether the handler is called. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msvcrt: Implement _get_tzname.
by Dmitry Timoshkov 03 Nov '10

03 Nov '10

Eryk Wieliczko <ewdevel(a)gmail.com> wrote: > -static char tzname_std[64] = ""; > -static char tzname_dst[64] = ""; > +static char tzname_std[64] = "PST"; > +static char tzname_dst[64] = "PDT"; > char *MSVCRT__tzname[2] = { tzname_std, tzname_dst }; ... This is not an implementation, this is a quick and dirty hack. -- Dmitry.

1 0

Re: [6/6] msvcr80/tests: _itow_s tests
by Marvin 03 Nov '10

03 Nov '10

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=6762 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [5/6] msvcr80/tests: qsort_s tests
by Marvin 03 Nov '10

03 Nov '10

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=6761 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [4/6] msvcr80/tests: install test files
by Marvin 03 Nov '10

03 Nov '10

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=6760 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: ddraw: Exclusive mode is the corner case for SetCooperative, not the normal mode.
by Marvin 03 Nov '10

03 Nov '10

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=6757 Your paranoid android. === W98SE (32 bit ddrawmodes) === ddrawmodes: unhandled exception c0000005 at 004122E8 === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

Use of uninitialized variable in combine_uri()
by Gerald Pfeifer 03 Nov '10

03 Nov '10

Hi Thomas, the following change of yours commit bced2e21dbc548ef9d41e3ff11384d7ad964c929 Author: Thomas Mullaly <thomas.mullaly(a)gmail.com> Date: Sat Oct 9 11:02:17 2010 -0400 urlmon: Implemented base case for CoInternetCombineIUri. introduces a new warning, use of uninitialized variable in the line marked "HERE" below. +static HRESULT combine_uri(Uri *base, Uri *relative, DWORD flags, IUri **result + Uri *ret; + HRESULT hr; + parse_data data; + + /* Base case is when the relative Uri has a scheme name, + * if it does, then 'result' will contain the same data + * as the relative Uri. + */ + if(relative->scheme_start > -1) { + DWORD create_flags = 0; + + memset(&data, 0, sizeof(parse_data)); + + data.uri = SysAllocString(relative->raw_uri); + if(!data.uri) { + IUri_Release(URI(ret)); <================== HERE + *result = NULL; + return E_OUTOFMEMORY; + } >From all I can tell this is a legitimate warning, that is, the code really invokes undefined behavior. Would you mind having a look? Gerald

2 1

re: xlive and msasn1.dll
by Dan Kegel 02 Nov '10

02 Nov '10

Austin wrote: > xlive.dll comes from Games for Windows ... [and] > fails on wine, however, unless a native msasn1.dll is provided, > because xlive.dll is digitally signed (so implementing our own > msasn1.dll won't help). That's interesting. I wonder what other modules Microsoft is checking signatures on, and whether they're planning on doing that more often in the future.

2 1

(no subject)
by Matijn Woudt 02 Nov '10

02 Nov '10

1 0

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

Jump to page:

2025

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 November 2010