This is the mail archive of the
mailing list for the Cygwin project.
Re: [ANNOUNCEMENT] Update: mintty 2.1.2
- From: "Houder" <houder at xs4all dot nl>
- To: cygwin at cygwin dot com
- Date: Mon, 27 Jul 2015 22:58:26 +0200
- Subject: Re: [ANNOUNCEMENT] Update: mintty 2.1.2
- Authentication-results: sourceware.org; auth=none
- References: <55B2B644 dot 8010506 at towo dot net> <be0351be5e3aa7b7ba980fc25f9cce0c dot squirrel at oude-webmail dot xs4all dot nl> <e731c3536912df8739a630e17ab5d8ec dot squirrel at oude-webmail dot xs4all dot nl> <10d3a46960f8ec71784bdf15a0ee6b58 dot squirrel at oude-webmail dot xs4all dot nl> <1e17310bb0689632cd19fd7648bd9907 dot squirrel at oude-webmail dot xs4all dot nl> <55B5109A dot 4010700 at towo dot net> <4afa07869c07cd6a57441b221ca5fdf7 dot squirrel at oude-webmail dot xs4all dot nl> <994a85838723f326327975650e214a79 dot squirrel at oude-webmail dot xs4all dot nl> <20bcab2c7a6ca2aa1990f8a421b674ae dot squirrel at oude-webmail dot xs4all dot nl> <55B66DE5 dot 40104 at towo dot net> <20150727192935 dot GA12449 at calimero dot vinschen dot de> <8ee33951118ac7ed81bb3a20e658950c dot squirrel at oude-webmail dot xs4all dot nl>
>> 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
>>> it is only the last of the flags, â?? Use visual styles on windows and
>>> 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: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple