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

Re: Speeding up wineserver synchronization objects with shared memory

by Robert O'Callahan

Alexandre Julliard wrote: > For a mutex the basic definition is obviously that you can never have > two threads holding the mutex at the same time, and that when it is > released some other thread has a chance at grabbing it. This has to be > true no matter what the process does, including corrupting memory or > crashing. ... but not including "process randomly decides to call AcquireMutex again", presumably. So your concern is simply that if it's too simple to lock the mutex, then you have an unacceptably high probability of a runaway process accidentally locking the mutex, whereas you regard the probability of the process accidentally calling AcquireMutex again (or executing the protected control transfer on its own) as acceptably low. That seems reasonable. You can vastly reduce the probability of accidental locking by changing the client_locked field to an int and requiring a specific magic number to be stored there to signal a taken lock. You can vary the magic number per mutex, and store it in your auxiliary per-mutex data structures XORed with some known constant, to ensure that the magic number is never stored anywhere in memory except for the lock field. But if "executes a protected control transfer" is your gold standard of an action that is so unlikely to happen by chance it must be the intended behaviour of the process, then of course no other solution will be acceptable. > You also need to make sure nothing a process does should be > able to crash/hang the wineserver or another process (except if they > fight over the same mutex of course), I think we're there. > and then there is the small > matter of respecting the Win32 semantics... Yeah, but that doesn't seem fundamental --- the wineserver can always take ownership of the mutex itself when it needs to do a complex atomic operation. I'll let Gavriel work out the details :-). 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. 26, 2001

Re: winspool.drv initialization problem

by Ian Pilcher

Alexandre Julliard wrote: > > Sounds like importing winspool.drv in wineps creates a circular load > dependency (user32->gdi32->wineps->winspool->comctl32->user32). We > could probably be a bit more clever about loading wineps only when > really necessary; OTOH there is no reason for winspool.drv to require > comctl32. Something like this should fix it (completely untested, so > it's probably broken): > It appears to work, based on my admittedly incomplete test -- starting Lotus Notes and printing a document. No more invalid heap error messages. Any idea when Windows loads printer drivers? -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

Feb. 26, 2001

Re: undefined symbol: GetPrinterDataA

by Dimitrie O. Paun

From: "Ove Kaaven" <ovehk(a)ping.uio.no> > I'm not sure if wineps is completely dll-separated yet. BTW, do we have a list of dlls that are not yet dll-separated? (I know, if we had, you'd know about wineps...:) ) Better yet, how can we tell if a dll is separated? Would it be useful to create such a list, and maybe list for each of the dlls in there, why there aren't separated yet? -- Dimi.

Feb. 26, 2001

winspool.drv initialization problem

by Ian Pilcher

The saga continues! I've gotten my modified version of the PostScript driver to load, but it seems to causing/exposing another problem. WINPROC_GetPtr is being called befor WINPROC_Init during Wine initialization. The call to WINPROC_GetPtr results from a call to LoadLibraryExA ("COMCTL32.DLL" ...); here is the stack: #0 HEAP_GetPtr (heap=0) at heap.c:217 #1 0x40093514 in HeapValidate (heap=0, flags=0, block=0x408ffc67) at heap.c:1508 #2 0x4081c93f in WINPROC_GetPtr () from /usr/lib/wine/libuser32.so #3 0x4081cbaa in WINPROC_SetProc () from /usr/lib/wine/libuser32.so #4 0x407e280d in RegisterClassA () from /usr/lib/wine/libuser32.so #5 0x40900058 in ANIMATE_Register () from /usr/lib/wine/libcomctl32.so #6 0x40906412 in COMCTL32_LibMain () from /usr/lib/wine/libcomctl32.so #7 0x400814e8 in PE_InitDLL () from /usr/lib/wine/libntdll.so #8 0x4007d0f9 in MODULE_InitDLL () from /usr/lib/wine/libntdll.so #9 0x4007d216 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #10 0x4007f364 in LoadLibraryExA () from /usr/lib/wine/libntdll.so #11 0x4007f916 in LoadLibraryA () from /usr/lib/wine/libntdll.so #12 0x40975772 in WINSPOOL_EntryPoint () from /usr/lib/wine/libwinspool.drv.so #13 0x400814e8 in PE_InitDLL () from /usr/lib/wine/libntdll.so #14 0x4007d0f9 in MODULE_InitDLL () from /usr/lib/wine/libntdll.so #15 0x4007d216 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #16 0x4007d1f0 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #17 0x4007f364 in LoadLibraryExA () from /usr/lib/wine/libntdll.so #18 0x4007f916 in LoadLibraryA () from /usr/lib/wine/libntdll.so #19 0x4087206b in MAIN_GdiInit () from /usr/lib/wine/libgdi32.so #20 0x400814e8 in PE_InitDLL () from /usr/lib/wine/libntdll.so #21 0x4007d0f9 in MODULE_InitDLL () from /usr/lib/wine/libntdll.so #22 0x4007d216 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #23 0x4007d1f0 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #24 0x4007d1f0 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #25 0x4007d1f0 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #26 0x4007d1f0 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #27 0x4007d1f0 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #28 0x400c758c in start_process () from /usr/lib/wine/libntdll.so #29 0x400caeed in SYSDEPS_DoCallOnStack () from /usr/lib/wine/libntdll.so #30 0x400caf97 in SYSDEPS_CallOnStack () from /usr/lib/wine/libntdll.so #31 0x400cb03a in SYSDEPS_SwitchToThreadStack () from /usr/lib/wine/libntdll.so #32 0x400c79d7 in PROCESS_InitWine () from /usr/lib/wine/libntdll.so #33 0x804b213 in main () #34 0x4027ff55 in __libc_start_main (main=0x804b1f8 <main>, argc=1, ubp_av=0xbffff9d4, init=0x8048728 <_init>, fini=0x804b25c <_fini>, rtld_fini=0x4000e3e4 <_dl_fini>, stack_end=0xbffff9cc) at ../sysdeps/generic/libc-start.c:129 This is way out of my depth! -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

Feb. 26, 2001

Re: undefined symbol: GetPrinterDataA

by Ove Kaaven

On Sun, 25 Feb 2001, Ian Pilcher wrote: > 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? I'm not sure if wineps is completely dll-separated yet. In any case, there is an IMPORTS = ... line in wineps/Makefile.in that should be added to.

Feb. 26, 2001

Re: Re: undefined symbol: GetPrinterDataA

by Eric Pouech

>wineps : > ># Generated automatically from Makefile.in by configure. >TOPSRCDIR = ../.. >TOPOBJDIR = ../.. >SRCDIR = . >MODULE = wineps >SOVERSION = 1.0 >ALTNAMES = wineps16 >IMPORTS = user32 gdi32 kernel32 ntdll in this case, just add winspool.drv to the IMPORT list in the Makefile.in, rerun configure, and it should work. (If Alexandre didn't convert the Makefile.in for dll separation, there should be some good reasons... like using non exported symbols... which would require much more work) A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Feb. 26, 2001

Re: undefined symbol: GetPrinterDataA

by gerard patel

At 08:30 PM 25/02/2001 +0600, you wrote: >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 Note the differences between the Makefile for common dialog (where this works) and the Makefile for wineps : commdlg : # Generated automatically from Makefile.in by configure. TOPSRCDIR = ../.. TOPOBJDIR = ../.. SRCDIR = . MODULE = comdlg32 ALTNAMES = commdlg EXTRALIBS = $(LIBUUID) LDDLLFLAGS = -Wl,-Bsymbolic SYMBOLFILE = $(MODULE).tmp.o (...) wineps : # Generated automatically from Makefile.in by configure. TOPSRCDIR = ../.. TOPOBJDIR = ../.. SRCDIR = . MODULE = wineps SOVERSION = 1.0 ALTNAMES = wineps16 IMPORTS = user32 gdi32 kernel32 ntdll C_SRCS = \ (...) I think that the mechanism is not working because dlls separation is not done for wineps ;-) Gerard

Feb. 26, 2001

Re: undefined symbol: GetPrinterDataA

by lawson_whitney＠juno.com

On Mon, 26 Feb 2001 lawson_whitney(a)juno.com wrote: > > > Hmmm, ... from "nm libwinspool.drv.so": > > 00012f58 D __wine_dllexport_winspool_GetPrintProcessorDirectoryA > 00012f58 D __wine_dllexport_winspool_GetPrintProcessorDirectoryW > 00012f58 D __wine_dllexport_winspool_GetPrinterA > 00012f58 D __wine_dllexport_winspool_GetPrinterDataA > 00012f58 D __wine_dllexport_winspool_GetPrinterDataExA > 00012f58 D __wine_dllexport_winspool_GetPrinterDataExW > 00012f58 D __wine_dllexport_winspool_GetPrinterDataW > > Try: > > import winspool > > instead of winspool.drv, and see if that helps. Just a guess. > Nope, that doesn't work. However, I can import winspool.drv to a winelib program, and GetPrinterDataA resolves to a stub in the spec.o file. Lawson | We apologize if this message has reached you in error. | Save the Planet, Save the Trees! Advertise via E mail. ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

Feb. 26, 2001

Re: various config files for various applications

by Eric Pouech

Martin Pilka wrote: > > 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. I don't think we need to export the PROFILE functions... just let the calling code check the keys under "<appname>/key" if it exists and then fallback to simply "key" if it doesn't > 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. GetModuleFileName(NULL, buffer, sizeof(buffer)); should do... A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Feb. 26, 2001

Re: undefined symbol: GetPrinterDataA

by lawson_whitney＠juno.com

On Sun, 25 Feb 2001, Ian Pilcher wrote: > > If only it were that simple. I've rebuilt from scratch, with a clean > source tree. > Hmmm, ... from "nm libwinspool.drv.so": 00012f58 D __wine_dllexport_winspool_GetPrintProcessorDirectoryA 00012f58 D __wine_dllexport_winspool_GetPrintProcessorDirectoryW 00012f58 D __wine_dllexport_winspool_GetPrinterA 00012f58 D __wine_dllexport_winspool_GetPrinterDataA 00012f58 D __wine_dllexport_winspool_GetPrinterDataExA 00012f58 D __wine_dllexport_winspool_GetPrinterDataExW 00012f58 D __wine_dllexport_winspool_GetPrinterDataW Try: import winspool instead of winspool.drv, and see if that helps. Just a guess. Lawson By the accident of what statisticians call birth... - Richard Fariña ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

Feb. 26, 2001