home *** CD-ROM | disk | FTP | other *** search
- Submitted-by: karish@pangea.Stanford.EDU (Chuck Karish)
-
- In article <1no7eqINN7f@ftp.UU.NET> peter@ferranti.com (peter da silva) writes:
- >
- >In article <1nja8cINNc45@ftp.UU.NET> jeffrey@netcom.com (Jeffrey Kegler)
- >writes a lot of good stuff about test-methods.
- >
- >And lest anyone think he's crying wolf, the crippled POSIX subsystem
- >described in Windows NT literature should be enough to show otherwise.
-
- I don't see why Microsoft's POSIX.1-in-a-box implementation
- should serve as an indictment of test methods standards.
- There's no reason to believe that it won't conform to the
- letter of the POSIX.1 standard. It's not productive to
- say "I know POSIX when I see it, and this ain't it".
-
- >But if that's not enough, I've run into situations where a vendor has
- >implemented a device driver in such a way that some features are totally
- >useless, and refused to fix them because they still conformed to the
- >SVID.
-
- The POSIX.3.1 test methods were never intended to be all-
- encompassing tests of the quality of POSIX.1 implementations.
- They were written to enable vendors to demonstrate that
- their systems provide standard interfaces that allow developers
- to port their code readily.
-
- >For example, a serial driver that would not let you raise DTR
- >after dropping it, either by closing it and reopening or by setting
- >B0 and then B2400, since the SVID didn't specify that you be able to
- >raise DTR again except by doing a "first open" with no control terminal.
-
- Peter, are you indicting the SVID or the SVVS? The SVID
- is a specifications document like POSIX.1, and the SVVS
- implements test methods for verifying SVID compliance.
-
- The task of weeding out systems that don't provide adequate
- usability belongs in the marketplace, not solely in the
- standards arena.
-
- --
-
- Chuck Karish karish@mindcraft.com
- (415) 323-9000 x117 karish@pangea.stanford.edu
-
-
- Volume-Number: Volume 31, Number 8
-
-