Mail Archives: cygwin/2005/05/26/14:20:49
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/
- Raw text -