August 2004 - Wine-Devel - list.winehq.org

MS Project 2000 not working in wine.
by James Courtier-Dutton Aug. 21, 2004

Aug. 21, 2004

Has anyone got MS Project 2000 working in wine? James

2 1

MS Visio 2000 not working with wine.
by James Courtier-Dutton Aug. 21, 2004

Aug. 21, 2004

Has anyone got MS Visio 2000 working with wine? James

2 1

Re: Added path settings to winecfg
by Marcelo Duarte Aug. 21, 2004

Aug. 21, 2004

Jacek Caban escreveu: > But what about other languages, which nobody updates as you do? > I have one more question: where can I find this script? I see that > polish translation is far from complete and I thought I could work > aroun dit. > > Thanks, > Jacek Sorry for the delay. Atached is the patch to create a trans.sh in in wine/tools. To run in wine directory run tools/trans.sh and it creates tools/trans_html/index.html This is a modified version of the original patch that Vincent Beron send in January.

1 0

[Fwd: Re: [ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]]
by Mike Hearn Aug. 21, 2004

Aug. 21, 2004

-------- Forwarded Message -------- From: Con Kolivas <kernel(a)kolivas.org> To: Mike Hearn <mike(a)navi.cx> Cc: ck(a)vds.kolivas.org Subject: Re: [ck] Re: Threading issues? [ck-request(a)vds.kolivas.org: ck Digest, Vol 3, Issue 16] Date: Sat, 21 Aug 2004 10:39:21 +1000 Mailer: Mozilla Thunderbird 0.7.1 (X11/20040626) Mike Hearn wrote: > On Tue, 17 Aug 2004 10:06:46 +0200, Andreas Mohr wrote: > >>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 > > > Well, apparently we don't use sched_yield, so the problem must > lie somewhere else. Maybe Con can help us out here? Alexandre says he > doesn't know what the issue is either and somebody needs to investigate. I > guess we do need to concern ourselves over the details :) Interesting. Probably the most valuable information is that it seems to work fine if we artificially limit the threads to exactly the same timeslice _or_ we put them at such a low priority that they are forced to be guaranteed to round robin one task at a time. This is the way 2.4 used to work which is why with the new 2.6 schedulers which do far more out-of-order rescheduling some applications have a problem; particularly under load. I suspect it's actually the latter issue. Locking between threads should prevent that being a problem, though. You already mentioned that you dont use sched_yield() and I couldn't even begin to look at the wine code myself so perhaps you know something more. The other (useful?) bit of information is that one person solved his issue with this: >I had a similar problem with Cedega. I fixed it by editing the >Cedega/WineX config file and specifying that I wanted to use ALSA >instead of WineOSS, then disable mmap for ALSA. I'm not sure if that fixes all the problems but perhaps that helps. I'm interested in getting this resolved so please keep me informed. Cheers, Con P.S. Sorry I had trouble posting to your newsgroup.

1 0

Re: Limit number of DirectDrawClipper_SetClipList FIXMEs
by Stefan Leichter Aug. 21, 2004

Aug. 21, 2004

Am Freitag, 20. August 2004 18:37 schrieb Tobias Burnus: > + > HRESULT WINAPI Main_DirectDrawClipper_SetClipList( > - LPDIRECTDRAWCLIPPER iface,LPRGNDATA lprgn,DWORD pdwSize > + LPDIRECTDRAWCLIPPER iface,LPRGNDATA lprgn,DWORD pdwFlag > ) { > ICOM_THIS(IDirectDrawClipperImpl,iface); > - FIXME("(%p,%p,%ld),stub!\n",This,lprgn,pdwSize); > + static int warned = 0; > + if (warned++ < 10 && lprgn != NULL) Hello, for me this looks like if (0 < 10 && lprgn != NULL) what is the same like if (lprgn != NULL) I thing you meant something different Bye Stefan

3 3

Compile on AMD Opetron
by chall＠bcrl.stcloudstate.edu Aug. 21, 2004

Aug. 21, 2004

I tried to compile wine-2004813 on a AMD Opetron this is what I found. ./configure No Problems found. make depend No Problems found. make **FAILS** chuck(a)sniper wine-20040813 $ make make[1]: Entering directory `/home/chuck/src/wine/wine-20040813/libs' make[2]: Entering directory `/home/chuck/src/wine/wine-20040813/libs/port' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o interlocked.o interlocked.c interlocked.c:248:3: #error You must implement the interlocked* functions for your CPU make[2]: *** [interlocked.o] Error 1 make[2]: Leaving directory `/home/chuck/src/wine/wine-20040813/libs/port' make[1]: *** [port] Error 2 make[1]: Leaving directory `/home/chuck/src/wine/wine-20040813/libs' make: *** [libs] Error 2 chuck(a)sniper wine-20040813 $ After looking at the file libs/port/interlocked.c I noticed that there are special instructions for the UltraSPARC proc. Since I do not read or know asm, I looked at the #include for for Solaris (/usr/include/synch.h). pulled from solaris 9 on sparc. (/usr/include/synch.h) /* * synch.h: * definitions needed to use the thread synchronization interface */ I then looked through a number of other include files and noticed that all this seems to be is a control for threads. Under linux on the AMD Opetron could you not use the pthreads.h #include file? If you need access to a AMD Opetron box I can setup remote access (via SSH) so you can test the code, or I can try the patches (if any) sent. Have Fun! Chuck Hall

2 1

Suggestion for wine-user
by Geoffrey Leach Aug. 20, 2004

Aug. 20, 2004

Perhaps some "worked examples"? It would be helpful to be able to have a set of examples that would illustrate the basic features of Wine. For example: o A "Hello World" .exe that used only the .dll files in the dist. o A script that executed a Windoze app that required only minimal configuration -- for example, just the mount point used for C: o A script that executed a (local) .exe that had its own (local) .dll files (both on the Unix side) Kudos to whoever put together the rpm. Regards.

1 0

Document an API difference
by Shachar Shemesh Aug. 20, 2004

Aug. 20, 2004

Hi list, I'm documenting a probable API result difference between Wine and Windows. At the moment, this is no longer a problem as far as I'm concerned, so there is no point for me to write regression tests and fix it, but this may be stopping someone else. It seems that if you call "select" with a FD set that holds the same file descriptor more than once, Wine's and Window's responses are different. Under windows, you get a statement saying that only one FD is active. Under Wine, you get as many as the number of times the repeating FD is in the set. Like I said, this does not affect, as far as I know, any program, so I'm not sure we need to fix it. I just wanted the list's archive to have a mention of this issue. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

1 0

Re: Backtrace Dumps
by Alexandre Julliard Aug. 20, 2004

Aug. 20, 2004

Robert Shearman <rob(a)codeweavers.com> writes: > I propose the addition of this new debug tool that will allow > developers to output backtraces to the console, without having to > interact with a debugger. It can give a useful indication of how > functions are being called in situations where a break point is not > appropriate. I think it's better to let the debugger take care of that. If you don't want a real breakpoint you could define a custom exception to tell winedbg to just dump the backtrace and continue. -- Alexandre Julliard julliard(a)winehq.org

7 13

Re: Optimization for FindFile* (resend)
by Alexandre Julliard Aug. 20, 2004

Aug. 20, 2004

Robert Shearman <rob(a)codeweavers.com> writes: > Changelog: > Handle case of mask containing no wildcards so that it is possible to > avoid searching through hundreds of directory entries. I'm afraid this doesn't work, you need to take the file position in the directory into account, and also update it properly (which will probably defeat the optimization). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Move include/async.h to include/wine/async.h
by Alexandre Julliard Aug. 20, 2004

Aug. 20, 2004

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 Aug. 20, 2004

Aug. 20, 2004

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(a)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(a)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 Aug. 20, 2004

Aug. 20, 2004

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 Aug. 20, 2004

Aug. 20, 2004

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 Aug. 20, 2004

Aug. 20, 2004

> 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 Aug. 20, 2004

Aug. 20, 2004

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 Aug. 20, 2004

Aug. 20, 2004

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(a)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 Aug. 20, 2004

Aug. 20, 2004

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 Aug. 20, 2004

Aug. 20, 2004

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 Aug. 19, 2004

Aug. 19, 2004

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

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 Michael Stefaniuc Aug. 19, 2004

Aug. 19, 2004

On Thu, Aug 19, 2004 at 03:54:40PM -0500, Alex Villacís Lasso wrote: > 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 > > --- wine-20040813/misc/registry.c 2004-07-29 20:35:52.000000000 -0500 > +++ wine-20040813-patch/misc/registry.c 2004-08-19 15:35:00.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 Was this name change planned? bye michael -- 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 0

Re: FontDlg fix
by Alexandre Julliard Aug. 19, 2004

Aug. 19, 2004

Jacek Caban<jack(a)itma.pwr.wroc.pl> writes: > + if(chf16->lpTemplateName) > + { > + len1 = strlen(MapSL(chf16->lpTemplateName)); > + chf32w->lpTemplateName = malloc(len1 * sizeof(WCHAR)); > + MultiByteToWideChar(CP_ACP, 0, (LPSTR)MapSL(chf16->lpTemplateName), > + len1, (LPWSTR)chf32w->lpTemplateName, len1); > + } > + if(chf16->lpszStyle) > + { > + len2 = strlen(MapSL(chf16->lpszStyle)); > + chf32w->lpszStyle = malloc(len2 * sizeof(WCHAR)); > + MultiByteToWideChar(CP_ACP, 0, (LPSTR)MapSL(chf16->lpTemplateName), > + len2, chf32w->lpszStyle, len2); > + } These strings never get freed (and please use HeapAlloc instead of malloc). Also the length arguments are wrong, you can't use strlen() to determine the size of the Unicode string. There are similar problems at other places in your patch too. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: gethostbyname on local host returns 127.0.0.1 for address
by Juan Lang Aug. 19, 2004

Aug. 19, 2004

Robert wrote: > On windows gethostbyname for the local host returns > the addresses of the available network interfaces. > On wine and unix, it only returns the localhost > 127.0.0.1. > > Any ideas on how to get the windows behavior? I assume you're referring to gethostname (as in your sample code), not gethostbyname (as in your email). Well, I guess you'd have to modify winsock/socket.c's WS_gethostname function, maybe to call GetAdaptersInfo or some such. That'll get you the addresses, anyway. If you want a name other than localhost you may want to call GetNetworkParams too. --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

2 2

RE: iostream and msvcrt?
by Scott Snell Aug. 19, 2004

Aug. 19, 2004

Is that simpler than fixing the MSVCRT headers? I have used STLport before so the idea sounds feasable to me. I imagine I have to change the gcc-linux.mak by: replacing the call to gcc with winegcc, removing references to GLIBC, adding a path pointing to /include/wine/MSVCRT. Anything else? regards, Scott. > -----Original Message----- > From: Boaz Harrosh [SMTP:boaz(a)hishome.net] > Sent: Tuesday, 17 August 2004 18:18 > To: Scott Snell > Cc: Wine-Devel (E-mail) > Subject: Re: iostream and msvcrt? > > Using gcc's c++ libraries will not work with msvcrt. If it will compile > (which it doesn't) it will not load. (Some circular linking) > Your best bet is STLPort. Check it out. What I have done is a special > makefiles set with special config.h that compiles and links STLPort over > msvcrt. I have written to STLPort if they want my changes as support for > another platform but I never got a response from them. Do you need me to > dig out the old HD and pack you an STLPort compiled over msvcrt? > You might need to make some changes because it is from before winegcc > times,. Going strait for gcc. and maybe some wine stuff changed since > than. > > Scott Snell wrote: >

3 2

Wine Status - User Interface
by Tom Aug. 19, 2004

Aug. 19, 2004

Hello, I have been working on a update for the Status UI page over the last couple day's and i'm attaching a copy of what I have. I've re-named the template to .html so you can view it in your e-mail program or browser of choice. I haven't done the changelog so just view this againt http://www.winehq.org/site/status_ui for changes or diff. commits, suggestions, and flames are welcomed Regards, Tom

2 1