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

Re: undefined symbol: GetPrinterDataA

by Ian Pilcher

Eric Pouech wrote: > > in this case, just add winspool.drv to the IMPORT list in the > Makefile.in, rerun configure, and it should work. That did the trick. Thanks! -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

Feb. 26, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Alexandre Julliard

"Robert O'Callahan" <roc+(a)cs.cmu.edu> writes: > Of course it has to be 100% reliable, but since you're dealing with > failing processes it's not 100% clear what 100% reliability is. Anyway, I > think 100% reliability is possible for any plausible definition. 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. 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), and then there is the small matter of respecting the Win32 semantics... Actually it is the last constraint that is the main problem. You can certainly provide some kind of mutexes using shared memory; but we don't need just 'some kind', we need Win32 mutexes. This means a mutex is identified by a handle that can be manipulated by CloseHandle or DuplicateHandle; it means you need to detect and handle abandoned mutexes; it means you must support WaitForMultipleObjects, including the 'all' case where you cannot grab the mutex unless all objects are signaled; all things that I didn't see in your implementation ;-) -- Alexandre Julliard julliard(a)winehq.com

Feb. 26, 2001

Re: undefined symbol: GetPrinterDataA

by lawson_whitney＠juno.com

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? > -- > ======================================================================== > Ian Pilcher pilcher(a)concentric.net > ======================================================================== 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. Maybe a make clean and a make would do better and quicker for now than make depend. or rm wineps.spec.* *.o and try make again. Lawson All's well that ends. - Ben Franklin ---cut here ________________________________________________________________ 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: Speeding up wineserver synchronization objects with shared memory

by Robert O'Callahan

Alexandre Julliard wrote: > 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. Actually, if you use a per-client shared memory block, then the wineserver can execute ownership changes itself, without any cooperation from the client, whenever the client does not actually have the mutex locked. Your problem goes away. > 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. Of course it has to be 100% reliable, but since you're dealing with failing processes it's not 100% clear what 100% reliability is. Anyway, I think 100% reliability is possible for any plausible definition. The following protocol looks good for the simpler one-thread-per-client-process case. It easily generalizes to the multiple threads per process case by treating each thread as a separate process, except then threads can stomp on their sibling threads' mutexes, but this is not new. (You could probably build an optimized version of the protocol for the multithread case, though.) // indices identify the client. Client i can only access variables // indexed by i, the wineserver can access all bool client_locked[N]; bool client_is_owner[N]; bool notify_wineserver_on_release[N]; // client Acquire(i) { retry: atomically { if (client_is_owner[i] && !client_locked[i]) { client_locked[i] = true; return; } } if (!client_is_owner[i]) { wineserver->GiveThisProcessOwnership(i); // blocking goto retry; } else if (client_locked[i]) { // fail; deadlocked } } Release(i) { int notify; atomically { notify = notify_wineserver_on_release[i]; client_locked = false; notify_wineserver_on_release[i] = false; } if (notify) { wineserver->NotifyUnlocked(); // nonblocking } } // wineserver int true_owner; bool requested_ownership[N]; GiveThisProcessOwnership(i) { if (true_owner != i) { bool granted; atomically { // take lock from owner if we can if (!client_locked[true_owner]) { client_is_owner[true_owner] = false; granted = true; } else { notify_wineserver_on_release[i] = true; granted = false; } } if (granted) { // give lock to the requester true_owner = i; atomically { if (client_locked[true_owner]) { // process is corrupt, it can't have the lock already } else { client_is_owner[true_owner] = true; } } ReplyToProcess(i); // nonblocking } else { // let the requester wait requested_ownership[i] = true; } } } NotifyUnlocked() { for (i = 0; i < N; i++) { if (requested_ownership[i]) break; } if (i == N) return; // no-one cares bool granted; atomically { // try to get lock from owner, as above if (!client_locked[true_owner]) { client_is_owner[true_owner] = false; granted = true; } else { notify_wineserver_on_release[true_owner] = true; granted = false; } } if (granted) { // give lock bool notify = false; true_owner = i; requested_ownership[i] = false; for (i = 0; i < N; i++) { if (requested_ownership[i]) notify = true; } atomically { if (client_locked[true_owner]) { // process is corrupt, it can't have the lock already } else { client_is_owner[true_owner] = true; notify_wineserver_on_release[true_owner] = notify; } } ReplyToProcess(i); // nonblocking } } Pack the client_locked and client_is_owner variables into a single word per client. Implement "atomically" with atomic compare-and-swap. There's no wineserver to client signalling (except for unblocking the client's blocking call). The wineserver never blocks. The wineserver never reads any values from client_is_owner or notify_wineserver_on_release. It only ever reads the client_locked value for the true_owner process. The only vulnerability that I can see is if a client process unlocks the mutex and then a unlucky stray write due to some bug subsequently writes 'true' to its client_locked field. Is that a significant increase in risk over the client simply hanging while it has the mutex locked? NB there may well be bugs in the above code. This kind of code is hard to get right. (Someone who knows how to drive a model checking tool could verify it without much difficulty, though.) If no-one needed fast mutexes it definitely wouldn't be worth doing. I'm advocating this just because a) someone does need them and b) I can't let the claim "it can't be done 100% safely this way" go unchallenged :-). 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: 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: (+82 11 430 0425)

Feb. 26, 2001

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