Post a Comment
I think the only substantial difference is that SUA aims to ultimately be a set of libraries providing a complete POSIX API & environment by mapping them to Win32 API calls. (The author provides ample evidence that SUA isn't 100% POSIX yet.) Its secondary purpose is to provide standard tools on top of the libraries. (Why have a POSIX environment if you can't even do ls?) I'm guessing if you typed in "ps" in SUA, you'll actually get a list of all the processes running in Windows. Cygwin's purpose is just to provide tools that are common in Linux. Cygwin provides some degree of mapping, but just enough to allow its tools to run correctly. Running "ps" only displays the processes running on top of the running bash shell instancce, not all the processes running in Windows. Honestly, I'm not sure totally sure. It must be a very subtle difference.
In terms of licensing, Cygwin is open source, whereas SUA, being developed by Microsoft, is closed source.
the posix subsystem runs in _parallel_ to win32, and thus maps calls to the winNT api calls, just like the win32 subsystem does.
cygwin and mingw both build on win32, so you go through three layers (unixish->win32->nt) instead of two (posix->nt), where win32 is substantially different from anything posix like (compare fork and CreateProcess for example), while directly mapping onto NT makes things faster and more reliable.
btw, services for unix provides many of the user land tools (at least those specified in posix)
Running ps initially only shows the processes running in the shell. There are options that will show all global processes, and there are options to just for showing the Interix processes.
It's a really neat little tool and works, for the most part, like a regular unix shell. It's great if you need to interact with unix boxes, but don't need any unix specific features. It saves from having to dual boot, everything is on one desktop.
- Microsoft Windows Services for Unix (that is what the article is talking about). It is huge, never used it, did the download and will put it on test (or not, I'm satisfied with GnuWin32, but who knows);
- cygwin (huge also, very complete and with the gnu args we already know - www.cygwin.com). A kind of emulation is used through cygwin.dll;
- GnuWin32 (big, the utilities are win32 console applications - gnuwin32.sourceforge.net). Not as complete as cygwin, but very good for regular needs;
- UnxUtils (small, all utilities are win32 console applications - unxutils.sourceforge.net). A bit outdated and not as complete as the above ones, but good anyway;
- Berkeley Utilities (tiny, all utilities are DOS applications, some differences on arguments and features - www.openetwork.com). If you need to use Unix tools on DOS it is for you.
The biggest problem on Windows to me is related to soft links. I know it has what they call "junction" points to allow something similar to Unix mounting points, but it seems too limited and error prone. Anyway it is way better than have to assign a drive letter to storage locations. That is something that should really be addressed on WIndows.
The biggest problem on Windows to me is related to soft links. I know it has what they call "junction" points to allow something similar to Unix mounting points, but it seems too limited and error prone. Anyway it is way better than have to assign a drive letter to storage locations. That is something that should really be addressed on WIndows.
Vista's NTFS exposes symbolic links for files and directories now, so these are an option in addition to junctions.
This is true. It's nice to be able to use it to keep up with my *ix skills. It's really not a replacement for a full system due to some idiosyncrasies of it having to run on top of Windows, but to keep the command line and scripting knowledge fresh, it's pretty good.







