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

Re: added wgl_bind_to_texture_depth_nv to ConvertAttribWGLtoGLX
by Roderick Colenbrander Feb. 5, 2008

Feb. 5, 2008

> This patch doesn't implement the format, simply says that is can't be > converted. This is my first patch, sorry if the format is wrong. Ok not converting the format is fine but you are also changing the return value of wglMakeCurrent. Resubmit the patch without that unneeded change. Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

1 0

Re: Bug in patch winex11.drv: Don't create a win_data structure for the desktop window, except in the process that owns it.
by Alexandre Julliard Feb. 5, 2008

Feb. 5, 2008

"Luis C. Busquets Pérez" <luis.busquets(a)ilidium.com> writes: > It affects to Patrician3.exe. When initiating, it hangs and does not > allow to play the movie. Actually, the programm changes the screen > resolution and hangs. I understand that the problem is that it does not > send the appropiate message for binkplayer.exe to play the movie. What message is that, and why doesn't it send it? -- Alexandre Julliard julliard(a)winehq.org

1 0

OUTB() and friends on Win32 and .sys files
by Uwe Bonnes Feb. 5, 2008

Feb. 5, 2008

Hallo, some programm with source uses giveio.sys to access the parallel port. You can find the source for giveio.sys e.g. in the avrdude package. We have code in dlls/winedos/ppdev.c to emulate the directed access on the parallel port to accesses to /dev/ppdev. However this code is not called for WIN32 code. So after starting giveio with loaddrv.exe supplied with giveio > wine loaddrv.exe start giveio starting giveio... ok. > wine javr.exe crashes when the outb access happens: javr [<filename>] [-p<port>] [-f<fusefilename>] [-e<eepromfilename>] [-L] [-V] Allocated flash buffer of 128K Using giveio.sys to gain port access to 0x378 trace:seh:raise_exception code=c0000096 flags=0 addr=0x4014b6 trace:seh:raise_exception eax=00000000 ebx=00000000 ecx=00000378 edx=00000378 esi=00000378 edi=00110388 trace:seh:raise_exception ebp=0072fe50 esp=0072fe50 cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00010246 trace:seh:call_stack_handlers calling handler at 0x7eddc5bc code=c0000096 flags=0 trace:seh:MSVCRT_signal (4, (nil)) wine: Unhandled privileged instruction at address 0x4014b6 (thread 0011), starting debugger... trace:seh:start_debugger Starting debugger "winedbg --auto 16 56" trace:seh:call_stack_handlers handler at 0x7eddc5bc returned 1 Unhandled exception: privileged instruction in 32-bit code (0x004014b6). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:004014b6 ESP:0072fe50 EBP:0072fe50 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:00000000 ECX:00000378 EDX:00000378 ESI:00000378 EDI:00110388 Stack dump: 0x0072fe50: 0072fe58 0040151a 0072fe88 00406ccf 0x0072fe60: 00000378 00000000 00000000 00403411 0x0072fe70: 00000001 00110388 0072fe88 0040a3ef 0x0072fe80: 0040a3ef 00000001 0072fec8 004025e4 0x0072fe90: 00000378 00000378 00110048 0040255c 0x0072fea0: 7ed5ff48 7ffdf000 0072fec8 7ed30f5c Backtrace: =>1 0x004014b6 outb+0x6(value=0x0, port=0x378) [/spare/bon/jtagprog/win/javr-2.8/ppiwin.c:311] in javr (0x0072fe50) MS msvcrt.dll also supplies outb(). What is the policy to handle outb() and friends? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Call for winetest ing
by Jeremy White Feb. 5, 2008

Feb. 5, 2008

Okay, so I got winetest to do something rational, and now I'd like to see if it will work for someone else. It's easy! Just apply this patch to a current Wine tree: http://www.winehq.org/pipermail/wine-patches/2008-February/049675.html Then configure and make Wine as you normally would. Then, cd programs/winetest ./runtests <your-tag-here> (The tag I used was jwhite-etch64; I think you should identify who you are, and then if you have multiple systems, your system within that). If you have winetricks in your path, it should be completely unattended. (If you don't, you'll need to hang around to click 'go' to the Gecko install dialog). After about 5 minutes, your test results should be run and sent up to test.winehq.org. The cron job runs every 5 minutes, so sometime after that, a reload of: firefox http://test.winehq.org/data/`date +%Y%m%d`/ Should show you your results! Easy as Pi! There is still quite a bit to do. First, I'm waiting for a 'real' winetest expert to wack me with a clue bat. But I'll stumble along until the hammer falls... Second, I want to do a stupidity check and make sure that winetest essentially correlates to a make -k test run. If they are not really identical, then we need to fix that problem... Next, I think we should probably shift the build-id from being the date to being the HEAD sha1, but that's a radical enough change that I felt I needed to start simpler and within the current conventions. But I'd really appreciate it if folks could try this and see if we can gather some data quickly. In theory, we should be able to quickly see the common points of failure and know where to attack first. Cheers, Jeremy

5 7

Blocked conformance tests
by Francois Gouget Feb. 5, 2008

Feb. 5, 2008

When I run winetest on Windows XP I get some dialog boxes asking me: Do you want to keep blocking this program? According to the title bar, the impacted tests are: dplayx rpcrt4 'Microsoft DirectPlay Helper' ??? ws2_32 My understanding is that it should only prevent the test from receiving network connections which I guess is not common. Does anyone know if this could cause any test failure currently? How does XP determine whether to block the test or not? Is the 'authorisation' based on the executable hash? If so there's no way to pre-authorise the tests for nightly tests. Should the winetest mark the executable so it is not hampered by this check? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

2 1

Re: kernel32: Implement ReplaceFileW. [RESEND]
by Alexandre Julliard Feb. 5, 2008

Feb. 5, 2008

Robert Shearman <rob(a)codeweavers.com> writes: > + /* > + * Open the replacement file for reading, writing, and deleting > + * (writing and deleting are needed when finished) > + */ > + if ((hReplacement = CreateFileW(lpReplacementFileName, > + GENERIC_READ | GENERIC_WRITE, > + FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, > + NULL, OPEN_EXISTING, 0, 0)) == INVALID_HANDLE_VALUE) > + { > + error = GetLastError(); /* Use error returned by CreateFileW */ > + goto fail; > + } Files should be opened with NtOpenFile the same way MoveFile does, to avoid having to convert path names twice. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [10/20] WineD3D: Make Clear aware of the depth stencil sharing
by H. Verbeet Feb. 5, 2008

Feb. 5, 2008

On 05/02/2008, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Stefan already knows this, but just for what it's worth, I've got a more complete fix in my tree for depth stencil sharing. Unfortunately that patch causes a couple of regressions, so it needs more work.

2 2

Re: [7/20] WineD3D: De-Statify depth blit opengl resources
by H. Verbeet Feb. 5, 2008

Feb. 5, 2008

On 05/02/2008, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > I was aware of this issue, but technically these resources should be stored in the shader backend, not the device.

2 2

running "make test" results in an error
by Christopher Feb. 5, 2008

Feb. 5, 2008

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, and if so how do I run the rest of the tests? I attached a log showing which test fails. Christopher make[1]: Entering directory `/home/christopher/wine-git/tools' make[1]: `makedep' is up to date. make[1]: Leaving directory `/home/christopher/wine-git/tools' make[1]: Entering directory `/home/christopher/wine-git/dlls' make[2]: Entering directory `/home/christopher/wine-git/dlls/advapi32/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/advapi32/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/advpack/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/advpack/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/browseui/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/browseui/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/cabinet/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/cabinet/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/comcat/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/comcat/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/comctl32/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/comctl32/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/comdlg32/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/comdlg32/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/credui/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/credui/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/crypt32/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/crypt32/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/cryptnet/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/cryptnet/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/d3d8/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/d3d8/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/d3d9/tests' ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so device.c && touch device.ok fixme:win:EnumDisplayDevicesW ((null),0,0x34f8c0,0x00000000), stub! fixme:d3d:IWineD3DDeviceImpl_CreateAdditionalSwapChain The app requests more than one back buffer, this can't be supported properly. Please configure the application to use double buffering(=1 back buffer) if possible err:xrandr:X11DRV_XRandR_SetCurrentMode Resolution change not successful -- perhaps display has changed? device.c:753: Test failed: Screen width is 1680 device.c:754: Test failed: Screen height is 1050 err:xrandr:X11DRV_XRandR_SetCurrentMode Resolution change not successful -- perhaps display has changed? device.c:798: Test failed: Screen width is 1680 device.c:799: Test failed: Screen height is 1050 err:d3d:IWineD3DDeviceImpl_DrawIndexedPrimitive (0x144548) : Called without a valid index buffer set, returning WINED3DERR_INVALIDCALL fixme:d3d:SetupForBlit >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glOrtho @ context.c / 622 fixme:d3d_surface:flush_to_framebuffer_drawpixels >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glDrawPixels @ surface.c / 1061 fixme:d3d:transform_projection >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glOrtho @ state.c / 2802 fixme:d3d_surface:flush_to_framebuffer_drawpixels >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glDrawPixels @ surface.c / 1061 fixme:d3d:IWineD3DDeviceImpl_SetLightEnable Too many concurrently active lights make[2]: *** [device.ok] Error 4 make[2]: Leaving directory `/home/christopher/wine-git/dlls/d3d9/tests' make[1]: *** [d3d9/tests/__test__] Error 2 make[1]: Leaving directory `/home/christopher/wine-git/dlls' make: *** [dlls/__test__] Error 2

4 3

Re: kernel32: Add tests for LoadLibraryEx
by Alexandre Julliard Feb. 5, 2008

Feb. 5, 2008

"James Hawkins" <truiken(a)gmail.com> writes: > I'm not sure how you feel this should be fixed. Is there a reason we > don't have tests for ntdll/loader.c? If not, I'd like add some tests > for LdrLoadDll. We don't have tests for it because apps don't use LdrLoadDll, so testing LoadLibraryEx should be enough. Of course if you have an app that depends on a specific behavior of LdrLoadDll then this should be tested. The todo in your test is because builtin dlls are supposed to get loaded even if the corresponding native file doesn't exist, that's a feature. -- Alexandre Julliard julliard(a)winehq.org

1 0

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

Re: cabinet: Include wine/port.h for strcasecmp().
by Dmitry Timoshkov Feb. 1, 2008

Feb. 1, 2008

"Bang Jun-young" <junyoung(a)mogua.com> wrote: >> > cabinet: Include wine/port.h for strcasecmp(). >> >> If a Wine DLL uses strcasecmp() then it's a bug. It should >> use an appropriate kernel32 API instead. > > I know, but it's too late. The tree is already contaminated with such > functions and quite a number of other unnecessary Wine-specific APIs > which shouldn't have been in the first place. It doesn't mean that instead of replacing them you can simply make an impression that it's OK to just hide the bug. -- Dmitry.

3 2

What's needed to make gdb work again?
by Maarten Lankhorst Feb. 1, 2008

Feb. 1, 2008

Hi folks, I've been trying some debugging with kdbg (Graphical kde debugger), but it fails on wine because it can't attach to a process. While it is of course possible to use WINEDEBUG flags, I want to be able to use a full debugger, and not just deduce from logs what happened, but rather be able to see the corresponding lines of source as well. so would it be possible to make gdb work with winedbg again, and perhaps make it understand threads this time? Cheers, Maarten.

2 1

test.winehq.org
by Stefan Leichter Feb. 1, 2008

Feb. 1, 2008

Hello, i just noticed that the test results for advapi32:service tests are not available for the last build (http://test.winehq.org/data/200801301937/) It looks like the parser did not create the files. Can someone familar with this stuff have a look? Thanks Stefan

4 4

Review comparing Wine and Vista for running games
by Dan Kegel Feb. 1, 2008

Feb. 1, 2008

http://wastingtimewithmikeandari.wordpress.com/2008/01/31/linux-has-better-… It'd be nice if we ran those games properly, but still, at least we didn't lock the system.

3 2

Re: cabinet: Include wine/port.h for strcasecmp().
by Dmitry Timoshkov Feb. 1, 2008

Feb. 1, 2008

"Bang Jun-young" <junyoung(a)mogua.com> wrote > cabinet: Include wine/port.h for strcasecmp(). If a Wine DLL uses strcasecmp() then it's a bug. It should use an appropriate kernel32 API instead. -- Dmitry.

1 0