Quoting "Eric V. Smith" <eric@windsor.com>:
> Jostein Chr. Andersen said:
> > On Tuesday 17 February 2004 19.41, Brian Mathis wrote:
> >> Sounds an awful lot like cygwin (http://www.cygwin.com/), only
> >> outdated :)
> >
> > It's a big diffrence: Cygwin is not native Windows.
>
> In what way? It doesn't use the POSIX subsystem, if that's what you're
> implying.
>
> (Does anything use the POSIX subsystem? I'm not sure it's even shipped in
> XP, but I haven't looked.)
Cygwin is an emulated Unix environment that sits on top of Windows. This is why
many Windows developers really dislike using cygwin, even if they are more
comfortable in a Unix environment. Often, I have found cygwin puts itself
between my application and windows and gives me incorrect results. I have even
gone so far as to use unxtools (a suite of standard Unix tools recompiled as
native Windows binaries) and to reimplement most standard unix tools using APR.
If you really want proof that cygwin is an emulated environment, you should take
a look at what they do to get fork() to work in cygwin. It is incredibly
clever, but very dangerous. In fact, their fork() call can't be used outside of
cygwin, because it requires everything to be compiled and run specifically for
that environment. A couple of friends of mine and I tried to implement fork()
for APR on windows. We got it working, but you couldn't load any external
libraries into any code that used it, because the child process would get corrupted.
Windows and Unix are incredibly different beasts, and trying to layer one on top
of the other is not a good idea IMNSHO.
Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 17 20:45:07 2004