win16 printer driver discovery
Hi all, http://support.microsoft.com/support/kb/articles/Q133/0/90.asp A Windows 95 printer driver should only use thunks in calls to the ABORTDOC, ENDDOC, NEWFRAME, NEXTBAND and STARTDOC subfunctions of its Control() function. If a Windows 95 printer driver thunks in any call other than a ABORTDOC, ENDDOC, NEWFRAME, NEXTBAND or STARTDOC call, the Windows graphics device interface (GDI) may become reentrant. Because the GDI was never designed to be reentrant, the system may be left in an unstable state or errors may occur. If the printer driver thunks or yields, this causes the Win16Mutex system semaphore to be released and another thread may enter the GDI. I'm not sure whether this is related to our Win16 printer driver problem. Does this provide any clue as to how we're allowed to solve our win16 printer driver deadlocks ? This description smells to me as if Win95 doesn't have any form of GDI object locking... Andreas Mohr
Re: win16 printer driver discovery
Andreas Mohr [EMAIL PROTECTED] writes: If a Windows 95 printer driver thunks in any call other than a ABORTDOC, ENDDOC, NEWFRAME, NEXTBAND or STARTDOC call, the Windows graphics device interface (GDI) may become reentrant. Because the GDI was never designed to be reentrant, the system may be left in an unstable state or errors may occur. If the printer driver thunks or yields, this causes the Win16Mutex system semaphore to be released and another thread may enter the GDI. I'm not sure whether this is related to our Win16 printer driver problem. Does this provide any clue as to how we're allowed to solve our win16 printer driver deadlocks ? No; what this says is that under Win95 GDI holds the Win16Mutex (which is not surprising since GDI is still mostly 16-bit code). This is also the reason Win95 GDI can run 16-bit drivers. If you want to do the same thing in Wine you have to make all of GDI (and most of USER too) hold the Win16 mutex all the time, which is not very nice... -- Alexandre Julliard [EMAIL PROTECTED]