Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Windows Operating Systems Software Unix Microsoft IT

Microsoft to Stop Releasing Services for Unix 296

Posted by CowboyNeal from the end-of-the-road dept.
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."
This discussion has been archived. No new comments can be posted.

Microsoft to Stop Releasing Services for Unix More

Microsoft to Stop Releasing Services for Unix

Comments Filter:

  • Microsoft's answer to UNIX (Score:5, Funny)

    by It doesn't come easy ( 695416 ) * on Friday September 02, 2005 @06:44AM (#13462855) Journal
    Embrace and extend! UNIX is doomed! Mwahahahahaha!
    • "From what the article hints at, Microsoft wants Unix interoperability integrated into the OS."


      I am sure this was ment to be :"WE WANT TO CONTROLL ALL COMMUNICATION PROTOCOLS HAHAHAHA, MONEY MONEY MONEY". Yep, more like that.
      • In theory, I think this should be a good thing. If Windows would feature a NFS client, a good Posix personality including a complete Posix commandline toolset, and a bunch of interoperability tools for printing, user authentication, etc out of the box, it would be great.

        But what this probably means is that they are dropping SFU and integrating a few incomplete crumbs from it into the server versions of Windows.

    • Re:Microsoft's answer to UNIX (Score:5, Insightful)

      by dubious9 ( 580994 ) on Friday September 02, 2005 @07:18AM (#13462997) Journal
      Just goes to show ya, the old koan is finally coming true.

      Given enough time and money, eventually Microsoft will re-invent Unix
      • Given enough time and money, eventually Microsoft will re-invent Unix

        Surely you mean Apple.

        And I thought the old koan is: what Apple does, Microsoft will copy
      • Just ask Dave Cutler.
    • Nah. If Microsoft wanted to kill UNIX, all they need to do is release Visual Basic 6 for Unix.
    • Windows NT from the get go has always had this notion of various subsystems that can sit on top of the raw OS layer. It is most common to use the Windows subsystem but there was for a time a POSIX subsystem and an OS/2 subsystem so that applications written to either could run under Windows. Over time maintenance of these subsystems was abandoned but I read somewhere that the next go around of Windows is going to have a fully compliant POSIX subsystem.

  • BSD isn't dying! (Score:4, Funny)

    by Anonymous Coward on Friday September 02, 2005 @06:45AM (#13462856)
    Microsoft are moving to it as well as Apple!
    • Maybe it will be undead. You know, with all the zombie machines...

    • Re:BSD isn't dying! (Score:2, Interesting)

      by ajs318 ( 655362 )
      Well, you're not that far off the mark really. All the networky bits of XP -- the big improvement over 3.11/9X -- were lifted lock, stock and barrel from FreeBSD. Not that there was anything wrong with that, since the BSD guys don't mind having their code looted and pillaged ..... otherwise they'd have used the GPL, wouldn't they?

      The more BSD code Microsoft lift, the better Windows will become ..... until it is just FreeBSD with some proprietary extensions.

  • Integrated (Score:5, Funny)

    by n9uxu8 ( 729360 ) on Friday September 02, 2005 @06:45AM (#13462860) Homepage
    Imagine...what a novel concept...the ability to interact with a Unix system...they should patent that!

    Dave

    • Re:Integrated (Score:5, Funny)

      by It doesn't come easy ( 695416 ) * on Friday September 02, 2005 @06:53AM (#13462893) Journal
      No no no...not interact...Microsoft plans to integrate UNIX into Window's code base. In the next five years, they will swap more and more Windows code for UNIX code. Eventually, there will be more UNIX code than legacy Windows code. At which point Microsoft will 1) claim ownership of UNIX, 2) begin to release Windows only UNIX code so you have to run Windows to get the "full experience of UNIX", and 3) hire analysts to compare the TCO of Windows vs. other UNIX systems.

      It's about time UNIX benefitted from Microsoft's years of marketing experience...

      • Many a true word spoken in jest. (Score:5, Interesting)

        by carldot67 ( 678632 ) on Friday September 02, 2005 @08:32AM (#13463403)
        Bill Gates' SWOT ANALYSIS:
        Strengths:
          1. Marketing == Massive propaganda machine.
          2. Proprietary == Huge market penetration.
          3. Rich applications == User lock-in.

        Weaknesses:
          1. Bloated and frankly god-awful code-base
          2. Expensive to maintain, insecure etc
          3. Cant really afford to start from scratch
          4. Cant steal Linux due to GPL

        Opportunities:
          1. Use BSD
          2. Convert some UNIX/Linux/BSD sites
          3. Remove some barriers to entry at UNIX shops

        Threats:
          1. Linux
          2. IBM
          3. Open Sourcerors

        The logical BUSINESS APPROACH is this:
          1. Grab BSD.
          2. Break the interfaces.
          3. Call it "WinBSD".
          4. Creat compatibility layer: "WinBSD-API"
          5. Patent "WinBSD-API" so you now own WinBSD
          6. Trivial porting exercise
          7. Brand it like youve never branded before

        What does this give you?
          -It gives you something that looks like Windows and works like Windows, but is better than it.
          -It leaves you with all your existing apps and protocols still working at minimal update cost.
          -It means your customers expensively bought/developed apps will still work.
          -It give UNIX shops one less reason to reject windows as a solution.
          -It locks out OS/3rd party developers due to the broken (and patented) WinBSD interface.
          -It offloads a large amount of knackered code.

        Now add all this up and it gives MS EXACTLY what they have always strived for: Continuing user lock-in to the Windows monopoly while maintaining a very painful barrier to anyone else who wants to write for the platform.

        Disclaimer: I am not an OS guru so there will be some technical issues with my analysis. Im just looking at it from a business point of view.

         
      • "Windows only UNIX code so you have to run Windows to get the "full experience of UNIX","

        You mean like those evil linusfollowing monopolists that depends on glibc extensions not in the bsd c library? And those assholes that don't test their c ode on various versions of solaris, aix, hpux, and all the other operating systems the auther really doesnt care about?

        If you write it, you're under no obligation to make it portable. Most stuff just isnt worth the effort of even testing let alone fixing for other oper

      • BillG claimed in 93 that NT was UNIX (Score:2, Informative)

        by Anonymous Coward
        The following piece was in Communication Week printed in June/July 1993 (no 461, p.8):

        UNIX IN NT'S CLOTHING

        In his latest positioning statement on Microsoft Corp.'s Windows NT operating system, company chairman and CEO Bill Gates said NT is not a competitor of Unix, but in fact uses the same kernel. "I think [NT] will very quickly be the most popular form of Unix out there, because we do not allow licensees to change it around to try and get proprietary advantages on top of what was on there," Gates said

    • the ability to interact with a Unix system...they should patent that!

      I know you were trying to be funny, but if they do produce some Unix integration feature in the OS, I fully expect them to try to get some patents around it (and probably succeed).

  • "Microsoft says that this integration couldn't be done with past architectures." seldom i heard them being so true about themselves.
    • This is exactly the sort of thing that we hear from Microsoft when it's selling us its Next Big Thing: "Old Thing couldn't do _____ but Next Big Thing handles it in its sleep."

      Microsoft's PR machine often does a good job of telling the truth (or, at least, part of the truth) about old issues when they have a new solution but, until that time, they are usually in full "la-la-la-la, we're not listening" mode.

      To be honest, this sort of selective spin isn't just something that's unique to Microsoft but they are
    • That's not true though. NT was a new system, the basic architecture was deliberately inaccessible. On top of it you have the win32 layer, the public NT layer, and for a while there was a posix layer. Believe it or not it worked fine, at least from the command line. X wasn't handled so well, but cygwin/X shows that could have been done a lot better. NT could have been a better unix than unix, in the same way as OS/2 with windows.

  • SFU was only good for one thing (Score:5, Insightful)

    by DrXym ( 126579 ) on Friday September 02, 2005 @06:48AM (#13462870)
    Free NFS. Other than that it was a pigs ear. It was just various Unix bits and pieces slapped together and massively intrusive to install, requiring reboots and services to be running all the time. I tried it for a bit, noticed the huge slowdown in startup times, the poor Unix environment which was next useless and uninstalled it. Cygwin is miles better.


    And if you really need a real Unix / Linux on XP then colinux can provide it running at near-native performance.

    • Free NFS. Other than that it was a pigs ear.

      Definitely agreed there, but I'd also add that the free NIS implementation is a big help as well. The NFS/NIS implementation contained in SFU is a great alternative to installing Samba on your servers. If you can dispense with CIFS altogether, it's a big win.

      (Not as big a win as ditching desktop Windows altogether, but sometimes we have to compromise.)
    • Apparently bits of it are free; not only is GPL software such as gcc, gdb software in SFU, but some of the utilities are taken from OpenBSD.
    • In particular, SFU is severely and notably lacking:

      * an X server
      * SSH
      * libraries and a compiler this side of the stone age

    • Re:SFU was only good for one thing (Score:5, Interesting)

      by aggieben ( 620937 ) <aggieben@NOsPAm.gmail.com> on Friday September 02, 2005 @09:28AM (#13463756) Homepage Journal
      I tried it for a bit, noticed the huge slowdown in startup times, the poor Unix environment which was next useless and uninstalled it. Cygwin is miles better.

      What are you even talking about? What startup times? A poor Unix environment next to useless? Cygwin is better how?

      What this sounds like to me is a person realizing that he's not familiar with SFU (read: BSD), says it sucks, and retreats to the nice, warm, Cygwin (read: Linux) blanky and sticks his thumb in his mouth.

      SFU is a much cleaner implementation that Cygwin, and it sits directly on top of the NT kernel rather than bringing its own layer of abstraction to the party. This makes SFU perform much better than Cygwin. Also, pkgsrc has support for SFU, which means that SFU has a proper package management system and Cygwin does not.

      The *only* thing lacking from SFU is a POSIX-compatible mapping from the X11 api to the DirectX api. Cygwin has this, to its credit. Everything else about SFU is superior.

  • The full story (Score:5, Informative)

    by mparaz ( 31980 ) on Friday September 02, 2005 @06:50AM (#13462875) Homepage
    The eWeek article is just a summary. The full story is here [microsoft-watch.com].

  • I love SFU 3.5! (Score:5, Interesting)

    by georgeha ( 43752 ) on Friday September 02, 2005 @06:50AM (#13462882) Homepage
    I support a Solaris based printer, and with SFU 3.5 I can make the customer's Windows server host the jobs, and make them responsible for the NFS server, while all I have to do is add one line to vfstab. This is one good thing Microsoft has done (and Slashdot, I first read of them freeing it here).

  • Reimplementing unix, poorly? (Score:5, Insightful)

    by MarkEst1973 ( 769601 ) on Friday September 02, 2005 @06:51AM (#13462885)
    What's the old koan of wisdom?

    Those who do not understand Unix are condemned to reinvent it, poorly. [72.14.207.104]

  • Heard that Before (Score:5, Insightful)

    by RAMMS+EIN ( 578166 ) on Friday September 02, 2005 @06:52AM (#13462889) Homepage Journal
    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?

    • Re:Heard that Before (Score:5, Interesting)

      by Spiked_Three ( 626260 ) on Friday September 02, 2005 @07:07AM (#13462949)
      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.

      I know, I worked for Microsoft Federal at the time. The only reason POSIX compliance was ever mentioned by a customer was to keep Microsoft out of a bid. So we put in POSIX. No one ever userd it or intended to use it, but it shut up the excuse to not buy Windows in the federal marketplace.
      Maybe POSIX is something more today. If it's not I can certainly see why Microsoft would drop it.
      Services for Linux on the other hand is useful and used in quite a number of places, and Microsoft might as well throw it in there, if nothing else just to make it easier to install. I can't see where the overhead is significant if it isnt being used.

      • Holy Confusion Batman (Score:5, Insightful)

        by RAMMS+EIN ( 578166 ) on Friday September 02, 2005 @07:30AM (#13463044) Homepage Journal
        ``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.
        • To be fair, the modern Single UNIX Specifications cover much more ground (and are more "useful" for application writers) than the original POSIX.1 spec that WinNT went through the motions with.

          I think the GP's point was more along the lines of it being useless as a RFP requirement -- federal customers didn't actually care if it was there or not, and if they did, they wouldn't be shopping for Windows to begin with.
        • 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.

          It was approved as PO

          • On BeOS, you can use the *SAME* filename to open the same file whether you use the POSIX or the BeOS interface. This was not true of the NT "POSIX".

            Love how you weasel out of the truth. Microsoft figured out a way to claim "POSIX compatability" without actually making it work, because the interoperability was ZERO with all the Windows applications. Rather than bragging about working on it, you should be ashamed of yourself.

    • Windows POSIX implementation (Score:5, Insightful)

      by nickos ( 91443 ) on Friday September 02, 2005 @07:20AM (#13463005)
      "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'm hoping that one day Microsoft will resurrect Xenix and port the Win32 API to it ;)''

        They can just use the (old) BSD-licensed WINE code and "embrace and extend". After all, that's what Cedega did.
      • Xenix was sold to the Santa Cruz Operation, which changed hands a few more times, and we know how they wound up. [groklaw.net]

        • Re:Windows POSIX implementation (Score:5, Informative)

          by sconeu ( 64226 ) on Friday September 02, 2005 @10:25AM (#13464037) Homepage Journal
          Actually, the Santa Cruz Operation became Tarantella, which was recently bought by Sun.

          The current entity calling themselves "The SCO Group" is what used to be called Caldera. They bought *something* from Santa Cruz (definitely their Operating Systems Division) and some sort of assets (but they can't produce the purchase agreement), and changed their name from Caldera to SCO. Allegedly this was for name recognition/branding, but apparently was really to sow confusion for their lawsuits.

      • Re:Windows POSIX implementation (Score:5, Interesting)

        by cant_get_a_good_nick ( 172131 ) on Friday September 02, 2005 @10:04AM (#13463900)
        Ironically, WinNT was the first OS to have POSIX compliance. MS was the first company to bother with the cerification. The UNIX companies saw the fact that they were POSIX as blatantly obvious, and didn't both initially. They came around when they saw they were losing "POSIX" contracts to WinNT.

        Originally, WinNT was a Microkernel, with OS2 and POSIX support. Both of the latter were bare minimums, to satisfy contractual obligations (IBM and OS/2) or checklists for new contracts (POSIX). Neither worked well. As tiem went on, more and more things ended up in the kernel (graphics, apps and servers) it would be hard to call it a microkernel anymore, more like some kind of hybrid.
    • CoLinux works quite well, actually.

  • A while ago I asked a few people on irc if there was a way to access nfs shares in windows and was told no.... would these unix services let me do that ?

  • What happened to ten years? (Score:3, Interesting)

    by MosesJones ( 55544 ) on Friday September 02, 2005 @07:00AM (#13462926) Homepage
    At last years TechEd Microsoft announced
    Ten Year [technologywizards.com] support on all products.

    Umm 2011.... sounds a bit closer than ten years.

    • It was released in January of 2004, so mainstream support should end 2009, extended support ends 2014. Sounds like they decided to extend mainstream support 2 years to 2011 and still end extended support in 2014. No conspiracy to see here.

  • Sub-standard integration? (Score:3, Interesting)

    by Anonymous Coward on Friday September 02, 2005 @07:03AM (#13462937)
    Will this mean poorer unix services? In the pre-OS X days, Apple File Services (AFS) for Windows was always years out-of-date, making Windows clients perform better than Apple clients on networks with Windows servers. The result was that poor-performing Mac clients soon disappeared. The truly paranoid might think MS did this on purpose or that MS had something to gain by keeping AFS out-of-date. ...but it was just business and allocation of resources, Right? Just happened to work out that way.
    • This is exactly what happened with NT's posix layer. The idea was that the native NT API would be completely hidden, and there would be various subsystems available - a win32 one, a posix one, and iirc a new NT-only one. Officially these were all on an even footing, and in early releases this seemed to be the case, the posix layer was actually quite decent. But then it sort of got gradually dropped, forcing application developers to port to NT if they wanted to be competitive. Here's hoping they don't do th

  • Perhaps they should change the name now, too? (Score:5, Funny)

    by Shoten ( 260439 ) on Friday September 02, 2005 @07:03AM (#13462938)
    Instead of Microsoft SFU, perhaps it would be better known as Microsoft STFU?

  • Probably a good thing (Score:3, Funny)

    by Tim C ( 15259 ) on Friday September 02, 2005 @07:04AM (#13462940)
    Everytime I read "SFU", my brain tried to parse it as "STFU"...

  • Not really discontinuing SFU... (Score:4, Informative)

    by RhettLivingston ( 544140 ) on Friday September 02, 2005 @07:08AM (#13462956) Journal

    but reinventing it. By moving this capability into the OS instead of hosting it as a parallel OS on the same kernel, they will gain performance and increase integration.

    This is actually just one more example of an acceleration of rumors of Longhorn features. The rumors were that Longhorn would be able to run Unix applications and, specifically, x86 Linux binaries without recompilation. It looks now like at least a portion of that capability will appear in SP2 for Win 2003 Server a full year before Vista release.

    • Exactly, as Bill Hilf, MS's linux lab manager pointed out [slashdot.org] on recently on /.

      "I can confirm that the next-generation of several components of Services for Unix are being integrated into Windows Server 2003 R2. The Network File System (NFS) client, NFS Server, User/Name Mapping, Telnet Server & Client, Password Sync and NIS Server components of Services for Unix are all present in the Windows Server 2003 R2 builds[...]In addition, a revamped POSIX subsystem, the 'Subsystem for Unix-based Applications' or

  • New kernel (Score:4, Funny)

    by marcantonio ( 895721 ) on Friday September 02, 2005 @07:20AM (#13463001)
    Microsoft says that this integration couldn't be done with past architectures.

    Because, unbeknownced to the world, Microsoft is using a BSD kernel in Vista.

    Use Cygwin.
    • is its posix on win32 rather than posix on NT

      This makes certain things (most notablly select) rather difficult to implement and slow.
      • Now that the native NT API is more or less available, would it be possible to rewrite those bits of cygwin that could benefit to use it on systems where it's available? (Remember cygwin still has to run on win98)

  • Aimed at Unix and Linux...copying Apple (Score:3, Interesting)

    by darealpat ( 826858 ) on Friday September 02, 2005 @07:24AM (#13463024) Journal
    I think that Microsft has looked at how well Apple has used BSD in their OS offering, and the wheel began turning.

    They have been targetting Unix for a while, and this is aimed squarely at killing off Unix as a viable alternative inside of 5 years, as Win for Workgroups was aimed at Novell. Their other target are the switchers from Unix who tend to gravitate towards BSD or Linux. Doing this will give an option that will be quite tempting, given their installed base.

    Off course, could be a bit more smoke and mirrors designed to bait switchers....

    Just my two cents.
    • Well, I think you somewhat have a point, but Microsoft is playing an entirely different ballgame than Apple. MS is really looking at all of the enterprise server systems migrating to Linux instead of Windows.

      On a technical level, "Unix" was important for Mac users because it gave them the robust, modern kernel that Apple had failed to develop in-house. Only a tiny minority of Mac users actually care about running awk or vi - they're just happy they can copy files without the machine grinding to a crawl.

      Micr

  • Another bastardized Unix (Score:3, Insightful)

    by t482 ( 193197 ) on Friday September 02, 2005 @07:30AM (#13463046) Homepage
    Say Windows is fully POSIX-compatible. No major applications claim "POSIX" compatibility -- developers still write for Unix dialects, and the Linux dialect has become the dominant Unix API dialect format. Windows will still have to develop seperately for Windows.

  • Honestly, in the 15 years that I've been forced to work with Windows, I've never met anybody that actually used this (yes I know the service isn't that old...you know what I mean).

    Will it really be missed?

    I don't see it as having any sort of hampering effect whatsoever.
  • I seem to recall that Microsoft recently bought SFU from some company, or acquired the whole company, or somesuch. I can't remember clearly. But if that is the case, and now they are announcing that the product will be discontinued, isn't that another nice instance of Microsoft killing interoperability with Unix?

    Yes, they say they will keep supporting it and that the features will be integrated...but I for one don't believe that's going to make things better in any way.
    • I believe it was Interix (not InterOp as sibling post has it).

      • Re:Kill Interoperability? (Score:3, Informative)

        by RupW ( 515653 ) *
        I believe it was Interix (not InterOp as sibling post has it).

        Interix was the product name, which survives today as part of SFU 3.5. The original vendor was Softway Systems. They wrote Interix; Microsoft bought Softway and rolled Interix 2.2SP1 into SFU 2.0.

        The confusion, I guess, is that InterOp systems bought the domain interix.com. They now sell util ports to interix and interix-related services. But AFAIK InterOp had nothing to do with SFU/Interix itself.

  • fork() and pipe() (Score:5, Interesting)

    by squarooticus ( 5092 ) on Friday September 02, 2005 @08:25AM (#13463365) Homepage
    As a mostly-Linux developer who has done his share of Linux->Windows porting, the lack of fork() and pipe() are easily the most irritating aspects of programming for Windows.

    Oftentimes in security code, you want to know which process is speaking to you on the other end of a pipe. Under Linux, this is very easy. Under Windows, it is a huge bear, not the least reason for which is that Windows lacks the concept of a named pipe, so you have to make something up based on shared memory or some other such garbage.

    And fork()... well, as anyone who has written a fork()-based program (i.e., one that doesn't just exec() right after forking) knows, this entirely changes the structure of the application. Yukk.

    Last I head, pipe() and fork() are both POSIX, so I hope these system calls appear when Microsoft takes the plunge and replaces their crappy kernel and API with something closer to UNIX. Given how long UNIX has been around and how much important software exists for it and is being developed daily (mostly on Linux and MacOS these days), I can't wait until we can finally declare system API "victory" and move the fight to something that causes much less irritation for developers.
    • Actually you can create named pipes in Win32. You use CreateFile() and pass in a filename such as "\\.\pipe\mypipe" as the name. You have to prepare it a little some special named pipe functions but then you just read and write to it like any other kind of file.


      It's not POSIX but you could probably wrap it up in POSIX-esque function if you wanted.

    • Microsoft has had named pipes i n WIn32 since day 1.
      Lookup CreateNamedPipe() on http://msdn.microsoft.com/library

      fork() is a legitimate problem, or should I say, a CHEAP fork() is a problem. cygwin has reinvented fork(), but it's a dog compared to fork() on a native Unix platform.

      Arguably, Windows' ownership and DAC/ACL semantics are MILES better than was comes by default in most Unixes.
    • mmap() is pretty high up the list, too. It's *so* annoying not being able to mmap files where appropriate, because win32 doesn't understand it.

    • Windows lacks the concept of a named pipe

      Windows has named pipes [microsoft.com].

  • As a BSD user, I understand the attractiveness of Unix. I can see M$ was trying to get people like me to feel a bit better about their software.

    But I don't get the real consequences of this -- what are the Unix-lovers going to do, now that this product is officially dead?

    E.g. switch entirely to NetBSD/FreeBSD/OpenBSD? Port the Unix userland they need to NT? Buy other crap from other people? Run Windows and a BSD on the same machine under some weird emulation?

    How will this change impact actual (power) users?
    • Run Cygwin. That's what I currently do at work, and it's a pretty decent environment if that's all you have. As far as I can tell, the only reason I have to run Windows is for outlook, though, so I'm working on the logistics of moving to Linux (Which would GREATLY aid my development efforts) without disrupting my work too much. Worst case scenario I can run Windows in VMWare for Outlook.
  • Windows can authenticate with a NIS server and mount users' home directories via NFS.

    Though I might have to wait until the genetic engineers manage to fit wings onto pigs first.

  • Never understood the name (Score:5, Informative)

    by vijayiyer ( 728590 ) on Friday September 02, 2005 @09:33AM (#13463808)
    Shouldn't it have been called Unix Services for Windows? In another example of MS marketing spin, they act as if SFU somehow does something for Unix, when it instead adds basic functionality to Windows. I used SFU for about 1 month. I still was so frustrated doing Fortran development under Windows that I wiped the drive and installed Linux.
  • Unix interoperability integrated into the OS? They must be using UNIX source code. ;-)

    Somebody tell SCO!

Slashdot Top Deals

"Hello again, Peabody here..." -- Mister Peabody

Close