Discussion:
Distributing Cygwin-based software
Soeren Nils Kuklau
2004-10-14 19:32:16 UTC
Permalink
Hi,

we're working on a cross-platform server daemon, and on the Windows
side, we have chosen to use Cygwin for POSIX compatibility reasons. We
have run into several issues on the way:

1) We've looked at `cygrunsrv', and it appears to be a convenient tool
for setting our daemon up as an NT service. For people that do not have
Cygwin installed, can we just distribute `cygrunsrv' as stand-alone tool
to go inside our daemon's working directory?

2) Similarly, what about distributing `cygwin1.dll' - I am aware of the
"dllpath hell" problem this causes; what is the preferred option here?

3) Cross-posting from the other mail: I also found rather little
documentation on `cygrunsrv'. The bundled README file comprehensively
lists possible arguments, but appears to assume that the daemon to be
run is inside the Cygwin root directory (such as C:\Cygwin), whereas we
believe it would make more sense to distribute our package for
installation inside Windows' Program Files folder. Does `cygrunsrv'
understand Windows-like paths, or can we rely on a `/cygdrive/c/Program\
Files/'-like path structure?

4) Finally, a coding issue: We use SHA1 hashing for passwords. During
linking, we get:

obj/alstring.o(.text+0x316):alstring.c: undefined reference to `_SHA1'

LDFLAGS are: -lpthread -lcrypto

Are we missing a specific Cygwin package?

Any help would be greatly appreciated.

TIA,
--
Soeren 'Chucker' Kuklau
Christopher Faylor
2004-10-14 19:54:04 UTC
Permalink
Post by Soeren Nils Kuklau
Hi,
we're working on a cross-platform server daemon, and on the Windows
side, we have chosen to use Cygwin for POSIX compatibility reasons. We
1) We've looked at `cygrunsrv', and it appears to be a convenient tool
for setting our daemon up as an NT service. For people that do not have
Cygwin installed, can we just distribute `cygrunsrv' as stand-alone tool
to go inside our daemon's working directory?
Again, as was answered in the cygwin-licensing mailing list, the tool is
distributed under the GPL. I don't understand why you are asking this
question again. Comply with the GPL and you can do whatever you want
with the code.
Post by Soeren Nils Kuklau
2) Similarly, what about distributing `cygwin1.dll' - I am aware of the
"dllpath hell" problem this causes; what is the preferred option here?
The preferred option is not to distribute the DLL but to point to the
cygwin web site and tell people to install it from there. This mailing
list is primarily for discussing the cygwin distribution, not for
talking about ways not to do things with the cygwin distribution.

However, to answer your question, if you are really intent on going down
this path, you should do rigorous checking to make sure that there is no
conflicting version of cygwin on the system. Look for a cygwin DLL in
the path and in the system directories. You can search for strings
beginning with '%% ' in the cygwin DLL to get version information or you
can grab the version information from the DLL headers (you'll undoubtedly
have to do research to figure out how to do the latter).

And, make sure that the user knows that your users know that they
shouldn't be coming to the cygwin mailing list if they have problems
since you're distribution is != the cygwin distribution.
Post by Soeren Nils Kuklau
3) Cross-posting from the other mail: I also found rather little
documentation on `cygrunsrv'. The bundled README file comprehensively
lists possible arguments, but appears to assume that the daemon to be
run is inside the Cygwin root directory (such as C:\Cygwin), whereas we
believe it would make more sense to distribute our package for
installation inside Windows' Program Files folder. Does `cygrunsrv'
understand Windows-like paths, or can we rely on a `/cygdrive/c/Program\
Files/'-like path structure?
Isn't this question simply answered by just trying cygrunsrv with
windows paths and seeing if it works? If not, then maybe the source
code would be instructive.

FWIW, you shouldn't expect to find much documentation in any cygwin
package for doing things in a way that is counter to common practice in
the cygwin distribution. That is very much not something that we are
interested in supporting.

cgf
Corinna Vinschen
2004-10-15 09:44:55 UTC
Permalink
Post by Soeren Nils Kuklau
1) We've looked at `cygrunsrv', and it appears to be a convenient tool
for setting our daemon up as an NT service. For people that do not have
Cygwin installed, can we just distribute `cygrunsrv' as stand-alone tool
to go inside our daemon's working directory?
That's possible, but see below.
Post by Soeren Nils Kuklau
2) Similarly, what about distributing `cygwin1.dll' - I am aware of the
"dllpath hell" problem this causes; what is the preferred option here?
The preferred option is to ask the user to install a standard Cygwin
installation from cygwin.com, using the Cygwin setup tool. Then your
application can rely on the standard Cygwin install.
Post by Soeren Nils Kuklau
3) Cross-posting from the other mail: I also found rather little
documentation on `cygrunsrv'. The bundled README file comprehensively
lists possible arguments, but appears to assume that the daemon to be
run is inside the Cygwin root directory (such as C:\Cygwin), whereas we
believe it would make more sense to distribute our package for
installation inside Windows' Program Files folder. Does `cygrunsrv'
understand Windows-like paths, or can we rely on a `/cygdrive/c/Program\
Files/'-like path structure?
cygrunsrv is made as a tool to support a Cygwin installation. cygrunsrv
itself requires the Cygwin DLL and it's designed to start Cygwin-linked
applications. If you're going to install a service which is outside the
Cygwin installation tree, you can rely on the standard Cygwin install
to request some information. E. g., the cygdrive prefix isn't hardcoded
to /cygdrive, but you can call `mount -p' in an installation script to
get the valid path prefix.
Post by Soeren Nils Kuklau
4) Finally, a coding issue: We use SHA1 hashing for passwords. During
obj/alstring.o(.text+0x316):alstring.c: undefined reference to `_SHA1'
LDFLAGS are: -lpthread -lcrypto
Are we missing a specific Cygwin package?
Probably openssl-devel.


Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:***@cygwin.com
Red Hat, Inc.
Dave Korn
2004-10-15 13:02:49 UTC
Permalink
-----Original Message-----
From: cygwin-owner On Behalf Of Soeren Nils Kuklau
Sent: 14 October 2004 20:32
we're working on a cross-platform server daemon, and on the Windows
side, we have chosen to use Cygwin for POSIX compatibility reasons.
Can I have a copy of your source code please?

cheers,
DaveK
--
Can't think of a witty .sigline today....
Jani Tiainen
2004-10-15 22:07:25 UTC
Permalink
Post by Dave Korn
-----Original Message-----
From: cygwin-owner On Behalf Of Soeren Nils Kuklau
Sent: 14 October 2004 20:32
we're working on a cross-platform server daemon, and on the Windows
side, we have chosen to use Cygwin for POSIX compatibility reasons.
Can I have a copy of your source code please?
Only if daemon is published (or distributed)... =)

Until then, you'll have to wait. (GPL section 2)

After distributing to "outside" you can have your copy.
(http://www.gnu.org/licenses/gpl-faq.html#InternalDistribution)
--
Jani Tiainen
Soeren Nils Kuklau
2004-10-15 22:37:05 UTC
Permalink
Post by Jani Tiainen
Post by Dave Korn
Can I have a copy of your source code please?
Soon :-)
Post by Jani Tiainen
Only if daemon is published (or distributed)... =)
Give us a few weeks and we'll release it to the outside. Source and
binaries for Mac OS X and Linux/x86.
Post by Jani Tiainen
Srvany?
Try that out :)
Thanks, we will.
Post by Jani Tiainen
sha1sum.exe?
Calling an external tool for generating password hashes seems awkward.
We do have openssl-devel installed, and the `sha.h' header file looks
identical to the one we're used to (from OS X), so we're unsure why this
bug is occurring. Since I haven't found any info on this on the 'net,
I'll have to assume the mistake is somewhere in our code :-)

Before we've fixed that, however, we can obviously not release a Windows
(Cygwin) binary.

As to the comments about this thread being on the wrong mailing list:

1) I don't want to be a bother - if a list moderator wants this
discussion to stop, I'll stop, and I hereby apologize for any trouble
I've apparently caused.

2) I personally believe that Cygwin is primarily an environment, and not
a distribution. We do use Cygwin to build our project, because Cygwin
feels less "alien" from our point of view. At the same time, however, we
do not want Windows-based users to feel forced into Cygwin's behaviours.
We want to distribute a Windows application - GPL'd, with some
Unix-style quirks, and compatible to the other major OS'es out there,
but Windows nevertheless. Those who truly want a full Unix experience
wouldn't use Windows in the first place, and thus not Cygwin either.

Have a nice weekend, everyone.
--
Soeren 'Chucker' Kuklau
Igor Pechtchanski
2004-10-15 22:55:50 UTC
Permalink
Post by Soeren Nils Kuklau
Post by Jani Tiainen
sha1sum.exe?
Calling an external tool for generating password hashes seems awkward.
We do have openssl-devel installed, and the `sha.h' header file looks
identical to the one we're used to (from OS X), so we're unsure why this
bug is occurring. Since I haven't found any info on this on the 'net,
I'll have to assume the mistake is somewhere in our code :-)
Try linking it with -lcrypto? ;-) I'm surprised it works on OS/X, though.
Post by Soeren Nils Kuklau
Before we've fixed that, however, we can obviously not release a Windows
(Cygwin) binary.
1) I don't want to be a bother - if a list moderator wants this
discussion to stop, I'll stop, and I hereby apologize for any trouble
I've apparently caused.
This is the right mailing list for discussing, say, problems building
something on Cygwin (if you think it's Cygwin's fault or some idiosyncracy
of Cygwin).

This is *not* the right list for discussing how to subvert the existing
Cygwin installations on users' machines by distributing your own copy of
cygwin1.dll (though this *has* been discussed in the past - search the
list archives). If you're careful, you might even pull it off.
Post by Soeren Nils Kuklau
2) I personally believe that Cygwin is primarily an environment, and not
a distribution.
Cygwin is an emulation layer. The Cygwin distribution contains a set of
packages that use this emulation layer.
Post by Soeren Nils Kuklau
We do use Cygwin to build our project, because Cygwin feels less "alien"
from our point of view.
That's one of the goals of Cygwin - to make porting Unix applications to
Windows easier.
Post by Soeren Nils Kuklau
At the same time, however, we do not want Windows-based users to feel
forced into Cygwin's behaviours. We want to distribute a Windows
application - GPL'd, with some Unix-style quirks, and compatible to the
other major OS'es out there, but Windows nevertheless.
So maybe the MinGW project is more like what you're looking for, then.
Post by Soeren Nils Kuklau
Those who truly want a full Unix experience wouldn't use Windows in the
first place, and thus not Cygwin either.
This is not true at all (to put it mildly). Those who want POSIX behavior
on Windows *will* (and *do*) use Cygwin. But this particular point is
better <http://cygwin.com/acronyms/#TITTTL>ed.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ ***@cs.nyu.edu
ZZZzz /,`.-'`' -. ;-;;,_ ***@watson.ibm.com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing." -- Dr. Jubal Harshaw
Soeren Nils Kuklau
2004-10-15 23:08:27 UTC
Permalink
Post by Igor Pechtchanski
[ sha1 call doesn't link ]
Try linking it with -lcrypto? ;-) I'm surprised it works on OS/X, though.
LDFLAGS = -lpthread -lcrypto

We do. ;-)
Post by Igor Pechtchanski
This is *not* the right list for discussing how to subvert the existing
Cygwin installations on users' machines by distributing your own copy of
cygwin1.dll (though this *has* been discussed in the past - search the
list archives).
Okay, but what /would/ be the right place? Since I don't think people
will be willing to install Cygwin just for being able to use a single
other piece of software...

Think Gtk for Windows programs (such as Gaim): they come with the proper
frameworks included, so the user won't have to worry about that.
Post by Igor Pechtchanski
Cygwin is an emulation layer. The Cygwin distribution contains a set of
packages that use this emulation layer.
Exactly - but where to discuss projects that use the emulation layer and
aren't part of the distribution (thought they might eventually be)?
Post by Igor Pechtchanski
At the same time, however, we do not want Windows-based users to feel
forced into Cygwin's behaviours. We want to distribute a Windows
application - GPL'd, with some Unix-style quirks, and compatible to the
other major OS'es out there, but Windows nevertheless.
So maybe the MinGW project is more like what you're looking for, then.
Indeed; we're looking into it.
Post by Igor Pechtchanski
Those who truly want a full Unix experience wouldn't use Windows in the
first place, and thus not Cygwin either.
This is not true at all (to put it mildly). Those who want POSIX behavior
on Windows *will* (and *do*) use Cygwin. But this particular point is
better <http://cygwin.com/acronyms/#TITTTL>ed.
Right, but I wouldn't define "POSIX behaviour" as "full Unix experience" ;-)

But yes, that's OT.

Thanks for the responses,
--
Soeren 'Chucker' Kuklau
Igor Pechtchanski
2004-10-15 23:23:34 UTC
Permalink
Post by Soeren Nils Kuklau
Post by Igor Pechtchanski
[ sha1 call doesn't link ]
Try linking it with -lcrypto? ;-) I'm surprised it works on OS/X, though.
LDFLAGS = -lpthread -lcrypto
We do. ;-)
No, you don't. You need

LDLIBS = -lpthread -lcrypto

Also, FYI, -lpthread is a no-op on Cygwin.
Post by Soeren Nils Kuklau
Post by Igor Pechtchanski
This is *not* the right list for discussing how to subvert the existing
Cygwin installations on users' machines by distributing your own copy of
cygwin1.dll (though this *has* been discussed in the past - search the
list archives).
Okay, but what /would/ be the right place? Since I don't think people
will be willing to install Cygwin just for being able to use a single
other piece of software...
So try MinGW...
Post by Soeren Nils Kuklau
Think Gtk for Windows programs (such as Gaim): they come with the proper
frameworks included, so the user won't have to worry about that.
So try MinGW... See also <http://cygwin.com/acronyms/#3PP>... :-)
Post by Soeren Nils Kuklau
Post by Igor Pechtchanski
Cygwin is an emulation layer. The Cygwin distribution contains a set
of packages that use this emulation layer.
Exactly - but where to discuss projects that use the emulation layer and
aren't part of the distribution (thought they might eventually be)?
On the mailing lists devoted to such projects. Or, you can ITP your
project for inclusion into Cygwin on the cygwin-apps list -- see
<http://cygwin.com/setup.html>.
Post by Soeren Nils Kuklau
Post by Igor Pechtchanski
At the same time, however, we do not want Windows-based users to
feel forced into Cygwin's behaviours. We want to distribute a
Windows application - GPL'd, with some Unix-style quirks, and
compatible to the other major OS'es out there, but Windows
nevertheless.
So maybe the MinGW project is more like what you're looking for, then.
Indeed; we're looking into it.
Be aware, though, that you won't get full POSIX functionality that Cygwin
provides -- only those parts that are directly supported by the MSVC
runtime. In particular, you'll lose the ability to understand POSIX
(Cygwin) filenames.
Post by Soeren Nils Kuklau
Post by Igor Pechtchanski
Those who truly want a full Unix experience wouldn't use Windows in
the first place, and thus not Cygwin either.
This is not true at all (to put it mildly). Those who want POSIX behavior
on Windows *will* (and *do*) use Cygwin. But this particular point is
better <http://cygwin.com/acronyms/#TITTTL>ed.
Right, but I wouldn't define "POSIX behaviour" as "full Unix experience" ;-)
Hey, we're getting there -- see the efforts on porting Gnome to Cygwin...
Post by Soeren Nils Kuklau
But yes, that's OT.
Yep. A perfect topic for the cygwin-talk list... ;-)
HTH,
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ ***@cs.nyu.edu
ZZZzz /,`.-'`' -. ;-;;,_ ***@watson.ibm.com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing." -- Dr. Jubal Harshaw
Jani Tiainen
2004-10-16 05:15:06 UTC
Permalink
Post by Igor Pechtchanski
Post by Soeren Nils Kuklau
Post by Igor Pechtchanski
This is *not* the right list for discussing how to subvert the existing
Cygwin installations on users' machines by distributing your own copy of
cygwin1.dll (though this *has* been discussed in the past - search the
list archives).
Okay, but what /would/ be the right place? Since I don't think people
will be willing to install Cygwin just for being able to use a single
other piece of software...
So try MinGW...
Post by Soeren Nils Kuklau
Think Gtk for Windows programs (such as Gaim): they come with the proper
frameworks included, so the user won't have to worry about that.
So try MinGW... See also <http://cygwin.com/acronyms/#3PP>... :-)
MinGW works greatly... And take GIMP as an example. You need sparate GTK
package installed. Just like many new .NET apps needs .NET Framework
installed - separately. Just to use _single_ application. Why does this
differ from installing Cygwin? Execpt other is enforced and offered by
Microsoft other by bunch of maniacs... (No offence =)
Post by Igor Pechtchanski
Post by Soeren Nils Kuklau
Post by Igor Pechtchanski
Post by Soeren Nils Kuklau
At the same time, however, we do not want Windows-based users to
feel forced into Cygwin's behaviours. We want to distribute a
Windows application - GPL'd, with some Unix-style quirks, and
compatible to the other major OS'es out there, but Windows
nevertheless.
So maybe the MinGW project is more like what you're looking for, then.
Indeed; we're looking into it.
Be aware, though, that you won't get full POSIX functionality that Cygwin
provides -- only those parts that are directly supported by the MSVC
runtime. In particular, you'll lose the ability to understand POSIX
(Cygwin) filenames.
There also exists GnuWin32 libraries that has very, very _minimal_ set
of POSIX functions to make many libraries and applications to work.
Post by Igor Pechtchanski
Post by Soeren Nils Kuklau
Post by Igor Pechtchanski
Post by Soeren Nils Kuklau
Those who truly want a full Unix experience wouldn't use Windows in
the first place, and thus not Cygwin either.
This is not true at all (to put it mildly). Those who want POSIX behavior
on Windows *will* (and *do*) use Cygwin. But this particular point is
better <http://cygwin.com/acronyms/#TITTTL>ed.
Right, but I wouldn't define "POSIX behaviour" as "full Unix experience" ;-)
Hey, we're getting there -- see the efforts on porting Gnome to Cygwin...
Microsoft also offers "competitive" package, SFU that has, mainly libs
for POSIX stuff. It doesn't contain all magnificent applications that
Cygwin does, like X11 and SSH (which are great tools when used together.)
Post by Igor Pechtchanski
Post by Soeren Nils Kuklau
But yes, that's OT.
Yep. A perfect topic for the cygwin-talk list... ;-)
That list doesn't exists in GMane... =(
--
Jani Tiainen
Reini Urban
2004-10-16 06:13:11 UTC
Permalink
Post by Jani Tiainen
Post by Igor Pechtchanski
Post by Soeren Nils Kuklau
But yes, that's OT.
Yep. A perfect topic for the cygwin-talk list... ;-)
That list doesn't exists in GMane... =(
it does:
http://news.gmane.org/gmane.os.cygwin.talk
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
Jani Tiainen
2004-10-16 21:19:32 UTC
Permalink
Post by Reini Urban
Post by Jani Tiainen
Post by Igor Pechtchanski
Post by Soeren Nils Kuklau
But yes, that's OT.
Yep. A perfect topic for the cygwin-talk list... ;-)
That list doesn't exists in GMane... =(
http://news.gmane.org/gmane.os.cygwin.talk
Hmm, now it did... Wonder why it didn't show earlier... Well this is
just a computer...
--
Jani Tiainen
Loading...