Slashdot Mirror
Unix To Beef Up Longhorn
An anonymous reader writes "VNUnet has a story about Longhorn having the ability to run unix or linux code via SFU." Microsoft's site has a lot more information about SFU itself. Regardless of ideological bent, it's an interesting piece o' technology.
http://www.cygwin.com
-m
#
# Modus Ponens
#
Hate to break it to yall, but there have been some VERY nice UNIX(tm) layers for Windows since NT 4.0 The same people that made Exceed X11 for Windows also made a kernel add-in with full POSIX support. All the UNIX goddies where there and it even seemed to increase stability. Microsoft purchased the company after they failed to get their software to run well on Windows 2k (they ran out of money and couldn't afford to redevlope). If they get this stuff working again in Longhorn, I'll be first in line to buy it when its released.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
"Zions confirmed that Microsoft is working to replace all open-source code in SFU with commercially licensed alternatives. Last year it licensed Unix software from SCO."
Apple, in unit shipments, is the largest vendor of UNIX systems in the world. They may not be used in the same fashion, but Apple completely eclipses "unix/solaris/linux/bsd" in shipped units, in fact ridiculously so.
"With the release of Mac OS X, Apple became the largest vendor of Unix in the world"
"There are over 5 million Mac OS X users, including scientists, animators, developers, and system administrators, making Apple the largest vendor of UNIX-based systems."
A lot more...
This has been common knowledge for a couple of years now.
I run SFU on Windows 2000 and XP Pro already.
I doubt Longhorn will add anything significantly new to this.
For what it's worth, it's a pretty good POSIX layer with a rather good ksh implementation.
It also appears to be more stable than Cygwin, and more palatable to corporate IT departments who have a tendencey to shy away from "those crazy open source guys".
I have seen sfu in operation, including the (latest) 3.5 release, and it is still an incomplete and ugly to use kludge. While cygwin itself is a bit clumsy, sfu is even worse.
/, and I have found no way to change this since it does not use /etc/passwd. Yet, it sets my HOME environment variable to something else based on the Windows USERPROFILE. Since ssh uses the one from getpwent, it of course uses /.ssh rather than what is in $HOME. By contrast, cygwin gets this right by creating a /home file layout and using the userid to form home directories for each user which match up both in what the getpw.. calls return and what $HOME is set to.
/dev/fs/C. Also, cygwin handles directory paths that include spaces in their filenames gracefully, sfu does not.
Of course it does not bundle many common and nessisary things like gcc, most gnu tools, cvs, ssh, or bash. You can get these from a seperate site (interopsys), but most of the standard things still require patches before they can be successfully compiled and used on sfu. In this sense, even at 3.5, sfu offers a lower level of compatibility with existing unix sources than cygwin does. As such, there is still no version of libtool that will build shared libraries on sfu, although this can now be done successfully with cygwin.
In addition to being incomplete, sfu offers no x server. cygwin includes xfree86 now. To get X under sfu, the only options are commercial, and expensive.
Finally, sfu integrates poorly in many ways with the win32 environment and with unix. For example, sfu insists internally my home directory is
Next, there is still some basically broken stuff related to file permissions between sfu and mswin. For example, I downloaded a tarball into the sfu file system from both exporer and firefox, but the permissions sfu saw for the saved files were ---, no r/w anything for anyone! At least cygwin and mswin do interoprate on files at this level!
Both cygwin and sfu mangle file names and file system layouts in complex ways. However, cygwin does a better job of this. I can use c:/ in cygwin, for example, but my only choice in sfu is
Finally, I had sfu 3.5 lock up on me, and it took down the entire machine. I have had older versions of cygwin lock up on me a few times, but they never killed the machine.
All in all, I have found even the latest and greatest SFU a very ugly and just barely usable kludge. Cygwin, while certainly not perfect, is far more usable and useful even before considering that cygwin is also far more complete in what it does offer out of the box. Cygwin is a very underrated tool in this respect.
There is valid historical reasons for this. The first versions of SFU contained an NFS and NIS server so that UNIX clients could connect to an NT Server. Only later were "Unix Services" added to the product.
Zions confirmed that Microsoft is working to replace all open-source code in SFU with commercially licensed alternatives.
That would be entertaining, considering that just about every userland component of Interix has OpenBSD copyright notices in it. Take out all the Open Source from Interix and you'd have little more than the "kernel" left.
If they're really talking about doing that, and perhaps replacing it with the code from Unixware... I don't think commercial UNIX or Linux have anything to fear from the result. I've used Unixware, and it was less than impressive.
Of course this is a minimal POSIX environment, while SFU includes things like networking, X, NFS, etc. In other words, minimal POSIX compliance has always been available, SFU has existed but cost money since 1996, has been free as of this year, and will be enhanced and included with the OS in the next version.
SFU only provides partial X support. Something about licensing issues and X servers. They also don't include an SSH server becuase of fears of a conflict with SSH, Inc. And despite the fact that WIndows uses Kerberos for integration, their telnet server and client (from SFU or just the OS) don't try to use it for encryption.
Last I heard, there was talk about the latter, but who knows if it will come to anything.
LedgerSMB: Open source Accounting/ERP
The assumption here is that once Windows can run Unix apps, the conventional Unix and Linux distributions will become redundant, because ... the reason people use them is that there are apps they can run only on Unix and not Windows? Ha ha ha... Seriously, by 2008 every vendor with any sense will sell both Linux and Windows ports of their software, and both SFU and Wine will be an occasionally useful convenience utility. Linux will win because the kernel is better than Windows, if that's the only differentiator.
Or maybe MS will switch to the Linux or BSD kernel after Longhorn is out. If OS's are a commodity why waste vast amounts of money competing with something that's already better and free. They're already doing that with IE (telling people they should switch to Mozilla).
The only new thing here is the thought of shipping SFU with Windows (and presumably a lot of new glue to make it possible for a non geek to configure). SFU and Cygwin are both old but good technologies.
Technically, SFU != Cygwin. They achieve the same aim, that of exposing a Unix API so that Unix programs can be compiled to run under Windows, but are apples and oranges under the hood. SFU does it by adding an API on top of the kernel and beside the Win32 API using a little known but cool capability of windows. Cygwin does it by adding an API on top of the Win32 API. Theoretically, SFU has less in its way to hinder performance than Cygwin. I've not tested whether the potential was realized.
This predates Cygwin, and is different anyhow. Cygwin uses a DLL that runs through the Win32 API. So it's an API on top of an API. There are some problems with this. SFU is different, it actually installs POSIX as an API alongside Win32. Windows isn't limited to a single API, and actually ships with simple POSIX and OS/2 APIs. Win32 is required, since all the main software is written in it, but you are perfectly able to develop your own APIs for it.
.NET (which will probably be it's primary API), Win32 and POSIX. The other change will be interoperability. Right now you can't really have POSIX and Win32 programs directly interact. They can communicate, but not directly call functions from one another or the like. This aims to change that.
Back in the day I believe it was Citrix that did this, and their product added a hell of a POSIX layer to NT4. They ran out of money and Microsoft picked them up, making SFU. Right now SFU is available from MS for no charge, and actually adds quite a good POSIX layer to Windows.
The difference would be right now it's pretty server-ish. It wants to setup a NFS server and such. It's also not included.
Sound like the idea here is to make Windows a multi-API system with Longhorn. Rather than just shipping with Win32, as XP does, it'll ship with
No idea if this is something that'l really work or just pie in the sky, but it's not the same thing as Cygwin, and isn't based on it.
Don't forget that Windows has a hybrid microkernel design, with the OS interfaces provided by user-mode subsystem processes. Windows is one such subsystem (csrss.exe), while POSIX is another (psxss.exe). Note that there is also a DOS subsystem (NTVDM.exe), and an OS/2 1.1 subsystem (os2ss.exe) which no longer ships.
Thus, there may not be any Windows pipe API, but the POSIX subsystem includes all 110 APIs required for strict POSIX.1 compliance. This means it properly supports pipe(), signal(), ttys, getuid(), getppid(). If you have a library that provides these calls under the Windows subsystem, they will probably be useless, but if you compile against the POSIX subsystem they will work.
Keep in mind that any one process can only run under one subsystem. That is, you cannot have a Windows program that calls into the POSIX subsystem to do a fork(), for example. The only way to combine Windows and POSIX functionality is with a pipe (e.g. WinCmd.exe | POSIXcmd.exe | DOSCMD.EXE).
aQazaQa