wine-devel February 2008

wine-devel@winehq.org

141 participants
325 discussions

Re: d3dx9_36: Implementation of D3DXCheckVersion try 2
by tony.wasserka＠freenet.de 05 Feb '08

05 Feb '08

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 05 Feb '08

05 Feb '08

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 05 Feb '08

05 Feb '08

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

[Fwd: d3dx8: Implement D3DXCreateTextureFromFile]
by "Luis C. Busquets Pérez" 04 Feb '08

04 Feb '08

I have created a /dlls/d3dx8/texture.c file where to put all functions related to textures and d3dx8. I have included D3DXIMAGE_FILEFORMAT in the patch because it is referred by D3DXIMAGE_FILEFORMAT which is referred in the function. If not included, it would not compile. They both are now in /include/d3dx8.h whci I think is the appropiate file. Do you propose to put them elsewhere? Do you think I am missing anything or is it ok?

2 2

re: running "make test" results in an error
by Dan Kegel 04 Feb '08

04 Feb '08

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 04 Feb '08

04 Feb '08

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 04 Feb '08

04 Feb '08

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 04 Feb '08

04 Feb '08

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 03 Feb '08

03 Feb '08

>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 02 Feb '08

02 Feb '08

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

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 February 2008