wine-devel

wine-devel@winehq.org

3 participants
84481 discussions

Compilation errors
by Shachar Shemesh 13 Oct '02

13 Oct '02

make[2]: Entering directory `/home/sun/sources/wine/wine/dlls/d3d8' ../../tools/makedep -I. -I. -I../../include -I../../include -I/usr/X11R6/include -C. basetexture.c cubetexture.c d3d8_main.c device.c directx.c indexbuffer.c resource.c surface.c swapchain.c texture.c vertexbuffer.c volume.c volumetexture.c math.h: No such file or directory math.h was first included from device.c:26 make[2]: *** [depend] Error 1 make[2]: Leaving directory `/home/sun/sources/wine/wine/dlls/d3d8' make[1]: *** [d3d8/__depend__] Error 2 make[1]: Leaving directory `/home/sun/sources/wine/wine/dlls' make: *** [dlls/__depend__] Error 2 The strange thing is that /usr/include/math.h exists, and seems ok. Then again, it does not appear to be in the include path provided for the command. Explanations? Shachar

5 5

Changes in Bitmap behaviour
by Uwe Bonnes 13 Oct '02

13 Oct '02

Hallo, Xilinx webpack 4.2 running with native Common Controls shows an artefact in the display of bitmaps associated with the listview widget. This behaviour changed with http://cvs.winehq.com/patch.py?id=5720 by Michael Stefaniuc <mstefani(a)redhat.de>, but still is not right. Appended I have jpegs of the error. The first file (comctl32-builtin.jpeg) shows the behaviour with builtin commctl32, which looks good. The second file (comctl32-native-prepatch.jpeg) shows the behaviour with todays cvs, Michael's patch reversed and native comctl32/commctrl (NT4). We get a discontinous black background of the bitmap The last file (comctl32-native-prepatch.jpeg) is with native comctl32/commctrl (NT4) and todays unmodified cvs version. No we have a all black background. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

4 9

OpenGL textures are wrong under HalfLife
by David D. Hagood 13 Oct '02

13 Oct '02

My old motherboard died, and so I upgraded from a single P3 to a dual P3 system. I went to run HalfLife, which had been running beautifully under Wine, and now all the wall textures are screwed up. There is nothing of the proper textures in them - it's not like the colors are screwed up, more like the actual data is screwed up. However, it IS consistent from run to run - the same patterns on the same vertexes each time. The various "humans" in the level are fine - it is just the environment that is screwed. This is running the OpenGL setting in HL - I thought I'd try the DirectX setting, but all I get there is "This is not supported by your card". Now, I have upgraded XFree to the latest CVS pull, I rebuilt my kernel, and upgraded Wine, so it COULD be any of the above. However, I pulled an older version of Wine from another machine with the same results. Native GL programs like Q3A, RTCW, and UT all look fine, so the native GL layer is running well. Could this be an artifact of SMP? Or is there something that Wine does differently in accessing the GL libraries from a native app that would explain this?

1 0

Re: wine/dlls/avifil32: implemented many functions
by Dmitry Timoshkov 13 Oct '02

13 Oct '02

"Michael GЭnnewig" <MichaelGuennewig(a)gmx.de> wrote: > + LPWSTR szExt = strrchrW(szFile, L'.'); > +#define SLASH(w) ((w) == L'/' || (w) == L'\\') As were discussed many times using L prefix in order to create unicode chars/strings is wrong due to difference in size of unicode characters between windows and unix (2 vs. 4). We forced to create unicode strings explicitly: static const WCHAR fooW[] = { 'f','o','o',0 }; static const WCHAR dotW[] = { '.',0 }; static const WCHAR slashW[] = { '/',0 }; static const WCHAR bkslashW[] = { '\\',0 }; That's somewhat ugly and awkward, but it's really needed for portability. -- Dmitry.

4 5

help! latest cvs build of wine crashes every time
by Graham Stoney 13 Oct '02

13 Oct '02

Hi winers, I've built the latest cvs version of wine on my Debian stable system, and it crashes every time I run it. Here's an example: greyham@fred:/tmp$ wine notepad wine: Unhandled exception, starting debugger... wine: Unhandled exception, starting debugger... wine: Unhandled exception, starting debugger... (messages continue indefinitely; the debugger never gets started) It appears to be dying in X11DRV_CreateDC at the call to wine_tsx11_lock; but I suspect this is due to a stack frame corruption. Here's a gdb backtrace at the point of failure: 121 wine_tsx11_lock(); (gdb) where #0 X11DRV_CreateDC (dc=0x40393e48, pdev=0x40393e5c, driver=0x406c2c20 "DISPLAY", device=0x0, output=0x0, initData=0x0) at ../../graphics/x11drv/init.c:121 #1 0x40a72ff9 in CreateDCA (driver=0x409e19a0 "DISPLAY", device=0x0, output=0x0, initData=0x0) at ../../objects/dc.c:586 #2 0x409a622b in SYSMETRICS_Init () at ../../windows/sysmetrics.c:119 #3 0x409cf5aa in process_attach () at user_main.c:229 #4 0x409cf725 in UserClientDllInitialize (inst=1083441152, reason=1, reserved=0x1) at user_main.c:327 #5 0x40088e9f in PE_InitDLL (module=1083441152, type=1, lpReserved=0x1) at ../../loader/pe_image.c:628 #6 0x40085a6b in MODULE_InitDLL (wm=0x403718e8, type=1, lpReserved=0x1) at ../../loader/module.c:157 #7 0x40085b89 in MODULE_DllProcessAttach (wm=0x403718e8, lpReserved=0x1) at ../../loader/module.c:228 #8 0x40085b65 in MODULE_DllProcessAttach (wm=0x40371518, lpReserved=0x1) at ../../loader/module.c:223 #9 0x40085b65 in MODULE_DllProcessAttach (wm=0x40371288, lpReserved=0x1) at ../../loader/module.c:223 #10 0x40085b65 in MODULE_DllProcessAttach (wm=0x40370ff8, lpReserved=0x1) at ../../loader/module.c:223 #11 0x40085b65 in MODULE_DllProcessAttach (wm=0x0, lpReserved=0x1) at ../../loader/module.c:223 #12 0x400bd088 in start_process () at ../../scheduler/process.c:540 #13 0x400c128d in call_on_thread_stack (func=0x400bcef4) at ../../scheduler/sysdeps.c:112 (gdb) s Program received signal SIGSEGV, Segmentation fault. 0x53e58955 in ?? () Other apps fair as badly; always crashing on startup. I'm running XF86 version 4.2; there must be something about my system that is triggering the failure; otherwise you guys would be hitting it all the time. Any hints where I should start looking? Thanks, Graham

3 4

Re: Listview N5
by Dimitrie O. Paun 13 Oct '02

13 Oct '02

If you haven't checked in N5, please ignore it. I'll resubmit it when I move all of the custom draw around. -- Dimi.

2 2

Re: 16 shell seperation
by Michael Stefaniuc 12 Oct '02

12 Oct '02

You forgot to do the right HKEY <--> HKEY16 conversions with HKEY_16() and HKEY_32(), examples how to do it should be in the code. bye michael On Sat, Oct 12, 2002 at 05:20:31PM -0000, György 'Nog' Jeney wrote: > Is it possible to move all of the resources in the shell32 directory to a > sub directory inside shell32 like resources (just like gdi)? Its quite > confusing the way it is now. > > Changelog: > * dlls/shell32/shell32_main.h > * dlls/shell32/shell.c > * dlls/shell32/shellreg.c > * dlls/shell32/Makefile.in > * dlls/shell32/shlexec.c > Seperate out 16-bit funvtions into seperate file. > > nog. > > Index: dlls/shell32/shell.c > =================================================================== > RCS file: /home/wine/wine/dlls/shell32/shell.c,v > retrieving revision 1.46 > diff -u -r1.46 shell.c > --- dlls/shell32/shell.c 10 Oct 2002 21:22:11 -0000 1.46 > +++ dlls/shell32/shell.c 12 Oct 2002 17:07:39 -0000 > @@ -2,6 +2,7 @@ > * Shell Library Functions > * > * Copyright 1998 Marcus Meissner > + * Copyright 2000 Juergen Schmied > * Copyright 2002 Eric Pouech > * > * This library is free software; you can redistribute it and/or > @@ -526,4 +527,115 @@ > break; > } > return ret; > +} > + > + > +/* 0 and 1 are valid rootkeys in win16 shell.dll and are used by > + * some programs. Do not remove those cases. -MM > + */ > +static inline void fix_win16_hkey( HKEY *hkey ) > +{ > + if (*hkey == 0 || *hkey == (HKEY)1) *hkey = HKEY_CLASSES_ROOT; > +} > + > +/****************************************************************************** > + * RegOpenKey [SHELL.1] > + */ > +DWORD WINAPI RegOpenKey16( HKEY hkey, LPCSTR name, PHKEY retkey ) > +{ > + fix_win16_hkey( &hkey ); > + return RegOpenKeyA( hkey, name, retkey ); > +} > + > +/****************************************************************************** > + * RegCreateKey [SHELL.2] > + */ > +DWORD WINAPI RegCreateKey16( HKEY hkey, LPCSTR name, PHKEY retkey ) > +{ > + fix_win16_hkey( &hkey ); > + return RegCreateKeyA( hkey, name, retkey ); > +} > + > +/****************************************************************************** > + * RegCloseKey [SHELL.3] > + */ > +DWORD WINAPI RegCloseKey16( HKEY hkey ) > +{ > + fix_win16_hkey( &hkey ); > + return RegCloseKey( hkey ); > +} > + > +/****************************************************************************** > + * RegDeleteKey [SHELL.4] > + */ > +DWORD WINAPI RegDeleteKey16( HKEY hkey, LPCSTR name ) > +{ > + fix_win16_hkey( &hkey ); > + return RegDeleteKeyA( hkey, name ); > +} > + > +/****************************************************************************** > + * RegSetValue [SHELL.5] > + */ > +DWORD WINAPI RegSetValue16( HKEY hkey, LPCSTR name, DWORD type, LPCSTR data, DWORD count ) > +{ > + fix_win16_hkey( &hkey ); > + return RegSetValueA( hkey, name, type, data, count ); > +} > + > +/****************************************************************************** > + * RegQueryValue [SHELL.6] > + * > + * NOTES > + * Is this HACK still applicable? > + * > + * HACK > + * The 16bit RegQueryValue doesn't handle selectorblocks anyway, so we just > + * mask out the high 16 bit. This (not so much incidently) hopefully fixes > + * Aldus FH4) > + */ > +DWORD WINAPI RegQueryValue16( HKEY hkey, LPCSTR name, LPSTR data, LPDWORD count > +) > +{ > + fix_win16_hkey( &hkey ); > + if (count) *count &= 0xffff; > + return RegQueryValueA( hkey, name, data, count ); > +} > + > +/****************************************************************************** > + * RegEnumKey [SHELL.7] > + */ > +DWORD WINAPI RegEnumKey16( HKEY hkey, DWORD index, LPSTR name, DWORD name_len ) > +{ > + fix_win16_hkey( &hkey ); > + return RegEnumKeyA( hkey, index, name, name_len ); > +} > + > + > +/************************************************************************* > + * ShellExecute [SHELL.20] > + */ > +HINSTANCE16 WINAPI ShellExecute16( HWND16 hWnd, LPCSTR lpOperation, > + LPCSTR lpFile, LPCSTR lpParameters, > + LPCSTR lpDirectory, INT16 iShowCmd ) > +{ > + SHELLEXECUTEINFOA sei; > + HANDLE hProcess = 0; > + > + sei.cbSize = sizeof(sei); > + sei.fMask = 0; > + sei.hwnd = HWND_32(hWnd); > + sei.lpVerb = lpOperation; > + sei.lpFile = lpFile; > + sei.lpParameters = lpParameters; > + sei.lpDirectory = lpDirectory; > + sei.nShow = iShowCmd; > + sei.lpIDList = 0; > + sei.lpClass = 0; > + sei.hkeyClass = 0; > + sei.dwHotKey = 0; > + sei.hProcess = hProcess; > + > + ShellExecuteExA32 (&sei, FALSE); > + return (HINSTANCE16)sei.hInstApp; > } > Index: dlls/shell32/Makefile.in > =================================================================== > RCS file: /home/wine/wine/dlls/shell32/Makefile.in,v > retrieving revision 1.53 > diff -u -r1.53 Makefile.in > --- dlls/shell32/Makefile.in 27 Aug 2002 01:34:34 -0000 1.53 > +++ dlls/shell32/Makefile.in 12 Oct 2002 17:07:42 -0000 > @@ -27,7 +27,6 @@ > iconcache.c \ > memorystream.c \ > pidl.c \ > - shell.c \ > shell32_main.c \ > shelllink.c \ > shellole.c \ > @@ -50,6 +49,7 @@ > > RC_SRCS= shres.rc > RC_SRCS16 = version16.rc > +C_SRCS16 = shell.c > > SUBDIRS = tests > > Index: dlls/shell32/shell32_main.h > =================================================================== > RCS file: /home/wine/wine/dlls/shell32/shell32_main.h,v > retrieving revision 1.53 > diff -u -r1.53 shell32_main.h > --- dlls/shell32/shell32_main.h 10 Oct 2002 21:22:11 -0000 1.53 > +++ dlls/shell32/shell32_main.h 12 Oct 2002 17:07:48 -0000 > @@ -202,4 +202,7 @@ > #define HINSTANCE_32(h16) ((HINSTANCE)(ULONG_PTR)(h16)) > #define HWND_32(h16) ((HWND)(ULONG_PTR)(h16)) > > +/* needed by 16-bit shell code in shell.c */ > +BOOL WINAPI ShellExecuteExA32 (LPSHELLEXECUTEINFOA sei, BOOL is32); > + > #endif > Index: dlls/shell32/shellreg.c > =================================================================== > RCS file: /home/wine/wine/dlls/shell32/shellreg.c,v > retrieving revision 1.14 > diff -u -r1.14 shellreg.c > --- dlls/shell32/shellreg.c 3 Oct 2002 19:46:27 -0000 1.14 > +++ dlls/shell32/shellreg.c 12 Oct 2002 17:07:52 -0000 > @@ -147,86 +147,3 @@ > TRACE("0x%04x\n",hkey); > return RegCloseKey( hkey ); > } > - > - > -/* 16-bit functions */ > - > -/* 0 and 1 are valid rootkeys in win16 shell.dll and are used by > - * some programs. Do not remove those cases. -MM > - */ > -static inline void fix_win16_hkey( HKEY *hkey ) > -{ > - if (*hkey == 0 || *hkey == (HKEY)1) *hkey = HKEY_CLASSES_ROOT; > -} > - > -/****************************************************************************** > - * RegOpenKey [SHELL.1] > - */ > -DWORD WINAPI RegOpenKey16( HKEY hkey, LPCSTR name, PHKEY retkey ) > -{ > - fix_win16_hkey( &hkey ); > - return RegOpenKeyA( hkey, name, retkey ); > -} > - > -/****************************************************************************** > - * RegCreateKey [SHELL.2] > - */ > -DWORD WINAPI RegCreateKey16( HKEY hkey, LPCSTR name, PHKEY retkey ) > -{ > - fix_win16_hkey( &hkey ); > - return RegCreateKeyA( hkey, name, retkey ); > -} > - > -/****************************************************************************** > - * RegCloseKey [SHELL.3] > - */ > -DWORD WINAPI RegCloseKey16( HKEY hkey ) > -{ > - fix_win16_hkey( &hkey ); > - return RegCloseKey( hkey ); > -} > - > -/****************************************************************************** > - * RegDeleteKey [SHELL.4] > - */ > -DWORD WINAPI RegDeleteKey16( HKEY hkey, LPCSTR name ) > -{ > - fix_win16_hkey( &hkey ); > - return RegDeleteKeyA( hkey, name ); > -} > - > -/****************************************************************************** > - * RegSetValue [SHELL.5] > - */ > -DWORD WINAPI RegSetValue16( HKEY hkey, LPCSTR name, DWORD type, LPCSTR data, DWORD count ) > -{ > - fix_win16_hkey( &hkey ); > - return RegSetValueA( hkey, name, type, data, count ); > -} > - > -/****************************************************************************** > - * RegQueryValue [SHELL.6] > - * > - * NOTES > - * Is this HACK still applicable? > - * > - * HACK > - * The 16bit RegQueryValue doesn't handle selectorblocks anyway, so we just > - * mask out the high 16 bit. This (not so much incidently) hopefully fixes > - * Aldus FH4) > - */ > -DWORD WINAPI RegQueryValue16( HKEY hkey, LPCSTR name, LPSTR data, LPDWORD count ) > -{ > - fix_win16_hkey( &hkey ); > - if (count) *count &= 0xffff; > - return RegQueryValueA( hkey, name, data, count ); > -} > - > -/****************************************************************************** > - * RegEnumKey [SHELL.7] > - */ > -DWORD WINAPI RegEnumKey16( HKEY hkey, DWORD index, LPSTR name, DWORD name_len ) > -{ > - fix_win16_hkey( &hkey ); > - return RegEnumKeyA( hkey, index, name, name_len ); > -} > Index: dlls/shell32/shlexec.c > =================================================================== > RCS file: /home/wine/wine/dlls/shell32/shlexec.c,v > retrieving revision 1.8 > diff -u -r1.8 shlexec.c > --- dlls/shell32/shlexec.c 16 Sep 2002 19:27:51 -0000 1.8 > +++ dlls/shell32/shlexec.c 12 Oct 2002 17:07:59 -0000 > @@ -673,35 +673,6 @@ > return TRUE; > } > > - > -/************************************************************************* > - * ShellExecute [SHELL.20] > - */ > -HINSTANCE16 WINAPI ShellExecute16( HWND16 hWnd, LPCSTR lpOperation, > - LPCSTR lpFile, LPCSTR lpParameters, > - LPCSTR lpDirectory, INT16 iShowCmd ) > -{ > - SHELLEXECUTEINFOA sei; > - HANDLE hProcess = 0; > - > - sei.cbSize = sizeof(sei); > - sei.fMask = 0; > - sei.hwnd = HWND_32(hWnd); > - sei.lpVerb = lpOperation; > - sei.lpFile = lpFile; > - sei.lpParameters = lpParameters; > - sei.lpDirectory = lpDirectory; > - sei.nShow = iShowCmd; > - sei.lpIDList = 0; > - sei.lpClass = 0; > - sei.hkeyClass = 0; > - sei.dwHotKey = 0; > - sei.hProcess = hProcess; > - > - ShellExecuteExA32 (&sei, FALSE); > - return (HINSTANCE16)sei.hInstApp; > -} > - > /************************************************************************* > * ShellExecuteA [SHELL32.290] > */ > -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 1

Re: improve scanf
by György 'Nog' Jeney 12 Oct '02

12 Oct '02

Ooops, that patch has got an error in it, use this one instead. > ChangeLog: > * dlls/msvcrt/scanf.c > * dlls/msvcrt/scanf.h > Implement [ format specifier. > > nog.

1 0

Re: MZ_Exec() patch, try 2
by Jukka Heinonen 12 Oct '02

12 Oct '02

> This look more reasonable? Yep. Only a few bugs left. Because cmdline buffer belongs to the calling application you should not modify the buffer. Use of memcpy or something like that would be recommended. Also, use of variable "status" is a mystery to me. If CreateProcessA fails, it might not initialize handles and even if it does not fail, they might be null handles (I don't know if that matters, though). -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

configuring wine under mingw
by David Fraser 12 Oct '02

12 Oct '02

When running configure on wine under mingw, I had problems creating secure temporary directories... The configure code has two options for creating a secure temporary directory. If the first method fails the second is used. The difficulty with the first one is that mktemp returns a Windows-style path ("C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cscP2080") instead of a Unix-style one (/tmp/cscP2080) Since the backslashes are not escaped this then causes problems later when the temporary path is passed to sed as it cannot find C:DOCUME~1ADMINI~1LOCALS~1TempcscP2080/subs.sed This is actually because mingw/msys converts the unix-style path passed in to mktemp to a Windows-style one in the first place. Actually mingw does not have mktemp and the reason it was finding mktemp is that the cygwin directory was in my path. Removing the cygwin path fixes this problem, but then I don't have access to bison and yacc, so configure fails As an alternate solution, If I disallow the first of the two options on cygwin, then the tmp variable is set to /tmp/cs* and so it proceeds fine --- configure 10 Oct 2002 17:54:27 -0000 1.349 +++ configure 11 Oct 2002 13:55:36 -0000 @@ -14315,9 +14315,17 @@ } # Create a (secure) tmp directory for tmp files. +host_os=`echo $ac_cv_host | sed 's/^$[^-]*$-$[^-]*$-$.*$$/\3/'` +# disallow mktemp on mingw +case $MSYSTEM in + MINGW32*) + allowmktemp= ;; + *) + allowmktemp=yes ;; +esac : ${TMPDIR=/tmp} { - tmp=`(umask 077 && mktemp -d -q "$TMPDIR/csXXXXXX") 2>/dev/null` && + [ $allowmktemp ] && tmp=`(umask 077 && mktemp -d -q "$TMPDIR/csXXXXXX") 2>/dev/null` && test -n "$tmp" && test -d "$tmp" } || { I thought the logical thing to check was $host_os to see if we were running mingw. But when I tried it didn't seem to work :-) Not sure if this configure is autogenerated or if this patch is applicable, but thought others trying the same thing might find this helpful... David Fraser

3 2

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