wine-devel August 2004

wine-devel@winehq.org

122 participants
273 discussions

Re: Move include/async.h to include/wine/async.h
by Alexandre Julliard 20 Aug '04

20 Aug '04

Robert Shearman <rob(a)codeweavers.com> writes: > Changelog: > Move include/async.h to include/wine/async.h Actually that file should be removed, we don't want to share internal data structures like that. It will require some restructuring of the async I/O support though. -- Alexandre Julliard julliard(a)winehq.org

1 0

Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]
by Andreas Mohr 20 Aug '04

20 Aug '04

Hi all, this is a nice little posting from the Con Kolivas Linux interactivity patches list. Note that it is about Cedega, not Wine, but it might easily affect Wine, too. Are we doing some big no-nos in the threading area here? (or maybe it's just done the way it is because we cannot do it a different, better way?) For the whole discussion, please see http://bhhdoa.org.au/pipermail/ck/2004-August/000428.html Andreas Mohr ----- Forwarded message from ck-request(a)vds.kolivas.org ----- Message: 12 Date: Mon, 16 Aug 2004 21:31:59 +1000 From: Con Kolivas <kernel(a)kolivas.org> Subject: Re: [ck] 2.6.8.1-ck1, cedega-cvs, ALSA sound (choppy) To: greblus(a)poczta.onet.pl Cc: ck(a)vds.kolivas.org Message-ID: <41209B2F.4030207(a)kolivas.org> Content-Type: text/plain; charset="us-ascii" Wiktor Grebla wrote: > On Mon, Aug 16, 2004 at 08:16:08PM +1000, Con Kolivas wrote: > > >>It wont be a preempt threshold problem. >>See if it's a priority issue on the part of wine*. Be absolutely certain >>that wineserver, wine and the game are all run the _same_ priority and >>not a better priority than X. Send me the output of 'top -b -n 1' during >>the sound being choppy. Then try running _all_ the wine things at nice >>+19. This is a simple sanity check to see where the problem lies. > > > It's in fact as you say, all parts of wine have different priorities, and > some of them are higher than X: > > greblus@greblus:~$ top -n 1 -b | grep wine > 1630 greblus 23 0 471m 230m 164m R 92.8 45.9 1:54.63 wine > 1666 greblus 20 0 471m 230m 164m S 2.0 45.9 0:01.64 wine > 1629 greblus 20 0 2400 1192 2176 S 0.0 0.2 0:00.00 winex > 1633 greblus 20 0 6864 5056 6756 S 0.0 1.0 0:01.10 wineserver > 1634 greblus 20 0 6864 5056 6756 S 0.0 1.0 0:00.15 wineserver > 1659 greblus 20 0 471m 230m 164m S 0.0 45.9 0:00.00 wine > 1660 greblus 21 0 471m 230m 164m S 0.0 45.9 0:00.00 wine > 1662 greblus 20 0 471m 230m 164m S 0.0 45.9 0:00.06 wine > 1663 greblus 33 0 471m 230m 164m R 0.0 45.9 0:00.41 wine > > greblus@greblus:~$ top -b -n 1 | grep X > 621 root 20 0 88092 18m 75m S 0.0 3.8 1:02.96 X > > After renicing all of them there is no problem with choppy sound in all of time > wasting programs I've on my disk :>, and overall (subjective) performance is > better of course. > > Full output of top -b -n 1 is here: > http://unixforge.org/~greblus/ck/top_-b_-n_1.txt > > Kindest Regards, > W. Thanks for details. You do not have different nice levels; that is PRI that is different, which is the "dynamic" priority that constantly changes by the scheduler. It is as I suspected, though - if you renice everything +19 and the problem goes away it is bad programming on the wine developers' part that use what's called sched_yield instead of proper locking between their threads. Don't concern yourself over the details, but at least you have a simple workaround... sigh Cheers, Con

2 1

Re: Different X Displays and Wine
by Eric Frias 20 Aug '04

20 Aug '04

Alexandre Julliard (julliard_at_winehq.org) wrote:> We don't support having the same user run from different displays at> the same time. I don't think that's a common setup at all. It probably is not a common setup, but Boaz isn't the only person to have been bitten by this. It has happened both to us and to people who use our software. In our development environment, we usually use one or two common user accounts to do all development and testing in. I know this isn't ideal, but I don't have any power to change this. Anyway, with this setup, it is very easy to have two people developing or testing from the same account but displaying on separate machines. Right now we have been doing what was suggested earlier -- we have a script to launch our application and this script creates a .wine-$DISPLAY directory and points WINEPREFIX to that directory. This works well enough for now. It's inconvenient that the config file and registry aren't shared, so doing things like changing printer settings is a bit of a chore, but this hasn't bothered us too much yet. We're also making the assumption that not many users will be running this on multiple displays, so things will just work for most users and the few that do try to run on multiple displays will at least be able to do it. I'm curious how much work would be involved in fixing this correctly. I've never looked at the wineserver code, so I don't know if this would just be a matter of adding another variable to a data structure that gets passed around to all of the windowing code, or if this would require major changes to the way wineserver works. If it's reasonably easy, I might be able to make the fix or lend some assistance; if it is a large amount of work, we'll probably be happy with the workaround we have. Eric

2 2

winetest results refused by server
by Robert Reif 20 Aug '04

20 Aug '04

The winetest server has been refusing to accept test results for a while now. Could someone look into it.

1 0

Re: RE: Adventures in serial port.
by Pouech Eric DMI AEI CAEN 20 Aug '04

20 Aug '04

> I have tried the updates but to no avail. I have a test program that > appears to work well. However when that code is used in my project I still > lose some characters at the end of the message. The main difference is that > my project uses sockets, in another thread, to transfer the read/write data > to/from another application. Could the results from the socket calls be > messing with the ReadFile() results? I will make an example program that > includes sockets to see if I can verify this. does your program (the final one, not the test) use the same buffers and/or the same events in the two threads ? As most of the read/write structures are thread-dependent, I don't really see how two threads could thrash their data, except for some buffer overflow, hence my first question. A+

1 0

make CryptSetProviderEx update the provider Name and TypeName to registry
by James Hawkins 20 Aug '04

20 Aug '04

Changelog * Call provider.dll's DllRegisterServer from CryptSetProviderEx to update the Name and TypeName values in the registry properly when setting the default provider -- James Hawkins

1 0

RE: Adventures in serial port.
by Scott Snell 20 Aug '04

20 Aug '04

Hi Eric, I have tried the updates but to no avail. I have a test program that appears to work well. However when that code is used in my project I still lose some characters at the end of the message. The main difference is that my project uses sockets, in another thread, to transfer the read/write data to/from another application. Could the results from the socket calls be messing with the ReadFile() results? I will make an example program that includes sockets to see if I can verify this. regards, scott. > -----Original Message----- > From: Eric Pouech [SMTP:pouech-eric@wanadoo.fr] > Sent: Thursday, 19 August 2004 3:14 > To: Scott Snell > Subject: Re: Adventures in serial port. > > Scott Snell a écrit : > > Fantastic! Can you let me know when it is committed? > it is

1 0

Re: Let StartServiceCtrlDispatcher handle services started other than with StartService (with patch)
by Alexander Yaworsky 20 Aug '04

20 Aug '04

I think that this is incorrect. If you let StartServiceCtrlDispatcher to continue with no error, you make calling program think that it is running under control of service control manager. When service program handles somehow any kind of its launching, the behaviour may be quite different. Also, under windows StartServiceControlDispatcher always fails if service program is started not with StartService (maybe we should add 15 seconds delay to exactly emulate versions earlier than XP? ;-))). Alexander

1 0

Re: KERNEL: pull WINDIR and WINSYSDIR from config before using hardcoded defaults (possible fix for WWN #234, #235 c:\\windows is not accessible Error)
by Alex Villacís Lasso 20 Aug '04

20 Aug '04

Alex Villacís Lasso wrote: > Alexandre Julliard wrote: > >> Alex Villacís Lasso <a_villacis(a)palosanto.com> writes: >> >> >> >>> Changelog: >>> * if windir or winsysdir environment vars are undefined, pull values >>> from config file before falling to hardcoded values >>> >> >> >> This of course defeats the whole purpose of the use of environment >> variables, which is to get rid of the config file. If the environment >> variables are not set it's because the user's config is wrong, they >> should be set in HKLM\System\CurrentControlSet\Control\SessionManager >> or (preferably) in HKCU\Environment. The code is supposed to migrate >> them automatically, but this may not always work if the registry >> already contains other values, in which case it needs to be fixed by >> hand. Going back to the config file is definitely not the right way. >> >> >> > Thanks for pointing me to misc/registry.c, it helped a LOT. > > Upon examination of the function convert_environment(), I realized the > following: the function > queries HKEY_CURRENT_USER/Environment with a call to NtCreateKey(). If > the call succeeds, > but the result is something other than REG_CREATED_NEW_KEY, the > function terminates in > the assumption that the environment was already migrated in a previous > invocation of Wine. > > The problem is, this assumption is false when the user has a Windows > partition for a Wine drive, > and the user has environment variables of his/her own in the registry. > For example, I am a cygwin user > and I have a Win2k registry with the variables VISUAL, CVS_RSH, and > CVSROOT already defined. > When the function sees that HKEY_CURRENT_USER/Environment already > exists (because it was > taken from the native Windows registry), it (incorrectly) skips the > migration of the config file variables. > > The obvious solution (implemented by this patch) is to remove the > assumption about > HKEY_CURRENT_USER/Environment being newly created, and instead test > for every value before > migrating. > > I hope this is definitely the right way. > > Changelog: > * Do not assume HKEY_CURRENT_USER/Environment exists ==> config file > was migrated. Instead test > for every key to migrate under HKEY_CURRENT_USER/Environment > > Alex Villacis Lasso > UPDATE: %Systemroot% should be migrated too, and this patch combines this and the previous fix. --- wine-20040813/misc/registry.c 2004-07-29 20:35:52.000000000 -0500 +++ wine-20040813-patch/misc/registry.c 2004-08-19 19:47:12.000000000 -0500 @@ -242,7 +242,7 @@ } /******************************************************************/ -/* WINDOWS 31 REGISTRY LOADER, supplied by Tor Sjøwall, tor(a)sn.no */ +/* WINDOWS 31 REGISTRY LOADER, supplied by Tor Sjwall, tor(a)sn.no */ /* reghack - windows 3.11 registry data format demo program. @@ -277,7 +277,7 @@ deduced from the reg.dat file by me. Mistakes may have been made. I claim no rights and give no guarantees for this program. - Tor Sjøwall, tor(a)sn.no + Tor Sjwall, tor(a)sn.no */ /* reg.dat header format */ @@ -1861,6 +1861,7 @@ static const WCHAR windowsW[] = {'w','i','n','d','o','w','s',0}; static const WCHAR systemW[] = {'s','y','s','t','e','m',0}; static const WCHAR windirW[] = {'w','i','n','d','i','r',0}; + static const WCHAR systemrootW[] = {'S','y','s','t','e','m','r','o','o','t',0}; static const WCHAR winsysdirW[] = {'w','i','n','s','y','s','d','i','r',0}; static const WCHAR envW[] = {'E','n','v','i','r','o','n','m','e','n','t',0}; static const WCHAR tempW[] = {'T','E','M','P',0}; @@ -1894,59 +1895,83 @@ NtClose( hkey_old ); return; } - if (disp != REG_CREATED_NEW_KEY) goto done; - /* convert TEMP */ + /* Test for existence of TEMP */ RtlInitUnicodeString( &nameW, tempW ); - if (!NtQueryValueKey( hkey_old, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) + if (NtQueryValueKey(hkey_env, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) { - NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); - RtlInitUnicodeString( &nameW, tmpW ); - NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); - MESSAGE( "Converted temp dir to new entry HKCU\\Environment \"TEMP\" = %s\n", - debugstr_w( (WCHAR*)info->Data ) ); + /* convert TEMP */ + RtlInitUnicodeString( &nameW, tempW ); + if (!NtQueryValueKey( hkey_old, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) + { + NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); + RtlInitUnicodeString( &nameW, tmpW ); + NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); + MESSAGE( "Converted temp dir to new entry HKCU\\Environment \"TEMP\" = %s\n", + debugstr_w( (WCHAR*)info->Data ) ); + } } - /* convert PATH */ + /* Test for existence of PATH */ RtlInitUnicodeString( &nameW, pathW ); - if (!NtQueryValueKey( hkey_old, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) + if (NtQueryValueKey(hkey_env, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) { - NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); - MESSAGE( "Converted path dir to new entry HKCU\\Environment \"PATH\" = %s\n", - debugstr_w( (WCHAR*)info->Data ) ); + /* convert PATH */ + RtlInitUnicodeString( &nameW, pathW ); + if (!NtQueryValueKey( hkey_old, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) + { + NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); + MESSAGE( "Converted path dir to new entry HKCU\\Environment \"PATH\" = %s\n", + debugstr_w( (WCHAR*)info->Data ) ); + } } - /* convert USERPROFILE */ - RtlInitUnicodeString( &nameW, profileW ); - if (!NtQueryValueKey( hkey_old, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) - { - RtlInitUnicodeString( &nameW, userprofileW ); - NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); - MESSAGE( "Converted profile dir to new entry HKCU\\Environment \"USERPROFILE\" = %s\n", - debugstr_w( (WCHAR*)info->Data ) ); + /* Test for existence of USERPROFILE */ + RtlInitUnicodeString( &nameW, userprofileW ); + if (NtQueryValueKey(hkey_env, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) + { + /* convert USERPROFILE */ + RtlInitUnicodeString( &nameW, profileW ); + if (!NtQueryValueKey( hkey_old, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) + { + RtlInitUnicodeString( &nameW, userprofileW ); + NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); + MESSAGE( "Converted profile dir to new entry HKCU\\Environment \"USERPROFILE\" = %s\n", + debugstr_w( (WCHAR*)info->Data ) ); + } } - /* convert windir */ - RtlInitUnicodeString( &nameW, windowsW ); - if (!NtQueryValueKey( hkey_old, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) - { - RtlInitUnicodeString( &nameW, windirW ); - NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); - MESSAGE( "Converted windows dir to new entry HKCU\\Environment \"windir\" = %s\n", - debugstr_w( (WCHAR*)info->Data ) ); + /* Test for existence of windir */ + RtlInitUnicodeString( &nameW, windirW ); + if (NtQueryValueKey(hkey_env, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) + { + /* convert windir */ + RtlInitUnicodeString( &nameW, windowsW ); + if (!NtQueryValueKey( hkey_old, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) + { + RtlInitUnicodeString( &nameW, windirW ); + NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); + RtlInitUnicodeString( &nameW, systemrootW ); + NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); + MESSAGE( "Converted windows dir to new entry HKCU\\Environment \"windir\" = %s\n", + debugstr_w( (WCHAR*)info->Data ) ); + } } - - /* convert winsysdir */ - RtlInitUnicodeString( &nameW, systemW ); - if (!NtQueryValueKey( hkey_old, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) - { - RtlInitUnicodeString( &nameW, winsysdirW ); - NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); - MESSAGE( "Converted system dir to new entry HKCU\\Environment \"winsysdir\" = %s\n", - debugstr_w( (WCHAR*)info->Data ) ); + + /* Test for existence of winsysdir */ + RtlInitUnicodeString( &nameW, winsysdirW ); + if (NtQueryValueKey(hkey_env, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) + { + /* convert winsysdir */ + RtlInitUnicodeString( &nameW, systemW ); + if (!NtQueryValueKey( hkey_old, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) + { + RtlInitUnicodeString( &nameW, winsysdirW ); + NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); + MESSAGE( "Converted system dir to new entry HKCU\\Environment \"winsysdir\" = %s\n", + debugstr_w( (WCHAR*)info->Data ) ); + } } - -done: NtClose( hkey_old ); NtClose( hkey_env ); }

1 0

poll vs. epoll
by Shachar Shemesh 19 Aug '04

19 Aug '04

Hi all, I have a program (a server) that has a very large number of synchronization constructs. Even when everything is idle there, wineserver is taking 60% of the CPU, raising load average to 2.4. When load is applied, response time occasionally jumps from tenths of a second to two minutes. I noticed that in server/fd.c, the wineserver is using "poll" to select between file descriptors. The application is going through this code over 2000 times a second, with over 380 file descriptors each time. I am wondering whether this can be the cause of the slowdown. One of the possible solutions to this would be to use epoll instead. This, of course, would have to be backed by a configure check, as not all systems for which wine is intended support epoll. Another, arguably better, solution would be to use libevent for this purpose. Libevent has the distinct advantage that it automatically chooses the best tool for the job (epoll, poll, /dev/poll, or if all else fails, select). However, if there is another, independent use of poll, porting the semantics to libevent may prove non-trivial. So what does the forum think? One last question. What are the "users"? What constructs cause a new file descriptor to be allocated in the wineserver? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

2 1

← Newer
1
...
9
10
11
12
13
14
15
...
28
Older →

Jump to page:

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 August 2004