"To make it possible to write programs that could run on any UNIX system, IEEE developed a standard for UNIX, called POSIX, that most versions of UNIX now support. POSIX defines a minimal system call interface that conformant UNIX systems must support. In fact, some other operating systems now also support the POSIX interface."
-- Operating Systems Design and Implementation, 2nd ed., p. 11
Before the release of Minix 2.0.0, efforts were made to check it against the then-current version of the official POSIX standard, International Standard ISO/IEC 9945-1, also known as ANSI/IEEE Std 1003.1, First edition, 1990-12-07. The full name of the document is Information Technology -- Portable Operating System Interface (POSIX) part 1: System Application Programming Interface (API) [C Language]. There have been a number of revisions and extensions since 1990. As of early 2005, the latest version of the basic document is known as IEEE Std 1003.1, 2004 Edition, Single UNIX Specification Version 3 .
Hard copy is available from the IEEE (Institute of Electrical and Electronics Engineers) in New York. It's expensive, however. Even paying to have a PDF document e-mailed to you is quite expensive. You can get information on purchasing IEEE documents on-line at http://standards.ieee.org/. You might also do well to look in the engineering library of a local university.
Possibly more useful than the IEEE document, and certainly considerably less expensive, is the book POSIX Programmer's Guide, by Donald Lewine, published by O'Reilly. It's listed at about US$35 on Amazon, with used copies from US$16 (prices noted Feb 2005) .
The Open Group (http://www.opengroup.org/) has the Single Unix Specification online. They want you to register, but you can read documents on-line for free. You can also buy hard copy or text on CD-ROMs, from their site, but these are expensive, too.
Well, maybe... in principle, yes, but many systems (Minix included) provide extensions to the basic C library functions defined by POSIX, so you may have to deal with these in porting a program. Also, standards, no matter how carefully defined, may contain elements that can be interpreted more than one way. Many things outside the scope of a standards document may make porting a program difficult. The GNU version of the make(1) utility, for instance, provides facilities that are not present in the Minix version; you might have to either port GNU make first or devote some effort to modifying a Makefile before you could compile on Minix a package developed on a GNU-ish system. Finally there may be basic assumptions about system resources that affect how a program works. One that often affects Minix users is the lack of virtual memory -- programmers writing for environments that provide virtual memory may assume that memory is effectively unlimited. This is very much a problem with 16-bit Minix; for 32-bit Minix it is becoming less problematic as newer computers come equipped with amounts of physical memory undreamed of just a few years ago.
In March 2006 an article by Peter Seebach, Standards and specs: Not by UNIX alone, subtitled A maze of twisty little standards, all alike was posted on IBM's developerWorks site.
This article discusses the history of Unix standards and the relationship of a number of operating systems to the standards. It also makes a useful distinction: "UNIX" (all capitals) is a trademark, there are legal implications to claiming a system is UNIX. But "Unix" (not all caps) is a name for a design philosophy. If we accept this distinction we can certainly call Minix a variety of Unix.If you would like to pursue this topic further, Seebach provides additional references. Particularly noteworthy is Eric Raymond's Unix Standards chapter in his The Art of Unix Programming.
|[HOME]||[HINTS/FAQ]||[MINIX DOWNLOADS]||[CONTRIB SOFTWARE]|