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

comctl32 failures on Win95, Win98, NT4 asnd Win2K
by Reece Dunn Feb. 5, 2008

Feb. 5, 2008

These tests are all failing consistently with identical failures on these platforms: combobox - 21 failures; all identical across the platforms. datetime - 2 failures; all identical across the platforms. The rebar tests have 146 failures on some (Win95 and NT4) and 545 failures on others (Win98 and Win2K). This looks like it is due to a different comctl32 version as a result of a different IE version. Several of the others have failures on Win95 and Win98 only. Is anyone going to look at these? - Reece

3 2

Re: d3dx9_36: Implementation of D3DXCheckVersion try 2
by tony.wasserka＠freenet.de Feb. 5, 2008

Feb. 5, 2008

Oh well, I forgot one point: if you take my example code again, but don't build it under winelib but under windows (i.e. it's a real win application) but later run it with wine it may also fail because all dlls forward to the D3DXCheckVersion of d3dx9_36. I know that you would have implemented another D3DXCheckVersion for each dll, but this again would've ended in the case I mentioned in the first e-mail. Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i…

1 0

Re: d3dx9_36: Implementation of D3DXCheckVersion try 2
by tony.wasserka＠freenet.de Feb. 5, 2008

Feb. 5, 2008

I probably should've gone into a bit more detail about this function: It's just for developer purpose. If you have a very big project and are trying to upgrade e.g. from d3dx9_27 to d3dx9_36 some files may need to be rebuild, some files may not. This function is just there to ensure the developer that all files are built with the right dll. Now THIS means, that we won't ever see an ENDUSER application fail because of a d3dx9 version mismatch. Also, we come to a problem when a user wants to built an application with Winelib, where we can only use one definition of D3DX_SDK_VERSION which only applies to ONE dll. Now just watch following code sample: > #include "d3dx9.h" > > int check_version() { > if( D3DXCheckVersion( D3D_SDK_VERSION, D3DX_SDK_VERSION ) == FALSE ) { > MessageBox( NULL, "D3DX9 Versions don't match!", "Error!", MB_OK ); > exit( 1 ); > } > } Now, if a Winelib user compiles this, D3DX_SDK_VERSION is 9 (as its specified in our current d3dx9core.h). But if the program requires to be built with d3dx9_36 (and thus uses our implementation of D3DXCheckVersion) it will report an error as D3DX_SDK_VERSION was expected to be 36. So, the only thing we can test in this function is if D3DX_SDK_VERSION is between 24 and 36, which are all compatible versions (also, no enduser application will need the accurate implementation as stated above). I have made a mistake though, when I defined D3DX_SDK_VERSION to be 9, which was caused by my somewhat old installation of the DX SDK, which is incompatible with d3dx9_24 to d3dx9_36. (it was statically linked at that time), You don't need correct this in your patch, as this will be addressed in one of my future patches, I am just waiting for Julliard to (hopefully) accept my d3dx9_24 patch. In conclusion, all you have to do is replace the line > return ((D3DSdkVersion==D3D_SDK_VERSION) && (D3DXSdkVersion==D3DX_SDK_VERSION)); with > return ((D3DSdkVersion==D3D_SDK_VERSION) && (D3DXSdkVersion>=24 && D3DXSdkVersion <=36)); (Could also be => and =<, ain't that familiar with it) Best regards, Tony

1 0

winetest experience
by Jeremy White Feb. 5, 2008

Feb. 5, 2008

Okay, so I boldly tried to use winetest with what documentation I could find, and had an...um...interesting time. I created these files: [jertop] cat build.id fcccd9fca605d1d4c462df5c33f4bacf03bdda5f [jertop] cat build.nfo A Large Shovel [jertop] cat tests.url http://www.IDontKnowWhatURLToPutHere.com/ [jertop] did a make dist, and then did: ./winetest -c -t "jw-etch32" It ran, did it's thing, and had one interactive thing (Gecko fussed at me; that's not a Winetest bug afaik). Then when it was all done, it transferred my nearly 1 MB file, and then errored out with: "Unknown build id" So then I looked at the output file, and sure enough, it had a - for build info, not my fancy git id. So I hacked that, put in jwtip, and then ran winetest -s to send my output file through. And then I have a lovely result here: http://test.winehq.org/data/jwtip/ So that's *something* at least. Although I suspect someone will now have to go clean up my mess :-/. So...what's the convention for build.id etc? And why didn't they get set? Cheers, Jeremy

2 2

re: running "make test" results in an error
by Dan Kegel Feb. 4, 2008

Feb. 4, 2008

Christopher raccoonone at procyongames.com wrote: >I tried running "make test" under Ubuntu 7.10, and I just updated to the >latest cvs this morning so it's not too old. However, after only running >a couple of tests it exited with an error. Is this normal Sadly, yes. See http://bugs.winehq.org/show_bug.cgi?id=9916 Believe it or not, the situation was much worse five months ago. At the last Wineconf, Jeremy White got everybody to spend a whole day just fixing test failures. We could use something like that again. > and if so how do I run the rest of the tests? Elementary, my dear Watson. "make -k test". - Dan

2 1

winedbg pdb issue - n00b
by Michel Jacques Feb. 4, 2008

Feb. 4, 2008

Hi. I've have setup my debug build (with pdbs) and MSVCRT debug dlls. When stopping on a breakpoint with winedbg, I get a stack of calls in winedbg which does not contains any function info from my dlls or app. I only get hex offset of call within my dll. But I do see the information for wine sources though, function name + line number. What do I need to do so that winedbg can extract info from my pdb? Thanks, Michel Découvrez les styles qui font sensation sur Yahoo! Québec Avatars. http://cf.avatars.yahoo.com/

2 1

attempt to install Wine from source
by Mike Harrison Feb. 4, 2008

Feb. 4, 2008

Dear Sir; This below is the config.log I got from trying to install Wine (a source archive from a British Linux mag) on to my AMD64 m/c under Debian 4.0. 64 bit OS. A similar message was obtained from an attempt to install Wine on my AMD64 laptop under Ubuntu 7.04. (not 64 bit). From the report log I can't identify just what went wrong. My aim is to use Wine to run Windows XP applications on both machines, and if possible Windows Vista applic'ns on the laptop - both machines running 32 bit applic'ns. My first priority for this is MS Excel XP pro. From a brief visit to WineHQ today (the connection died for some unknown reason) I believe it may not be as straightforward a project as I had hoped. Please tell me either what I must do to load/install my Wine source package, or where I have to go for help to go a little further. I prefer to load the sources I already have, plus supplementary programs, if that's possible. Any advice you can give would be appreciated. Thanks; Mike Harrison This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by Wine configure 20050830, which was generated by GNU Autoconf 2.59. Invocation command line was $ ./configure -C --prefix=/usr/local ## --------- ## ## Platform. ## ## --------- ## hostname = ultima uname -m = x86_64 uname -r = 2.6.18-4-amd64 uname -s = Linux uname -v = #1 SMP Mon Mar 26 11:36:53 CEST 2007 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = x86_64 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/bin PATH: /usr/bin PATH: /bin PATH: /usr/bin/X11 PATH: /usr/games ## ----------- ## ## Core tests. ## ## ----------- ## configure:1249: creating cache config.cache configure:1424: checking build system type configure:1442: result: x86_64-unknown-linux-gnu configure:1450: checking host system type configure:1464: result: x86_64-unknown-linux-gnu configure:1504: checking whether make sets $(MAKE) configure:1524: result: yes configure:1579: checking for gcc configure:1605: result: gcc -m32 configure:1849: checking for C compiler version configure:1852: gcc -m32 --version </dev/null >&5 ./configure: line 1853: gcc: command not found configure:1855: $? = 127 configure:1857: gcc -m32 -v </dev/null >&5 ./configure: line 1858: gcc: command not found configure:1860: $? = 127 configure:1862: gcc -m32 -V </dev/null >&5 ./configure: line 1863: gcc: command not found configure:1865: $? = 127 configure:1888: checking for C compiler default output file name configure:1891: gcc -m32 conftest.c >&5 ./configure: line 1892: gcc: command not found configure:1894: $? = 127 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "Wine" | #define PACKAGE_TARNAME "wine" | #define PACKAGE_VERSION "20050830" | #define PACKAGE_STRING "Wine 20050830" | #define PACKAGE_BUGREPORT "wine-devel(a)winehq.org" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:1933: error: C compiler cannot create executables See `config.log' for more details. ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_build=x86_64-unknown-linux-gnu ac_cv_build_alias=x86_64-unknown-linux-gnu ac_cv_env_CC_set= ac_cv_env_CC_value= ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_CXXFLAGS_set= ac_cv_env_CXXFLAGS_value= ac_cv_env_CXX_set= ac_cv_env_CXX_value= ac_cv_env_LDFLAGS_set= ac_cv_env_LDFLAGS_value= ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_host=x86_64-unknown-linux-gnu ac_cv_host_alias=x86_64-unknown-linux-gnu ac_cv_prog_ac_ct_CC='gcc -m32' ac_cv_prog_make_make_set=yes ## ----------------- ## ## Output variables. ## ## ----------------- ## ALSALIBS='' AR='' ARTSCCONFIG='' ARTSINCL='' ARTSLIBS='' AS='as --32' AUDIOIOLIBS='' BISON='' BUILTINFLAG='' CC='gcc -m32' CFLAGS='' COREFOUNDATIONLIB='' CPP='' CPPBIN='' CPPFLAGS='' CROSSCC='' CROSSTEST='' CROSSWINDRES='' CRTLIBS='' CURSESLIBS='' CXX='' CXXFLAGS='' DEFS='' DLLDEFS='' DLLEXT='' DLLFLAGS='' DLLIBS='' DLLTOOL='' DLLWRAP='' ECHO_C='' ECHO_N='-n' ECHO_T='' EGREP='' ESDCONFIG='' ESDINCL='' ESDLIBS='' EXEEXT='' EXTRACFLAGS='' FONTFORGE='' FONTSSUBDIRS='' FREETYPEINCL='' FREETYPELIBS='' GLU32FILES='' GLUT32FILES='' GLUT_LIBS='' ICULIBS='' IMPLIBEXT='' INSTALL_DATA='' INSTALL_PROGRAM='' INSTALL_SCRIPT='' IOKITLIB='' LCMSLIBS='' LD='ld -m elf_i386' LDAPLIBS='' LDCONFIG='' LDD='' LDDLLFLAGS='' LDEXECFLAGS='' LDFLAGS='' LDLIBWINEFLAGS='' LDPATH='' LDSHARED='' LEX='' LEXLIB='' LEX_OUTPUT_ROOT='' LIBEXT='' LIBOBJS='' LIBPTHREAD='' LIBS='' LINT='' LINTFLAGS='' LN='' LN_S='' LTLIBOBJS='' MAIN_BINARY='' NASLIBS='' OBJEXT='' OPENGLFILES='' OPENGL_LIBS='' PACKAGE_BUGREPORT='wine-devel(a)winehq.org' PACKAGE_NAME='Wine' PACKAGE_STRING='Wine 20050830' PACKAGE_TARNAME='wine' PACKAGE_VERSION='20050830' PATH_SEPARATOR=':' PKG_CONFIG='' PRELINK='' RANLIB='' SANEINCL='' SANELIBS='' SET_MAKE='' SHELL='/bin/sh' SOCKETLIBS='' STRIP='' TOOLSDIR='' WIN16_FILES='$(WIN16_FILES)' WIN16_INSTALL='$(WIN16_INSTALL)' WINDRES='' WINE_BINARIES='' XFILES='' XLEX='' XLIB='' XML2INCL='' XML2LIBS='' X_CFLAGS='' X_EXTRA_LIBS='' X_LIBS='' X_PRE_LIBS='' ac_ct_AR='' ac_ct_AS='' ac_ct_CC='gcc -m32' ac_ct_CPPBIN='' ac_ct_CXX='' ac_ct_DLLTOOL='' ac_ct_DLLWRAP='' ac_ct_LD='' ac_ct_RANLIB='' ac_ct_STRIP='' ac_ct_WINDRES='' bindir='${exec_prefix}/bin' build='x86_64-unknown-linux-gnu' build_alias='' build_cpu='x86_64' build_os='linux-gnu' build_vendor='unknown' datadir='${prefix}/share' exec_prefix='NONE' ft_devel2='' ft_devel='' host='x86_64-unknown-linux-gnu' host_alias='' host_cpu='i386' host_os='linux-gnu' host_vendor='unknown' includedir='${prefix}/include' infodir='${prefix}/info' libdir='${exec_prefix}/lib' libexecdir='${exec_prefix}/libexec' localstatedir='${prefix}/var' mandir='${prefix}/man' oldincludedir='/usr/include' prefix='/usr/local' program_transform_name='s,x,x,' sane_devel='' sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' sysconfdir='${prefix}/etc' target_alias='' ## ------------- ## ## Output files. ## ## ------------- ## MAKE_DLL_RULES='' MAKE_IMPLIB_RULES='' MAKE_LIB_RULES='' MAKE_PROG_RULES='' MAKE_RULES='' MAKE_TEST_RULES='' ## ----------- ## ## confdefs.h. ## ## ----------- ## #define PACKAGE_BUGREPORT "wine-devel(a)winehq.org" #define PACKAGE_NAME "Wine" #define PACKAGE_STRING "Wine 20050830" #define PACKAGE_TARNAME "wine" #define PACKAGE_VERSION "20050830" configure: exit 77

4 3

winehq.org down?
by James Hawkins Feb. 4, 2008

Feb. 4, 2008

Hey guys, I'm having problems connecting to the winehq.org server. Is this a known issue? -- James Hawkins

6 6

cabinet: Include wine/port.h for strcasecmp().
by Kirill K. Smirnov Feb. 3, 2008

Feb. 3, 2008

>The rules are as follows: > * For case insensitive comparisons of 'windows strings', a Windows > function must be used (stricmp() or similar). and >In this case, KERNEL32 lstrcmpiA() would be more appropriate. In >general, using stricmp() in Win32 code should be discouraged since it >may cause unnecessary dependency on MSVCRT. Wine lstrcmpi is broken (bug #10767). There are cases GLIBC strcasecmp and Windows lstrcmpi handle correctly but wine not. Should we fix this first? -- Kirill

2 1

Re: winex11.drv: Use bitwise NOT not logical NOT
by Marcus Meissner Feb. 2, 2008

Feb. 2, 2008

On Sat, Feb 02, 2008 at 05:43:27PM +0000, Andrew Talbot wrote: > Changelog: > winex11.drv: Use bitwise NOT not logical NOT. > > diff --git a/dlls/winex11.drv/settings.c b/dlls/winex11.drv/settings.c > index d68b674..2cd36c7 100644 > --- a/dlls/winex11.drv/settings.c > +++ b/dlls/winex11.drv/settings.c > @@ -369,10 +369,10 @@ LONG X11DRV_ChangeDisplaySettingsEx( LPCWSTR devname, LPDEVMODEW devmode, > devmode->dmBitsPerPel,devmode->dmDisplayFrequency, handler_name); > > dwBpp = devmode->dmBitsPerPel; > - if (devmode->dmFields & DM_BITSPERPEL) def_mode &= !dwBpp; > - if (devmode->dmFields & DM_PELSWIDTH) def_mode &= !devmode->dmPelsWidth; > - if (devmode->dmFields & DM_PELSHEIGHT) def_mode &= !devmode->dmPelsHeight; > - if (devmode->dmFields & DM_DISPLAYFREQUENCY) def_mode &= !devmode->dmDisplayFrequency; > + if (devmode->dmFields & DM_BITSPERPEL) def_mode &= ~dwBpp; > + if (devmode->dmFields & DM_PELSWIDTH) def_mode &= ~devmode->dmPelsWidth; > + if (devmode->dmFields & DM_PELSHEIGHT) def_mode &= ~devmode->dmPelsHeight; > + if (devmode->dmFields & DM_DISPLAYFREQUENCY) def_mode &= ~devmode->dmDisplayFrequency; I do not think this is right, def_mode is a boolean and we actually check for not-0-being of various struct members. Ciao, Marcus

3 3