“Want to run best of breed apps under both Windows and Unix? Eric Hall tells you about an option for doing this: Microsoft’s Posix subsystem. It lets Unix apps think they are using regular Unix, but they are actually using Windows instead.”
“Want to run best of breed apps under both Windows and Unix? Eric Hall tells you about an option for doing this: Microsoft’s Posix subsystem. It lets Unix apps think they are using regular Unix, but they are actually using Windows instead.”
So how does this compare to things like MinGW and Cygwin?
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)
Actually the Win32 subsystem is privileged and serves also as as a ‘gateway’ to NT kernel for other subsystems (POSIX, OS/2).
So the path is still posix -> win32 -> nt.
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.
Unix and Windows?
That’s like a peanut butter and ass sandwich.
Seriously, just learn to run a real OS and stay away from Wintendo.
Like the author explained, he couldn’t get drivers for his new hardware in Linux. This article is useful when you have to compromise and you need some POSIX compatibility.
Tsk, tsk. Buying hardware without checking for compatibility. Will they ever learn?
Any port in a storm.
Not really. It’s actually very useful when people are on a Windows domain, but need to interact with unix boxes.
Like the author explained, he couldn’t get drivers for his new hardware in Linux. This article is useful when you have to compromise and you need some POSIX compatibility.”
How you can argue that statement is beyond me, missed your point completely
SFU does have quite a bit of functionality, so I didn’t really didn’t see the problem on quite the same the desperation level.
Well, all except for the Windows part.
– 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 – http://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 – http://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.
There’s also MSYS from the MinGW guys and UWIN from AT&T.
Edited 2006-09-08 11:00
SFU draws on significant openBSD code – see the paper packaging for an acknowledgment.
I had very bad experiences with SFU 3.0 & 3.5, since their NFS client couldn’t authenticate ONCE against my FreeBSD NFS servers, and I bent over backwards to try and get it to work.
SFU will I think help in it’s own little way of feeding practices and info of how a unix commands operates even without a unix box
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.