as they say, "when in rome, do as the romans."

go native!

cygwin is a (pardon the language, but the literal meaning of the word is very apt) bastard of windows & linux.

i used cygwin from 2001-2004 (so my specific criticisms might be dated). i never developed against it (except to compile a few apps, like tree and perl-tk, that were missing from the distribution), but merely used the environment. it was installed on my desktop because a software development tool ("ported" from unix to windows) required it and i use linux exclusively at home, so i used it.

cygwin can refer to the cygwin dll, which provides a set of linux-like apis, or the linux-like environment, which provides a gnu/unix environment (bash, gcc, x-windows, and even kde at one time). my comments are about the environment as i only compiled a few small foss apps against the dll.

• dll hell: because (as i understood it) the cygwin dll used a shared memory region for communication between processes, the formatting of that shared memory was versioned. this shared memory versioning kept two processes, compiled against different cygwin dll versions, from trashing the shared memory by writing to it in incompatible ways. add to this a few separate applications that included their own version of cygwin (to support grep or any other gnu utility used by the application; eg searching through source code), and you have dll hell. while a cygwin dll is loaded, that shared memory region is versioned. all other cygwin dlls that try to concurrently load must recognize that version or you get a nice pop-up summarizing the cygwin dll version conflict. and even after that first app ceased executing, the cygwin dll might remain loaded by windows. the only sure way to unload the dll and clear the shared memory region was rebooting, though logging out was usually sufficient. this complicated upgrading cygwin, concurrently using applications compiled against different cygwin dll versions, etc.
• long process start-up time: cygwin's grep, cut, tr, sed, awk, etc took ~2-10x longer to start executing than native ports and this problem was exasperated in scripts (which frequently execute external apps).
• unexpected interactions between cygwin and native apps: piping/processing CR & CRLF, bash job control, quoting command-line arguments, etc.

having used bash, cmd is pathetic enough to drive anybody to cygwin if only for an interactive shell and scripting, but in the end i settled on the "native" cross-platform ipython (and helps sharpen the python skills).

cygwin provides a nearly perfect build environment for linux/gnu applications (99% successful "./configure && make && make install"), but from my experience the trade off is in performance and seamlessness (mixing command-line apps in cmd or integrating x-windows apps into desktop). native is more difficult to achieve, but i believe it's also more rewarding.

some "native" cross-platform recommendations:

• unxutils
• gnuwin32
• emacs (or vi if you insist ;)
• mingw
• msys (when necessary for building with mingw)
• python (or perl, php, ruby, etc)
• java (gnu or sun)
• gtk (wxwidgets, or even qt now that it's finally open source on windows)
• gnome libs (dunno about kde)
• pthreads (if porting from linux)
• x.org
• and the best media player on windows: MPLAYER!

the most frustrating thing about going native is finding foss apps that build on windows with visual studio (which some would argue is more "native" to windows, but is definitely not foss, no matter how pragmatically tempting the "free-beer" visual c++ express looks) but have poor or no support for mingw (unmaintained/missing makefiles).

Although I agree with the above user (undefined) that cygwin is less then ideal, sometimes it helps to have some familiar app's around.

Check out the cygwin ports project. I found it really helpful, since i could run an xfce environment on my universities windows computer (now i discovered where they keep their slackware pc's). And it has some app's that might be useful.