The portable operating-system interface for Unix, 16-bit computing and the OS/2 subsystem will ‘be lost’ along with some legacy transport protocols, product manager for the Windows 64-bit client says.
Some Legacy Subsystems Won’t Get Windows 64-Bit Support
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
If Microsoft really wanted to support a POSIX subsystem or a Unix migration tool then they could do the same thing as CoLinux with *BSD rather than the broken POS that is the Posix Subsystem and SFU. Of course they dont want a working POSIX subsystem because that would allow people to write applications that were not just tied to Windows.
This is step in the right direction. Not having that garbage in there will make Windows more stable. If you absolutely must run a 16-bit app, you could use a virtual machine like VMWare or Virtual PC.
Will disposal of the POSIX subsystem include WinSock? It seems to me a lot of apps rely on WinSock…or is it just MY code in my eternal quest to not learn the W32 APIs?
-braddock
im not sure if they can dump all the 16bit parts, alot of installers for 32bit apps invoke the ntdvm and wowexec, which are the 16bit emulation environments on 2k/xp. I have seen that many many times.
i guess we will find out
16-32 bit api’s can be supportted b Virtual PC which will probaly be built in like Apples classic emulation. It wouldn’t be hard, and those programs wouldstill get a speed boost because longhorn’s requirements are so huge that it should be able to emulate all 7 of the computers currently in my house without a hiccup.
That way you windows users can still get your daily dose of BSOD’s just for fun.
I’m fairly sure there won’t be much sleep lost over this.
@hrm: interesting point, and something I’ve wondered about before- why on Earth does InstallShield still use 16-bit code in the installer stub?? And would migrating to pure MSI files for installations solve the problem?
I’m sure people that use these will miss them, but as a user who doesn’t. I can’t wait to see them depart!! I wonder what other things they’re going to nix with regards to backward compatibility.
Also, does this mean that 16-bit dos apps will not work as well (not that i mind that either)? Or does it just apply to win16 binaries.
This is step in the right direction. Not having that garbage in there will make Windows more stable.
Maybe for the WOW bit, but from what I recall, the OS/2 and the (neutered) POSIX subsystems ran along side the Win32 one, therefore not really affecting stability or performace in any way.
It’s good to remove crufty bits, but it’s not always good to remove compatibility. I’m assuming that so few people use such apps any more that Microsoft feels justified in doing this, but like you say, they could always spend twice as much on their software, and get not only the new OS, but a copy of VMware or VirtualPC.
Like you, I agree with what they are doing here, but I do not agree with your reasoning.
“16-32 bit api’s can be supportted b Virtual PC which will probaly be built in like Apples classic emulation. It wouldn’t be hard, and those programs wouldstill get a speed boost because longhorn’s requirements are so huge that it should be able to emulate all 7 of the computers currently in my house without a hiccup.
That way you windows users can still get your daily dose of BSOD’s just for fun.”
Windows 64 bit extended is not longhorn though a version of longhorn will have the extensions as well.
buy an amd64 today and run the beta os today for free via dl from ms site. this os is due to go gold this year, not 2006 with longhorn.
at the launch of Apple’s Mac OSX 10.1, a microsoft Mac unit spokesman commented that now that Apple and Windows both had a degree of POSIX-compliance porting of applications would become a lot easier.
I take it that’s no longer on the table….
As I understand it, one of the engineering tradeoffs AMD made in x86-64 was removing the virtual 8086 mode necessary for 16-bit compatibility, so this is a hardware issue that could not have been resolved any other way short of writing an emulator and is really not too surprising.
As for POSIX, my guess is that it simply doesn’t make sense to bother maintaining it when it was generally regarded as pretty bad (to put it nicely…). Besides, SFU, which is much better (albeit not perfect) is also available for free. At the very least, there’s always coLinux and Cygwin.
I suspect that the reasoning for OS/2 is much simpler. OS/2 is dead and there is no strategic incentive to continue maintaining the compatibility mode. Besides, IBM never ported OS/2 to 64-bit hardware, so it would have been a pointless waste of effort.
All in all, there’s nothing to see here. Move along…
Isnt posix compliance mandatory for government use?
The native POSIX subsystem that comes with Windows 2000/XP is POSIX 1003.3, the POSIX subsystem that comes with SFU is more up to date and why include the POSIX system when SFU is just a download away and is free and that is the way to go. OS/2 is very rarely used anymore so I can see the cutting of support for the OS/2 subsystem as a positive thing.
isnt posix compliance mandatory for government use?
Yes.
Since Windows NT includes a POSIX.1 subsystem, it is enough to get it certified for government use.
However, POSIX.1 conformance provides a _bare minimum_ of functionality and does not include real time and threading extensions (POSIX.1b and POSIX.1c respectively).
sure you can run win XP 64 bit but with out any libraries you can’t run much including office, mozilla(I never liked IE), games, or basically just about every other app. there is only a handful of specialty apps for winXP 64 bit.
Instead just install a 64 bit linux distro, and get all the toys you could want. Price the same extra software availble linux several thousand ports farther along.
just for the record I lke BSOD’s as well. since I am running a WinMe machine for games.
yeah, going to a pure .msi should remove any 16bit-ness
>> Peragrin: sure you can run win XP 64 bit but with out any libraries you can’t run much including office, mozilla(I never liked IE), games, or basically just about every other app. there is only a handful of specialty apps for winXP 64 bit.
That’s false. Windows XP for AMD64 runs 32-bit applications alongside the applications that have been retargeted for AMD64.
I thought Cygwin relied on the POSIX subsystem of NT based systems to function. Does this pull the rug out from under them? Or does Cygwin provide its own POSIX environment independent of the OS subsystem underpinnings?
A Swedish version? What is it with the swedes? A Swedish IE for Mac, a Swedish Flash Player, a Swedish Windows XP 64-bit, but no Dutch version of them! Why? Because there are three to four time as much speakers of Dutch? Because there are more .nl hosts than hosts in any other European TLD?
Besides that, I do not entirely understand taking out the 16-bit Windows subsystem, as it is more an emulator than anything else (unlike the POSIX or OS/2 subsystems). I could understand it if they leave it out in Longhorn, but why in XP-64? Why don’t they try to make it as similar as possible to the normal version? Money can’t be the problem, so why then?
Thanks for the info Paul.. So will adding SFU to the install make it compliant? Will SFU work on Longhorn when released? Or are they going to change the compliance standard since windows is “dominant”.
how much better would windows 64 for amd64 be if m$ junked all old api’s kept for compatibility reasons and streamlined it and updated it, squeezing every little ounce out of the addition 8GPR’s.
> Besides that, I do not entirely understand taking out the 16-bit Windows subsystem, as it is more an emulator than anything else (unlike the POSIX or OS/2 subsystems). I could understand it if they leave it out in Longhorn, but why in XP-64? Why don’t they try to make it as similar as possible to the normal version? Money can’t be the problem, so why then?
“Blame” AMD. They removed the virtual 8086 mode in AMD64, so if you want to run DOS, you’ll need an emulator (like bochs).
OS2 and POSIX subsystem are not present on Windows XP.
A yes thanks for the push.. I went to technet and found this article that seems to state the iterix subsytem adds this.
So i guess SFU adds this.. So Thanks ALL!
There seems to be a lot of confusion out there as to how one goes about running old 16bit setup programs for 32bit apps, and how 32bit apps work at all on Win64. Here are three great articles that cover these issues:
16bit installer stub support still in Win64:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wi…
This is accomplished by substituting ported 32bit versions of popular 16bit installer stubs on-the-fly.
32bit app support on Win64 (and a great explanation of what “Win64” means):
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dn…
Scroll down to the WOW64 section for an explanation of 32bit subsystem “emulation.” Works just like support for 16bit apps on Win32 currently functions.
More detailed explanation of just the WOW64 for 32bit app support:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wi…
Yes, they’re all from MSDN. No, I’m not shilling for M$…right now
…other server-side programs like Apache on Windows and stuff like PHP? MySQL?
will posix absence mean that these programs won’t run anymore on XP for AMD64?
at the launch of Apple’s Mac OSX 10.1, a microsoft Mac unit spokesman commented that now that Apple and Windows both had a degree of POSIX-compliance porting of applications would become a lot easier.
I can’t imagine how it would have mattered in the first place, given the vast majority of OS X apps are targetted at Cocoa, not POSIX…
> I can’t imagine how it would have mattered in the first place, given the vast majority of OS X apps are targetted at Cocoa, not POSIX…
Do you really think that? What about all the CLI apps? (gcc, …)
krammit wrote:
> I thought Cygwin relied on the POSIX subsystem of NT based systems to function.
Well, it does not.
It is a client to the win32 subsystem instead.
> Does this pull the rug out from under them?
No, read above. Internix/SFU more or less does though.
> Or does Cygwin provide its own POSIX environment
Yes.
> independent of the OS subsystem underpinnings?
No. It relys on win32.
(As such should be portable to any system providing a win32 compatible API (ie: WINE.))
The native NT API is still largely undocumented (thus you cannot roll your own ntdll.dll level lib) …
I cant help but think this might have something to do with the (LGPL) licence of the NT POSIX.1 utilities: http://www.tburke.net/info/reskittools/topics/posix.htm (Look for “Copyright Notice”.)
Also, i wonder if U/WIN* could still be made to work:
http://www.research.att.com/sw/tools/uwin/
16-bit installers
Microsoft has worked together with installer writers, and now ships with Windows the 32 bit ports of the most used installer stubs (like WISE and InstallShield). The flexible “shim” (runtime patching) engine introduced in Windows 2000 Service Pack 3 handles the on-the-fly replacement of the installer stub.
POSIX subsystem
Nobody has ever used it, nor will. It was a very basic kernel, and came with next to no utilities (pax archiver, ln, vi and a few others, most of which came with Resource Kits). Softway Systems rewrote it as an usable environment and sold it under the product name of OpenNT. Microsoft bought it back, renamed it Interix and sold it for US$ 100. It’s now part of Services For UNIX, which comes for free. Interix, for the record, is a microkernel BSD-like. It supports POSIX threads, SysV IPC, BSD sockets, and even low-level features like position-independent code and shared object semantics. It doesn’t come with its own X server (yet). It has decent Win32 interoperability, in the measure a basically stand-alone system can.
OS/2 subsystem
Ancient, even by OS/2 standards. It only runs 16-bit executables.
Cygwin
Cygwin is unaffected by this. Since it has to work on Windows 95/98 too, it’s very self-contained. In fact, I doubt any program makes use of POSIX for Windows NT. It’s more likely that such third-party subsystems use the low-level Windows support for certain POSIX features, like forking of processes – features that are definitely going to stay, because Interix depends on them.
Even worse, it only runs 16-bit *text-mode* OS/2 executables.
Some of the older OS/2 utilities one can find on FTP sites and such might still work in such an environment, but people have been writing 32-bit OS/2 code for well over ten years, so the OS/2 subsystem in question was pretty much without value anyway even to an OS/2 user.
So all the 64bit versions of Windows (for AMD64/Intels copy of it and Itanium) won’t/don’t have support for 16 bit (Windows 3.x and DOS) programs. MS makes some installers work by replacing them on the fly with compatible 32 bit versions, so that popular 32 bit software using these installers can be installed on win64. Afaik, they used the same hack to make some Win9x/me only software (mostly games) work on Win XP, the EXE is detected and replaced with a patched one upon execution of the program. So XP is very “compatible” 🙂
I wonder if they will drop DOS and 16bit support from the 32 bit versions of longhorn, too …