Linked by Thom Holwerda on Thu 7th Sep 2006 19:00 UTC, submitted by Eugenia
General Unix "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."
Order by: Score:
Comparison
by raboof (2.04) on Thu 7th Sep 2006 20:18 UTC
raboof
Member since:
2005-07-24
Fans: 0

So how does this compare to things like MinGW and Cygwin?

RE: Comparison
by samad (3.24) on Thu 7th Sep 2006 20:48 UTC in reply to "Comparison"
samad Member since:
2006-03-31
Fans: 0

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.

RE[2]: Comparison
by oxygene (2.04) on Thu 7th Sep 2006 20:59 UTC in reply to "RE: Comparison"
oxygene Member since:
2005-07-07
Fans: 0

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)

RE[3]: Comparison
by zanusi (1) on Fri 8th Sep 2006 16:45 UTC in reply to "RE[2]: Comparison"
zanusi Member since:
2006-09-08
Fans: 0

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.

RE[2]: Comparison
by Flatland_Spider (2.96) on Fri 8th Sep 2006 14:00 UTC in reply to "RE: Comparison"
Flatland_Spider Member since:
2006-09-01
Fans: 4

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.

v hmm
by tmack (2.84) on Thu 7th Sep 2006 20:44 UTC
RE: hmm
by samad (3.24) on Thu 7th Sep 2006 20:50 UTC in reply to "hmm"
samad Member since:
2006-03-31
Fans: 0

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.

RE[2]: hmm
by r_a_trip (3.2) on Thu 7th Sep 2006 21:14 UTC in reply to "RE: hmm"
r_a_trip Member since:
2005-07-06
Fans: 0

Tsk, tsk. Buying hardware without checking for compatibility. Will they ever learn?

RE[2]: hmm
by Sphinx (2.84) on Thu 7th Sep 2006 22:20 UTC in reply to "RE: hmm"
Sphinx Member since:
2005-07-09
Fans: 12

Any port in a storm.

RE[3]: hmm
by Flatland_Spider (2.96) on Fri 8th Sep 2006 14:02 UTC in reply to "RE[2]: hmm"
Flatland_Spider Member since:
2006-09-01
Fans: 4

Not really. It's actually very useful when people are on a Windows domain, but need to interact with unix boxes.

RE[4]: hmm
by Sphinx (2.84) on Sun 10th Sep 2006 14:50 UTC in reply to "RE[3]: hmm"
Sphinx Member since:
2005-07-09
Fans: 12

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

v That's awesome!
by Clinton (2.64) on Thu 7th Sep 2006 21:12 UTC
Unix tools to Windows
by acobar (3.6) on Thu 7th Sep 2006 22:18 UTC
acobar
Member since:
2005-11-15
Fans: 0

- 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.

RE: Unix tools to Windows
by n4cer (2.6) on Fri 8th Sep 2006 06:18 UTC in reply to "Unix tools to Windows"
n4cer Member since:
2005-07-06
Fans: 5

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.

RE: Unix tools to Windows
by pxa270 (5.4) on Fri 8th Sep 2006 11:00 UTC in reply to "Unix tools to Windows"
pxa270 Member since:
2006-01-08
Fans: 0

There's also MSYS from the MinGW guys and UWIN from AT&T.

Edited 2006-09-08 11:00

openBSDin SFU
by project_2501 (2.76) on Fri 8th Sep 2006 00:07 UTC
project_2501
Member since:
2006-03-20
Fans: 0

SFU draws on significant openBSD code - see the paper packaging for an acknowledgment.

Never worked
by lopisaur (2.64) on Fri 8th Sep 2006 00:44 UTC
lopisaur
Member since:
2006-02-27
Fans: 0

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.

Quite Good For Unix Beginner
by neo_0531 (1.13) on Fri 8th Sep 2006 01:32 UTC
neo_0531
Member since:
2006-08-03
Fans: 0

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

RE: Quite Good For Unix Beginner
by Flatland_Spider (2.96) on Fri 8th Sep 2006 14:14 UTC in reply to "Quite Good For Unix Beginner"
Flatland_Spider Member since:
2006-09-01
Fans: 4

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.