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

Re: Speeding up wineserver synchronization objects with shared memory

by Michael McCormack

Two things: 1. How about expiring client's unix file descriptors by having wineserver writing a single non-zero byte[*] to the server-communication socket when another client modifies the fd? The code to validate fds before use could then be reduced from a server call to a single nonwaiting poll on NtCurrentTeb()->reply_fd. 2. How about using pipes to implement critical sections? InitCriticalSection would create a pipe and write one byte, EnterCritical section would do a poll on the pipe, followed by a read of one byte, and leave critical section would write one byte back to the pipe. [*] wineserver would write a zero byte when it wished to restart a client after a server call, and the client would need to check this. Mike -- __________________________________________________________________ mailto:Michael.McCormack(a)alcatel.com.au phone: (+612) 9690 5305

Feb. 26, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Alexandre Julliard

Gavriel State <gav(a)transgaming.com> writes: > Even without that approach though, I don't think that the new failure mode > is really likely to be that big a deal. If process A owns a mutex that process > B wants, they quite likely have some functional interdependance which would be > disrupted as much by any generic hang in process A as by a hang followed by > a failure to release the mutex. Imagine a process that does a SuspendThread() on one of its threads, but makes sure by some kind of internal protocol that the thread is never holding the mutex when it is suspended. This would work just fine under Windows or under the wineserver, but would fail with the shared memory approach. There is simply no point in implementing a mutex that works only 99% of the time, no matter how fast it is. The synchronization objects have to be 100% reliable, performance only comes next; and none of the shared memory approaches I've seen so far are 100% reliable. In fact the original implementation of the kernel objects was based on shared memory and signals. A lot of time was spent trying to make this work right, but it was simply not possible without assuming that all processes will always follow the protocol correctly, which is clearly not something we can assume when running arbitrary Windows code. -- Alexandre Julliard julliard(a)winehq.com

Feb. 25, 2001

Re: undefined symbol: GetPrinterDataA

by Ian Pilcher

lawson_whitney(a)juno.com wrote: > > Try: > > import winspool > > instead of winspool.drv, and see if that helps. Just a guess. > Nope. winebuild complains that it "could not open .so file for winspool". I've uncovered a couple of additional facts which (I hope) may shed some light on the situation. I whipped up a quick Winelib program which calls GetPrinterDataA, and it runs just fine -- using a previous, working, Wine build. I tried commenting out the calls to GetPrinterDataA, and Wine now complains that OpenPrinterA is an undefined symbol. So the problem seems to affect multiple functions in winspool.drv, but it doesn't affect Winelib programs. -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

Feb. 25, 2001

Re: undefined symbol: GetPrinterDataA

by Ian Pilcher

lawson_whitney(a)juno.com wrote: > > I think maybe you have created a new dependency and need to run make > depend again? If I understand the import mechanism, something > (winebuild?) generates stubs for the functions you import and ties them > in to the import mechanism, so they shouldn't be left hanging for ld.so > to choke on. They should resolve to .spec.o. It looks to me as if the > .spec didin't get rebuilt. > If only it were that simple. I've rebuilt from scratch, with a clean source tree. -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

Feb. 25, 2001

Re: [PATCH] 16 bits print dialog

by Dmitry Timoshkov

"gerard patel" <gerard.patel(a)asi.fr> wrote: > As it's rather unlikely anyone will craft 16 bits specific resources now, I have > mapped the 32 bits resource into 16 bit ones > I did not test if 16 bits printing still works, but the print dialog box displays again > at least. > There is also a minor fix to cast the return value for the 16 bits hook to 16 bits. > > ChangeLog: > > * dlls/commdlg/printdlg.c > maps 32 bits resource for 16 bits print dialog. Gerard, your patch is fine, but I have one tiny comment: in Win32 hInstance and hModule are the same thing, unlike in Win16. So, instead of GetModuleHandleA("COMDLG32") you can safely use COMMDLG_hInstance32.

Feb. 25, 2001

undefined symbol: GetPrinterDataA

by Ian Pilcher

I am trying to modify the Wine PostScript driver to use GetPrinterDataA to read configuration information from the registry. I have added a line that reads "import winspool.drv" to wineps.spec, and Wine builds with no errors. When I try to run Wine, however, I get the following error: BUILTIN32_dlopen failed to load .so lib for builtin wineps.dll: /usr/lib/wine/libwineps.so: undefined symbol: GetPrinterDataA Ideas? -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

Feb. 25, 2001

Re: various config files for various applications

by Martin Pilka

Alexandre Julliard wrote: > This is getting way too complex IMO. I think having everything in the > .wine/config file is much more reasonable; most people don't need that > many different configurations anyway. > > What we should do is take advantage of the new config file format to > create a deeper configuration hierarchy. So for instance the default > x11drv config is under the registry key Wine\Config\x11drv, but we > could create subtrees like Wine\Config\AppDefaults\Solitaire\x11drv > which would contain the Solitaire-specific config values. This is then > very fast to lookup, just try AppDefaults\<current module> and if not > found fall back to the current method. I don't think we need regular > expressions at all. attached is the patch. i wasn't always sure i'm doing the things in the right way, so you guys can have a look before i make the real submit. here are some explanations: 1) i think we shouldn't access the wine configuration directly through registry, but use the PROFILE_ functions instead. in addition - now, when we're trying to do some kind of redirection, it's absolutely necessary. all the parts with direct access were rewritten. 2) in case of winaspi/winaspi16.c, dlls/shell32/shelllink.c and winmm/mci.c there weren't the PROFILE_ functions linked in, so i added them with "IMPORTS = ntdll" option in Makefile. i'm really not sure if it's a right way. 3) i wasn't able to find out the name of windows application we're just executing. that's why i added the win_app_exe_name variable into misc/options.c. the application specific profile is in Software\\Wine\\Wine\\Config\\AppProfile\\file_name.exe section. if some subsection is found (let's say x11drv), then that and only that subsection is used. if it's not found it just fall back to the current method. martin Index: wine/dlls/shell32/Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/shell32/Makefile.in,v retrieving revision 1.41 diff -u -r1.41 Makefile.in --- wine/dlls/shell32/Makefile.in 2001/02/23 01:12:26 1.41 +++ wine/dlls/shell32/Makefile.in 2001/02/25 14:19:14 @@ -6,6 +6,8 @@ ALTNAMES = shell EXTRALIBS = $(LIBUUID) $(LIBUNICODE) +IMPORTS = ntdll + LDDLLFLAGS = @LDDLLFLAGS@ SYMBOLFILE = $(MODULE).tmp.o Index: wine/dlls/shell32/shelllink.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/shelllink.c,v retrieving revision 1.33 diff -u -r1.33 shelllink.c --- wine/dlls/shell32/shelllink.c 2001/02/12 01:17:39 1.33 +++ wine/dlls/shell32/shelllink.c 2001/02/25 14:19:17 @@ -29,6 +29,7 @@ #include "pidl.h" #include "shell32_main.h" #include "shlguid.h" +#include "options.h" DEFAULT_DEBUG_CHANNEL(shell); @@ -522,7 +523,6 @@ char *path_name = NULL; char *work_dir = NULL; BOOL bDesktop; - HKEY hkey; _ICOM_THIS_From_IPersistFile(IShellLinkImpl, iface); @@ -538,13 +538,7 @@ /* check if ShellLinker configured */ buffer[0] = 0; - if (!RegOpenKeyExA( HKEY_LOCAL_MACHINE, "Software\\Wine\\Wine\\Config\\Wine", - 0, KEY_ALL_ACCESS, &hkey )) - { - DWORD type, count = sizeof(buffer); - if (RegQueryValueExA( hkey, "ShellLinker", 0, &type, buffer, &count )) buffer[0] = 0; - RegCloseKey( hkey ); - } + PROFILE_GetWineIniString("wine","ShellLinker","",buffer,sizeof(buffer)); if (!*buffer) return NOERROR; shell_link_app = HEAP_strdupA( GetProcessHeap(), 0, buffer ); Index: wine/dlls/user/user_main.c =================================================================== RCS file: /home/wine/wine/dlls/user/user_main.c,v retrieving revision 1.14 diff -u -r1.14 user_main.c --- wine/dlls/user/user_main.c 2001/01/22 02:17:29 1.14 +++ wine/dlls/user/user_main.c 2001/02/25 14:19:18 @@ -23,6 +23,7 @@ #include "user.h" #include "win.h" #include "debugtools.h" +#include "options.h" DEFAULT_DEBUG_CHANNEL(graphics); @@ -40,20 +41,8 @@ static BOOL load_driver(void) { char buffer[MAX_PATH]; - HKEY hkey; - DWORD type, count; - if (RegCreateKeyExA( HKEY_LOCAL_MACHINE, "Software\\Wine\\Wine\\Config\\Wine", 0, NULL, - REG_OPTION_VOLATILE, KEY_ALL_ACCESS, NULL, &hkey, NULL )) - { - MESSAGE("load_driver: Cannot create config registry key\n" ); - return FALSE; - } - count = sizeof(buffer); - if (RegQueryValueExA( hkey, "GraphicsDriver", 0, &type, buffer, &count )) - strcpy( buffer, "x11drv" ); /* default value */ - RegCloseKey( hkey ); - + PROFILE_GetWineIniString("Wine","GraphicsDriver","x11drv",buffer,sizeof(buffer)); if (!(graphics_driver = LoadLibraryA( buffer ))) { MESSAGE( "Could not load graphics driver '%s'\n", buffer ); @@ -160,15 +149,8 @@ { static const char *OS = "Win3.1"; char buffer[80]; - HKEY hkey; - DWORD type, count = sizeof(buffer); - if (RegCreateKeyExA( HKEY_LOCAL_MACHINE, "Software\\Wine\\Wine\\Config\\Tweak.Layout", 0, NULL, - REG_OPTION_VOLATILE, KEY_ALL_ACCESS, NULL, &hkey, NULL )) - return; - if (RegQueryValueExA( hkey, "WineLook", 0, &type, buffer, &count )) - strcpy( buffer, "Win31" ); /* default value */ - RegCloseKey( hkey ); + PROFILE_GetWineIniString("Tweak.Layout","WineLook","Win31",buffer,sizeof(buffer)); /* WIN31_LOOK is default */ if (!strncasecmp( buffer, "Win95", 5 )) Index: wine/dlls/winaspi/Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/winaspi/Makefile.in,v retrieving revision 1.11 diff -u -r1.11 Makefile.in --- wine/dlls/winaspi/Makefile.in 2000/11/30 01:17:55 1.11 +++ wine/dlls/winaspi/Makefile.in 2001/02/25 14:19:18 @@ -4,6 +4,7 @@ VPATH = @srcdir@ MODULE = wnaspi32 ALTNAMES = winaspi +IMPORTS = ntdll LDDLLFLAGS = @LDDLLFLAGS@ SYMBOLFILE = $(MODULE).tmp.o Index: wine/dlls/winaspi/winaspi16.c =================================================================== RCS file: /home/wine/wine/dlls/winaspi/winaspi16.c,v retrieving revision 1.25 diff -u -r1.25 winaspi16.c --- wine/dlls/winaspi/winaspi16.c 2000/12/13 20:20:14 1.25 +++ wine/dlls/winaspi/winaspi16.c 2001/02/25 14:19:20 @@ -19,6 +19,7 @@ #include "heap.h" #include "debugtools.h" #include "miscemu.h" +#include "options.h" DEFAULT_DEBUG_CHANNEL(aspi); @@ -43,7 +44,6 @@ static int ASPI_OpenDevice16(SRB_ExecSCSICmd16 *prb) { - HKEY hkey; int fd; char idstr[50]; char device_str[50]; @@ -63,17 +63,9 @@ } /* device wasn't cached, go ahead and open it */ - sprintf( idstr, "Software\\Wine\\Wine\\Config\\scsi c%1dt%1dd%1d", - prb->SRB_HaId, prb->SRB_Target, prb->SRB_Lun); + sprintf( idstr, "scsi c%1dt%1dd%1d", prb->SRB_HaId, prb->SRB_Target, prb->SRB_Lun); - device_str[0] = 0; - if (!RegOpenKeyExA( HKEY_LOCAL_MACHINE, idstr, 0, KEY_ALL_ACCESS, &hkey )) - { - DWORD type, count = sizeof(device_str); - if (RegQueryValueExA( hkey, "Device", 0, &type, device_str, &count )) device_str[0] = 0; - RegCloseKey( hkey ); - } - + PROFILE_GetWineIniString(idstr,"Device","",device_str,sizeof(device_str)); if (!device_str[0]) { TRACE("Trying to open unlisted scsi device %s\n", idstr); Index: wine/dlls/winmm/Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/winmm/Makefile.in,v retrieving revision 1.19 diff -u -r1.19 Makefile.in --- wine/dlls/winmm/Makefile.in 2001/01/13 01:01:00 1.19 +++ wine/dlls/winmm/Makefile.in 2001/02/25 14:19:20 @@ -8,6 +8,8 @@ LDDLLFLAGS = @LDDLLFLAGS@ SYMBOLFILE = $(MODULE).tmp.o +IMPORTS = ntdll + C_SRCS = \ driver.c \ joystick.c \ Index: wine/dlls/winmm/mci.c =================================================================== RCS file: /home/wine/wine/dlls/winmm/mci.c,v retrieving revision 1.17 diff -u -r1.17 mci.c --- wine/dlls/winmm/mci.c 2001/01/28 23:11:27 1.17 +++ wine/dlls/winmm/mci.c 2001/02/25 14:19:25 @@ -19,6 +19,7 @@ #include "wine/winbase16.h" #include "debugtools.h" #include "winreg.h" +#include "options.h" DEFAULT_DEBUG_CHANNEL(mci); @@ -2601,10 +2602,6 @@ BOOL MULTIMEDIA_MciInit(void) { LPSTR ptr1, ptr2; - HKEY hWineConf; - HKEY hkey; - DWORD err; - DWORD type; DWORD count = 2048; MCI_InstalledCount = 0; @@ -2613,14 +2610,8 @@ if (!MCI_lpInstallNames) return FALSE; - /* FIXME: should do also some registry diving here ? */ - if (!(err = RegOpenKeyA(HKEY_LOCAL_MACHINE, "Software\\Wine\\Wine\\Config", &hWineConf)) && - !(err = RegOpenKeyA(hWineConf, "options", &hkey))) { - err = RegQueryValueExA(hkey, "mci", 0, &type, MCI_lpInstallNames, &count); - RegCloseKey(hkey); - - } - if (!err) { + PROFILE_GetWineIniString("Options","mci","",MCI_lpInstallNames,count); + if (*MCI_lpInstallNames) { TRACE("Wine => '%s' \n", ptr1); while ((ptr2 = strchr(ptr1, ':')) != 0) { *ptr2++ = 0; @@ -2639,7 +2630,6 @@ MCI_InstalledCount++; } } - RegCloseKey(hWineConf); return TRUE; } Index: wine/dlls/x11drv/x11drv_main.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/x11drv_main.c,v retrieving revision 1.29 diff -u -r1.29 x11drv_main.c --- wine/dlls/x11drv/x11drv_main.c 2001/02/14 00:27:35 1.29 +++ wine/dlls/x11drv/x11drv_main.c 2001/02/25 14:19:34 @@ -134,20 +134,10 @@ static void setup_options(void) { char buffer[256]; - HKEY hkey; - DWORD type, count; - if (RegCreateKeyExA( HKEY_LOCAL_MACHINE, "Software\\Wine\\Wine\\Config\\x11drv", 0, NULL, - REG_OPTION_VOLATILE, KEY_ALL_ACCESS, NULL, &hkey, NULL )) - { - ERR("Cannot create config registry key\n" ); - ExitProcess(1); - } - /* --display option */ - - count = sizeof(buffer); - if (!RegQueryValueExA( hkey, "display", 0, &type, buffer, &count )) + PROFILE_GetWineIniString("x11drv","display","",buffer,sizeof(buffer)); + if (*buffer) { if (Options.display) { @@ -168,7 +158,7 @@ MESSAGE( "%s: no display specified\n", argv0 ); ExitProcess(1); } - RegSetValueExA( hkey, "display", 0, REG_SZ, Options.display, strlen(Options.display)+1 ); + PROFILE_SetWineIniString("x11drv","display",Options.display); } /* check and set --managed and --desktop options in wine config file @@ -176,26 +166,20 @@ if ((!Options.managed) && (Options.desktopGeometry == NULL)) { - count = sizeof(buffer); - if (!RegQueryValueExA( hkey, "managed", 0, &type, buffer, &count )) - Options.managed = IS_OPTION_TRUE( buffer[0] ); - - count = sizeof(buffer); - if (!RegQueryValueExA( hkey, "Desktop", 0, &type, buffer, &count )) - /* Imperfect validation: If Desktop=N, then we don't turn on - ** the --desktop option. We should really validate for a correct - ** sizing entry */ - if (! IS_OPTION_FALSE(buffer[0])) - Options.desktopGeometry = strdup(buffer); + int bool; + + bool = PROFILE_GetWineIniBool("x11drv","managed",2); + if (bool != 2) Options.managed = bool; + + /* Imperfect validation: If Desktop=N, then we don't turn on + ** the --desktop option. We should really validate for a correct + ** sizing entry */ + PROFILE_GetWineIniString("x11drv","Desktop","",buffer,sizeof(buffer)); + if (!IS_OPTION_FALSE(*buffer)) Options.desktopGeometry = strdup(buffer); } - - if (Options.managed) - RegSetValueExA( hkey, "managed", 0, REG_SZ, "y", 2 ); - if (Options.desktopGeometry) - RegSetValueExA( hkey, "desktop", 0, REG_SZ, Options.desktopGeometry, strlen(Options.desktopGeometry)+1 ); - - RegCloseKey( hkey ); + if (Options.managed) PROFILE_SetWineIniString("x11drv","managed","y"); + if (Options.desktopGeometry) PROFILE_SetWineIniString("x11drv","desktop",Options.desktopGeometry); } Index: wine/files/profile.c =================================================================== RCS file: /home/wine/wine/files/profile.c,v retrieving revision 1.46 diff -u -r1.46 profile.c --- wine/files/profile.c 2001/01/22 19:27:06 1.46 +++ wine/files/profile.c 2001/02/25 14:19:36 @@ -62,9 +62,12 @@ #define CurProfile (MRUProfile[0]) -/* wine.ini config file registry root */ +/* wine config registry root */ static HKEY wine_profile_key; +/* app config registry root */ +static HKEY wine_app_profile_key; + #define PROFILE_MAX_LINE_LEN 1024 /* Wine profile name in $HOME directory; must begin with slash */ @@ -939,7 +942,7 @@ /*********************************************************************** * PROFILE_GetWineIniString * - * Get a config string from the wine.ini file. + * Get a config string from the registry */ int PROFILE_GetWineIniString( const char *section, const char *key_name, const char *def, char *buffer, int len ) @@ -948,7 +951,8 @@ HKEY hkey; DWORD err; - if (!(err = RegOpenKeyA( wine_profile_key, section, &hkey ))) + if (!(err = RegOpenKeyA( wine_app_profile_key, section, &hkey )) || + !(err = RegOpenKeyA( wine_profile_key, section, &hkey ))) { DWORD type; DWORD count = sizeof(tmp); @@ -960,6 +964,32 @@ return strlen(buffer); } +/*********************************************************************** + * PROFILE_SetWineIniString + * + * Set a config string to the registry + */ +BOOL PROFILE_SetWineIniString( const char *section, const char *key_name, const char *value) +{ + HKEY hkey; + + TRACE( "('%s','%s','%s')\n", section, key_name, value ); + + if (!(RegOpenKeyA( wine_app_profile_key, section, &hkey )) || + !(RegCreateKeyA( wine_profile_key, section, &hkey ))) { + if (RegSetValueExA( hkey, key_name, 0, REG_SZ, value, strlen(value)+1 )) { + TRACE("unable to set value.\n"); + RegCloseKey( hkey ); + return FALSE; + } + } else { + TRACE( "unable to open key.\n"); + return FALSE; + } + + RegCloseKey( hkey ); + return TRUE; +} /*********************************************************************** * PROFILE_EnumWineIniString @@ -1080,10 +1110,20 @@ return 0; } RegCloseKey( hKeySW ); + if (RegCreateKeyExA( HKEY_LOCAL_MACHINE, "Software\\Wine\\Wine\\Config", 0, NULL, REG_OPTION_VOLATILE, KEY_ALL_ACCESS, NULL, &wine_profile_key, &disp )) { ERR("Cannot create config registry key\n" ); + return 0; + } + + strcpy( buffer, "AppProfile\\" ); + strncat( buffer, win_app_exe_name, MAX_PATHNAME_LEN-strlen(buffer) ); + if (RegCreateKeyExA( wine_profile_key, buffer, 0, NULL, + REG_OPTION_VOLATILE, KEY_ALL_ACCESS, NULL, &wine_app_profile_key, NULL )) + { + ERR("Cannot create app config registry key\n" ); return 0; } Index: wine/include/options.h =================================================================== RCS file: /home/wine/wine/include/options.h,v retrieving revision 1.31 diff -u -r1.31 options.h --- wine/include/options.h 2001/01/10 23:56:59 1.31 +++ wine/include/options.h 2001/02/25 14:19:36 @@ -21,6 +21,7 @@ extern struct options Options; extern const char *argv0; extern const char *full_argv0; +extern const char *win_app_exe_name; /* name of the main windows executable */ extern unsigned int server_startticks; extern void OPTIONS_Usage(void) WINE_NORETURN; @@ -32,6 +33,8 @@ extern void PROFILE_UsageWineIni(void); extern int PROFILE_GetWineIniString( const char *section, const char *key_name, const char *def, char *buffer, int len ); +extern BOOL PROFILE_SetWineIniString( const char *section, const char *key_name, + const char *value); extern BOOL PROFILE_EnumWineIniString( const char *section, int index, char *name, int name_len, char *buffer, int len ); extern int PROFILE_GetWineIniInt( const char *section, const char *key_name, int def ); Index: wine/misc/options.c =================================================================== RCS file: /home/wine/wine/misc/options.c,v retrieving revision 1.24 diff -u -r1.24 options.c --- wine/misc/options.c 2001/02/12 03:47:11 1.24 +++ wine/misc/options.c 2001/02/25 14:19:36 @@ -36,8 +36,9 @@ FALSE /* Managed windows */ }; -const char *argv0; /* the original argv[0] */ -const char *full_argv0; /* the full path of argv[0] (if known) */ +const char *argv0; /* the original argv[0] */ +const char *full_argv0; /* the full path of argv[0] (if known) */ +const char *win_app_exe_name; /* name of the main windows executable */ static char *inherit_str; /* options to pass to child processes */ @@ -377,6 +378,7 @@ { char buffer[1024]; int i; + char *tmp; if (GetEnvironmentVariableA( "WINEOPTIONS", buffer, sizeof(buffer) ) && buffer[0]) inherit_options( buffer ); @@ -404,6 +406,12 @@ app_argv = argv; app_argc = 0; while (argv[app_argc]) app_argc++; + + /* store the win app executable name */ + tmp = argv[1] + strlen(argv[1]); + while ( (tmp > argv[1]) && (*tmp != '/') && (*tmp != '\\') ) tmp--; + if ( (*tmp == '/') || (*tmp == '\\') ) tmp++; + win_app_exe_name = strdup(tmp); }

Feb. 25, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Gavriel State

Ove Kaaven wrote: > > On Sat, 24 Feb 2001, Robert O'Callahan wrote: > > > Ove Kaaven wrote: > > > On Thu, 22 Feb 2001, Robert O'Callahan wrote: > > > > Then on some other thread in the same address space > > > > that serves wineserver requests: > > > > > > There's no such thread, and will never be such a thread (having the > > > wineserver calling into client threads is an inherently unstable > > > design). > > > > The wineserver need not depend on the client thread responding to its > > (asynchronous) messages. In this case, if the client ignores the > > messages, you get the same effect as if it never releases its mutex, > > which is not a new failure mode. > > Sure it is, if the process isn't holding the mutex. Your design lets a > process own the mutex without holding it. So if a process acquires it, > then releases it, does something else for 10 minutes and then hangs, and > some other process decides it should grab the mutex, then it should be > allowed to do so, since the original process isn't holding it. But it > can't... Rather than have a dedicated thread to maintain any such communication back and forth with the server, why not simply use a signal to the first thread in the process. The signal should execute regardless of whether or not the thread is hung, and if the mutex is 'owned' by the process, but not currently 'held', the signal handler releases the mutex, and marks it as no longer owned. Even without that approach though, I don't think that the new failure mode is really likely to be that big a deal. If process A owns a mutex that process B wants, they quite likely have some functional interdependance which would be disrupted as much by any generic hang in process A as by a hang followed by a failure to release the mutex. And besides, once the user kills the hung process, the server should be able to reclaim the shared mutex object anyway. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

Feb. 25, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Joerg Mayer

Ove, On Sat, Feb 24, 2001 at 12:06:07PM +0100, Ove Kaaven wrote: > There's no such thread, and will never be such a thread (having the > wineserver calling into client threads is an inherently unstable design). I think I've read this before, when the topic was FindWindow. IIRC that thread never came to any conlusion/solution. Will the same happen to this topic too? If it looks like these problems could be solved by some sort of server calling into the client then why not do this until someone finds a better solution? On the other hand, if this mechanism doesn't work on a technical basis, that is something I can live with. "inherently unsable design" could be both: People simply not liking the idea of this and the corresponding design implications or it could be just another variant of "it won't work any better than the solution proposed so far". Which one is it? Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

Feb. 25, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Robert O'Callahan

Ove Kaaven wrote: > On Sat, 24 Feb 2001, Robert O'Callahan wrote: > > Ove Kaaven wrote: > > > On Thu, 22 Feb 2001, Robert O'Callahan wrote: > > > > Then on some other thread in the same address space > > > > that serves wineserver requests: > > > > > > There's no such thread, and will never be such a thread (having the > > > wineserver calling into client threads is an inherently unstable > > > design). > > > > The wineserver need not depend on the client thread responding to its > > (asynchronous) messages. In this case, if the client ignores the > > messages, you get the same effect as if it never releases its mutex, > > which is not a new failure mode. > > Sure it is, if the process isn't holding the mutex. Your design lets a > process own the mutex without holding it. So if a process acquires it, > then releases it, does something else for 10 minutes and then hangs, and > some other process decides it should grab the mutex, then it should be > allowed to do so, since the original process isn't holding it. But it > can't... I call that "not a new failure mode" because it's the same behavior as if the faulty client process had a bug that caused it to fail to release the mutex in the first place. If you want a more restricted fault model, you can limit the vulnerability window by having the client periodically poll for owned-but-unlocked mutexes and release them to the wineserver. > > Actually there is another design that doesn't need a per-client > > thread. Instead it uses a per-client memory block shared between the > > client and the wineserver. > > Alexandre already shot down the shared-memory solution, especially > disliking solutions that force the wineserver out of its single-threaded > model, like making it do locking and atomic operations for itself. You can do it all with non-blocking operations. The shared memory solution previously proposed had the disastrous property that a misbehaving client process could interfere with mutexes owned by other processes. It doesn't have to be that way if you use a separate shared memory block per client. This could be extended to other shared resources too. But I could believe that it is too complicated to be worth doing. Rob -- [Robert O'Callahan http://www.cs.cmu.edu/~roc 7th year CMU CS PhD student "Now when Joshua was near Jericho, he looked up and saw a man standing in front of him with a drawn sword in his hand. Joshua went up to him and asked, 'Are you for us or for our enemies?' 'Neither,' he replied, 'but as commander of the army of the LORD I have now come.'" - Joshua 5:13-14]

Feb. 24, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Ove Kaaven

On Sat, 24 Feb 2001, Robert O'Callahan wrote: > Ove Kaaven wrote: > > On Thu, 22 Feb 2001, Robert O'Callahan wrote: > > > Then on some other thread in the same address space > > > that serves wineserver requests: > > > > There's no such thread, and will never be such a thread (having the > > wineserver calling into client threads is an inherently unstable > > design). > > The wineserver need not depend on the client thread responding to its > (asynchronous) messages. In this case, if the client ignores the > messages, you get the same effect as if it never releases its mutex, > which is not a new failure mode. Sure it is, if the process isn't holding the mutex. Your design lets a process own the mutex without holding it. So if a process acquires it, then releases it, does something else for 10 minutes and then hangs, and some other process decides it should grab the mutex, then it should be allowed to do so, since the original process isn't holding it. But it can't... > Actually there is another design that doesn't need a per-client thread. > Instead it uses a per-client memory block shared between the client and > the wineserver. Alexandre already shot down the shared-memory solution, especially disliking solutions that force the wineserver out of its single-threaded model, like making it do locking and atomic operations for itself.

Feb. 24, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Robert O'Callahan

Ove Kaaven wrote: > On Thu, 22 Feb 2001, Robert O'Callahan wrote: > > Then on some other thread in the same address space > > that serves wineserver requests: > > There's no such thread, and will never be such a thread (having the > wineserver calling into client threads is an inherently unstable > design). The wineserver need not depend on the client thread responding to its (asynchronous) messages. In this case, if the client ignores the messages, you get the same effect as if it never releases its mutex, which is not a new failure mode. Actually there is another design that doesn't need a per-client thread. Instead it uses a per-client memory block shared between the client and the wineserver. This memory block holds the lock associated with each mutex, and the wineserver itself does the actions that I previously ascribed to the client thread. (It's a bit tricky because the wineserver never wants to block on acquiring the lock in shared memory; you have to set some flag in the lock word, wait for the client process to send you a message that it's released its mutex lock, and then try again.) As long as the wineserver maintains its own record of who owns each mutex, it need not actually trust any of the contents of the shared memory blocks. Other than not requiring separate client threads, this design also requires fewer process context switches. In the non-contended case, acquiring a mutex previously held by another process would require only a switch to the wineserver and back. Sorry I'm not familiar with the Wine code and I don't have time to dig into it, but I just want to urge you not to give up on finding a safe, very efficient solution. Rob -- [Robert O'Callahan http://www.cs.cmu.edu/~roc 7th year CMU CS PhD student "Now when Joshua was near Jericho, he looked up and saw a man standing in front of him with a drawn sword in his hand. Joshua went up to him and asked, 'Are you for us or for our enemies?' 'Neither,' he replied, 'but as commander of the army of the LORD I have now come.'" - Joshua 5:13-14]

Feb. 24, 2001

Printer setup dialog enhancement

by Duane Clark

Howdy, Since the landscape/portrait icons were added to the printer setup dialog a couple weeks ago, here is a minor patch so that the landscape/portrait radio buttons cause an immediate change of the icon. Duane Index: dlls/commdlg/printdlg.c =================================================================== RCS file: /home/wine/wine/dlls/commdlg/printdlg.c,v retrieving revision 1.37 diff -u -r1.37 printdlg.c --- dlls/commdlg/printdlg.c 2001/02/12 19:42:08 1.37 +++ dlls/commdlg/printdlg.c 2001/02/24 19:52:37 @@ -940,12 +940,20 @@ case rad1: /* Paperorientation */ if (lppd->Flags & PD_PRINTSETUP) + { lpdm->u1.s1.dmOrientation = DMORIENT_PORTRAIT; + SendDlgItemMessageA(hDlg, ico1, STM_SETIMAGE, (WPARAM) IMAGE_ICON, + (LPARAM)(PrintStructures->hPortraitIcon)); + } break; case rad2: /* Paperorientation */ if (lppd->Flags & PD_PRINTSETUP) + { lpdm->u1.s1.dmOrientation = DMORIENT_LANDSCAPE; + SendDlgItemMessageA(hDlg, ico1, STM_SETIMAGE, (WPARAM) IMAGE_ICON, + (LPARAM)(PrintStructures->hLandscapeIcon)); + } break; case cmb1:

Feb. 24, 2001

Re: SHLocalAlloc

by Eric Pouech

"J.Brown (Ender/Amigo)" wrote: > > I've been trying to get the Windows ME version of internet > explorer/explorer to load successfully under Wine.. However, it runs into > an unimplemented SHLocalAlloc function in shell32. > > This appears to be an undocumented function, or I'm looking in the > wrong place... has anyone got a patch or API specs on it? I don't think we'll get specs on this one... from the name (and the associated funcs SHLocalFree and SHLocalReAlloc) this sounds like function to alloc (near) memory on shell32 data segment what you could do is: - implement a stub for those 3 functions. Alloc is likely to take one or two parameters (size of block for sure and maybe some flags)... - to guess the number of parameters, run your program with the debugger, set a breakpoint on this function, and then disas the calling frame, where you should be able to validate the number of parameters... - once this is done you can map the call to either allocation on the process heap (or create a specific shell32 heap, and go from here...) under Wine (as it is today), it wouldn't bring nothing using a shell heap (except the memory cleanup on DLL unloading...) while you're at it, Free and ReAlloc must be writte too (don't implement one without the others) last point, since there is no lock function, the returned value of Alloc is likely to be the linear address of the memory block... but, once again this is a wild guess... you're on your own to do the reverse engineering A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Feb. 24, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Ove Kaaven

On Thu, 22 Feb 2001, Robert O'Callahan wrote: > Then on some other thread in the same address space > that serves wineserver requests: There's no such thread, and will never be such a thread (having the wineserver calling into client threads is an inherently unstable design).

Feb. 24, 2001

SHLocalAlloc

by J.Brown (Ender/Amigo)

I've been trying to get the Windows ME version of internet explorer/explorer to load successfully under Wine.. However, it runs into an unimplemented SHLocalAlloc function in shell32. This appears to be an undocumented function, or I'm looking in the wrong place... has anyone got a patch or API specs on it? Regards, Ender _________________________ ______________________________ | James 'Ender' Brown | "Where are we going, and why | | http://www.enderboi.com | am I in this handbasket?!?" | +-------------------------+------------------------------+

Feb. 24, 2001

Re: huge library renaming ?

by admiral coeyman

Group, > > Sure Debian handles everything perfectly, and sure other distros do the > same, but this *will* fail at the user level somewhere e.g. if they > want to install the stuff themselves, and e.g. need to uninstall the mess > cleanly again. > (I know my newbies ;-) > The main problem we'll have is always going to be on the user end. We're trying to get windows applications ported, thus we have to make the porting as painless for windows programmers as we can. Wine must be set up in the way that is simplest for the end user. If we plan this out properly, then wine will make porting easier that the complexities of using wine. Otherwise, wine will not be used. Renaming the libraries is the simplest solution. Even placing them in a custom directory, the user must take action to avoid name conflicts. That's additional work on the user end which adds to the learning curve. Is it reasonable to expect the end user to use rpath? > > Thus I'd rather see this solved in the best way possible. > And this is not the current solution IMHO. > I concur. > > The libraries are not clearly identified as being win32 stuff or wine stuff. > And this is wrong IMHO, regardless of whether "we normally do this or that > to avoid problems like that". > Which also makes them hard to remove. I've removed one set of libraries to give me drive space for the next set. We risk becomming like 'other monopolies' if we expect other people to work around problems with wine. Name conflicts are not the user's problem--they are ours. I've worked with dll conflicts just like this with a pair of HP devices under windows. End users wouldn't put the time into finding conflicts that we put into tracking that down.... > > It will fail. Somewhere. Sometime. > And the less total the failure, the harder the source will be to find.... -Robert 'Admiral' Coeyman -- http://www.corner.net/admiral/ May you live as long as you wish and age but a single day. [Telnet to telnet.corner.net]

Feb. 24, 2001

Re: huge library renaming ?

by Andreas Mohr

On Fri, Feb 23, 2001 at 03:47:39PM +0100, Bernhard Rosenkraenzer wrote: > On Fri, 23 Feb 2001, Ove Kaaven wrote: > > > > AFAIR there have been several naming conflicts with other projects > > > (libole, ...), and people who need to remove a previous Wine install > > > from their system manually have a rather hard time... > > > > Any reason for doing this? > > I can't think of any... > > > > The Debian packages work perfectly, without any potential for conflict. > > They install the dlls into /usr/lib/wine, do *not* put /usr/lib/wine into > > ld.so.conf, while Wine loads the dlls from /usr/lib/wine, not from > > /usr/lib (and Wine's own configure adds rpath stuff last time I looked) > > The Red Hat package does the same thing, but still I'd prefer renaming the > libraries for all the people who compile from source without knowing all > the details. > > You quickly get from "I'm a total newbie" to "I'm still a newbie, but I > know that basics and I've figured out I can install almost any program > from source by just typing "./configure --prefix=/usr; make install"!" > state. We shouldn't kill those users' normal libraries. [Yes, I know users > should in theory put all their stuff to /usr/local, but I haven't seen > many people who actually do] > > Either rename them, or make configure intelligent enough to do > /usr/lib/wine trickery automatically (if prefix=/usr) unless explicitly > told not to do it... Exactly. Renaming them is *much* cleaner. Sure Debian handles everything perfectly, and sure other distros do the same, but this *will* fail at the user level somewhere e.g. if they want to install the stuff themselves, and e.g. need to uninstall the mess cleanly again. (I know my newbies ;-) Thus I'd rather see this solved in the best way possible. And this is not the current solution IMHO. The libraries are not clearly identified as being win32 stuff or wine stuff. And this is wrong IMHO, regardless of whether "we normally do this or that to avoid problems like that". It will fail. Somewhere. Sometime. Andreas Mohr

Feb. 24, 2001

Re: ./dlls/libntdll.so: undefined reference to `PTHREAD_init_done'

by Gerald Pfeifer

On 23 Feb 2001, Alexandre Julliard wrote: >> Perhaps just some incomplete #ifdef ... #endif sequence? > Yep, here's a fix: > > Index: scheduler/pthread.c Yes, that fixes it. Thanks! Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Feb. 23, 2001

Re: ./dlls/libntdll.so: undefined reference to `PTHREAD_init_done'

by Alexandre Julliard

Gerald Pfeifer <pfeifer(a)dbai.tuwien.ac.at> writes: > I'm leaving for holidays very soon and have to proof-read some 60 exams > before that, so I won't be able to track this down, but perhaps one of > could fix the build failure seen on FreeBSD 4.2? > > Perhaps just some incomplete #ifdef ... #endif sequence? Yep, here's a fix: Index: scheduler/pthread.c =================================================================== RCS file: /opt/cvs-commit/wine/scheduler/pthread.c,v retrieving revision 1.11 diff -u -r1.11 pthread.c --- scheduler/pthread.c 2001/02/23 01:37:05 1.11 +++ scheduler/pthread.c 2001/02/23 22:27:07 @@ -18,6 +18,13 @@ #include "winbase.h" #include "thread.h" +static int init_done; + +void PTHREAD_init_done(void) +{ + init_done = 1; +} + /* Currently this probably works only for glibc2, * which checks for the presence of double-underscore-prepended * pthread primitives, and use them if available. @@ -86,13 +93,6 @@ #define MAX_KEYS 16 /* libc6 doesn't use that many, but... */ #define P_OUTPUT(stuff) write(2,stuff,strlen(stuff)) - -static int init_done; - -void PTHREAD_init_done(void) -{ - init_done = 1; -} void __pthread_initialize(void) { -- Alexandre Julliard julliard(a)winehq.com

Feb. 23, 2001

./dlls/libntdll.so: undefined reference to `PTHREAD_init_done'

by Gerald Pfeifer

I'm leaving for holidays very soon and have to proof-read some 60 exams before that, so I won't be able to track this down, but perhaps one of could fix the build failure seen on FreeBSD 4.2? Perhaps just some incomplete #ifdef ... #endif sequence? : rm -f libwine_unicode.so && ln -s unicode/libwine_unicode.so libwine_unicode.so rm -f libwine_uuid.a && ln -s ole/libwine_uuid.a libwine_uuid.a gmake[1]: Entering directory `/.amd_mnt/vexpert/files8/test/wine/miscemu' LD_LIBRARY_PATH="../unicode:$LD_LIBRARY_PATH" ../tools/winebuild/winebuild -fPIC -L../dlls -o wine.spec.c -spec wine.spec /usr/bin/gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -fno-strength-reduce -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o wine.spec.o wine.spec.c /usr/bin/gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -fno-strength-reduce -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o main.o main.c ld -r wine.spec.o main.o -o miscemu.o gmake[1]: Leaving directory `/.amd_mnt/vexpert/files8/test/wine/miscemu' /usr/bin/gcc -o wine miscemu/miscemu.o -L./dlls -lntdll -L./library -lwine -L./unicode -lwine_unicode -lncurses -lxpg4 -lm -lutil ./dlls/libntdll.so: undefined reference to `PTHREAD_init_done' gmake: *** [wine] Error 1 Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Feb. 23, 2001

Re: huge library renaming ?

by Andreas Mohr

On Fri, Feb 23, 2001 at 01:29:29PM +0100, Marcus Meissner wrote: > On Fri, Feb 23, 2001 at 08:31:50PM +0100, Andreas Mohr wrote: > > Hello all, > > > > one thing that occurred to me: > > Shouldn't we rename *all* Wine libraries to libwineXXX ? > > > > AFAIR there have been several naming conflicts with other projects > > (libole, ...), and people who need to remove a previous Wine install > > from their system manually have a rather hard time... > > > > Any reason for not doing this ? > > I can't think of any... > > > > If this is a good thing, then we should do this NOW, not when it's too late. > > > > The current drawbacks are just too much IMHO. > > Why not put them in /usr/lib/wine/ as suggested by the FHS? Hmm, yes that's one solution. However this doesn't solve naming conflicts, does it ? If we have libole and another project (was it gnumeric ?) uses the same name, then there really is nothing to our defense. If we choose to use libwine_xxx or something similar, then the other project looks pretty stupid if it somehow decides to choose the same name (which won't happen anyway). Putting the libraries in /usr/lib/wine instead seems to only solve the "easy uninstall" problem. Andreas Mohr

Feb. 23, 2001

Re: Perl/Wine extension for perusal

by Eric Pouech

Alexandre Julliard wrote: > > Eric Pouech <Eric.Pouech(a)wanadoo.fr> writes: > > > Do you really feel like a C compiler is less common than a perl binary > > under Windows ? I seriously doubt it... > > Anybody can install a perl binary on their machine, while nearly all > Windows compilers are commercial software... I know at least two free compilers... lcc and mingw to me the greatest obstable is to maintain the build environments for all the possible compilers (MSVC, Borland...) > > there's just one point that worries me. Let me explain how I ended up with > > XML. one thing I don't like is to have a "reference" file, but I don't > > know what it refers to. I think the test process should output both the result > > of the test (pure ASCII is fine) but also the environment of the test > > (Windows - if so version, even DLLs used... -, vs wine - which version, which > > DLLs are used, native vs builtin...) so that we could make usefull > > comparisons > > But none of this information is relevant for unit testing. The only > information that may be needed is the Windows version, and this only > for the few APIs that actually behave differently between > versions. And if you do your test scripts right you don't even need to > know about it. For instance, instead of doing something like: > > kernel32->MapViewOfFile(bad params); > print kernel32->GetLastError(); > > which would print different things on 95 and NT, you'd do: > > kernel32->MapViewOfFile(bad params); > $err = kernel32->GetLastError(); > if (kernel32->GetVersion() == win95) > { > print ($err == ERROR_INVALID_ADDRESS) ? "OK" : "failed: $err"; > } > else > { > print ($err == ERROR_INVALID_PARAMETER) ? "OK" : "failed: $err"; > } > > This way the script always prints the same thing no matter the Windows > version, and you can use a simple diff against a single reference file. this is utterly true for low level APIs (like kernel) however, testing a highler level API will depend on all the others DLL the tested DLL depends on... and here you may introduce some discrepencies... A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Feb. 23, 2001

IBM Websphere Studio

by David.Goodenough＠dga.co.uk

Having got Java running properly under Wine 20010216, now I return to the application that caused me to start looking at Java, Websphere Studio. I managed to get it to install with a few non-fatal messages, and it starts. It is very slow, but my first interest is to get it to work. It uses ImmAssociateContext and ImmGetContext, but currently these are stubs, and so FixMe's happen. Is anyone working in this area, if so have they written non-stub versions of these functions, alternatively does anyone know where the HIMC should be stored, and how I get to it from a HWND and then I can code them up.

Feb. 23, 2001

huge library renaming ?

by Andreas Mohr

Hello all, one thing that occurred to me: Shouldn't we rename *all* Wine libraries to libwineXXX ? AFAIR there have been several naming conflicts with other projects (libole, ...), and people who need to remove a previous Wine install from their system manually have a rather hard time... Any reason for not doing this ? I can't think of any... If this is a good thing, then we should do this NOW, not when it's too late. The current drawbacks are just too much IMHO. Andreas Mohr

Feb. 23, 2001