Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm 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 Subject: Re: Questions on patching dcrt0.cc From: Max Kaehn To: cygwin AT cygwin DOT com In-Reply-To: <20050526180031.GD9111@trixie.casa.cgf.cx> References: <1117064831 DOT 5390 DOT 174 DOT camel AT fulgurite> <20050526145843 DOT GB5619 AT trixie DOT casa DOT cgf DOT cx> <1117129479 DOT 5390 DOT 225 DOT camel AT fulgurite> <20050526180031 DOT GD9111 AT trixie DOT casa DOT cgf DOT cx> Content-Type: text/plain Message-Id: <1117131635.5390.245.camel@fulgurite> Mime-Version: 1.0 Date: Thu, 26 May 2005 11:20:35 -0700 Content-Transfer-Encoding: 7bit X-Spam-Not-Checked: Messages over 100K or from internal Electric Cloud machines are not checked X-IsSubscribed: yes On Thu, 2005-05-26 at 11:00, Christopher Faylor wrote: > Rather than talking about "MSVC code" being "acceptable", please just > provide a specific indication of *what* you are trying to do. Where do > you want to put this code? Look at the directories available in winsup > and tell us where you want to put this. I want to make it as easy as possible for cygwin developers who are working with the cygwin initialization code that they don't break this functionality. It seems to me that a subdirectory of winsup/testsuite would be good for this. You remarked in semi-private E-mail that "we won't be putting any MSVC source in the winsup directory", and I want to respect the policies of the cygwin project, so I'm asking where you would like a program of this nature. A new subdirectory of "contrib" might also be appropriate. Wherever it goes, I want to put comments in the patches I will submit for dcrt0.cc and how-programming.texinfo that refer the reader to this test program. > As I mentioned in semi-private email, the fact that you can get cygwin > working by dynamic linking doesn't mean that it can necessarily be used > by proprietary programs if by "proprietary" you mean "non open source". As I understand it, this clause in the cygwin license: --- Red Hat sells a special Cygwin License for customers who are unable to provide their application in open source code form. For more information, please see: http://www.redhat.com/software/tools/cygwin/, or call 866-2REDHAT ext. 3007 --- allows vendors of proprietary, non-open source software to pay for the privilege of linking to the GPL. As it states at http://www.redhat.com/software/cygwin/ : --- A Cygwin Contract provides customers with: * The ability to distribute customer's applications without being bound by the GPL. Therefore, customers are not required to provide their applications in open source code form. --- If I'm missing something, please let me know: it looks to me like there's a very nice setup here of: * If your program is proprietary, you must pay for the privilege of linking to cygwin1.dll. * If your program is open source, you can link to cygwin1.dll for free. To my eyes, this is a win-win proposition for the open source community. > ? Why wouldn't signal handling just work? A program would have to call > "GetProcAddress" to retrieve the address of any signal function that it > wanted to use but it should just work if all of the appropriate stuff is > initialized in cygwin. As far as I can tell, the main thread needs to be running an interruptible cygwin function in order to receive signals from cygwin. This works fine if your main routine is waiting on sleep() or pthread_cond_timedwait(), but not if it's busy in the Microsoft libraries. Spawning an additional thread to call sigwait() will minimize the cost of integration of this functionality into existing programs. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/