R&A ships SysVIPC v3.5

SHARED MEMORY & SEMAPHORE EMULATION FOR NEXTSTEP/OPENSTEP
FREE UPGRADE FOR EXISTING CUSTOMERS

Contact: Info@RnA.nl

R&A announces the shipping of the v3.5 release of SysVIPC. Changes with respect to version v3.4 are (see release notes):
1. Usable with NEXTSTEP code that uses POSIX (compile and link with -posix flag). See the special notes on POSIX-compatibility and source licensing below.
2. one bug fix.
Existing license holders may use the current version under their current license. Prices have not changed, with the exception of source licensing, see below.

Product description

SysVIPC offers NEXTSTEP programmers the possibility to use Unix System V style shared memory and semaphores in their code, thus enhancing portability on one side and easier porting of existing applications that use the Unix System V shared memory and semaphore API. System V style IPC is used widely on SunOS, Ultrix and most System V Unix implementations for interprocess synchronisation and is not part of the NEXTSTEP developer libraries. Operating systems that include that API are (besides System V Unix implementations) for instance Digital Corporation's Ultrix 4.x and Sun Microsystem's SunOS 4.x BSD-style Unix implementations as well as more recent BSD-style Unix implementations.

The implementation does not need any change on the systems where programs created with SysVIPC are executed. Just installing on the developer system is normally enough.

The following library calls are supported:
	semctl, semget, semop,
	shmctl, shmget, shmat, shmdt,
	ftok
The following programs are included:
	ipcs,  ipcrm
The software license allows copies of the executables of icps and icprm to be shipped with your product.

The implementation is as good as 100% complete (sometimes even more than complete). There are a few minor incompatibilities and some extra compatibilities beyond the API on the implementation level. These differences are (implementation level compatibilities are marked with '+', incompatibilities are marked with '±' and remarks are marked with 'o'):

+ Shmids and semids are system-wide unique -- as most System V-like implementations, including those of Ultrix and SunOS.  This means that you can create, for instance, a semaphore set with semget() in one process, scribble the semid obtained by that down, and use it directly in another process to access that same semaphore set. 
    This is important especially when porting programs that use this feature of the common implementations (which appear to be many). For a strict implementation of the API this is not necessary. Code from systems like SCO Unix (where the ids are on a per process basis) is not affected by the added  functionality of system-wide id uniqueness.

± You cannot give away a semaphore- or shared-memory id to another user unless you are the super user.  A semid or shmid is owned by a single user at a time, just like a file.  (on System V it can be owned by the creator and another user.)
    Not being able to give away has to do with the general possibility on System V to give away things to other users. On System V, for instance, you can give away files. This behaviour is neither part of Mach nor  of BSD. Our implementation is not loaded in the kernel, but runs in user space. Therefore, we had to choose between API compatibility and security. We chose to implement the latter, since in most situation this behaviour is not used anyway.

Semaphores:

± all semop() and semctl() operations require READ + WRITE access to the semid, even those that according to the documentation only need READ access. This incompatibility is automatically lifted by our implementation for semaphores that are from the same owner.
    This incompatibility also has to do with our choice for security vs. completeness. In almost all cases developers will not be affected, since mostly semaphore operations are from one and the same user.

Shared memory:

+ a single shmid can be attached multiple times by the same program (to different addresses) -- this is the behaviour of most System V implementations, including those of Ultrix and SunOS, but it is usually not clearly documented.
    Another beyond-the-API compatibility that is useful for porting existing code.

o all shmids require at least READ access in order to be useful Ð this is also true of System V shmids, but again, is usually not clearly pointed out.

± shmat() and shmdt() cannot update the shmid_ds control structure if the shmid is read-only.    
    Another security vs. API conflict for a user-space implementation.

 ± the emulation is not aware of processes that do not explicitly detach their shared memory segments before exiting.  In short, the `shm_nattch' count may not reflect the actual number of segments attached.
    This would need some sort of server process, or a kernel implementation. Since we use a user-space implementation, we had to leave out the server for improved speed (and ease of use on the client side). The obvious solution is that your code should 'behave' and explcitely detach their shared memory before exiting.

o the shmctl() commands SHM_LOCK and SHM_UNLOCK are currently not implemented -- these are used in other implementations to lock/unlock the shared memory segment in physical memory, i.e., to avoid swapping (for performance?)    
    The API defined behaviour is not affected by ignoring these. They are also impossible to implement in a user-space implementation. Also speed is not really affected by leaving these out.
    
NB: We advise strongly against using the "beyond the API" parts of System V shared memory and semaphores when developing new code. The availablity of this behaviour is not guaranteed on other systems (e.g. SCO Unix), thus diminishing the portability of your code.

You might wonder why we did not choose for a kernel-space implementation. Kernel loadable would have to be loaded on every machine that you run your software on. This implies heavy system administration and a big burden for anybody who wants to sell products that use our implementation. The user-space implementation does not have that disadvantage and is also inherently more safe to use. Any error in our implementation (of which b.t.w. we are not aware that there exists one) will not bring down the kernel, but merely a user process.

Use with POSIX 

From release 3.1 until release 3.3, NEXTSTEP has a POSIX implementation, consisting of an adapted compiler frontend (-posix flag), adapted header files, a library and changes in the kernel. NEXTSTEP's POSIX implementation contains a bug that (among others) cripples SysVIPC. OPENSTEP (4.0, 4.1 and 4.2), the successor to NEXTSTEP, does not contain the posix library anymore, but still contains the kernel support so that NEXTSTEP 3.x posix applications may run under OPENSTEP. Sadly, the kernel support still has that same bug.

R&A has found a way around this bug. This will be marketed seperately under the name noposix. The binary distribution of SysVIPC v3.5 ships with this workaround in place at no additional charge. The workaround coms with some risks (race conditions), so not using POSIX under NEXTSTEP remains the preferred choice. The workaround is inactive (except for a single test) when the program is not a POSIX program.

Price and ordering information

Prices as of 28/11/97 (may change without notice). Prices are in dutch guilders.

License cost

License		Price		Edu use
1st CPU binary		Dfl 1000		shareware
2nd ± 5th CPU binary	Dfl 800		shareware
6th ± 50th CPU binary	Dfl 600		shareware
51th ± 100th CPU binary	Dfl 400		shareware
All other CPU's		Dfl 200		shareware
Source license		10 times binary**)	NA

**) see below under Source licensing for additional fees.

There is no runtime fee (so in general, just a few licenses are enough for any organisation, just on the developer side, and source licenses are for sites who require source control over as many parts of their product as possible). 

Note: SysVIPC is shareware for educational 'use', not for educational 'users'. This implies that you can use it for educational uses in commercial environments and you can't use it for commercial purposes in educational environments.

Edu shareware means: we'd like to get money from you but it is not required. Send us money if you really like the package. Commecrial use of course implies that you have to buy a license.

Prices are without shipping, handling and VAT (Dutch VAT is 17.5%).  Customers outside the European Union do not pay VAT. Customers inside the EU do, unless they send us their VAT registration number.

Source licensing

As of version 3.5, SysVIPC can be source licensed in two forms:
1. non-POSIX capable version at 10 times of the cost of a binary version.
2. POSIX-capable version also at 10 times of the cost of a binary version, but this source license is only sold in combination with a source license for noposix.

Shipping and handling

The SysVIPC v3.5 binary distribution is shipped as Multiple Architecture Binary  for Intel 486, Motorola m68k, Hewlett-Packard PA-RISC and SPARC architectures.

SysVIPC is distributed via the Internet. The fully functional binary distribution can be found in the directory:

	ftp://ftp.nluug.nl/pub/comp/next/SysVIPC/

We handle non-electronic shipping (floppy) on request. We charge:

Destination		Shipping
The Netherlands		Dfl 15
Europe		Dfl 20
Rest of the world		Dfl 25

How to order your license

Customers in the Netherlands may send a written order. A bill will be enclosed with the shipment. All other customers have to pre pay. No credit cards accepted.
 The best way to pay is to go to a bank that has access to SWIFT. Customer pays money transfer cost of both sides (which should normally lie around Dfl 15 per side). When ordering, please tell us if you want a floppy-distribution or if you just want to obtain a license.

Bank to send money to:
ABM-AMRO Bank
Kneuterdijk 8
The Hague
The Netherlands
Account: 40.16.84.016 R&A
Information: what you purchase and where to send it.
In general: give as much info as you can.

We do accept certified cheques. They should be written out in Dfl.
Eurocheques are accepted and there is no payment fee involved. Make sure the Eurocheque is written in Dfl.

Packaging

SysVIPC comes in an installer package for NEXTSTEP 3.1 or higher. The package includes full documentation in the form of Unix man pages, as well as the ipcs and ipcrm programs. Both library and programs are in MAB format for all supported architectures.

The source license comes with full sources for library, man pages and programs added to the mentioned binary installer package.

Contact

R&A
Goudreinetstraat 582
2564 PX Den Haag
The Netherlands
Fax: +31 70 4480031
Email: Info@RnA.NL

We prefer e-mail. NeXTmail and MIME welcome.

R&A is a small firm specialized in quality software design and implementation and consultancy. We are specialized in OO, Unix, NEXTSTEP and portability.

Acknowledgements

Ultrix is a trademark of Digital, SunOS is a trademark of Sun, SCO is a trademark of the Santa Cruz Operation, Unix is a trademark of USL, NEXTSTEP is a trademark of NEXT. All trademarks belong to their respective owners.