Slashdot Mirror
Microsoft to Stop Releasing Services for Unix
lilrowdy18 writes "According to a recent article, Microsoft will stop releasing any new versions of Services for Unix. SFU 3.5 will continue to be supported until 2011 and will have extended support until 2014. From what the article hints at, Microsoft wants Unix interoperability integrated into the OS. Microsoft says that this integration couldn't be done with past architectures."
And if you really need a real Unix / Linux on XP then colinux can provide it running at near-native performance.
Those who do not understand Unix are condemned to reinvent it, poorly.
Hmmm, when Windows NT was still new, there were great plans to implement not only the win32 API, but also the DOS and win16 APIs, and even POSIX! All of these were implemented to some extent, but the POSIX personality never reached a state where it was really usable.
Knowing that, and knowing all the announcements that Microsoft has been making about great new features that were going to be in Longhorn, and the subsequent withdrawal of nearly all of those features, I find it hard to believe that Microsoft will be providing POSIX compliance in Windows.
Of course, there's always Cygwin. And BTW, what came of CoLinux?
Please correct me if I got my facts wrong.
The negative spin is right there in the headline - makes it sound like MS is dropping Unix interop support, when in fact they're integrating it more tightly into the Windows core to improve it.
Just goes to show ya, the old koan is finally coming true.
Given enough time and money, eventually Microsoft will re-invent Unix
Why, o why must the sky fall when I've learned to fly?
"the POSIX personality never reached a state where it was really usable"
;)
Wasn't this needed in order for Windows to be used by certain US governmental agencies that stipulated that all OSs they used must have POSIX compliance. If I'm right in thinking that they must have been accredited with being POSIX compliant from someone so it can't have been all that bad...
You're right that Cygwin's the way to go though. I'm hoping that one day Microsoft will resurrect Xenix and port the Win32 API to it
``I don't know about now, but at the time Microsofot did the POSIX implementation it wasn't so much that MS version of it was useless, it was more that the spec itself was useless. It did not have things like printing and network access, so in all reality not one single useful application in the world could say it was POSIX compliant.''
Wow, slow down for a bit. You're saying three different things here and presenting them as a single argument.
First, your argument that POSIX is useless. Certainly, POSIX does not standardize everything under the sun. That wouldn't be possible, and it wouldn't be a good idea either. That doesn't make it "useless". It standardizes the interface to a lot of system functionality, from basic file I/O to sockets, threads and shared memory. This facilitates porting of applications between conformant systems - for many applications, the core functionality would not need to be rewritten for a new system. POSIX-compliance is what causes most open-source software to quickly spread to all alternative operating systems, whereas it takes a long time to get ported to Windows.
Then, the point about the Microsoft POSIX implementation being useless. Last I read about it, it said that the POSIX personality and the win32 personality were basically completely isolated from one another. POSIX process ids are separate from win32 process ids, POSIX processes cannot start win32 processes, and communication between the two types of processes is difficult. In addition, large parts of POSIX were unimplemented, which means that many POSIX apps simply wouldn't work on NT.
And then the claim that no single application in the world can claim to be POSIX-compliant. Well, just because not everything in an application is also specified in POSIX doesn't make it not POSIX compliant. As long as everything that is in POSIX is also done the POSIX way in the application, it can be called POSIX-compliant. And for the record, there are hordes of applications that are purely POSIX; basically any Unix command-line program or daemon is a good candidate.
Finally, an interesting bit of knowledge: although POSIX is typically associated with Unix-like systems, there are other systems that are POSIX-compliant, too. IBM's MVS and VMS are two examples.
Please correct me if I got my facts wrong.
Really?
Let's just say that I admire how much resources it takes under NT to spawn one new process. In fact I'm positively astonished. A good thing? I think not.
I'm also in awe of the way the NT kernel is virtualized and compartimentalized. Wait, it's not. You do know, don't you, that a Sun E15k with an arbitrary number of CPUs under Solaris can be split any which way (dynamically even) as virtual computers?
Is it the TCP/IP stack that you admire? Hmm, where was that taken from again?
The directory system then? Novell anyone?
NUMA perhaps? no, NT doesn't have that.
In fact what's so special about NT, with or without win32, that is so good? Is there a single piece that no one else has?
1969 AT&T Unix V.1 has nothing to do with current versions of Solaris, BSD or even Linux other than that they are their common ancestor.
According to K&R 1st edition, the complete V1 of Unix was about 10,000 lines of codes in C plus about 1000 in assembly, whereas Win2000 is reportedly 25 million LoC.
How about a fairly consistant graphics API that can be used for applications, and is backward compatible accross 95% of all computers in the market... you can't even rely on any *nix system to *HAVE* a gui api, let alone *WHICH* gui api is available on even 50% of *nix installs.
This may seem like a troll, but having a consistant gui api structure, and can reliably have a base of software on *nix (linux or bsd) systems to build from that one can build applications that will run on >90% of linux/bsd desktops, it won't take over the desktop market.
It isn't so much the underlying technology, it's the developer capability, and the fairly consistant API.
Michael J. Ryan - tracker1.info