- Wine-Devel - list.winehq.org

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