On Dec 14, 2009, at 6:16 AM, John D. Earle wrote:
I am already familiar with SUA and it doesn't make Windows POSIX complaint in a way that I would call genuine.
full POSIX compliance for certain Microsoft Windows products." I also grant you that the Microsoft POSIX subsystem only supported
I grant you that certain aspects of Windows POSIX support have earned it the "DeathStation 9000" label, but it's genuine enough to have earned this claim in the Wikipedia entry for POSIX: "Microsoft Windows Services for UNIX 3.5 – enables the 1990 version of POSIX and has been described as "close to useless". But of SUA it has been said "As of 2004, server versions of Windows have a POSIX subsystem that supports threads, signals, sockets, and shared memory, less than twenty years after the standard was finalized, and only a little over a decade after Microsoft began advertising POSIX compliance."
It was something I evaluated. There was no point in your mentioning that it exists unless you had ulterior motives.
"ulterior: being intentionally concealed so as to deceive". Nope. You said that Apple and Microsoft hadn't gone down the POSIX line. I pointed out that current MacOS _is_ a Unix; until today I've relied on Single Unix Specification version 3 documents to guide my Mac programming which makes it close enough for me. Today I downloaded the SUSv4 spec (POSIX 2008). I also pointed out that Windows NT had a fully compliant POSIX subsystem, by design, and that Microsoft cared at least enough about POSIX support to buy the company that made what is now SUA. For that matter, no version of Linux, no version of BSD, and no version of OpenSolaris is certified POSIX-compliant (open source projects change too fast for certification to be cheap). Microsoft can't "go the POSIX route" exclusively without killing their cash cow. VMS was the first POSIX-certified system, but that didn't mean DEC or VMS users abandoning VMS. zOS is POSIX-compliant, but I expect most sites running zOS have no intention of switching, and IBM have no intention of making them.
It isn't what they are telling you that matters; it is what they are not telling you. It is called a half truth. If Haskell wants to be saved, it has got to give up the lying.
What on earth is Haskell lying about? What does Haskell need to be saved from? (Its growing popularity and mushrooming library?)
Richard O'Keefe wrote:
I also pointed out that Windows NT had a fully compliant POSIX subsystem, by design, and that Microsoft cared at least enough about POSIX support to buy the company that made what is now SUA.
How does that explain things like fstat() and stat() returning different values for the same file: http://www.mega-nerd.com/erikd/Blog/Windiots/posix.html That bug exists in windows XP, Vista and 7.
For that matter, no version of Linux, no version of BSD, and no version of OpenSolaris is certified POSIX-compliant (open source projects change too fast for certification to be cheap).
For the last decade I have been the main author of libsndfile: http://www.mega-nerd.com/libsndfile/ a library that requires nothing of POSIX other than file I/O but needs to run on windows and *nix. You would think that Microsoft's much touted POSIX support would mean that the POSIX calls I used on *nix would JustWork(tm) on windows. Unfortunately, due to bugs in Microsoft's POSIX implementation this is not the case. Bugs include: - fstat() (64 bit file length aware version) returning the wrong file length after a write (win9x). - lseek() (64 bit file length aware version) to SEEK_END not actually going to the end of the file (win2000 and win2003). - fstat() and stat() returning different results on the same file (XP, Vista and 7). Because testing for and working around these bugs is simply too difficult, I have been forced to maintain tow versions of the file I/O code, one POSIX (that works on *nix including Mac OS X) and for windows, the native windows file I/O API. I suspect that authors of other open source projects that started on Linux and were then ported to windows would have similar stories of egregious unfixed bugs in Microsoft's POSIX implementation. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
Hello Erik, Monday, December 14, 2009, 5:44:22 AM, you wrote:
I also pointed out that Windows NT had a fully compliant POSIX subsystem, by design, and that Microsoft cared at least enough about POSIX support to buy the company that made what is now SUA.
How does that explain things like fstat() and stat() returning different values for the same file:
POSIX is a *subsystem*. you are using Win32 subsystem. There is also OS2 subsystem for execution of 16-bit OS/2 programs partial emulation of POSIX API in C compiler libraries has nothing common with subsystem implemented as part of the OS. you have never used POSIX subsystem actually (and btw, it's absent in Win9x line) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin wrote:
POSIX is a *subsystem*. you are using Win32 subsystem. There is also OS2 subsystem for execution of 16-bit OS/2 programs
partial emulation of POSIX API in C compiler libraries has nothing common with subsystem implemented as part of the OS. you have never used POSIX subsystem actually (and btw, it's absent in Win9x line)
Please enlighten me. How do I access the POSIX subsystem? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
Hello Erik, Monday, December 14, 2009, 1:02:58 PM, you wrote:
POSIX is a *subsystem*. you are using Win32 subsystem. There is also
Please enlighten me. How do I access the POSIX subsystem?
i don't know since i never tried. it seems that this is bad idea. if you really need it, it should be better to use cygwin POSIX subsystem was implemented by MS (and other major players) only to meet some bureaucratic reqs from DoD/UsGov, and i don't know any program really using it. just don't mix C library emulation of POSIX calls on top of Win32 with POSIX subsystem (btw, both are implemented on top of native Windows API) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Dec 14, 2009, at 11:16 PM, Bulat Ziganshin wrote:
POSIX subsystem was implemented by MS (and other major players) only to meet some bureaucratic reqs from DoD/UsGov, and i don't know any program really using it.
There are two separate things being confused here, maybe three. (0) "POSIX" functions in the Windows C library. (1) The original POSIX subsystem in Windows NT. As far as I know it isn't shipped any more. (2) Softway Systems' "Interix"/SFU/SUA. Microsoft bought Softway. Softway wrote Interix to make money out of people who wanted a workable Unix environment on Windows. This _is_ amongst other things a "subsystem", but it's NOT the one that was originally written to let weasels tick the "POSIX" box. I was talking about (2), not (1) or (0). This does matter for Haskell people wanting to use Haskell on Windows. It would be very interesting to know whether Haskell can be built to run under Services for Unix Applications (SUA) -- after all, Qt, SSH, Apache, and so on have been.
On Mon, 2009-12-14 at 21:02 +1100, Erik de Castro Lopo wrote:
Bulat Ziganshin wrote:
POSIX is a *subsystem*. you are using Win32 subsystem. There is also OS2 subsystem for execution of 16-bit OS/2 programs
partial emulation of POSIX API in C compiler libraries has nothing common with subsystem implemented as part of the OS. you have never used POSIX subsystem actually (and btw, it's absent in Win9x line)
Please enlighten me. How do I access the POSIX subsystem?
I'm not sure of all the details, but the program ends up getting linked differently. The GNU ld user guide says: --subsystem which:major.minor Specifies the subsystem under which your program will execute. The legal values for which are native, windows, console, posix, and xbox. You may optionally set the subsystem version also. Numeric values are also accepted for which. Duncan
Hello Duncan, Monday, December 14, 2009, 1:33:14 PM, you wrote:
Please enlighten me. How do I access the POSIX subsystem?
I'm not sure of all the details, but the program ends up getting linked differently. The GNU ld user guide says:
yes, it should be linked to other dlls. the catch is that RTS/stdlib uses subsystem-specific calls, so you will need to write in assembler to ensure that your program don't use any Win32 calls :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Mon, 2009-12-14 at 21:02 +1100, Erik de Castro Lopo wrote:
Bulat Ziganshin wrote:
POSIX is a *subsystem*. you are using Win32 subsystem. There is also OS2 subsystem for execution of 16-bit OS/2 programs
partial emulation of POSIX API in C compiler libraries has nothing common with subsystem implemented as part of the OS. you have never used POSIX subsystem actually (and btw, it's absent in Win9x line)
Please enlighten me. How do I access the POSIX subsystem?
(1) Install Services for Unix. (2) Start it. You are now running bash staring at something rather like Unix. (3) Build programs using c89, which comes with it, but needs MSVC, or gcc, which you can download from http://www.suacommunity.com/tool_warehouse.htm
On Dec 14, 2009, at 03:44 , Bulat Ziganshin wrote:
POSIX is a *subsystem*. you are using Win32 subsystem. There is also OS2 subsystem for execution of 16-bit OS/2 programs
Microsoft dropped both of those some time back (specifically the "subsystem" mechanism, that is). Some parts of the subsystems migrated elsewhere, though. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
On Dec 14, 2009, at 3:44 PM, Erik de Castro Lopo wrote:
Richard O'Keefe wrote:
I also pointed out that Windows NT had a fully compliant POSIX subsystem, by design, and that Microsoft cared at least enough about POSIX support to buy the company that made what is now SUA.
How does that explain things like fstat() and stat() returning different values for the same file:
http://www.mega-nerd.com/erikd/Blog/Windiots/posix.html
That bug exists in windows XP, Vista and 7.
I did mention the "DeathStation 9000" label it has earned.
I actually got that from your web site. I got this bug report there
too.
I am an anti-Microsoft bigot. I go around saying that if this
University were really opposed to software piracy, we'd ban all
Microsoft products. But I hope you like horror stories, because
in _this_ case, while all sanity and practicality are on one side,
Microsoft are fully within their legal rights to be on the other.
The Single Unix Specification, version 4 (POSIX.1-2008) defines
what fstat(), fstatat(), stat(), and lstat() should do to st_size for
- shared memory objects
- typed memory objects
- symbolic links
For other file types,
the structure members st_mode, st_ino, st_dev, st_uid,
st_gid,st_atim, st_ctim, and st_mtim shall have meaningful
values and the value of the member st_nlink shall be set to
the number of links to the file.
That is, st_size is specifically *not* defined and need *not* have
"meaningful values".
The description of st_size in
You would think that Microsoft's much touted POSIX support would mean that the POSIX calls I used on *nix would JustWork(tm) on windows. Unfortunately, due to bugs in Microsoft's POSIX implementation this is not the case. Bugs include:
- fstat() (64 bit file length aware version) returning the wrong file length after a write (win9x).
It doesn't have to return ANYTHING sensible, EVER, for a regular file.
- lseek() (64 bit file length aware version) to SEEK_END not actually going to the end of the file (win2000 and win2003).
That one looks like a real bug. Is it still there in Vista and Windows 7?
- fstat() and stat() returning different results on the same file (XP, Vista and 7).
They don't have to return ANYTHING sensible, EVER, for regular files, and they DON'T have to agree. You are completely absolutely 100% right that the {,f}stat() issues are deplorable and that any company having a decent respect for its customers would fix the problem. But it _is_ legal POSIX behaviour. Which is why I'm not so terribly impressed when John Earle said that about Apple and Microsoft not adopting POSIX. POSIX is fine, but it isn't perfect. Microsoft shows that "adopting" POSIX doesn't ensure producing something _good_; Apple show that not quite adopting POSIX doesn't mean what you have is necessarily _bad_. Can we get back to "How Can Haskell Be Saved" now?
participants (6)
-
Brandon S. Allbery KF8NH -
Bulat Ziganshin -
Derek Elkins -
Duncan Coutts -
Erik de Castro Lopo -
Richard O'Keefe