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

1.0 bugs
by Dan Kegel Nov. 26, 2007

Nov. 26, 2007

[putting on tastemaster hat] So far, 82 bugs have been nominated to be fixed for 1.0. I checked a bunch of them, and so far most look reasonable. Some even look easy or have patches, e.g. http://bugs.winehq.org/show_bug.cgi?id=5402 http://bugs.winehq.org/show_bug.cgi?id=5884 http://bugs.winehq.org/show_bug.cgi?id=7544 http://bugs.winehq.org/show_bug.cgi?id=7571 http://bugs.winehq.org/show_bug.cgi?id=9104 http://bugs.winehq.org/show_bug.cgi?id=10147 The list looks meaty enough that it's probably worth folks going through and seeing what they can pick off. Stuff that's silly or too hard - just skip it for now, we'll defer those for later. - Dan

1 1

Re: d3dx8: Implementation of D3DXAssembleShaderFromFileA using D3DXAssembleShaderFromFileW
by Stefan Dösinger Nov. 26, 2007

Nov. 26, 2007

Am Montag, 26. November 2007 11:37:28 schrieb luis.busquets(a)ilidium.com: > --- > dlls/d3dx8/d3dx8_main.c | 22 ++++++++++++++++------ > include/d3dx8core.h | 4 ++-- > 2 files changed, 18 insertions(+), 8 deletions(-) Please watch out with indentions. You are mixing tabs and spaces in D3DXAssembleShaderFromFileA, so the code looks a bit dissorted here.

1 0

Re: Re: urlmon: Wrap heap functions.
by Lionel Debroux Nov. 26, 2007

Nov. 26, 2007

Hi, > In Wine HeapAlloc gets wrapped in different places, each using a > different name and even a different naming convention. This makes the > code harder to understand for people that browse the code (people doing > janitorial work) as they have to check every time if the function is yet > another wrapper around HeapFree or if the function is doing more than > that. And this makes it even harder for static code analyzing tools. I second Michael on that. A number of spurious entries previously in his list of potential issues detected by Smatch ( http://people.redhat.com/mstefani/wine/smatch/bugs_all.html ) were due to the wrappers around HeapFree that the script wasn't yet aware of. Currently, the list of functions that allocate memory, in the unfree_wine script, contains 33 entries. The list of functions that free memory contains 34 entries. > I therefore propose to standardize all the internal HeapAlloc wrappers > to a common name and form, Something along the lines of: > walloc() > wzalloc() > wrealloc() > wzrealloc() > wfree() > It's short and concise and doesn't conflict with the Win32 API. I like that solution. Bye, Lionel. ____________________________________________________________________________________________ Yahoo! Mail innove : interface hyper pratique, messenger intégré, couleurs - http://mail.yahoo.fr

1 0

Re: widl [1/7]: Output working exception handling macros. [take 2]
by Alexandre Julliard Nov. 26, 2007

Nov. 26, 2007

Dan Hipschman <dsh(a)linux.ucla.edu> writes: > This is essentially the same as the last attempt but doesn't add a wine- > internal function to kernel32. It just puts the code directly in the > widl-generated exception handler. An alternative is to handle these access- > based page faults for which we can continue in the signal handler (signal_i386, > etc., in ntdll) so they never actually result in an exception being raised. > I'm not sure if anything depends on the current behavior and didn't want to > mess much more with the exception handling code than I had to. You shouldn't have to do anything of the kind, there's no reason that the generated code has to duplicate the unhandled exception filter. What you have to do is to filter properly and not catch exceptions you are not interested in. For cases where Windows would catch the access violation exception, then the unhandled filter won't be called on Windows either, that's the way it's supposed to work. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: d3dx8: Implementation of D3DXAssembleShaderFromFileA using D3DXAssembleShaderFromFileW
by Dmitry Timoshkov Nov. 26, 2007

Nov. 26, 2007

<luis.busquets(a)ilidium.com> wrote: > + LPWSTR pSrcFileW = NULL; > + DWORD len; > + HRESULT ret; > + if (pSrcFile) > + { > + len = MultiByteToWideChar( CP_ACP, 0, pSrcFile, -1, NULL, 0 ); > + pSrcFileW = HeapAlloc( GetProcessHeap(), 0, len * sizeof(WCHAR) ); > + MultiByteToWideChar( CP_ACP, 0, pSrcFile, -1, pSrcFileW, len ); > + ret=D3DXAssembleShaderFromFileW(pSrcFileW, Flags, ppConstants, ppCompiledShader, ppCompilationErrors); > + HeapFree( GetProcessHeap(), 0, pSrcFileW ); > + return ret; > + } > + else return D3DXERR_INVALIDDATA; > } Usually it's much more readable and helps to avoid not necessary indentation to check parameters at the start of the function and return right away with appropriate error code. Besides you are mixing tabs and spaces. > -HRESULT WINAPI D3DXAssembleShaderFromFileW(LPSTR pSrcFile, DWORD Flags, > +HRESULT WINAPI D3DXAssembleShaderFromFileW(LPWSTR pSrcFile, DWORD Flags, You marked pSrcFile parameter 'const' in D3DXAssembleShaderFromFileA declaration but not in D3DXAssembleShaderFromFileW, any reason for that? -- Dmitry.

1 0

Fontforge and building wine
by Dan Kegel Nov. 26, 2007

Nov. 26, 2007

It's been mentioned many times, but building Wine without a recent fontforge yields a wine that doesn't work too well. Tonight, for instance, I built wine on an updated dapper system, and forgot; here are the commands I had to use to recover (just in case somebody needs to do this again). The fontforge I chose just happens to be the latest; the --without-freetype-bytecode option is there to keep configure from searching the whole freaking hard drive for the nonexistent freetype source tree. tar -xjvf fontforge_full-20071110.tar.bz2 cd fontforge-20071110/ ./configure --prefix=/usr/local/fontforge --without-freetype-bytecode make sudo make install cd ~/wine-git cd fonts make clean PATH=/usr/local/fontforge/bin:$PATH make - Dan

1 0

Re: shdocvw: Silence common invalid QueryInterface FIXMEs.
by Alistair Leslie-Hughes Nov. 25, 2007

Nov. 25, 2007

> hres = IUnknown_QueryInterface(unk, &IID_IRunnableObject, > (void**)&runnable); > ok(hres == E_NOINTERFACE, "QueryInterface returned %08x, expected > E_NOINTERFACE\n", hres); > ok(runnable == NULL, "runnable=%p, ezpected NULL\n", runnable); > + > + hres = IUnknown_QueryInterface(unk, &IID_IPerPropertyBrowsing, > (void**)&propbrowse); > + ok(hres == E_NOINTERFACE, "QueryInterface returned %08x, expected > E_NOINTERFACE\n", hres); > + ok(runnable == NULL, "runnable=%p, ezpected NULL\n", runnable); > + > + hres = IUnknown_QueryInterface(unk, &IID_IOleCache, (void**)&cache); > + ok(hres == E_NOINTERFACE, "QueryInterface returned %08x, expected > E_NOINTERFACE\n", hres); > + ok(cache == NULL, "runnable=%p, ezpected NULL\n", runnable); > } Hi Jacek, The tests seem wrong. Is there a reson your printing runnable twice, and not propbrowse and cache. Best Regards Alistair Leslie-Hughes

1 0

Re: bug fix: Prevented strlen(NULL) in PRINTDLG_CreateDevNames()
by Stefan Dösinger Nov. 25, 2007

Nov. 25, 2007

Am Sonntag, 25. November 2007 12:35:36 schrieb Jorma Laaksonen: > Hello! > > wine-0.9.49 (as well as many earlier versions) seems to crash when > PRINTDLG_CreateDevNames() is for some reason called with DeviceDriverName > equal to NULL. The real cause of this problem might be somewhere else > where the NULL is assigned, but this simple fix prevents NULL being > passed to strlen(). If you suspect that the real problem is somewhere else, it is recommended to write a test case to see how Windows deals with this situation. Windows could return an error if the device driver name is NULL. If Windows crashes as well, your patch would only hide a bug instead of fixing it.

1 0

Re: [Bug 10488] GIT of 16.11 Exeption becaus of VBA while analysing a text
by Zac Brown Nov. 25, 2007

Nov. 25, 2007

wine-bugs(a)winehq.org wrote: > http://bugs.winehq.org/show_bug.cgi?id=10488 > > > > > > --- Comment #14 from Yolande Haneder <yolande(a)haneder.biz> 2007-11-25 00:30:20 --- > Re: > > err:ole:StdMarshalImpl_ReleaseMarshalData could not map object ID to stub > manager, oxid=3700000038, oid=d > err:ole:CoReleaseMarshalData IMarshal::ReleaseMarshalData failed with error > 0x8001011d > > Which I have been told to be a memory conflict in C > > and > > err:ole:apartment_getclassobject DllGetClassObject returned error 0x80040111 > > Could someone tell me which file in Wine is concerned so that someone my look > at it? > > Thank you > > Looks like dlls/ole32/marshal.c by the dump. I believe Dan Kegel had reported a bug for Wine 1.0 based on the dlls/ole32/tests/marshal.c in which it failed. The relevant bug is as follows: http://bugs.winehq.com/show_bug.cgi?id=10076 -Zac

1 1

Asking Valve for Steam Survey Results
by Scott Ritchie Nov. 24, 2007

Nov. 24, 2007

Valve regularly runs surveys of steam users, where they profile many different things about the hardware. They're nice enough to publish the results: http://www.steampowered.com/status/survey.html Some of these provide a way to detect Wine users. Everyone using the "Wine waveout" audio driver, for instance, must be a Wine user. Unfortunately, valve lumps all of these into "other" on the survey results page. Worries about sampling bias aside (maybe Wine users are less likely to do the steam survey), if we had the raw data from Valve we could determine the actual percentage of Steam users playing through Wine. Looking at the data we do have, we may be able to make a good guess from examining the video card driver name field. Excluding NVidia, ATI, and Intel leaves just over 4% of respondents using an "other" video driver like the Wine one. If even only a quarter of these "others" are using Wine, that still gives us 1% of the entire 10 million+ Steam user base, translating into hundreds of thousands of users. Does anyone know whom we can contact at Valve for more specific results? Thanks, Scott Ritchie

5 6