From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9007 invoked by alias); 25 Jul 2013 13:11:17 -0000 Mailing-List: contact cygwin-developers-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com Received: (qmail 8995 invoked by uid 89); 25 Jul 2013 13:11:17 -0000 X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_50,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RDNS_NONE,SPF_PASS,TW_CG autolearn=no version=3.3.1 Received: from Unknown (HELO out1-smtp.messagingengine.com) (66.111.4.25) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 25 Jul 2013 13:11:16 +0000 Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B847420F21 for ; Thu, 25 Jul 2013 09:11:08 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Thu, 25 Jul 2013 09:11:08 -0400 Received: from [158.147.137.108] (unknown [158.147.137.108]) by mail.messagingengine.com (Postfix) with ESMTPA id 78108680092; Thu, 25 Jul 2013 09:11:08 -0400 (EDT) Message-ID: <51F123EB.9000900@cwilson.fastmail.fm> Date: Thu, 25 Jul 2013 13:11:00 -0000 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: cygwin-developers@cygwin.com Subject: Re: MSYS mode (continue) References: <20130704091632.GM5118@calimero.vinschen.de> <20130704101046.GN5118@calimero.vinschen.de> <20130704103708.GA12995@calimero.vinschen.de> <20130704121617.GC12995@calimero.vinschen.de> <20130704163612.GA4729@ednor.casa.cgf.cx> <20130705090704.GB4009@calimero.vinschen.de> <20130705164230.GA7282@ednor.casa.cgf.cx> <20130711111744.GG15346@calimero.vinschen.de> In-Reply-To: <20130711111744.GG15346@calimero.vinschen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-07/txt/msg00028.txt.bz2 On 7/11/2013 7:17 AM, Corinna Vinschen wrote: > The hooking itself is the lesser problem. What I'm rather wondering > about is how the MSYS helper DLL comes into action. > > Ideally, MSYS executables would actually be Cygwin executables, linked > against the Cygwin DLL. The advantage being that the executable could > run in an MSYS and a Cygwin environment, whatever it happens to be > dropped into. > > The MSYS DLL could be loaded from an MSYS specific crt0.o, which tries > to load the MSYS DLL dynamically. Either loading the MSYS DLL works or > it doesn't, but if it works, it could just call cygwin_internal in it's > dll_entry function to set up the hooking mechanism. If it fails, the > executable works as a plain Cygwin executable. I dunno. Back in 2009, I (re)built and updated to then-current EVERY single element of MinGW.org's msys distribution. There were a LOT of patches required, which were not required on cygwin. Some, to be sure, were because both cygwin and the app in question had progressed since the msys fork circa cygwin 1.3.x -- for instance, OpenSSH. As cygwin itself gained new capabilities, the OpenSSH code adapted -- eliminating certain workarounds it had previously implemented which were no longer necessary on newer cygwin. However, as MSYS was frozen in time, those workarounds had to be manually patched back in. In the cygwin-as-msys scenario, *those* sorts of things would not be necessary, because cygwin-as-msys would be just as "current" as regular cygwin; in fact, sharing the same cygwin1.dll. However, many of the patches were to handle differences inherent in the environment. For example, msys-make kept the "allow X:/foo/bar paths in rules" patch, which cgf long ago removed from cygwin-make. The reason for that change is obvious; msys is intended to make compiling with native mingw[64,.org] compilers easier, and so you run into dos-style paths a lot more often, even when you are nominally on the "unix" side of the fence as with (msys-)make. Or, as an example, I suspect msys users would prefer a "native windowing" tcl/tk -> gdb/insight, not the X11-windowing version we now ship. However, we (cygwin) long ago made the decision that we would not muck with our X11 tcl/tk's directory structure to accomodate a side-by-side GDI version simultaneously installed. So "we" can't actually provide both (one X11 that is probably preferred by "real" cygwin users, and one GDI that the cygwin-as-msys users would prefer), without a lot of rework in our existing tcl/tk offerings. A final example: msys (and, I presume, cygwin-as-msys) deliberate dumbs down the permission model to the old mechanism used by cygwin on FAT: everything is owned by $current-user, every file is always readable by everybody. Every directory is rx by everybody. The DOS read-only flag is used to control +w/-w for all users. But some apps (and our config-foo scripts!) check those settings; for instance, ssh.exe wants to ensure that ~/.ssh is not writable by anybody except the owner. That stuff had to be patched out, to work on msys. Well, we don't want $real-cygwin's ssh.exe to act in such an insecure manner, but then cygwin-as-msys users lose out, unless then only use the ssh.exe from their parallel installation of $real-cygwin. > Alternatively, MSYS crt0.o itself provides all the necessary functionality, > which might be a lot easier to implement. It could call cygwin_internal > and provide the necessary callbacks and it would be linked against the > Cygwin DLL "just so". I think you would actually need an entirely separate distribution of tools, each compiled specifically for the "new" platform -- so they could directly link against the msys-modifier DLL (as well as cygwin1.dll). The good news is, there's already a project out there to handle distributing and maintaining a collection of msys ports -- "we" don't have to do it. -- Chuck