wine-devel April 2007

wine-devel@winehq.org

139 participants
312 discussions

WINECFG: use directory harddiskvolume1 for mapping drive C
by EA Durbin 22 Apr '07

22 Apr '07

What's the status of this patch? http://article.gmane.org/gmane.comp.emulators.wine.devel/40343/match=harddi… _________________________________________________________________ Mortgage refinance is Hot. *Terms. Get a 5.375%* fix rate. Check savings https://www2.nextag.com/goto.jsp?product=100000035&url=%2fst.jsp&tm=y&searc…

2 2

Re: Improving SysEx handling in winealsa.drv
by Stefan Dösinger 22 Apr '07

22 Apr '07

Am Samstag 21 April 2007 18:44 schrieb Michał W.: > Please consider incorporating the patch I submit, which improves > handling of MIDI System Exclusive messages > in alsa driver. It should be applied to dlls/winealsa.drv/midi.c file. > > The patch resolves the following bug: > http://bugs.winehq.org/show_bug.cgi?id=6788 > > Regards, > Michał Wiernowolski < /* FIXME: Should handle sysex greater that a single buffer */ --- > /* FIXME: Should handle sysex greater than lpMidiHdr->dwBufferLength */ ... It is highly recommendet to use git to generate patches. If you're using cvs or diff, please make unified diffs.

2 1

re: WINECFG: use directory harddiskvolume1 for mapping drive C
by Dan Kegel 22 Apr '07

22 Apr '07

To state the obvious, another workaround is: cd ~/.wine mv drive_c harddiskvolume1 cd dosdevices ln -sf ../harddiskvolume1 c: BTW this is http://bugs.winehq.org/show_bug.cgi?id=5351 - Dan

1 0

re: Make wine build with the Intel CC
by Dan Kegel 21 Apr '07

21 Apr '07

Maarten wrote: > I cannot test this as I don't have icc It's a free download for noncommercial use; see http://www.intel.com/cd/software/products/asmo-na/eng/compilers/277618.htm - Dan

1 0

[PATCH] Make wine build with the Intel CC
by Jonathan Schleifer 21 Apr '07

21 Apr '07

Hi! This patch makes it possible to build an run wine with the Intel compiler. Here are the environment variables I used to build: export CC="icc" export CFLAGS="-O3 -xP -msse3 -parallel" export CXX="icc" export CXXFLAGS="-O3 -xP -msse3 -parallel" export LDFLAGS="-lguide -lsvml -lstdc++ -parallel" export MAKEFLAGS="-j 2" (Not all are needed, just quoting from my .profile) And here's the patch: diff -Nru wine-0.9.35/dlls/kernel32/sync.c wine-0.9.35-icc/dlls/kernel32/sync.c --- wine-0.9.35/dlls/kernel32/sync.c 2007-04-13 17:47:52.000000000 +0200 +++ wine-0.9.35-icc/dlls/kernel32/sync.c 2007-04-21 17:20:13.000000000 +0200 @@ -1885,12 +1885,14 @@ * InterlockedCompareExchange (KERNEL32.@) */ /* LONG WINAPI InterlockedCompareExchange( PLONG dest, LONG xchg, LONG compare ); */ +#ifndef __INTEL_COMPILER __ASM_GLOBAL_FUNC(InterlockedCompareExchange, "movl 12(%esp),%eax\n\t" "movl 8(%esp),%ecx\n\t" "movl 4(%esp),%edx\n\t" "lock; cmpxchgl %ecx,(%edx)\n\t" "ret $12") +#endif /*********************************************************************** * InterlockedExchange (KERNEL32.@) diff -Nru wine-0.9.35/dlls/kernel32/thread.c wine-0.9.35-icc/dlls/kernel32/thread.c --- wine-0.9.35/dlls/kernel32/thread.c 2007-04-13 17:47:52.000000000 +0200 +++ wine-0.9.35-icc/dlls/kernel32/thread.c 2007-04-21 17:21:25.000000000 +0200 @@ -554,11 +554,13 @@ * SetLastError (KERNEL32.@) */ /* void WINAPI SetLastError( DWORD error ); */ +#ifndef __INTEL_COMPILER __ASM_GLOBAL_FUNC( SetLastError, "movl 4(%esp),%eax\n\t" ".byte 0x64\n\t" "movl %eax,0x34\n\t" "ret $4" ) +#endif /*********************************************************************** * GetLastError (KERNEL.148) diff -Nru wine-0.9.35/dlls/ntdll/thread.c wine-0.9.35-icc/dlls/ntdll/thread.c --- wine-0.9.35/dlls/ntdll/thread.c 2007-04-13 17:47:52.000000000 +0200 +++ wine-0.9.35-icc/dlls/ntdll/thread.c 2007-04-21 17:19:41.000000000 +0200 @@ -1429,7 +1429,9 @@ */ #if defined(__i386__) && defined(__GNUC__) +#ifndef __INTEL_COMPILER __ASM_GLOBAL_FUNC( NtCurrentTeb, ".byte 0x64\n\tmovl 0x18,%eax\n\tret" ) +#endif #elif defined(__i386__) && defined(_MSC_VER) diff -Nru wine-0.9.35/libs/wine/ldt.c wine-0.9.35-icc/libs/wine/ldt.c --- wine-0.9.35/libs/wine/ldt.c 2007-04-13 17:47:52.000000000 +0200 +++ wine-0.9.35-icc/libs/wine/ldt.c 2007-04-21 17:19:41.000000000 +0200 @@ -480,10 +480,14 @@ __ASM_GLOBAL_FUNC( wine_get_cs, "movw %cs,%ax\n\tret" ) __ASM_GLOBAL_FUNC( wine_get_ds, "movw %ds,%ax\n\tret" ) __ASM_GLOBAL_FUNC( wine_get_es, "movw %es,%ax\n\tret" ) +#ifndef __INTEL_COMPILER __ASM_GLOBAL_FUNC( wine_get_fs, "movw %fs,%ax\n\tret" ) +#endif __ASM_GLOBAL_FUNC( wine_get_gs, "movw %gs,%ax\n\tret" ) __ASM_GLOBAL_FUNC( wine_get_ss, "movw %ss,%ax\n\tret" ) +#ifndef __INTEL_COMPILER __ASM_GLOBAL_FUNC( wine_set_fs, "movl 4(%esp),%eax\n\tmovw %ax,%fs\n\tret" ) +#endif __ASM_GLOBAL_FUNC( wine_set_gs, "movl 4(%esp),%eax\n\tmovw %ax,%gs\n\tret" ) # endif /* defined(_MSC_VER) */ diff -Nru wine-0.9.35/programs/winefile/winefile.c wine-0.9.35-icc/programs/winefile/winefile.c --- wine-0.9.35/programs/winefile/winefile.c 2007-04-13 17:47:52.000000000 +0200 +++ wine-0.9.35-icc/programs/winefile/winefile.c 2007-04-21 17:19:41.000000000 +0200 @@ -283,7 +283,11 @@ if (!pvswprintf) { HMODULE hModMsvcrt = LoadLibraryA("msvcrt"); +#ifdef __INTEL_COMPILER + pvswprintf = GetProcAddress(hModMsvcrt, "vswprintf"); +#else pvswprintf = (int(__cdecl*)(WCHAR*,const WCHAR*,va_list)) GetProcAddress(hModMsvcrt, "vswprintf"); +#endif } va_start(ap, fmt); I #ifdef'd the asm code out since for some strange reason, it was already defined when using ICC. Could you please test it and commit it if it works? -- Jonathan

2 1

winmm: Allow a FORCE_SHUTDOWN on driver close?
by Maarten Lankhorst 21 Apr '07

21 Apr '07

After trying to implement the alsa mixer I came across a problem: If winmm is unloading, a deadlock could occur if during unloading it's waiting for another thread. In winmm itself this isn't much of a problem: there aren't any threads. However, the drivers used by winmm may have threads, and if the application doesn't shut down their drivers properly, it could be possible that a deadlock occurs when the drivers unload because winmm unloads. For that reason I propose to add a flag that's passed to the sound drivers that signals a shutdown in DLL_DETACH context, so that drivers can choose to call TerminateThread instead of waiting tidily for the thread to finish running. It's not pretty, but I don't see another way how to make sure that deadlocks won't occur when unloading winmm. I'm open for other suggestions though. Maarten

2 3

Re: dsound: Make sure we're holding the lock on Drop And Stop , try 2
by Peter Beutner 21 Apr '07

21 Apr '07

Maarten Lankhorst schrieb: > This fixes an interesting deadlock with the alsa driver: > > DSOUND_Stop is called, message is added to thread queue. > DSOUND_Release is called, message is added to thread queue. > > Both are fast messages, so second is added before first. But this only works if DSOUND_Stop and DSOUND_Release are called from different threads, right? > > thread reads: We're going down! And terminates. > > DSOUND_Stop's message is never read and it waits till eternity, so > starting/stopping never occurs any more. Isn't the real problem that when ALSA_DestroyRingMessage(*) is called from IDsDriverBuffer_Release it doesn't check if there are still any "fast messages" in the queue which wait for their message to be handled? Just from a quick look it seems you could theoretically trigger the same deadlock with the WODM_RESET & WODM_CLOSE messages when using the waveout system. (*) probably affects all other sound drivers as well which use this (horrible complex) message ring buffer system.

2 4

PATCH: fix configure.ac to find functions on Solaris
by sol11x86＠comcast.net 21 Apr '07

21 Apr '07

This patch allows configure.ac to generate a configure script which will properly find some network functions that require Solaris to include -lsocket on. The first AC_CHECK_FUNCS tests connect, and if it's not found in "libc", then the existing code just adds -lsocket to the list of libraries. Once that occurs, the rest of the get X by Y functions are found for a solaris host. Prior to this patch, mozilla.exe would start, but would fail when looking up a host. When applied, this patch allows mozilla.exe to actually resolve a host on Solaris and render the page. Ben --- configure.ac | 24 ++++++++++++++++-------- 1 files changed, 16 insertions(+), 8 deletions(-) diff --git a/configure.ac b/configure.ac index 5f718c7..7895ec5 100644 --- a/configure.ac +++ b/configure.ac @@ -1141,6 +1141,9 @@ fi dnl **** Check for functions **** +dnl **** connect, gethostbyname and inet_aton are not actually +dnl **** used, but are included to help identify the right +dnl **** libraries to use. AC_CHECK_FUNCS(\ _pclose \ @@ -1165,22 +1168,15 @@ AC_CHECK_FUNCS(\ ftruncate \ futimes \ futimesat \ - getaddrinfo \ getdirentries \ gethostbyname \ - getnameinfo \ - getnetbyname \ getopt_long \ getpagesize \ - getprotobyname \ - getprotobynumber \ getpwuid \ - getservbyport \ gettid \ gettimeofday \ getuid \ inet_aton \ - inet_network \ kqueue \ lstat \ memmove \ @@ -1195,7 +1191,6 @@ AC_CHECK_FUNCS(\ rfork \ sched_yield \ select \ - sendmsg \ setrlimit \ settimeofday \ sigaltstack \ @@ -1247,6 +1242,19 @@ then AC_CHECK_LIB(resolv,inet_aton) fi +dnl **** Check for functions which may rely on -lsocket on Solaris. +dnl **** If connect is found in libc, then it's all good anyway. +AC_CHECK_FUNCS( + getaddrinfo \ + getnameinfo \ + getnetbyname \ + getprotobyname \ + getprotobynumber \ + getservbyport \ + inet_network \ + sendmsg \ +) + dnl **** Check for types **** AC_C_CONST -- 1.5.1.1

1 0

Re: include: introduce ntsecpkg.h
by Kai Blin 21 Apr '07

21 Apr '07

On Saturday 21 April 2007 00:20, Yuval Fledel wrote: > ntsecpkg.h specifies the interface with Authentication Security > Support Providers. This is a quick glance over your file, comparing with the implementation I had lying around on my box. > The first 50 lines were imported from w32api. The rest was submitted > to w32api too. The ISC_* and ASC_* #defines are useless. You include security.h, which in turn includes sspi.h which contains all of those. SECURITY_NATIVE_DREP and SECURITY_NETWORK_DREP are defined in rpc.h, no need to have them in ntsecpkg.h Looking at other include files, I don't think +#if __GNUC__ >=3 +#pragma GCC system_header +#endif + +#include "windef.h" +#include "ntsecapi.h" +#include "security.h" + should be in there. > I wish I could make the patch smaller, however the last two lines > depend on all the rest, and the rest is useless without the last two. You could make the patch mor readable by adding the occasional new line between the typedefs of all those structs. Looking good otherwise. Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

1 0

re: gethostbyname(my_name) and IL2-Sturmovik CONTINUED
by Dan Kegel 21 Apr '07

21 Apr '07

Briareos wrote: > The Problem: gethostbyname(own_name) always returns 127.0.0.1. ... > To me it's logical that you get 127.0.0.1 when pinging your local hostname, > but if windows does give the IP of your NIC then wine should do as well - as > we want to reach compatibility. > >If, on the other hand, you say it's simply bad programming done by the >app-developer if he tries to fetch the IP of the NIC that way, I'd say let's >still comply to it, because its more likely than having a programmer >expecting to get 127.0.0.1 when asking for "localhostname". My understanding is that hostnames are not really hostnames, but interface names. On Unix, 127.0.0.1 is never normally returned unless you ask for literally "localhost". I suspect Windows behaves like Unix here. So this probably is a valid bug in wine. (I suspect that the app developer is misguided, because binding to just one interface doesn't work well if you have multiple interfaces, but that's neither here nor there.) - Dan

4 4

← Newer
1
...
10
11
12
13
14
15
16
...
32
Older →

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 April 2007