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

67 of 296 comments (clear)

  1. Microsoft's answer to UNIX by It+doesn't+come+easy · · Score: 5, Funny

    Embrace and extend! UNIX is doomed! Mwahahahahaha!

    --
    The NSA: The only part of the US government that actually listens.
    1. Re:Microsoft's answer to UNIX by alexandreracine · · Score: 2, Funny
      "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.
      --
      No sig for now.
    2. Re:Microsoft's answer to UNIX by dubious9 · · Score: 5, Insightful

      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?
    3. Re:Microsoft's answer to UNIX by EvilSS · · Score: 3, Funny

      Nah. If Microsoft wanted to kill UNIX, all they need to do is release Visual Basic 6 for Unix.

      --
      I browse on +1 so AC's need not respond, I won't see it.
    4. Re:Microsoft's answer to UNIX by /ASCII · · Score: 2, Insightful

      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.

      --
      Try out fish, the friendly interactive shell.
    5. Re:Microsoft's answer to UNIX by tjstork · · Score: 2, Interesting

      The irony is that a lot of VB6 developers are extremely pissed off about VB.NET as a migration path. If Linux actually had a VB6, a lot of VB developers would probably jump ship.

      --
      This is my sig.
    6. Re:Microsoft's answer to UNIX by Klaus+Obermeyer · · Score: 2, Funny

      I suppose that would explain why Windows NT is largely based on VMS and uses code from FreeBSD. Oh wait, it doesn't.

    7. Re:Microsoft's answer to UNIX by HuguesT · · Score: 3, Insightful

      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.

    8. Re:Microsoft's answer to UNIX by IllForgetMyNickSoonA · · Score: 2, Interesting

      The express edition you posted the link to is not free at all. The *beta* is free, the price for the released version will be USD 49 (current MS "plan", as they put it on their web page).

    9. Re:Microsoft's answer to UNIX by dar · · Score: 2, Informative

      Your statement doesn't make any sense. Win32 is an API of which NT is one implementation.

      --
      My other Slashdot ID is much lower.
    10. Re:Microsoft's answer to UNIX by Master+of+Transhuman · · Score: 2, Interesting


      I was going to respond citing lines of code for Windows and Linux, but the fucking stupid /. "lameness filter" - which itself is fucking lame - wouldn't accept the post because of supposed "junk characters" that were nowhere to be found in the post...

      Anyway, the lines of code for Windows XP is supposedly 40-50 million lines of code, whereas for the Linux kernel, it is 6 million, and for a Linux distro like Red Hat or Debian (presumably including the two desktops and the utilities, and perhaps even the included apps), the figures range from 30 million to 213 million.

      The most useful figure, though, is the Coverity study that showed Linux had five times fewer bugs than commercial products of the same size.

      Given that Windows XP was released with, what, 65,000 bugs or whatever the figure was, supposedly, according to a Microsoft memo at the time, that's pretty good news.

      --
      Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
    11. Re:Microsoft's answer to UNIX by aztracker1 · · Score: 3, Insightful

      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
    12. Re:Microsoft's answer to UNIX by 99BottlesOfBeerInMyF · · Score: 3, Funny

      ...you can't even rely on any *nix system to *HAVE* a gui api...

      What you call a bug, I call a feature. I like being able to build a box without having an unnecessary GUI adding overhead and unneeded complexity. If I'm building a box that is destined to sit under the hood of some machinery and has to be 100% reliable and as fast and stable as possible why would I want to add an unnecessary GUI? The inability of Windows to be customized and have parts removed is a huge weakness, not an advantage.

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

      Having the same GUI API as other distributions and UNIX like systems is not a core feature, it is an interoperability feature. Solaris, RedHat Linux, OpenBSD, MacOS X, etc. all have had consistent GUI APIs for years. Sure some of them also support other GUI APIs and they don't have the same GUI API as one another, but then again, Windows doesn't have the same GUI API as any of these others either. Complaining that a given Linux distro and an SGI machine don't have same GUI API is like complaining a given version of Windows and Amigas don't have the same GUI APIs. If you want to argue about who has better support for cross-platform graphics, well I can run most X-11 based graphics on my Mac OS X machine out of the box, without resorting to an emulator. Can any version of Windows?

  2. BSD isn't dying! by Anonymous Coward · · Score: 4, Funny

    Microsoft are moving to it as well as Apple!

    1. Re:BSD isn't dying! by ajs318 · · Score: 2, Interesting

      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.

      --
      Je fume. Tu fumes. Nous fûmes!
  3. Integrated by n9uxu8 · · Score: 5, Funny

    Imagine...what a novel concept...the ability to interact with a Unix system...they should patent that!

    Dave

    1. Re:Integrated by It+doesn't+come+easy · · Score: 5, Funny

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

      --
      The NSA: The only part of the US government that actually listens.
    2. Re:Integrated by b100dian · · Score: 3, Informative

      You can use PAM LDAP for login against an AD.
      And, of course, samba.

      Is this enough "Client for Microsoft Networks"? :)

      --
      gtkaml.org
    3. Re:Integrated by Xenophon+Fenderson, · · Score: 2, Insightful

      Part of the problem is that Unix's directory and authentication systems are 30+ years old. PAM and NSS are attempts to fix some of the problems and cruft, but they really aren't all that nice, either. It's amazing that things like Samba's winbind work at all, and even then, there are serious flaws. For example, searching for a particular user account is a straight table scan, order O(n), when using the getpwent API. If your Unix box is a member of an Active Directory domain with lots of accounts (where "lots of" is "more than 1,000"), that user lookup takes forever. Guess what: every time you do an "ls -l", that lookup happens for each line. Now, the newest version of winbind tries to do some caching and whatnot (as do the tools that use account information), but since they are restricted to the 70s-era UNIX get*ent APIs that assume your password file is a flat, unindexed, small, and locally available file, the Samba team cannot make the actual searches faster than O(n).

      One would think that by now, someone would have modernized the Unix authentication infrastructure beyond PAM and NSS, but that would break a lot of old code. And not to rant, but it's stupid crap like not being able to log into a cached non-local account that keeps Unix and friends off the enterprise desktops and laptops. Apple probably gets closest, and they still are missing many of the enterprise-class features Windows, I am sad to say, has had for years.

      --
      I'm proud of my Northern Tibetian Heritage
    4. Re:Integrated by Tony+Hoyle · · Score: 4, Informative

      If 'ls -l' is doing a lookup for each line then your nscd is not running or broken.

      All user information (and host) on Unix is cached - and the cache is *not* a linear lookup.

      Username/PAM lookup is *not* linear. If I call getpwnam for example it goes to pam -> active directory -> username lookup. There's no searching involved.

    5. Re:Integrated by HairyCanary · · Score: 5, Informative

      I have a gaggle of Solaris boxes that authenticate to LDAP (which AD is) and I do not see any appreciable delay due to the username lookups. And yes, our LDAP directory has thousands upon thousands of users.

    6. Re:Integrated by Dolda2000 · · Score: 5, Informative
      I don't know what Unix system you use, but on my GNU/Linux system (which uses the same APIs), based on GNU libc, the get*ent APIs are implemented using nameswitch modules, which can do lookups in LDAP, NIS, /etc/passwd, /etc/passwd.db, a MySQL database, or anything else. And indeed, it will be on the complexity order of whatever that algorithm chooses -- it's not a flat search.

      I will agree that there are a lot of things that should be done with the Unix "directory services", but not that which you describe. The greatest problem is that Unix still uses numeric UIDs, whereas it should be using symbolic UIDs (such as Kerberos principles).

    7. Re:Integrated by irc.goatse.cx+troll · · Score: 2, Insightful

      "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 operating systems.

      --
      Pain lasts, kid. Its how you know you're alive. Sometimes I think this growing up thing is just pain management-TheMaxx
    8. Re:Integrated by Just+Some+Guy · · Score: 2, Informative
      All user information (and host) on Unix is cached

      That's true, where "Unix" == "Linux with nscd installed and running". Don't feel bad, these kinds of assumptions aren't new.

      --
      Dewey, what part of this looks like authorities should be involved?
  4. m$ agnizing their weakness... once again by leckmi · · Score: 2, Insightful

    "Microsoft says that this integration couldn't be done with past architectures." seldom i heard them being so true about themselves.

    --
    free 880 megs file hosting - www.FTPZ.US - best
  5. SFU was only good for one thing by DrXym · · Score: 5, Insightful
    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.

    1. Re:SFU was only good for one thing by aggieben · · Score: 4, Interesting

      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.

      --
      Don't become a regular here, you will become retarded. -- Yoda the Retard
    2. Re:SFU was only good for one thing by NuShrike · · Score: 3, Interesting
      Bzzzz. Comes from Redhat, famous repackagers of Linux.

      Let's look at the webpage www.cygwin.com:
      # Cygwin is a Linux-like environment for Windows. It consists of two parts: A DLL (cygwin1.dll) which acts as a Linux API emulation layer providing substantial Linux API functionality.
      # A collection of tools, which provide Linux look and feel.
      Let's look at the page it www.cygwin.com points to:
      http://www.redhat.com/software/cygwin/ which even has this sentence:
      Cygwin delivers the open source standard Red Hat GNU gcc compiler and gdb debugger on Windows.
      It may not be 'pureblood' Linux, but it comes from the package sources. Thanks for playing.

      SFU is better (and FASTER) because it's a real subsystem talking to the kernel instead of a futzing emulation layer on top of Windows. You might call it a better kernel than Cygwin.

      What makes Cygwin better is the ample userland where wider and better supported range of 3rd party program packages built into the default install than SFU.

      Now if pkgsrc fixes that issue, I might switch over more. I'm using it for speedier NFS vs Samba file access due to better metadata caching.

      For those of you whom has tried WinCVS over Samba and declared it unusable, you haven't tried it through NFS. Night and day.
  6. The full story by mparaz · · Score: 5, Informative

    The eWeek article is just a summary. The full story is here.

    1. Re:The full story by barking_at_airplanes · · Score: 2, Informative

      Hardly shocking information since it was announced back on April, 26, 2005 in the Interix Forums (http://www.interopsystems.com/tools/forum). So this has been known *publicly* for over 4 months now with a lot more detail than is in the other articles. The link is http://www.interopsystems.com/tools/forum/tm.aspx? m=5623

      The real story is not that SFU is ending, but rather that it is becoming part of the regular distribution. Since January, 2004 SFU version 3.5 has been available as a free download from Microsoft (http://www.microsoft.com/windows/sfu) with no restrictions, etc. So this change has been expected for some time.

      Complaints in other posting about "missing" applications are pretty hollow: two compilers are available (gcc 3.3 and MSVC {a free version of MSVC is available}, OpenSSH, bash, zsh, etc. They can be picked up freely from the Interix Tools site http://www.interopsystems.com/tools.

  7. I love SFU 3.5! by georgeha · · Score: 5, Interesting

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

  8. Reimplementing unix, poorly? by MarkEst1973 · · Score: 4, Insightful
  9. Heard that Before by RAMMS+EIN · · Score: 4, Insightful

    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.
    1. Re:Heard that Before by Spiked_Three · · Score: 5, Interesting

      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.

      --
      slashdot troll = you make a compelling argument I do not like the implications of.
  10. i didn't know about these unix services by Adult+film+producer · · Score: 2

    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 ?

    1. Re:i didn't know about these unix services by LurkerXXX · · Score: 2, Insightful

      Yes. Don't listen to people in irc channels. :)

  11. negative spin by Anonymous Coward · · Score: 3, Insightful

    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.

  12. What happened to ten years? by MosesJones · · Score: 2, Interesting

    At last years TechEd Microsoft announced
    Ten Year support on all products.

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

    --
    An Eye for an Eye will make the whole world blind - Gandhi
    1. Re:What happened to ten years? by Bluey · · Score: 3, Informative

      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.

  13. Sub-standard integration? by Anonymous Coward · · Score: 3, Interesting

    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.

  14. Perhaps they should change the name now, too? by Shoten · · Score: 5, Funny

    Instead of Microsoft SFU, perhaps it would be better known as Microsoft STFU?

    --

    For your security, this post has been encrypted with ROT-13, twice.
  15. Probably a good thing by Tim+C · · Score: 3, Funny

    Everytime I read "SFU", my brain tried to parse it as "STFU"...

  16. Not really discontinuing SFU... by RhettLivingston · · Score: 3, Informative

    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.

    1. Re:Not really discontinuing SFU... by brajesh · · Score: 2, Informative

      Exactly, as Bill Hilf, MS's linux lab manager pointed out 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 'SUA' is also available as an optional install in R2."

      --
      95% of all sigs are made up.
  17. Re:Microsoft's bait and switch by Bluey · · Score: 3, Informative

    Why pity them? They will still be supported for another 6 years (9 if they want extended support). They just aren't releasing any new versions of it.

    Even still, some of the next-gen SFU functionality is being integrated into Windows Server 2003 R2. It's not the end of unix interoperability from Microsoft, just this derivation of it.

  18. New kernel by marcantonio · · Score: 4, Funny

    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.

  19. Windows POSIX implementation by nickos · · Score: 4, Insightful

    "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 ;)

    1. Re:Windows POSIX implementation by cant_get_a_good_nick · · Score: 4, Interesting

      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.

    2. Re:Windows POSIX implementation by sconeu · · Score: 4, Informative

      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.

      --
      General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
  20. Aimed at Unix and Linux...copying Apple by darealpat · · Score: 3, Interesting

    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.

    --
    For every present, there is a past
  21. Holy Confusion Batman by RAMMS+EIN · · Score: 4, Insightful

    ``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.
    1. Re:Holy Confusion Batman by spitzak · · Score: 2, Insightful

      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.

  22. Another bastardized Unix by t482 · · Score: 2, Insightful

    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.

  23. But will it be missed? by 3CRanch · · Score: 2, Insightful

    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.

  24. The trouble with cygwin by petermgreen · · Score: 2, Informative

    is its posix on win32 rather than posix on NT

    This makes certain things (most notablly select) rather difficult to implement and slow.

    --
    note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
  25. fork() and pipe() by squarooticus · · Score: 4, Interesting

    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.

    --
    [ home ]
    1. Re:fork() and pipe() by squarooticus · · Score: 2, Insightful

      One big advantage fork() has over threads:

      Fault isolation.

      There are between 10 and 50 people who have had some hand in most of the systems. So, let's face reality: there are going to be bugs. And while I've done my best to develop engineering paradigms that avoid the sorts of bugs that lead to segfaults, it's virtually impossible to guarantee correctness in these types of systems.

      To add an additional layer of protection between the main program and the various crappy libraries I have to interface with, I use fork(). A library has some fatal bug that causes my program to crash? No problem, because it's a child process! The main program is still running, serving other requests.

      --
      [ home ]
  26. Re:This should be interesting. by MightyMartian · · Score: 2, Insightful
    Negative spin? I'd love it if integration with *nix systems was more tightly bound to Windows. Hell, I'd love it if Microsoft would put in something like NFS support, so I wouldn't have to use that hideous Samba.

    If there was ever a necessary evil that remained evil, it's Samba. Not that I'm slagging the dedicated guys that keep trying to figure out MS's ever-changing mutilation of LANServer, but it is a sonofabitch to get working right.

    --
    The world's burning. Moped Jesus spotted on I50. Details at 11.
  27. Many a true word spoken in jest. by carldot67 · · Score: 5, Interesting

    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.

    --
    I wish at was Friday, but I dont want to wish my life away. So I wish it was last Friday.
    1. Re:Many a true word spoken in jest. by WWWWolf · · Score: 2, Insightful
      4. Creat compatibility layer: "WinBSD-API"

      If they really want to break the compatibility with Unix, they have to start adding e to creat()... =)

  28. You misspelled "VMS." by msauve · · Score: 2, Funny

    Just ask Dave Cutler.

    --
    "National Security is the chief cause of national insecurity." - Celine's First Law
  29. Never understood the name by vijayiyer · · Score: 4, Informative

    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.

  30. BillG claimed in 93 that NT was UNIX by Anonymous Coward · · Score: 2, Informative
    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 at last week's PC Expo in New York. "NT is a form of Unix. It will not replace Unix, but I expect it to be the most popular form of Unix."

  31. Re:Windows Vista to get POSIX subsystem by sconeu · · Score: 2, Informative

    NT4 actually had a (not very functional) POSIX subsystem. It was needed to get certain government contracts that specified POSIX. The POSIX subsystem was removed/deprecated in Win2K.

    --
    General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
  32. Somebody call Darl! by lexbaby · · Score: 2, Funny

    Unix interoperability integrated into the OS? They must be using UNIX source code. ;-)

    Somebody tell SCO!

    --
    lexbaby
    "Be Brave, Be Loyal, Be True." -- Hawkeye Pierce
  33. Re:Kill Interoperability? by RupW · · Score: 2, Informative

    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.

  34. Re:death of win32? by MerlinTheWizard · · Score: 2, Insightful

    Why would you want MS to embrace another platform than Win32(/64)? If I want U*ix, I'll use U*ix. I don't need to wait around for MS. Saying that Win32 is inherently unfunctional is pretty wild, though. I think it's functional enough. At least, on the desktop... although I think Linux/FreeBSD is getting there, and I feel more and more like switching to that for my desktop needs. I already run a professional server and also a "media" server at home on Linux.

    But you know, the main strategy of MS has not been exactly interoperability per se. They don't care to interoperate, unless the interoperability gives them that many more customers. I think their whole success is based on having had the "wisdom" to always be compatible on some level with the old technologies, whereas most of its competitors strove to market strong innovations. Innovation has always been last on MS's list, compatibility, first. That explains, amongst other things, why it's a lot more successful commercially than Apple. So, if some compatibility level with U*ix, maybe built in the next Windows version (and not as an add-on of some kind) proves to be able to attract a new, significant user base, then MS will do it. Not because they want to interoperate with others for the technological beauty of it, but to gain market.