X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-6.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Message-ID: <4DE579AC.1040007@redhat.com> Date: Tue, 31 May 2011 17:28:44 -0600 From: Eric Blake User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.10 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Why does windows have such probs with dynamically loaded libs? References: <20110529233841 DOT GC5283 AT ednor DOT casa DOT cgf DOT cx> <20110530174649 DOT GB14225 AT ednor DOT casa DOT cgf DOT cx> <4DE5773D DOT 9040008 AT tlinx DOT org> In-Reply-To: <4DE5773D.9040008@tlinx.org> OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig8448B407C9AA2A879ED62300" X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com --------------enig8448B407C9AA2A879ED62300 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/31/2011 05:18 PM, Linda Walsh wrote: > Other than the stock answer of poor design, it seems loading a > dynamically linked library at run-time shouldn't be a difficult task. Poor design of Windows, not of cygwin. > When Cygwin forks, how different is it from linux (other than stock > answer of 'alot'), i.e. Does it create a new process and load the same > static libs in, then have problems with dynamically loaded libs because > they aren't recorded in the static binary? Windows does _not_ have a native copy-on-write fork operation. Linux does. When Linux forks, it merely needs mark all pages as copy-on-write, then both the parent and the child share the same memory image until one or the other execs and gives up that memory. When cygwin forks, it must manually hand-copy every single page of memory from the parent into the child, including pages that can't normally be copied by user space apps but are instead allocated by Windows (such as dlls). How? By loading the same dlls in the child as in the parent, and _hoping_ that windows loads them at the same address as the parent. > Does cygwin actually copy, or attempt to setup COW pages that are not > from static libs? If so, wouldn't that catch dynamically loaded libs? Windows doesn't support COW pages between a parent process and its spawned child, at least not in the windows subsystem. And the documentation of the various subsystems lacking to the point that cygwin has no way of reproducing the subsystem setup utilized by Interix for its fork implementation (Interix doesn't have to care about interaction with the windows subsystem). So yes, cygwin really is stuck with copying data, and for the data not directly manageable by user space, cygwin has to go to great lengths to circumvent random behaviors introduced by newer windows versions to try to get dlls loaded into the same location. > This may be complete insanity, but given the low level of support of MS's > own Unix subsystem, I wonder if they might be persuaded (if it was > desired) to lend more help or hooks for cygwin to do its magic reliably.= =20 Put yourself in Microsoft's shoes - why would you want to make it easier for free software to replace your proprietary software? Once you answer that question, then you can see why it is unlikely that Cygwin will ever have enough weight to convince MS to make our lives easier. --=20 Eric Blake eblake AT redhat DOT com +1-801-349-2682 Libvirt virtualization library http://libvirt.org --------------enig8448B407C9AA2A879ED62300 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJN5XmsAAoJEKeha0olJ0Nqe0gIAJFmrlv+2UuvfJw6HHK1aoGO jif2gFFxnuW7ITVzGAOUm4hWr9AxFToJIwot8LbbhYDlTab5Vrd9IX9K75dWNh45 Ngc7a/c8FPxT76f4WbNDaKDLaKy1j4W3xxDEGHJoz/31tYifEHzM5Of9O39KVeW9 4oq4fAxJyN0RVDAL0hrIWGKGo6MSwHiKa+vPng9gL6/iurTSyKw1i6FkKrHdU9YE aBlpN4LfiuWPWcdEV6GhWrfoGvDa08HPEVTGgW06evFG8/lGCVrTKEIcrLy2Nmnl cbMGNre8qO8S8ZdCk5Lq222M9+IaYSfLEKLUWGRMu94qA1FBGj03luXZ0H7rDLw= =7qUx -----END PGP SIGNATURE----- --------------enig8448B407C9AA2A879ED62300--