Editing DNIX (section)

== History ==

=== Inception at DIAB in Sweden ===
[[File:DIAB system binders.jpg|thumb|System binders for DIAB DS90 and D-NIX]]
Dataindustrier AB (literal translation: computer industries shareholding company) was started in 1970 by Lars Karlsson as a [[single-board computer]] manufacture in [[Sundsvall]], [[Sweden]], producing a [[Zilog Z80]]-based computer named ''Data Board 4680''.{{clarify|reason=Clearly they weren't producing a Z80-based computer in 1970, as the Z80 didn't exist in 1970.|date=March 2020}} In 1978, DIAB started to work with the Swedish television company [[Luxor AB]] to produce the home and office computer series [[ABC 80]] and [[ABC 800]].

In 1983 DIAB independently developed the first [[Unix]]-compatible machine, DIAB DS90 based on the [[Motorola 68000]] CPU. D-NIX here made its appearance, based on a [[UNIX System V]] license from [[AT&T Corporation]]. DIAB was however an [[industrial control system]] (automation) company, and needed a [[real-time operating system]], so the company replaced the AT&T-supplied UNIX [[Kernel (operating system)|kernel]] with their own in-house developed, yet compatible real-time variant. This kernel was inspired by a Z80 kernel named ''OS.8'' created for Monroe Systems division of [[Litton Industries]].<ref name="rskap5">{{cite book
 | last = Sjöström
 | first = Roland
 | title = Positionering under strategisk osäkerhet - Luxor Datorer och persondatorbranschen
 | series = Linköping Studies in Management and Economics, Dissertations no 30
 | volume = 2
 | year = 1996
 | publisher = Ekonomiska institutionen, Linköpings tekniska högskola
 | publication-place = Linköping
 | isbn = 91-7871-699-3
 | issn = 0345-7524
 | pages = 73–100
 | chapter = 1981 Introduktionen av ABC 800
 }}</ref><ref name="rskap6">{{cite book|chapter=1982 Ökad konkurrens och specialisering|first=Roland|isbn=91-7871-699-3|issn=0345-7524|last=Sjöström|pages=101–122|publication-place=Linköping|publisher=Ekonomiska institutionen, Linköpings tekniska högskola|series=Linköping Studies in Management and Economics, Dissertations no 30|title=Positionering under strategisk osäkerhet - Luxor Datorer och persondatorbranschen|volume=2|year=1996}}</ref>

Over time, the company also replaced several of the UNIX standard userspace tools with their own implementations, to the point where no code was derived from UNIX, and their machines could be deployed independently of any AT&T UNIX license. Two years later and in cooperation with Luxor, a computer called [[ABC 1600]] was developed for the office market, while in parallel, DIAB continue to produce enhanced versions of the DS90 computer using newer versions of the Motorola CPUs such as [[Motorola 68010]], [[Motorola 68020|68020]], [[Motorola 68030|68030]] and eventually [[Motorola 68040|68040]]. In 1990 DIAB was acquired by [[Groupe Bull]] who continued to produce and support the DS machines under the brand name ''DIAB'', with names such as ''DIAB 2320'', ''DIAB 2340'' etc., still running DIABs version of DNIX.<ref>[http://www.df.lth.se/~triad/diab/ Historien om DIAB – Dataindustrier AB]</ref>

=== Derivative at ISC Systems Corporation ===
ISC Systems Corporation (ISC) purchased the right to use DNIX in the late 1980s for use in its line of [[Motorola]] [[68k]]-based banking computers. (ISC was later bought by [[Olivetti]], and was in turn resold to [[Wang Laboratories|Wang]], which was then bought by [[Getronics]]. This corporate entity, most often referred to as 'ISC', has answered to a bewildering array of names over the years.)  This code branch was the [[SVR2]] compatible version, and received extensive modification and development at their hands. Notable features of this [[operating system]] were its support of [[demand paging]], [[diskless workstation]]s, [[multiprocessing]], [[Asynchrony (computer programming)|asynchronous]] [[input/output]] (I/O), the ability to mount processes (handlers) on directories in the [[file system]], and [[message passing]]. Its [[real-time operating system|real-time]] support consisted largely of internal [[event-driven architecture|event-driven]] queues rather than list search mechanisms (no 'thundering herd'<ref>[http://www.citi.umich.edu/projects/linux-scalability/reports/accept.html Accept() scalability on Linux]</ref>), static process priorities in two classes (run to completion and timesliced), support for contiguous files (to avoid [[fragmentation (computer)|fragmentation]] of critical resources), and memory locking. The quality of the [[orthogonal#Derived meanings|orthogonal]] asynchronous event implementation has yet to be equalled in current commercial operating systems, though some approach it. (The concept that has yet to be adopted is that the synchronous marshalling point of all the asynchronous activity could also be asynchronous, ad infinitum. DNIX handled this with aplomb.)  The [[asynchronous I/O]] facility obviated the need for [[Berkeley sockets]] ''select'' or [[SVR4]]'s [[STREAMS]] ''poll'' mechanism, though there was a socket emulation library that preserved the socket semantics for backward compatibility. Another feature of DNIX was that ''none'' of the standard utilities (such as ''ps'', a frequent offender) rummaged around in the kernel's memory to do their job. System calls were used instead, and this meant the kernel's internal architecture was free to change as required. The handler concept allowed network protocol stacks to be outside the kernel, which greatly eased development and improved overall reliability, though at a performance cost. It also allowed for foreign file systems to be user-level processes, again for improved reliability. The main file system, though it could have been (and once was) an external process, was pulled into the kernel for performance reasons. Were it not for this DNIX could well have been considered a [[microkernel]], though it was not formally developed as such. Handlers could appear as any type of 'native' Unix file, directory structure, or device, and file I/O requests that the handler could not process could be passed off to other handlers, including the underlying one on which the handler was mounted. Handler connections could also exist and be passed around independent of the file system, much like a [[Anonymous pipe|pipe]]. One effect of this is that [[text terminal]] (TTY) like ''devices'' could be emulated without needing a kernel-based [[pseudo terminal]] facility.

An example of where a handler saved the day was in ISC's diskless workstation support, where a bug in the implementation meant that using [[named pipe]]s on the workstation could induce undesirable resource locking on the fileserver. A handler was created on the workstation to field accesses to the afflicted named pipes until the appropriate kernel fixes could be developed. This handler required approximately 5 [[kilobyte]]s of code to implement, an indication that a non-trivial handler did not need to be large.

ISC also received the right to manufacture [[DIAB]]'s DS90-10 and DS90-20 machines as its file servers. The multiprocessor DS90-20's, however, were too expensive for the target market and ISC designed its own servers and ported DNIX to them. ISC designed its own [[GUI]]-based diskless workstations for use with these file servers, and ported DNIX again. (Though ISC used Daisy workstations running Daisy DNIX to design the machines that would run DIAB's DNIX, there was negligible confusion internally as the drafting and layout staff rarely talked to the software staff. Moreover, the hardware design staff didn't use ''either'' system!  The running joke went something like: "At ISC we ''build'' computers, we don't ''use'' them.")  The asynchronous I/O support of DNIX allowed for easy [[event-driven programming]] in the workstations, which performed well even though they had relatively limited resources. (The GUI diskless workstation had a 7&nbsp;MHz [[68010]] processor and was usable with only 512K of memory, of which the kernel consumed approximately half. Most workstations had 1 [[megabyte|MB]] of memory, though there were later 2 MB and 4 MB versions, along with 10&nbsp;MHz processors.)  A full-blown installation could consist of one server (16&nbsp;MHz [[68020]], 8 MB of RAM, and a 200 MB hard disk) and up to 64 workstations. Though slow to boot up, such an array would perform acceptably in a [[bank teller]] application. Besides the innate efficiency of DNIX, the associated [[DIAB]] C compiler was key to high performance. It generated particularly good code for the [[68010]], especially after ISC got done with it. (ISC also retargeted it to the [[Texas Instruments]] [[TMS34010]] graphics coprocessor used in its last workstation.)  The [[DIAB]] C compiler was, of course, used to build DNIX, which was one of the factors contributing to its efficiency, and is still available, in some form, through [[Wind River Systems]].

These systems are still in use as of this writing in 2006, in former [[Seattle-First National Bank]] branches now branded [[Bank of America]]. There may be, and probably are, other ISC customers still using DNIX in some capacity. Through ISC there was a considerable DNIX presence in [[Central America|Central]] and [[South America]].