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.
Huh?
Some estimates show Google as having "100,000" servers. There are over 12 million OS X users. Saying Apple is the largest UNIX-based system vendor isn't just saying it about desktops...it INCLUDES *ALL* UNIX/Linux systems, in all environments. Sorry.
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.
Perhaps you don't realize that Windows NT has included POSIX compatibility as a design requirement since Day 1. In other words, every version of NT from 3.1 to 2003 has had a POSIX subsystem which properly implements things like fork(), link(), chmod, chown, and inode change times (most of which are poorly, if at all, supported by cygwin).
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.
It may even be possible that the Longhorn SFU will be advanced enough to get licensing for the UNIX trademark!
aQazaQa
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
If you read the sfu35new.doc it says these features have been available for download since 1999. I remember using an early version. I think I used it to nfs mount stuff.
http://threetechguys.info Come, discuss Technology. Got a technology question? Come ask!
How many people that bought those motherboards just threw away the CD that came with it?
Now how many people who bought Apple computers probably use OS X?
Common sense tells you the number of people who keep using OS X vs. the number of people who use a freebee included with an MB are probably drastically different.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
(that's StFU) if you're missing it.
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
All Windows software was written for Win32 subsystem not for NT kernel. NT kernel is what hosts various subsystems including Win32, which is most important.
"All of MS's own software is written & tuned for the NT kernel, so switching to a different kernel would mean a rewrite of MS-SQL and so on."
Methinks you don't quite understand. This is a subsystem that runs under the Windows kernel, side-by-side with your windows apps. It's not a separate kernel. It's kind of a layer between the Posix API and the Windows kernel, so to speak. So you could, for example, get rid of IIS (if Windows will even let you remove it) and run Apache, for example. Or you could run both side by side (using different ports, of course).
So, you could have SQL Server running but also have Apache running. No rewriting of anything.
I actually had this software when it was written by the company MS bought, and used it under NT 4.0. It was lacking in a lot of areas at the time and it sounds like they've done a lot more with it. Still, I imagine it won't be quite as good as running the software under Linux, in terms of performance. Not to mention, one of the biggest advantages of running apps under Linux is for stability and security. Why would you want to run Linux apps on a less stable, less secure OS?
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.
The article is talking about binary emulation, where apps compiled for Linux are run on Windows.
Nonsense. There is no mention of binary emulation in the article, nor is there any mention of binary emulation anywhere on the Windows SFU pages of Microsoft's website - nor, in fact, is there any mention of binary emulation, in connexion with this article, anywhere except in the ass you're talking out of.
This has nothing to do with binary emulation. You cannot take a Linux binary and run it with SFU.
So how does it differ from Cygwin? The answer is simple. Cygwin binaries run in Win32 userspace: they can access the Win32 API directly, or they can access the POSIX API through cygwin1.dll. Interix applications run in POSIX userspace: they can access the POSIX API directly, but they cannot access the Win32 API at all.
Well you have been able to download and run SFU for XP for over a year. I might find them useful if I was writing code for both Windows and Unix, its a bit tedious having to edit code on one platform, go through the whole cross platform build thing. I have yet to find a development environment on UNIX that is on a par with VMS/LSE, let alone Visual studio.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
You dont need to wait for Longhorn or even pay anything for it. Its 220mb in size. Whether it remains free is another issue entirely.
How does this silly troll get modded as insightful?
Thank you, anonymous coward, for your troll, but a troll is no subsititute for reason and fact. If it's "much easier to put unix on windows" than vice versa as you claim, how do you explain away the rather disturbing fact thousands are now running windows applications on linux, while microsoft is still talking about pie in the sky vaporware that would allow linux apps to run on windows?
oops...
I just recently found and installed SFU. It is very nice.
.exe: "SFU35SEL_EN.exe". I found the MS mirror of it would stop part way through the 218MB download. It is an exefied .zip file, so I initally wondered what was causing the "invalid exe file" error. Then I did a google search for "SFU35SEL_EN.exe" and found lots of copies. 5-6 tries later I found a site that actually worked: "http://debian.goldweb.com.au/microsoft/unixservic es/SFU35SEL_EN.exe"
As for getting hold of it, I went through the registering process(heh, MS eat my made up details) and found the name of the
My biggest gripe is that it comes with everything EXCEPT a damn X-Server!! You either have to buy one, or use the cygwin+Xfree86. Doh! Though I have looked into the comerical versions, and X-Win32 from http://www.starnet.com/ looks promising. I have downloaded the demo version, but I am waiting for a crack/keygen/serial for this version before I install it.
In the mean time, I found Microsoft Virtual PC(I don't think it is a free download - though it was for me -- my friend has access to the developer network). This is potentially even sweeter than SFU. Run an entire OS inside a virtual PC! I installed FreeBSD with great ease(I only had 1 small problem). Heh, and unlike SFU it actually comes with an X-Server. I have been a long time windows user, so both tools will help me to migrate to *nix, or at least keep me out of trouble if I ever need to use a *nix system.
Wait...I seem to remember another PC operating system that was supposedly vastly superior than the market dominating environment, but one of it's great features was that it could run that environment's apps, right alongside the superior OS's apps. Though obviously, once you had experienced this wonderful new way of working, you'd eventually convert to all new native apps. What was that OS? (think...think...think...)
Oh right. It was OS/2!
Seriously, rarely have OSes succeeded when one of their main benefits was running another OS's software. SCOX and Sun have made various stabs at convincing customers UnixWare and Solaris run Linux apps, and they are still hemoraging marketshare. Though Microsoft's marketing machine is second to none, I still can't believe customers will buy Longhorn as an integration/migration platform. That marketing never worked in the past, why would it work now?
Oh wait, that's right: Microsoft is expecting it to work 4 years from now. OK, then perhaps they believe in 4 years Linux will have made so many inroads they'll have to run Linux apps. Maybe we really are winning after all!
--Mythos
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.
Uh, so, what, did a fairy drop that copy of Windows on your doorstep or something? You paid for SFU, you will pay for future versions of SFU, it's all nicely subsidized by the cost of the OS. Monopolies make for very strange economics.
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
An interesting point (albeit a little of topic)... Firefox and Mozilla (under Windows 2000 try it when I get home under linux) failed to load the SFU page but IE loads it up straight away hmmmmmm.
On the topic of GPL'd code. A "friend" of mine worked for a software company that has no problems with taking OSS and changing a few things in the source and calling it their own and shipping it as apart of the end product license NOT intact (or insight for that matter) AND for a handsome PROFIT mind you!
A classic line my "friend" told me was that it was changed enough so it "sort-of" looked different but not changed so much that the updates couldn't be easily intergrated.
What is to stop micro$oft from ripping the source and changing a few things (such as cross-platform compilability) and rebadging it in the old red, green, blue and yellow?
I recently bought a new laptop and tested Linux, FreeBSD, OpenBSD, NetBSD and Windows XP on it. OpenBSD crashed the most (because of the NIC driver, as far as I can tell), followed by FreeBSD and Linux (both seemed to suffer from bugs in the video-related code, as well as power management). NetBSD and Windows XP didn't crash at all, but only Windows XP supported all my hardware (NetBSD came second in that category).
In short, the myth that Windows crashes more than open-source OSes is a relic of the 90s (when the main MS OSes, Win95 and Win98, really were unstable), that Linux zealots will only be able to hang onto for so long.