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

Re: msvcrt: Fixed (_w)fopen_s with test. (try 2)
by Dmitry Timoshkov Nov. 10, 2010

Nov. 10, 2010

Eryk Wieliczko <ewdevel(a)gmail.com> wrote: > + if (!p_fopen_s) > + { > + win_skip("Skipping fopen_s test\n"); > + return; > + } > + else > + { > + /* testing fopen_s */ > + ret = p_fopen_s(&file, name, "w"); > + ok(ret == 0, "fopen_s failed with %d\n", ret); > + ok(file != 0, "fopen_s failed to return value\n"); > + fwrite(name, sizeof(name), 1, file); > + > + ret = fclose(file); > + ok(ret != EOF, "File failed to close\n"); > + > + file = fopen(name, "r"); > + ok(file != 0, "fopen failed\n"); > + len = fread(buff, 1, sizeof(name), file); > + ok(len == sizeof(name), "File length supposed to be %d, not %d\n", sizeof(name), len); > + buff[sizeof(name)] = '\0'; > + ok(strcmp(name, buff) == 0, "File content mismatch! Got %s, expected %s\n", buff, name); > + > + ret = fclose(file); > + ok(ret != EOF, "File failed to close\n"); > + > + ok(_unlink(name) == 0, "Couldn't unlink file named '%s'\n", name); > + } > +} The whole 'else { }' block is not necessary, same for the test below. -- Dmitry.

1 0

GetSystemPaletteEntries() patch
by Eric Durbin Nov. 10, 2010

Nov. 10, 2010

What was wrong with the patch sent in this post? http://article.gmane.org/gmane.comp.emulators.wine.devel/54403%29

1 0

Re: msvcrt: Fixed (_w)fopen_s with test. (try 2)
by Marvin Nov. 10, 2010

Nov. 10, 2010

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=6922 Your paranoid android. === W98SE (32 bit file) === file.c:999: Test failed: smaller size block: Wrong error data () file.c:1007: Test failed: smaller size block: Stdout file shouldn't contain data

1 0

Re: krnl386.exe: Mention dosemu
by Charles Davis Nov. 9, 2010

Nov. 9, 2010

On 11/9/10 4:20 PM, André Hentschel wrote: > @@ -643,7 +643,7 @@ static DWORD WINAPI MZ_DOSVM( LPVOID lpExtra ) > > if (GetLastError() == ERROR_NOT_SUPPORTED) > MESSAGE( "wine: Cannot start DOS application %s\n" > - " because vm86 mode is not supported on this platform.\n", > + " because vm86 mode is not supported on this platform, try dosemu.\n", You mean DOSBox, right? dosemu needs vm86(2) anyway, and AFAIK isn't even available on non-Linux. Chip

1 0

Re: msvcrt: Fixed (_w)fopen_s always fails.
by Austin English Nov. 9, 2010

Nov. 9, 2010

On Tue, Nov 9, 2010 at 9:38 PM, Eryk Wieliczko <ewdevel(a)gmail.com> wrote: > (_w)fopen_s were always failing due to regression introduced in > commit 00f07046c0be658d97c47f69e1b4c518bc06b3a2 > --- > dlls/msvcrt/file.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/msvcrt/file.c b/dlls/msvcrt/file.c > index 329cdeb..91cd448 100644 > --- a/dlls/msvcrt/file.c > +++ b/dlls/msvcrt/file.c > @@ -2742,7 +2742,7 @@ int CDECL MSVCRT_fopen_s(MSVCRT_FILE** pFile, > const char *filename, const char *mode) > { > if (!MSVCRT_CHECK_PMT(pFile != NULL) || !MSVCRT_CHECK_PMT(filename != NULL) || > - MSVCRT_CHECK_PMT(mode != NULL)) { > + !MSVCRT_CHECK_PMT(mode != NULL)) { > *MSVCRT__errno() = MSVCRT_EINVAL; > return MSVCRT_EINVAL; > } > @@ -2769,7 +2769,7 @@ int CDECL MSVCRT__wfopen_s(MSVCRT_FILE** pFile, const MSVCRT_wchar_t *filename, > const MSVCRT_wchar_t *mode) > { > if (!MSVCRT_CHECK_PMT(pFile != NULL) || !MSVCRT_CHECK_PMT(filename != NULL) || > - MSVCRT_CHECK_PMT(mode != NULL)) { > + !MSVCRT_CHECK_PMT(mode != NULL)) { > *MSVCRT__errno() = MSVCRT_EINVAL; > return MSVCRT_EINVAL; > } > -- > 1.7.0.4 Sounds like a good reason to add a unit test to prevent it from happening again, then. -- -Austin

1 0

Re: (try 2)[PATCH 1/4] d3dcompiler: Add initial reflection parsing.
by Henri Verbeet Nov. 9, 2010

Nov. 9, 2010

2010/11/8 Rico Schüller <kgbricola(a)web.de>: > - object->vtbl = &d3dcompiler_shader_reflection_vtbl; > - object->refcount = 1; > + hr = d3dcompiler_shader_reflection_init(object, data, data_size, riid); > + if (FAILED(hr)) > + { > + WARN("Failed to initialize shader reflection\n"); > + IUnknown_Release((IUnknown *)object); > + return hr; > + } You can't do that. Since d3dcompiler_shader_reflection_init() is responsible for setting the vtbl, you can't assume it's set if d3dcompiler_shader_reflection_init() fails. You'll have to use HeapFree() here. > + if (!IsEqualGUID(riid, &IID_ID3D11ShaderReflection)) > + { > + WARN("Wrong rrid %s, accept only %s!\n", debugstr_guid(riid), debugstr_guid(&IID_ID3D11ShaderReflection)); > + return E_FAIL; > + } This can be done in D3DReflect() before even allocating the reflection object. (Also, "rrid" is a typo.)

2 3

Re: AUTHORS list and the C locale on Mac OS X
by James Mckenzie Nov. 9, 2010

Nov. 9, 2010

Charles Davis <cdavis(a)mymail.mines.edu> wrote: > >Hi, > >There may be a problem with the way the authors.c file is generated on a >Mac with GNU sed installed. > >On Mac OS X, the C locale's default encoding is MacRoman, not UTF-8. >This has some pretty surprising consequences. For example, since the >AUTHORS file contains UTF-8 multibyte sequences that aren't valid in the >MacRoman encoding, GNU sed doesn't match those sequences in the .* >regexp, and the authors.c file comes out wrong. Mac OS sed does not have >this problem. So now I'm stuck changing the Makefile to use the system >sed (in /usr/bin) instead of GNU sed. > I found this a long time ago. Fink just modifies the Authors.c file to remove those sequences. I went one better and removed GNU sed from my Mac (fink purge sed) as I found that MacOSX version of sed would do everything that GNU sed did and I did not have to edit the file. >I could uninstall GNU sed, but there's one small problem. I have a >Gentoo prefix set up. It is the reason I have GNU sed installed. If I >install or upgrade practically anything in my Gentoo prefix, then GNU >sed will just get pulled right back in. > >Reading the manual for GNU sed tells me that this is by design and that >this behavior--not matching characters that are invalid in the current >locale--is in fact mandated by POSIX. If that's the case, then the >LC_ALL= statement in the Makefile needs to change. To what, I don't >know. I'm hoping one of you has an idea. > >If you think, however, that this is a bug in GNU sed, then I will gladly >write a report to the maintainer about it. > No, it is not a bug in GNU sed. The authors.c file needs to have the erroneous characters for the language used by MacOSX changed to be acceptable? James McKenzie

2 1

AUTHORS list and the C locale on Mac OS X
by Charles Davis Nov. 9, 2010

Nov. 9, 2010

Hi, There may be a problem with the way the authors.c file is generated on a Mac with GNU sed installed. On Mac OS X, the C locale's default encoding is MacRoman, not UTF-8. This has some pretty surprising consequences. For example, since the AUTHORS file contains UTF-8 multibyte sequences that aren't valid in the MacRoman encoding, GNU sed doesn't match those sequences in the .* regexp, and the authors.c file comes out wrong. Mac OS sed does not have this problem. So now I'm stuck changing the Makefile to use the system sed (in /usr/bin) instead of GNU sed. I could uninstall GNU sed, but there's one small problem. I have a Gentoo prefix set up. It is the reason I have GNU sed installed. If I install or upgrade practically anything in my Gentoo prefix, then GNU sed will just get pulled right back in. Reading the manual for GNU sed tells me that this is by design and that this behavior--not matching characters that are invalid in the current locale--is in fact mandated by POSIX. If that's the case, then the LC_ALL= statement in the Makefile needs to change. To what, I don't know. I'm hoping one of you has an idea. If you think, however, that this is a bug in GNU sed, then I will gladly write a report to the maintainer about it. Chip

1 0

Re: gdi32: Remove broken check for WinXP.
by Marvin Nov. 9, 2010

Nov. 9, 2010

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=6910 Your paranoid android. === W2KPROSP4 (32 bit font) === Failure running script in VM: Exceeded timeout limit of 315 sec

1 0

Re: [PATCH 10/14] [Msvcrt*]: implemented _vc(w)printf
by Alexandre Julliard Nov. 9, 2010

Nov. 9, 2010

Eric Pouech <eric.pouech(a)orange.fr> writes: > +int CDECL _vcprintf(const char* format, __ms_va_list xvalist) > { > char buf[2048], *mem = buf; > int written, resize = sizeof(buf), retval; > - __ms_va_list valist; > + __ms_va_list valist = xvalist; You can't copy a valist. This needs to be integrated properly with the other printf functions. -- Alexandre Julliard julliard(a)winehq.org

3 4

Re: [PATCH] [Msvcrt]: now using macro for parameters validation itoa_s (and updated the tests as well)
by Eric Pouech Nov. 9, 2010

Nov. 9, 2010

to sum up the recent discrepencies between msvcrt and msvcrN0 Dlls: - msvcrt doesn't raise exception on _s functions while msvcrN0 does - (likely) in _s functions returning an errno_t value, msvcrt does set errno to the returned value, while msvcrN0 doesn't change the errno value (tested on _itoa_s and wcsncat_s) I wonder if should challenge the current scheme of forwarding all APIs from msvcrN0 to msvcrt (and writing wrappers in msvcr90 to cope with the various discrepencies) we could let msvcrt behave differently when loaded from our msvcrN0 DLLs than when loaded standalone, and factorize the discrepencies within msvcrt itself comments welcome A+ -- Eric Pouech

1 0

(no subject)
by Greg Geldorp Nov. 8, 2010

Nov. 8, 2010

> From: Eric Pouech > > how come I got two different test results for the same patch ? > moreover one is perfectly ok, while the other shows strange results > any idea ? Yeah, that's a bit weird. The only thing I can think of is some kind of timing issue, but looking at the code that seems unlikely in this case. So basically, I don't have a clue. Ge.

3 2

wine cannot handle fc-cache (64bit) but fc-cache32 is okay
by Per Olesen Nov. 8, 2010

Nov. 8, 2010

Hi Is it as-it-should-be, that wine only handles 32bit fc-cache? Is it known, that executing the 64bit version /usr/sbin/fc-cache will make the font-cache fail for wine, hence making wine *very* slow to startup? Rebuilding the cache with fc-cache32 makes wine start quickly again. It seems that the actual font cache format for fc-cache has changed between architectures. ? Regards, Per

1 0

Re: winegcc: Add Macho-o lib detection support
by Charles Davis Nov. 8, 2010

Nov. 8, 2010

On 11/8/10 10:52 AM, André Hentschel wrote: > @@ -321,7 +321,8 @@ static int check_platform( struct options *opts, const char *file ) > unsigned char header[16]; > if (read( fd, header, sizeof(header) ) == sizeof(header)) > { > - /* FIXME: only ELF is supported, platform is not checked beyond 32/64 */ > + /* FIXME: only ELF and Macho-o is supported, platform is not checked beyond 32/64 */ Typo 'Macho-o'. > @@ -331,6 +332,15 @@ static int check_platform( struct options *opts, const char *file ) > ret = (opts->force_pointer_size == 4 || > (!opts->force_pointer_size && opts->target_cpu != CPU_x86_64)); > } > + /* Big Endian or Little Endian Mach-o File */ > + else if (!memcmp( header, "\376\355\372\316", 4 ) || !memcmp( header, "\316\372\355\376", 4 )) For 64-bit files, the magic number is 0xfeedfacf, not 0xfeedface. (Notice how the 64-bit magic is one more than the 32-bit magic.) You should check for that, too. I would like to take this time to point out that on Mac OS, there are no separate 32-bit and 64-bit library directories (i.e. no lib32 and lib64, only lib). If you want a 32-bit and a 64-bit version of a binary or library installed, you're expected to build a fat binary/library. Nearly all of the system libraries and binaries installed with Mac OS X are in fact fat. Chip

2 1

'winetricks dotnet35' starting to work
by Dan Kegel Nov. 8, 2010

Nov. 8, 2010

In svn ( http://winezeug.googlecode.com/svn/trunk/winetricks ), I've added Louis' workaround from http://bugs.winehq.org/show_bug.cgi?id=22551#c5 to winetricks dotnet35. This let the game Bloodline Champions at least show its splash screen. Perhaps it will be useful for other apps, too. With wine-1.3.4 or earlier, anyway; dotnet30 explodes with wine-1.3.5 or later, see http://bugs.winehq.org/show_bug.cgi?id=25074

2 1

Re: [PATCH] comctl32/tests: Change expect_band_content test into a macro to ensure line numbers are reported correctly on test failure.
by Alexandre Julliard Nov. 8, 2010

Nov. 8, 2010

Austin Lund <austin.lund(a)gmail.com> writes: > +#define expect_band_content(hRebar, uBand, fStylep, clrForep, clrBackp, \ > + lpTextp, iImagep, hwndChildp, cxMinChildp, cyMinChildp, cxp, hbmBackp, \ > + wIDp, cyChildp, cyMaxChildp, cyIntegralp, cxIdealp, lParamp, cxHeaderp, cxHeader_brokenp) \ > +{ \ > + CHAR buf[MAX_PATH] = "abc"; \ > + REBARBANDINFOA rb; \ > + memset(&rb, 0xdd, sizeof(rb)); \ > + rb.cbSize = REBARBANDINFOA_V6_SIZE; \ > + rb.fMask = RBBIM_BACKGROUND | RBBIM_CHILD | RBBIM_CHILDSIZE | RBBIM_COLORS \ > + | RBBIM_HEADERSIZE | RBBIM_ID | RBBIM_IDEALSIZE | RBBIM_IMAGE | RBBIM_LPARAM \ > + | RBBIM_SIZE | RBBIM_STYLE | RBBIM_TEXT; \ > + rb.lpText = buf; \ > + rb.cch = MAX_PATH; \ > + ok(SendMessageA(hRebar, RB_GETBANDINFOA, uBand, (LPARAM)&rb), "RB_GETBANDINFO failed\n"); \ > + expect_eq(rb.fStyle, fStylep, int, "%x"); \ > + expect_eq(rb.clrFore, clrForep, COLORREF, "%x"); \ > + expect_eq(rb.clrBack, clrBackp, COLORREF, "%x"); \ > + expect_eq(strcmp(rb.lpText, lpTextp), 0, int, "%d"); \ > + expect_eq(rb.iImage, iImagep, int, "%x"); \ > + expect_eq(rb.hwndChild, hwndChildp, HWND, "%p"); \ > + expect_eq(rb.cxMinChild, cxMinChildp, int, "%d"); \ > + expect_eq(rb.cyMinChild, cyMinChildp, int, "%d"); \ > + expect_eq(rb.cx, cxp, int, "%d"); \ > + expect_eq(rb.hbmBack, hbmBackp, HBITMAP, "%p"); \ > + expect_eq(rb.wID, wIDp, int, "%d"); \ > + /* the values of cyChild, cyMaxChild and cyIntegral can't be read unless the band is RBBS_VARIABLEHEIGHT */ \ > + expect_eq(rb.cyChild, cyChildp, int, "%x"); \ > + expect_eq(rb.cyMaxChild, cyMaxChildp, int, "%x"); \ > + expect_eq(rb.cyIntegral, cyIntegralp, int, "%x"); \ > + expect_eq(rb.cxIdeal, cxIdealp, int, "%d"); \ > + expect_eq(rb.lParam, (LPARAM)lParamp, LPARAM, "%ld"); \ > + ok( rb.cxHeader == cxHeaderp || broken(rb.cxHeader == cxHeader_brokenp), \ > + "expected %d for %d\n", cxHeaderp, rb.cxHeader ); \ Please don't define huge macros like that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/4] mshtml: Don't free string that will be cleared by SafeArrayDestroy.
by Michael Stefaniuc Nov. 8, 2010

Nov. 8, 2010

Hello Jacek, Jacek Caban wrote: > --- > dlls/mshtml/tests/dom.c | 1 - > 1 files changed, 0 insertions(+), 1 deletions(-) in that case "str" becomes unused and can be removed like in the attached patch. bye michael

2 1

Re: [PATCH 4/4] mshtml: Moved tid declaration to separated file.
by Alexandre Julliard Nov. 8, 2010

Nov. 8, 2010

Jacek Caban <jacek(a)codeweavers.com> writes: > Doing define/include tricks isn't perfect solution, but the current > state is even worse. > --- > dlls/mshtml/dispex.c | 93 ++--------------------------------------- > dlls/mshtml/mshtml_private.h | 94 ++--------------------------------------- > dlls/mshtml/tid.inc | 88 +++++++++++++++++++++++++++++++++++++++ > 3 files changed, 98 insertions(+), 177 deletions(-) > create mode 100644 dlls/mshtml/tid.inc Please don't create a separate file, particularly not with a non-standard extension. You can do this with a macro in mshtml_private.h. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 1/8] d3dcompiler: Add ID3D11ShaderReflectionType stub interface.
by Henri Verbeet Nov. 8, 2010

Nov. 8, 2010

2010/11/7 Rico Schüller <kgbricola(a)web.de>: > --- > dlls/d3dcompiler_43/d3dcompiler_private.h | 7 ++ > dlls/d3dcompiler_43/reflection.c | 106 > +++++++++++++++++++++++++++++ > 2 files changed, 113 insertions(+), 0 deletions(-) > You're adding dead code. Also, I expect there to be no reason to for the vtbl and implementation structure to be visible outside of reflection.c.

1 0

Re: [PATCH 4/8] d3dcompiler: Add initial reflection parsing.
by Henri Verbeet Nov. 8, 2010

Nov. 8, 2010

2010/11/7 Rico Schüller <kgbricola(a)web.de>: > + hr = d3dcompiler_parse_reflection(data, data_size, riid, object); > + if (FAILED(hr)) > + { > + WARN("Failed to parse shader reflection\n"); > + IUnknown_Release((IUnknown *)object); > + return hr; > + } You might as well create a function along the lines of d3dc_shader_reflection_init(), call that here, and keep the vtbl and d3dcompiler_parse_reflection() internal to reflect.c. > +static void d3dcompiler_parse_unknown(const char *data, DWORD data_size) > +{ > + const char *ptr = data; > + > + skip_dword_unknown(&ptr, data_size >> 2); > + > + return; > +} I don't think this is very useful in general, it's just going to create a lot of console spam.

1 0

Re: [PATCH 3/5] ddraw: Setup the device window in SetCooperativeLevel().
by Marvin Nov. 8, 2010

Nov. 8, 2010

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

1 0

Re: [PATCH] wined3d: correctly guess_card_vendor() for gallium r600 drivers
by Austin English Nov. 8, 2010

Nov. 8, 2010

On Sun, Nov 7, 2010 at 2:08 PM, Brian Paterni <bpaterni(a)gmail.com> wrote: > Hello, I've been receiving a couple "unrecognized GL_VENDOR" fixme's lately and > decided to poke around wine's source. I've found that wined3d_guess_card_vendor > does not return the correct enum for people running mesa's r600g driver, and now > that r600g returns "AMD <gpu chip>" as part of openGL's renderer string, we can > easily use that to check for AMD (ATI) hardware: > > --- > dlls/wined3d/directx.c | 5 ++--- > 1 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index 32d2431..3908c5f 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -1373,11 +1373,10 @@ static enum wined3d_pci_vendor wined3d_guess_card_vendor(const char *gl_vendor_s > if (strstr(gl_vendor_string, "ATI") > || strstr(gl_vendor_string, "Advanced Micro Devices, Inc.") > || strstr(gl_vendor_string, "X.Org R300 Project") > + || (strstr(gl_vendor_string, "X.Org") && strstr(gl_renderer, "AMD")) > || strstr(gl_renderer, "R100") > || strstr(gl_renderer, "R200") > - || strstr(gl_renderer, "R300") > - || strstr(gl_renderer, "R600") > - || strstr(gl_renderer, "R700")) > + || strstr(gl_renderer, "R300")) > return HW_VENDOR_ATI; > > if (strstr(gl_vendor_string, "Intel(R)") > -- > 1.7.2.3 Howdy Brian, You're mixing tabs and spaces. Please use consistent spacing, as the rest of the file does. -- -Austin

3 2

Where in the code does wine read fonts?
by Per Olesen Nov. 8, 2010

Nov. 8, 2010

Hi! I am trying to figure out how wine reads fonts on startup but am having a little trouble. I checked out the source and found a lot of good stuff in "winex11.drv/xfont.c", but I am not sure this is actually the code, that gets executed when my wine boots. What I experience, is that wine reads the X fonts, using the fontconfig library. Is that correct? Maybe I should say *why* I am digging into the font handling in the code. When I rebuild the system fontcache (using "fc-cache"), wine suddenly gets painfully slow to boot. When I revert to the old cache I had before rebuild, it gets fast again. Listing the cache content (using "fc-list") yields the same amount of fonts before and after rebuild, so I find it strange with the extra boot time. Actually, it would be better for me to NOT have wine read the X fonts (I think). So, I tried digging in to understand it better from the code. Is there a central place in the source code I am missing, that could lead me to the lightsource :-) Regards, Per

2 1

Re: [PATCH] comctl32/tests: Change expect_band_content test into a macro to ensure line numbers are reported correctly on test failure.
by Nikolay Sivov Nov. 8, 2010

Nov. 8, 2010

On 11/8/2010 13:29, Austin Lund wrote: > --- > dlls/comctl32/tests/rebar.c | 69 ++++++++++++++++++++---------------------- > 1 files changed, 33 insertions(+), 36 deletions(-) It's better to use ok_() for that, and a one line macro to pass a line number.

1 0

Re: shell32/tests: Fix IShellFolderView test failure under Windows 7.
by Vitaliy Margolen Nov. 8, 2010

Nov. 8, 2010

On 11/07/2010 04:06 PM, David Hedberg wrote: > - ok(hr == S_OK, "got (0x%08x)\n", hr); > + ok(hr == S_OK || hr == E_FAIL /* Win7 */, "got (0x%08x)\n", hr); This can't be correct. It either works or it fails. Can't be both at the same time. You should look into why it's failing on Win7 and correct the test so it succeeds. Vitaliy

5 5