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

Re: [8/8] WineD3D: Use the source surface's texture for writing the backup

by H. Verbeet

On 28/02/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: >The hwstretch blit code creates a new texture each time it is called to back up the back buffer and >releases it afterwards. It is more efficient to keep the texture and release it with the surface. This >patch uses the source surface's texture to do the job. Because the source surface is an active render >target its texture is either only needed for blitting(onscreen target) or will be completely overwritten >on the next render target change(offscreen target). Is this supposed to work with FBOs?

Feb. 28, 2007

Unknown issue with test.winehq.org

by Paul Vriens

Hi, So finally we have a working winetest executable and the test.winehq.org scripts should be able to handle the new reports. Could someone have a look what the issue currently is on the webserver as I've sent several reports (a few hours ago) and they are not handled yet? Cheers, Paul.

Feb. 28, 2007

Re: [4/8] WineD3D: Prepare only fixed function samplers for blit

by H. Verbeet

On 28/02/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: >+ /* The blitting code uses (for now) the fixed function pipeline, so make sure to reset all fixed >+ * function texture unit. No need to care for higher samplers >+ */ >+ for(i = GL_LIMITS(texture_stages) - 1; i > 0 ; i--) { You should use GL_LIMITS(textures) here, since that's the number of fixed function texture units.

Feb. 28, 2007

Re: kernel32: Implement ReplaceFileA/ReplaceFileW

by Erich Hoover

Oops, I must have hit the wrong reply button. >>> The "right" way would probably to do the copying yourself by >>> read/write.. but I dunno. >> Except that it would ignore the permissions issues that have already >> been coded into the copy routines (and any updates that may eventually > No, CreateFile (and friends) does the permissions checks (which you > would still have to call). That was worded poorly, Copy/Move already handle copying file attributes and I imagine would eventually implement copying the access control list information. Implementing ReplaceFile as calls to either Copy or Move takes these issues into account. >> be made to these routines). Also, it seems to me that MSDN is >> describing the list of function calls that ReplaceFile actually makes. > No it doesn't? >From my perspective the "remarks" section discusses the implementation of ReplaceFile as calls to existing API functions (as a sort of macro) as a convenience. Granted, it discusses moving files instead of copying but that conflicted with the file locking. Should I make a new patch file with the previously attached changes or would you prefer that the function be implemented in the read/write manner? Re-implementing the function in such a fashion would make it possible to do a more move-like operation while maintaining the file locking, but would lose out on any future improvements to CopyFile. Erich Hoover ehoover(a)mines.edu On 2/28/07, Felix Nawothnig <flexo(a)holycrap.org> wrote: > > (CC-ing wine-devel again) > > Erich Hoover wrote: > >> The "right" way would probably to do the copying yourself by > >> read/write.. but I dunno. > > Except that it would ignore the permissions issues that have already > > been coded into the copy routines (and any updates that may eventually > > No, CreateFile (and friends) does the permissions checks (which you > would still have to call). > > > be made to these routines). Also, it seems to me that MSDN is > > describing the list of function calls that ReplaceFile actually makes. > > No it doesn't? > > Your other objections were right. Your last version follows for > wine-devel. > > > ------------------------------------------------------------------------ > > > > > /************************************************************************** > > * ReplaceFileW (KERNEL32.@) > > * ReplaceFile (KERNEL32.@) > > */ > > BOOL WINAPI ReplaceFileW(LPCWSTR lpReplacedFileName,LPCWSTR > lpReplacementFileName, > > LPCWSTR lpBackupFileName, DWORD dwReplaceFlags, > > LPVOID lpExclude, LPVOID lpReserved) > > { > > HANDLE hReplaced, hReplacement; > > BOOL skipBackup = FALSE; > > > > if(dwReplaceFlags) > > FIXME("Ignoring flags %x\n", dwReplaceFlags); > > /* First two arguments are mandatory */ > > if(!lpReplacedFileName || !lpReplacementFileName) > > { > > SetLastError( ERROR_INVALID_PARAMETER ); > > return FALSE; > > } > > /* > > * Lock the "replacement" file, fail if it does not exist > > */ > > if((hReplacement = CreateFileW(lpReplacementFileName, GENERIC_READ, > > FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, > > NULL, OPEN_EXISTING, 0, 0)) == INVALID_HANDLE_VALUE) > > { > > return FALSE; > > } > > if(!LockFile( hReplacement, 0, 0, 0, 0 )) > > { > > CloseHandle( hReplacement ); > > return FALSE; > > } > > /* > > * Lock the "replaced" file while we're working. > > */ > > if((hReplaced = CreateFileW(lpReplacedFileName, GENERIC_READ, > > FILE_SHARE_READ | FILE_SHARE_WRITE, > > NULL, OPEN_EXISTING, 0, 0)) == INVALID_HANDLE_VALUE) > > { > > /* If "replaced" does not exist then create it for the lock, but > skip backup */ > > if((hReplaced = CreateFileW(lpReplacedFileName, GENERIC_READ, > > FILE_SHARE_READ | FILE_SHARE_WRITE, > > NULL, CREATE_ALWAYS, 0, 0)) == INVALID_HANDLE_VALUE) > > { > > UnlockFile( hReplacement, 0, 0, 0, 0 ); > > CloseHandle( hReplacement ); > > return FALSE; > > } > > skipBackup = TRUE; > > } > > if(!LockFile( hReplaced, 0, 0, 0, 0 )) > > { > > UnlockFile( hReplacement, 0, 0, 0, 0 ); > > CloseHandle( hReplacement ); > > CloseHandle( hReplaced ); > > return FALSE; > > } > > /* > > * If the user wants a backup then that needs to be performed first > > */ > > if( lpBackupFileName && !skipBackup ) > > { > > /* If an existing backup exists then copy over it */ > > if(!CopyFileW( lpReplacedFileName, lpBackupFileName, FALSE )) > > goto replace_fail; > > } > > /* > > * Now that the backup has been performed (if requested), copy the > replacement > > * into place > > */ > > if(!CopyFileW( lpReplacementFileName, lpReplacedFileName, FALSE )) > > { > > /* Assume that all access denied errors are a write problem. */ > > if(GetLastError() == ERROR_ACCESS_DENIED) > > SetLastError( ERROR_UNABLE_TO_REMOVE_REPLACED ); > > else > > SetLastError( ERROR_UNABLE_TO_MOVE_REPLACEMENT ); > > goto replace_fail; > > } > > /* Delete the replacement file */ > > if(!DeleteFileW( lpReplacementFileName )) > > return FALSE; > > /* Unlock the handles */ > > UnlockFile( hReplacement, 0, 0, 0, 0 ); > > CloseHandle( hReplacement ); > > UnlockFile( hReplaced, 0, 0, 0, 0 ); > > CloseHandle( hReplaced ); > > /* All done, file replacement successful */ > > return TRUE; > > > > replace_fail: > > UnlockFile( hReplacement, 0, 0, 0, 0 ); > > CloseHandle( hReplacement ); > > UnlockFile( hReplaced, 0, 0, 0, 0 ); > > CloseHandle( hReplaced ); > > return FALSE; > > } > >

Feb. 28, 2007

Using ex-user32 controls from native comctl32 6

by Felix Nawothnig

(CC-ing to Frank Richter because I hope he knows the answer :) Hi. I've been trying to make wine use the ex-user32 controls (listbox, scrollbox, etc.) in comctl32 where Microsoft copied them to in version 6 to get message traces of those controls (I know I could use msg spy tools on Windows but comparing two Wine spy logs is way more straight forward, especially since those tools don't get you stuff like +win). You need a manifest file on Windows to get application to use comctl6 but we don't use that since we've chosen to theme the user controls via subclassing. I've tried to just remove registration of the classes from our user32 and use native comctl32 6 (which otherwise works nice) but no success. So, any idea how Windows makes comctl32 register the user classes? Felix

Feb. 28, 2007

Re: Using ex-user32 controls from native comctl32 6

by Frank Richter

On 28.02.2007 18:26, Felix Nawothnig wrote: > So, any idea how Windows makes comctl32 register the user classes? I think it just re-registered the classes, but I'm not sure. A trace with class registrations (ie +class) might give some hint at what native does. -f.r.

Feb. 28, 2007

Re: kernel32: Implement ReplaceFileA/ReplaceFileW

by Felix Nawothnig

(CC-ing wine-devel again) Erich Hoover wrote: >> The "right" way would probably to do the copying yourself by >> read/write.. but I dunno. > Except that it would ignore the permissions issues that have already > been coded into the copy routines (and any updates that may eventually No, CreateFile (and friends) does the permissions checks (which you would still have to call). > be made to these routines). Also, it seems to me that MSDN is > describing the list of function calls that ReplaceFile actually makes. No it doesn't? Your other objections were right. Your last version follows for wine-devel. > ------------------------------------------------------------------------ > > /************************************************************************** > * ReplaceFileW (KERNEL32.@) > * ReplaceFile (KERNEL32.@) > */ > BOOL WINAPI ReplaceFileW(LPCWSTR lpReplacedFileName,LPCWSTR lpReplacementFileName, > LPCWSTR lpBackupFileName, DWORD dwReplaceFlags, > LPVOID lpExclude, LPVOID lpReserved) > { > HANDLE hReplaced, hReplacement; > BOOL skipBackup = FALSE; > > if(dwReplaceFlags) > FIXME("Ignoring flags %x\n", dwReplaceFlags); > /* First two arguments are mandatory */ > if(!lpReplacedFileName || !lpReplacementFileName) > { > SetLastError( ERROR_INVALID_PARAMETER ); > return FALSE; > } > /* > * Lock the "replacement" file, fail if it does not exist > */ > if((hReplacement = CreateFileW(lpReplacementFileName, GENERIC_READ, > FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, > NULL, OPEN_EXISTING, 0, 0)) == INVALID_HANDLE_VALUE) > { > return FALSE; > } > if(!LockFile( hReplacement, 0, 0, 0, 0 )) > { > CloseHandle( hReplacement ); > return FALSE; > } > /* > * Lock the "replaced" file while we're working. > */ > if((hReplaced = CreateFileW(lpReplacedFileName, GENERIC_READ, > FILE_SHARE_READ | FILE_SHARE_WRITE, > NULL, OPEN_EXISTING, 0, 0)) == INVALID_HANDLE_VALUE) > { > /* If "replaced" does not exist then create it for the lock, but skip backup */ > if((hReplaced = CreateFileW(lpReplacedFileName, GENERIC_READ, > FILE_SHARE_READ | FILE_SHARE_WRITE, > NULL, CREATE_ALWAYS, 0, 0)) == INVALID_HANDLE_VALUE) > { > UnlockFile( hReplacement, 0, 0, 0, 0 ); > CloseHandle( hReplacement ); > return FALSE; > } > skipBackup = TRUE; > } > if(!LockFile( hReplaced, 0, 0, 0, 0 )) > { > UnlockFile( hReplacement, 0, 0, 0, 0 ); > CloseHandle( hReplacement ); > CloseHandle( hReplaced ); > return FALSE; > } > /* > * If the user wants a backup then that needs to be performed first > */ > if( lpBackupFileName && !skipBackup ) > { > /* If an existing backup exists then copy over it */ > if(!CopyFileW( lpReplacedFileName, lpBackupFileName, FALSE )) > goto replace_fail; > } > /* > * Now that the backup has been performed (if requested), copy the replacement > * into place > */ > if(!CopyFileW( lpReplacementFileName, lpReplacedFileName, FALSE )) > { > /* Assume that all access denied errors are a write problem. */ > if(GetLastError() == ERROR_ACCESS_DENIED) > SetLastError( ERROR_UNABLE_TO_REMOVE_REPLACED ); > else > SetLastError( ERROR_UNABLE_TO_MOVE_REPLACEMENT ); > goto replace_fail; > } > /* Delete the replacement file */ > if(!DeleteFileW( lpReplacementFileName )) > return FALSE; > /* Unlock the handles */ > UnlockFile( hReplacement, 0, 0, 0, 0 ); > CloseHandle( hReplacement ); > UnlockFile( hReplaced, 0, 0, 0, 0 ); > CloseHandle( hReplaced ); > /* All done, file replacement successful */ > return TRUE; > > replace_fail: > UnlockFile( hReplacement, 0, 0, 0, 0 ); > CloseHandle( hReplacement ); > UnlockFile( hReplaced, 0, 0, 0, 0 ); > CloseHandle( hReplaced ); > return FALSE; > }

Feb. 28, 2007

Error Invalid EXE Format when executing a exe.so built with winelib

by Roger Wimbert

Here is the Debug output: warn:module:load_builtin_dll failed to load .so lib for builtin L"Z:\\bb\\s\\bc\\wine\\dmsw.exe.so": /bb/home/.wine/dosdevices/z:/bb/s/bc/wine/dmsw.exe.so: cannot allocate memory in static TLS block warn:module:load_dll Failed to load module L"Z:\\bb\\s\\bc\\wine\\dmsw.exe.so"; status=c000007b warn:module:load_builtin_dll failed to load .so lib for builtin L"Z:\\bb\\s\\bc\\wine\\dmsw.exe.so": /bb/home/.wine/dosdevices/z:/bb/s/bc/wine/dmsw.exe.so: cannot allocate memory in static TLS block warn:module:load_dll Failed to load module L"Z:\\bb\\s\\bc\\wine\\dmsw.exe.so"; status=c000007b wine: could not load L"Z:\\bb\\s\\bc\\wine\\dmsw.exe.so": Fehlerhaftes EXE-Format f³r It has something to do with TLS memory or threads, but the /lib/tls/libc.so is linked in: (rw 8 amd64) /bb/s/bc/wine 105>ldd dmsw.exe.so linux-gate.so.1 => (0xffffe000) libwine.so.1 => /usr/local/lib/libwine.so.1 (0x557be000) libm.so.6 => /lib/tls/libm.so.6 (0x558e8000) libc.so.6 => /lib/tls/libc.so.6 (0x5590a000) libdl.so.2 => /lib/libdl.so.2 (0x55a1f000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x56555000) Our system: (rw 8 amd64) /bb/s/bc/wine 106>uname -a Linux amd64 2.6.5-7.193-smp #1 SMP Wed Jul 20 14:39:18 UTC 2005 x86_64 x86_64 x86_64 GNU/Linux glibc has version 2.3.3 A simple program does work, but no program which uses threads. wine is created with the 32 bit libraries. If I use the original exe of my program with wine, it does work. Does anyone has an idea what is going wrong? The makefile is attached. Thanks a lot. ### Generated by Winemaker TOPSRCDIR = /bb/s TOPOBJDIR = /bb/s/bc/wine SRCDIR = . SUBDIRS = DLLS = EXES = dmsw.exe ### Common settings CEXTRA = -mno-cygwin -fno-pic -fno-PIC CXXEXTRA = -mno-cygwin CFLAGS = -D_DMSW RCEXTRA = RCFLAGS = -DBB_WINE INCLUDE_PATH = -I. -I/bb/nt/wine -I/bb/s/i -I/bb/fg/i -I/bb/ze/i -I/bb/fe/i -I/bb/pbm/i -I/bb/wb1/i DLL_PATH = LIBRARY_PATH = LIBRARIES = -lmsvcrt40 -lws2_32 -lversion -lnetapi32 -liphlpapi -lcomctl32 -lshlwapi -lwinmm ### dmsw.exe sources and settings dmsw_exe_MODULE = dmsw.exe dmsw_exe_C_SRCS = /bb/s/c/bbcrypt.c \ /bb/s/c/bbdes.c \ /bb/s/c/bbmalloc.c \ /bb/s/c/bbmd5.c \ /bb/s/c/bbo.c \ /bb/s/c/bbtwofish.c \ /bb/s/c/cmp.c \ /bb/s/c/costri.c \ /bb/s/c/cpy.c \ /bb/s/c/datec.c \ /bb/s/c/dfa.c \ /bb/fg/c/dgcode.c \ /bb/fg/c/dgvar.c \ /bb/s/c/dhinfo.c \ /bb/s/c/dholz.c \ /bb/fg/c/digcte.c \ /bb/fg/c/digecm.c \ /bb/fg/c/digranox.c \ /bb/fg/c/digvec.c \ /bb/s/c/dirview.c \ /bb/s/c/dirwalk.c \ /bb/s/c/dmsb.c \ /bb/s/c/dmsc.c \ /bb/s/c/dmsca.c \ /bb/s/c/dmse.c \ /bb/s/c/dmsf.c \ /bb/s/c/dmsfr.c \ /bb/s/c/dmsg.c \ /bb/s/c/dmsh.c \ /bb/s/c/dmshc.c \ /bb/s/c/dmsl.c \ /bb/s/c/dmsliz.c \ /bb/s/c/dmsm.c \ /bb/s/c/dmsmv.c \ /bb/s/c/dmsp.c \ /bb/s/c/dmsr.c \ /bb/s/c/dmss.c \ /bb/s/c/dmssb.c \ /bb/s/c/dmst.c \ /bb/s/c/dmstast.c \ /bb/s/c/dmsw.c \ /bb/s/c/dmswf.c \ /bb/s/c/dmswicon.c \ /bb/s/c/dmsy.c \ /bb/s/c/encode.c \ /bb/s/c/fileleng.c \ /bb/s/c/fordat.c \ /bb/s/c/gtypes.c \ /bb/fg/c/image.c \ /bb/fg/c/imgprint.c \ /bb/s/c/itoa.c \ /bb/fg/c/jpegconv.c \ /bb/s/c/lru.c \ /bb/s/c/ltoa.c \ /bb/s/c/map.c \ /bb/s/c/msleep.c \ /bb/s/c/packbits.c \ /bb/s/c/packdiff.c \ /bb/s/c/pfad.c \ /bb/fg/c/rgbtools.c \ /bb/s/c/rtt.c \ /bb/s/c/scrinfo.c \ /bb/s/c/set.c \ /bb/s/c/sockcom.c \ /bb/s/c/softdum.c \ /bb/s/c/swap.c \ /bb/s/c/syslog.c \ /bb/s/c/textino.c \ /bb/fg/c/tiffconv.c \ /bb/s/c/udpcom.c \ /bb/s/c/utoa.c \ /bb/s/c/vgl.c \ /bb/s/c/w32argv.c \ /bb/fg/c/w32bmp.c \ /bb/s/c/w32error.c \ /bb/s/c/w32font.c \ /bb/fg/c/w32ico.c \ /bb/s/c/w32macadr.c \ /bb/s/c/w32pfad.c \ /bb/s/c/w32pipe.c \ /bb/s/c/w32print.c \ /bb/s/c/w32puts.c \ /bb/s/c/w32reg.c \ /bb/fg/c/w32scalebmp.c \ /bb/s/c/w32screen.c \ /bb/s/c/w32scroll.c \ /bb/s/c/w32toolbar.c \ /bb/s/c/w32tools.c \ /bb/s/c/w32winms.c \ /bb/s/c/wsinit.c \ /bb/s/c/zeitc.c dmsw_exe_CXX_SRCS= dmsw_exe_RC_SRCS = /bb/nt/rc/dmsw/dmsw_wine.rc dmsw_exe_LDFLAGS = -mwindows \ -mno-cygwin dmsw_exe_DLL_PATH= dmsw_exe_DLLS = odbc32 \ ole32 \ oleaut32 \ winspool dmsw_exe_LIBRARY_PATH= dmsw_exe_LIBRARIES= uuid dmsw_exe_OBJS = $(dmsw_exe_C_SRCS:.c=.o) \ $(dmsw_exe_CXX_SRCS:.cpp=.o) \ $(dmsw_exe_RC_SRCS:.rc=.res) ### Global source lists C_SRCS = $(dmsw_exe_C_SRCS) CXX_SRCS = $(dmsw_exe_CXX_SRCS) RC_SRCS = $(dmsw_exe_RC_SRCS) ### Tools CC = winegcc CXX = wineg++ RC = wrc ### Generic targets all: $(SUBDIRS) $(DLLS:%=%.so) $(EXES:%=%.so) ### Build rules .PHONY: all clean dummy $(SUBDIRS): dummy @cd $@ && $(MAKE) # Implicit rules .SUFFIXES: .cpp .rc .res DEFINCL = $(INCLUDE_PATH) $(DEFINES) $(OPTIONS) .c.o: $(CC) -c $(CFLAGS) $(CEXTRA) $(DEFINCL) -o $@ $< .cpp.o: $(CXX) -c $(CXXFLAGS) $(CXXEXTRA) $(DEFINCL) -o $@ $< .cxx.o: $(CXX) -c $(CXXFLAGS) $(CXXEXTRA) $(DEFINCL) -o $@ $< .rc.res: $(RC) $(RCFLAGS) $(RCEXTRA) $(DEFINCL) -fo$@ $< # Rules for cleaning CLEAN_FILES = y.tab.c y.tab.h lex.yy.c core *.orig *.rej \ \\\#*\\\# *~ *% .\\\#* clean:: $(SUBDIRS:%=%/__clean__) $(EXTRASUBDIRS:%=%/__clean__) $(RM) $(CLEAN_FILES) $(RC_SRCS:.rc=.res) $(C_SRCS:.c=.o) $(CXX_SRCS:.cpp=.o) $(RM) $(DLLS:%=%.so) $(EXES:%=%.so) $(EXES:%.exe=%) $(SUBDIRS:%=%/__clean__): dummy cd `dirname $@` && $(MAKE) clean $(EXTRASUBDIRS:%=%/__clean__): dummy -cd `dirname $@` && $(RM) $(CLEAN_FILES) ### Target specific build rules DEFLIB = $(LIBRARY_PATH) $(LIBRARIES) $(DLL_PATH) $(dmsw_exe_MODULE).so: $(dmsw_exe_OBJS) $(CC) $(dmsw_exe_LDFLAGS) -o $@ $(dmsw_exe_OBJS) $(dmsw_exe_LIBRARY_PATH) $(DEFLIB) $(dmsw_exe_DLLS:%=-l%) $(dmsw_exe_LIBRARIES:%=-l%)

Feb. 28, 2007

Re: fc4 rpms

by Bill Medland

On Wed, 2007-28-02 at 09:43 +0100, Andreas Bierfert wrote: > On Tue, 27 Feb 2007 18:17:04 -0800 > Bill Medland <billmedland(a)shaw.ca> wrote: > > > Is there any chance that someone with the ability can create the fedora > > core 4 wine rpms for version 0.9.30? > > > > Bill Medland > > If you want to I can upgrade the spec in fedora cvs to the newest versions as > well. It is sad that I cannot push builds for fc 3 and fc 4 anymore I might put > builds on my webpage if the audience is big enough... > > - Andreas > Thanks but that's no help for me; I guess I'll just build for myself. Actually it's for Red Hat Enterprise Linux 4 Server and Desktop for redistribution. I was hoping that I wouldn't have to become totally au fait with the more advanced stuff in the spec files, but I guess I need to bite the bullet. Thanks, anyway Bill

Feb. 28, 2007

Re: [8/12] WineD3D: Create multithreading contexts for swapchains

by Stefan Dösinger

Hi, > I can even run Tom Clancy's Rainbow Six Vegas, but there are still > problems with offscreen rendering. Yeah, offscreen rendering is unsupported with my multithreading patches. I have another patch to fix that, but I haven't tested it. I have a bit of a mess in my wine tree at the moment(2 sets of patches), I will clean that up, send a few non-multithreaded patches to wine-patches and the newest multithreading thing to wine-devel for testing.

Feb. 28, 2007