While it does provide many of the unix capabilities, it's still Windows. (Think of it as Windows++). It gives you many of the advantages of unix, and it doesn't preclude you from using the Windows capabilities. Around here, it's a commonly used perl on Windows boxes, even for people not running bash, vim and such.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

While it does provide many of the unix capabilities, it's still Windows.

By which definition??? It doesn't use the Windows API. It doesn't know anything about Windows.

An Atari game doesn't run on Windows even if I run an Atari emulator on Windows.

ikegami:

It's still windows because it still runs windows programs. At its heart, cygwin really isn't an emulator, it's a compatibility DLL that you can link your programs against to gain some unix capabilities in your programs. It in no way prevents you from using the Windows API in your code, though you'll have to link against the Windows libraries too. But that's no problem--here's a simple example:

$ cat cygmsgbox.cpp
#include <stdio.h>
#include <unistd.h>
#include <windows.h>

int main(int, char **) {

   int PID = fork();
   if (PID) {
      MessageBox(NULL,
                 "Congratulations, it's a boy!",
                 "Proud parent",
                 MB_OK | MB_ICONINFORMATION
                 );
      puts("Parent messagebox closed");
   }
   else {
      MessageBox(NULL,
                 "Hello, are you my mother?",
                 "New child",
                 MB_OK | MB_ICONINFORMATION
                 );
      puts("Child messagebox closed");
   }
   return 0;
}

$ gcc cygmsgbox.cpp -lstdc++

$ ./a.exe
Child messagebox closed
Parent messagebox closed
[download]

Give it a try: it will fork, and both the parent and child process will then pop up a standard windows messagebox. When you close either messagebox, the appropriate process will tell you so. There are no special hoops you have to jump through, because it's just another Windows program.

If you want to avoid the windows API, the cygwin DLL, along with the other DLLs in the basic cygwin package will certainly let you pretend the windows API doesn't exist. But the windows API is just an #include <windows> away.

In the perl world, people who use cygwin aren't precluded from using the Win32 modules. I usually avoid them because I spend a significant amount of time in unix, and I like to use modules that I can use everywhere. But when I need them, I use them.

Your analogy with an Atari emulator is apples vs. oranges. An Atari emulator actually emulates the entire machine, and doesn't directly run Atari programs or Windows programs. When you run an Atari game on it, the emulator treats the machine code as an interpreted language and couldn't call a windows API if it tried. The cygwin DLLs in no way attempt to emulate unix: they simply give you access to some of the unix APIs.

I'll grant you that most of the programs linked against the cygwin DLLs don't use the Windows API, but so what? The reason many of them exist is to provide a comfortable environment for people who frequently switch between windows and unix.

...roboticus

When your only tool is a hammer, all problems look like your thumb.