This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ANNOUNCEMENT] Update: mintty 2.1.2

>> On Jul 27 19:44, Thomas Wolff wrote:
>>> Am 27.07.2015 um 17:58 schrieb Houder:
>>> >Hi Thomas,
>>> >
>>> >Moving load_dwm_funcs() did the trick ...
>>> >
>>> >
>>> Thanks again for your analysis.
>>> In Control Panel â?? Performance Information and Tools â?? Adjust visual
>>> effects,
>>> it is only the last of the flags, â?? Use visual styles on windows and
>>> buttons,
>>> that makes the difference; if deselected, mintty crashes if called from a
>>> console or somehow doubly isolated by
>>> (setsid mintty &).
>>> Apparently, LoadLibrary does not propagate to a forked thread;
>> Forked process, I hope :)
>> No, it doesn't.  Loading a library is purly process lokal on Windows.
>> Cygwin DLLs(*) have special startup code which allows to register them
>> in the process and to re-load them in the child process at fork time.
>> (*) Actually, any DLL using this special entry point would work.
>>     Native Windows DLLs just don't, usually :}
> Ha, Corinna, you are the expert here, of course :-)
> From MSDN I learned (LoadLibrary() ):
>     "Module handles are not global or inheritable. A call to LoadLibrary by one
>      process does not produce a handle that another process can use in calling
>      GetProcAddress (as an example). The other process must make its OWN call to
>      LoadLibrary for the module before calling GetProcAddress"
> Well, ok, alright, that makes sense ...
> However, if pDwmIsCompositionEnabled() returns 1, which will be the case if one
> has selected 'Windows 7' i.s.o. 'Windows Basic' (Personalization),
>     as an example ...
> it turned out to be possible to invoke load_dwm_funcs() (i.e. LoadLibrary() )
> before the fork to a child withOUT a crash of the child !!!!!
>     After all, it is Windows ?????
> No doubt, it will have been documented somewhere (DWM) ...

As an follow-up:

The "companion" to pDwmIsCompositionEnabled(), i.e. pDwmExtendFrameIntoClientArea()
made the child crash -- in update_glass(), Thomas, when 'Windows Basic' had been

Both "function pointers" always showed the same addresses, but when 'Windows Basic'
had been selected, they turned out to be a jump into 'void'.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]