R&A SysVIPC v3.4 FREE FOR EDUCATIONAL USE AND DISTRIBUTED VIA THE NET

R&A CHANGES LICENSING CONDITIONS AND DISTRIBUTION SCHEME FOR SysVIPC v3.4

Contact: Info@RnA.nl

R&A today announces a change in the licensing conditions of SysVIPC v3.4. In short, these changes are:

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

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

2. Use for educational purposes is free. Note that it is 'educational use' and not 'educational users'. If you want to use SysVIPC for commercial activities, you still need a license.

Original version 3.4 announcement (with adapted prices) follows:

R&A SHIPS Quad-fat SysVIPC V3.4
SHARED MEMORY & SEMPAHORE EMULATION FOR NEXTSTEP
FREE UPGRADE FOR EXISTING CUSTOMERS *)

Version 3.4, second release

A new version due to shipping quad-fat (m68k, i486, hppa, sparc). Prices have changed to Dfl instead of US $. Two bugs have been fixed since pre-3.4 releases.

*) Contact Info@RnA.NL for details

Version 3.2

Version 3.2 differs from version 3 only with respect to POSIX support. The POSIX implementation and the BSD implementation of the directory functions and structures of NEXTSTEP 3.2 are not binary compatible. Version 3.2 of SysVIPC supports both.

Follows: the text of the original Version 3 release with adapted prices

R&A announces the shipping of the second release of SysVIPC: version 3. This version maximises the emulation completeness of the implementation within the constraints of security and speed. 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. 

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. 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. R&A, for instance,  used SysVIPC internally for the shared memory and semaphores when porting the University Postgres RDBMS (which is available as a separate product).

The implementation does not need any change on the systems where programs created with SysVIPC are executed. Just installing on the developer system is 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).

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 we are not aware that there exists one) will not bring down the kernel, but merely a user process.

The SysVIPC binary distribution is shipped as MAB  (Version 3.4 for Intel 486, Motorola m68k and Hewlett-Packard PA-RISC architectures).

Price and ordering information

Prices as of 24/2/96 (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

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.

Shareware means: we'd like to get money from you but it is not required. Send us money if you really like the package.

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.

Shipping and handling:

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

How to order

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).

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 on a 3.5" HD floppy disk. 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 3230851
Email: Info@RnA.NL

We prefer e-mail. NeXTmail 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.