From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42103 invoked by alias); 27 Jul 2015 20:44:25 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 42034 invoked by uid 89); 27 Jul 2015 20:44:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: lb1-smtp-cloud6.xs4all.net Received: from lb1-smtp-cloud6.xs4all.net (HELO lb1-smtp-cloud6.xs4all.net) (194.109.24.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 27 Jul 2015 20:44:23 +0000 Received: from oude-webmail.xs4all.nl ([194.109.26.21]) by smtp-cloud6.xs4all.net with ESMTP id xYkL1q0050TK8Cq01YkL9H; Mon, 27 Jul 2015 22:44:20 +0200 Received: from 83.162.234.136 (SquirrelMail authenticated user incog) by oude-webmail.xs4all.nl with HTTP; Mon, 27 Jul 2015 22:44:20 +0200 Message-ID: <8ee33951118ac7ed81bb3a20e658950c.squirrel@oude-webmail.xs4all.nl> In-Reply-To: <20150727192935.GA12449@calimero.vinschen.de> References: <55B2B644.8010506@towo.net> <10d3a46960f8ec71784bdf15a0ee6b58.squirrel@oude-webmail.xs4all.nl> <1e17310bb0689632cd19fd7648bd9907.squirrel@oude-webmail.xs4all.nl> <55B5109A.4010700@towo.net> <4afa07869c07cd6a57441b221ca5fdf7.squirrel@oude-webmail.xs4all.nl> <994a85838723f326327975650e214a79.squirrel@oude-webmail.xs4all.nl> <20bcab2c7a6ca2aa1990f8a421b674ae.squirrel@oude-webmail.xs4all.nl> <55B66DE5.40104@towo.net> <20150727192935.GA12449@calimero.vinschen.de> Date: Mon, 27 Jul 2015 20:44:00 -0000 Subject: Re: [ANNOUNCEMENT] Update: mintty 2.1.2 From: "Houder" To: cygwin@cygwin.com User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00415.txt.bz2 > 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) ... Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple