DNIX war ein Unix ähnliches Echtzeitbetriebssystem von der schwedischen Gesellschaft Dataindustrier AB (DIAB). Eine Version genannt ABCenix wurde auch für den ABC1600 Computer von Luxor entwickelt. (Erstklassige Systeme hatten auch etwas genannt Gänseblümchen DNIX an einigen ihrer CAD-Arbeitsplätze. Es war zum Produkt von DIAB ohne Beziehung.)

Geschichte

ISC Systems Corporation (ISC) hat das Recht gekauft, DNIX gegen Ende der 1980er Jahre für den Gebrauch in seiner Linie von Motorola mit Sitz in 68k Bankverkehrscomputer zu verwenden. (ISC wurde später von Olivetti gekauft, und wurde der Reihe nach Wang wieder verkauft, der dann von Getronics gekauft wurde. Diese korporative Entität, die meistenteils auf als 'ISC' verwiesen ist, hat auf eine verwirrende Reihe von Namen im Laufe der Jahre geantwortet.) Dieser Codezweig war die SVR2 vereinbare Version, und hat umfassende Modifizierung und Entwicklung an ihren Händen erhalten. Bemerkenswerte Eigenschaften dieses Betriebssystems waren seine Unterstützung der Nachfragepaginierung, diskless Arbeitsplätze, Mehrverarbeitung, asynchrone Eingabe/Ausgabe, die Fähigkeit, Prozesse (Dressierer) auf Verzeichnissen im Dateisystem und Nachrichtenübergang zu besteigen. Seine Echtzeitunterstützung hat größtenteils aus inneren Ereignis-gesteuerten Warteschlangen aber nicht Listensuchmechanismen (keine 'donnernde Herde'), statische Prozess-Prioritäten in zwei Klassen (geführt zur Vollziehung und timesliced), Unterstützung für aneinander grenzende Dateien bestanden (um Zersplitterung von kritischen Mitteln zu vermeiden), und Speicherblockierung. Der Qualität der orthogonalen asynchronen Ereignis-Durchführung muss noch in aktuellen kommerziellen Betriebssystemen, obwohl etwas Annäherung es gleichgekommen werden. (Das Konzept, das noch angenommen werden muss, ist, dass der gleichzeitige aufstellende Punkt der ganzen asynchronen Tätigkeit selbst ad infinitum asynchron sein konnte. DNIX hat das mit dem Selbstbewusstsein behandelt.) Die asynchrone Eingabe/Ausgabe-Möglichkeit ist das Bedürfnis nach Steckdosen von Berkeley begegnet ausgesuchte oder SVR4's STRÖME befragen Mechanismus, obwohl es eine Steckdose-Wetteifer-Bibliothek gab, die die Steckdose-Semantik für die rückwärts gerichtete Vereinbarkeit bewahrt hat. Eine andere Eigenschaft von DNIX war dass keines der Standarddienstprogramme (solcher als ps, ein häufiger Übertreter) durchstöbert ringsherum im Gedächtnis des Kerns, um ihren Job zu tun. Systemanrufe wurden statt dessen verwendet, und das hat bedeutet, dass die innere Architektur des Kerns frei war, sich wie erforderlich, zu ändern. Das Dressierer-Konzept hat Netzprotokoll-Stapeln erlaubt, außerhalb des Kerns zu sein, der außerordentlich Entwicklung erleichtert hat und gesamte Zuverlässigkeit, obwohl an Leistungskosten verbessert hat. Es hat auch Auslandsdateisysteme berücksichtigt, um Benutzerniveau-Prozesse wieder für die verbesserte Zuverlässigkeit zu sein. Das Hauptdateisystem, obwohl es gewesen sein könnte (und war einmal), ein Außenprozess, wurde in den Kern aus Leistungsgründen gezogen. Waren es nicht für diesen DNIX könnte als ein Mikrokern gut betrachtet worden sein, obwohl es als solcher nicht formell entwickelt wurde. Dressierer konnten als jeder Typ 'der heimischen' Datei von Unix, der Verzeichnisstruktur oder des Geräts erscheinen, und Dateieingabe/Ausgabe bittet, dass der Dressierer selbst nicht in einer Prozession gehen konnte, konnte anderen Dressierern einschließlich des zu Grunde liegenden ausgegeben werden, auf den der hander bestiegen wurde. Dressierer-Verbindungen konnten auch bestehen und unabhängig des filesystem viel wie eine Pfeife verteilt werden. Eine Wirkung davon besteht darin, dass ohne TTY ähnliche 'Geräte' wettgeeifert werden konnte, eine kernbasierte Pseudoendmöglichkeit zu verlangen.

Ein Beispiel dessen, wo ein Dressierer den Tag gespart hat, war in der diskless Arbeitsplatz-Unterstützung von ISC, wo ein Programmfehler in der Durchführung gemeint hat, dass das Verwenden genannt Pfeifen am Arbeitsplatz unerwünschte Quelle veranlassen konnte, die sich auf dem fileserver schließen lässt. Ein Dressierer wurde am Arbeitsplatz zu Feldzugängen zu den gequälten genannten Pfeifen geschaffen, bis die passenden üblen Kernlagen entwickelt werden konnten. Dieser Dressierer hat verlangt, dass etwa 5 Kilobytes des Codes, eine Anzeige durchgeführt haben, dass ein nichttrivialer Dressierer nicht groß zu sein brauchte.

ISC hat auch das Recht erhalten, den DS90-10 von DIAB und DS90-20 Maschinen als seine Dateiserver zu verfertigen. Die Mehrverarbeiter-DS90-20er-Jahre waren jedoch für den Zielmarkt zu teuer, und ISC hat seine eigenen Server entworfen und hat DNIX zu ihnen getragen. ISC hat entwickelt sein eigenes hat diskless Arbeitsplätze für den Gebrauch mit diesen Dateiservern GUI-basiert, und hat DNIX wieder getragen. (Obwohl ISC Arbeitsplätze von Daisy verwendet hat, die Daisy DNIX führen, um die Maschinen zu entwerfen, die den DNIX von DIAB führen würden, gab es unwesentliche Verwirrung innerlich als das Zeichnen und der mit dem Softwarepersonal selten geredete Lay-Out-Personal. Außerdem hat der Hardware-Designpersonal kein System verwendet! Der laufende Witz ist etwas gegangen wie: "An ISC bauen wir Computer, wir verwenden sie nicht.") Die asynchrone Eingabe/Ausgabe-Unterstützung von DNIX hat leichte Ereignis-gesteuerte Programmierung in den Arbeitsplätzen berücksichtigt, die eine gute Leistung gebracht haben, wenn auch sie relativ Mittel beschränkt hatten. (Der GUI diskless Arbeitsplatz hatte 7 MHz 68010 Verarbeiter und war mit nur 512K des Gedächtnisses verwendbar, dessen der Kern ungefähr Hälfte verbraucht hat. Die meisten Arbeitsplätze hatten 1 Mb des Gedächtnisses, obwohl es spätere 2-mb- und 4-Mb-Versionen zusammen mit 10-MHz-Verarbeitern gab.) Eine voll aufgeblühte Installation konnte aus einem Server (16 MHz 68020, 8 Mb des RAM und eine 200-Mb-Festplatte) und bis zu 64 Arbeitsplätze bestehen. Obwohl langsam, um zu starten, würde solch eine Reihe annehmbar in einer Bankerzähler-Anwendung leisten. Außer der angeborenen Leistungsfähigkeit von DNIX war der verbundene DIAB C Bearbeiter Schlüssel zur hohen Leistung. Es hat besonders guten Code für die 68010 besonders erzeugt, nachdem ISC damit getan wurde. (ISC hat es auch zu den Instrumenten von Texas TMS34010 in seinem letzten Arbeitsplatz verwendetes Grafikcoprozessor ins Visier wiedergenommen.) Der DIAB C Bearbeiter wurde natürlich verwendet, um DNIX selbst zu bauen, der einer der Faktoren war, die zu seiner Leistungsfähigkeit beitragen, und noch (in einer Form) durch Windflusssysteme verfügbar ist.

Diese Systeme sind noch im Gebrauch bezüglich dieses Schreibens 2006 im ehemaligen Seattle Zuerst Nationale Bankzweige haben jetzt Bank Amerikas gebrandmarkt. Es kann geben, und ist wahrscheinlich, andere ISC Kunden, die noch DNIX in etwas Kapazität verwenden. Durch ISC gab es eine beträchtliche DNIX Anwesenheit in Mittelamerika und Südamerika.

Asynchrone Ereignisse

Der heimische Systemanruf von DNIX war der dnix (2) Bibliotheksfunktion, die normalem Unix unix (2) oder syscall (2) Funktion analog ist. Es hat vielfache Argumente genommen, von denen das erste ein Funktionscode war. Semantisch hat dieser einzelne Anruf die ganze passende Funktionalität von Unix zur Verfügung gestellt, obwohl es von Unix syntaktisch verschieden war und, natürlich, zahlreich DNIX-nur Erweiterungen hatte.

DNIX Funktionscodes wurden in zwei Klassen organisiert: Typ 1 und Typ 2. Befehle des Typs 1 waren diejenigen, die mit der Eingabe/Ausgabe-Tätigkeit vereinigt wurden oder irgendetwas, was den Ausgabe-Prozess potenziell veranlassen konnte zu blockieren. Hauptbeispiele waren F_OPEN, F_CLOSE, F_READ, F_WRITE, F_IOCR, F_IOCW, F_WAIT und F_NAP. Typ 2 war der Rest, wie F_GETPID, F_GETTIME usw. Sie konnten durch den Kern selbst sofort zufrieden sein.

Um asynchronicity anzurufen, hat ein spezieller Dateideskriptor gerufen eine Falle-Warteschlange müsste über den Typ 2 opcode F_OTQ geschaffen worden sein. Ein Anruf des Typs 1 würde die F_NOWAIT-Bit-ODER-HRSG. mit seinem Funktionswert haben, und einer der zusätzlichen Rahmen zu dnix (2) war der Falle-Warteschlange-Dateideskriptor. Der Rückwert von einem asynchronen Anruf war nicht der normale Wert, aber ein kernzugeteilter Bezeichner. In solcher Zeit wie die asynchrone vollendete Bitte würde ein gelesener (2) (oder F_READ) des Falle-Warteschlange-Dateideskriptors eine kleine kerndefinierte Struktur zurückgeben, die den Bezeichner und Ergebnis-Status enthält. Die F_CANCEL Operation war verfügbar, um jede asynchrone Operation zu annullieren, die nicht noch vollendet worden war, war eines seiner Argumente der kernzugeteilte Bezeichner. (Ein Prozess konnte nur Bitten annullieren, die zurzeit allein im Besitz gewesen sind. Die genaue Semantik der Annullierung war bis zum Dressierer jeder Bitte, im Wesentlichen hat es nur bedeutet, dass jedes Warten begrenzt werden sollte. Eine teilweise vollendete Operation konnte zurückgegeben werden.) Zusätzlich zum kernzugeteilten Bezeichner war eines der jeder asynchronen Operation gegebenen Argumente 32 Bit benutzerzugeteilter Bezeichner. Das hat meistenteils in einem Funktionszeigestock zum passenden Unterprogramm Verweise angebracht, das die Eingabe/Ausgabe-Vollziehungsmethode behandeln würde, aber das war bloß Tagung. Es war die Entität, die die Falle-Warteschlange-Elemente lesen, der dafür verantwortlich war, diesen Wert zu interpretieren.

struct itrq {/* Struktur von Daten von der Falle-Warteschlange gelesen. * /

kurzer it_stat;/*-Status * /

kurzer it_rn;/*-Bitte-Zahl * /

langer it_oid;/*-Eigentümerpersonalausweis gegeben auf Anfrage * /

langer it_rpar;/* hat Parameter * / Zurückgegeben

};

</Quelle>

Des Zeichens ist, dass die asynchronen Ereignisse über gelesene Operationen des Deskriptors der normalen Datei gesammelt wurden, und dass solches Lesen selbst dazu fähig war, asynchron gemacht zu werden. Das hatte Implikationen für halbautonome asynchrone Ereignis-Berühren-Pakete, die innerhalb eines einzelnen Prozesses bestehen konnten. (DNIX 5.2 hatte Leichtgewichtsprozesse oder Fäden nicht.) Auch des Zeichens ist, dass jede potenziell blockierende Operation dazu fähig war, asynchron ausgegeben zu werden, so wurde DNIX gut ausgestattet, um viele Kunden mit einem einzelnen Server-Prozess zu behandeln. Ein Prozess wurde darauf nicht eingeschränkt, nur eine Falle-Warteschlange zu haben, so konnten Eingabe/Ausgabe-Bitten äußerst prioritized auf diese Weise sein.

Vereinbarkeit

Zusätzlich zum heimischen dnix (2) Anruf war ein ganzer Satz 'des Standards' libc Schnittstelle-Anrufe verfügbar.

offen (2), nahe (2), gelesen (2), schreiben (2), usw. Außer, nützlich für umgekehrt die Vereinbarkeit zu sein, wurden diese auf eine binär-vereinbare Weise mit dem NCR Turm-Computer durchgeführt, so dass Dualzahlen dafür kompiliert haben, würde unverändert unter DNIX laufen. Der DNIX Kern hatte zwei Falle-Fahrdienstleiter innerlich, ein für die DNIX Methode und ein für die Methode von Unix. Die Wahl des Fahrdienstleiters war bis zum Programmierer, und beide verwendend, war austauschbar annehmbar. Semantisch waren sie identisch, wo auch immer Funktionalität überlappt hat. (In diesen Maschinen wurde die 68000 Instruktion für den unix (2) Anrufe und die Instruktion für dnix (2) verwendet. Die zwei Falle-Dressierer waren wirklich ziemlich ähnlich, obwohl [gewöhnlich verborgen] unix (2) Anruf den Funktionscode im D0-Register des Verarbeiters gehalten hat, wohingegen dnix (2) es auf dem Stapel mit dem Rest der Rahmen gehalten hat.)

DNIX 5.2 hatte keine Netzwerkanschlussprotokoll-Stapel innerlich (abgesehen vom dünnen X.25-basierten Ethernet Protokoll-Stapel, der durch ISC für den Gebrauch durch sein diskless Arbeitsplatz-Unterstützungspaket hinzugefügt ist), der ganze Netzwerkanschluss wurde durch das Lesen und das Schreiben Dressierern geführt. So gab es keinen Steckdose-Mechanismus, aber ein libsocket (3) hat bestanden, der asynchrone Eingabe/Ausgabe verwendet hat, um mit dem TCP/IP Dressierer zu sprechen. Das typische Berkeley-abgeleitete Netzwerkanschlussprogramm konnte kompiliert und unverändert geführt werden (modulo üblicher Unix, der Probleme trägt), obwohl es so nicht effizient sein könnte wie ein gleichwertiges Programm, das heimische asynchrone Eingabe/Ausgabe verwendet hat.

Dressierer

Unter DNIX konnte ein Prozess verwendet werden, um Eingabe/Ausgabe-Bitten zu behandeln und den filesystem zu erweitern. Solch ein Prozess wurde einen Dressierer genannt, und war eine Haupteigenschaft des Betriebssystems. Ein Dressierer wurde als ein Prozess definiert, der mindestens eine Bitte-Warteschlange, ein spezieller Dateideskriptor besessen hat, der auf eine von zwei Weisen beschafft wurde: mit einem F_ORQ oder einem F_MOUNT-Anruf. Der erstere hat eine isolierte Bitte-Warteschlange erfunden, deren ein Ende dann normalerweise an einen Kinderprozess weitergegeben wurde. (Das Netz entfernte Ausführungsprogramme, von denen es viele gab, hat diese Methode verwendet, Standardeingabe/Ausgabe-Pfade ihren Kindern zur Verfügung zu stellen.) Haben sich die Letzteren in den filesystem festgehakt, so dass Dateieingabe/Ausgabe-Bitten von Dressierern angenommen werden konnten. (Die Netzanmeldungsprogramme, von denen es noch mehr gab, haben diese Methode verwendet, Standardeingabe/Ausgabe-Pfade ihren Kindern zur Verfügung zu stellen, weil die Semantik der Protokollierung in unter Unix verlangt, dass sich ein Weg für vielfache Prozesse vielleicht ohne Beziehung auf dem Standardeingabe/Ausgabe-Pfad dem Maschinenbediener einmischt.) Einmal bestiegen auf einem Verzeichnis im filesystem hat der Dressierer dann alle Eingabe/Ausgabe-Anrufe zu diesem Punkt erhalten.

Ein Dressierer würde dann kleine kernzugeteilte Bitte-Datenstrukturen von der Bitte-Warteschlange lesen. (Solches Lesen konnte gleichzeitig oder asynchron getan werden, wie der Autor des Dressierers gewünscht hat.) Der Dressierer würde dann tun, dass jede Bitte, die erforderlich ist, häufig mit dem DNIX F_UREAD und F_UWRITE-Anrufe zufrieden zu sein, zu lesen und in den Datenraum der Bitte zu schreiben, und dann die Bitte passend mit F_TERMIN begrenzen würde. Ein privilegierter Dressierer konnte die Erlaubnis seines Kunden für individuelle Bitten annehmen, Dressierer (wie der filesystem) über den F_T1REQ-Anruf unterzuordnen, so brauchte es nicht das Erlaubnis-Schema des Untergebenen wieder hervorzubringen. Wenn ein Dressierer unfähig war, eine Bitte selbst zu vollenden, konnte die F_PASSRQ-Funktion verwendet werden, um Eingabe/Ausgabe-Bitten von einem Dressierer zu einem anderen zu passieren. Ein Dressierer konnte einen Teil der Arbeit durchführen, die vor dem Weitergeben des Rests einem anderen Dressierer gebeten ist. Es war für einen Dressierer sehr üblich, orientierte Zustandmaschine zu sein, so dass Bitten, die es von einem Kunden aufs Feld schickte, alle asynchron getan wurden. Das hat einen einzelnen Dressierer zu Feldbitten von vielfachen Kunden gleichzeitig ohne sie berücksichtigt, einander unnötigerweise blockierend. Ein Teil der Bitte-Struktur war der Prozess-Personalausweis und sein Vorrang, so dass ein Dressierer wählen konnte, was man am auf dieser Information gestützten ersten arbeitet, gab es keine Voraussetzung, dass Arbeit, in der Ordnung durchgeführt werden, es gebeten wurde. Um darin zu helfen, war es möglich, sowohl Bitte als auch Falle-Warteschlangen zu befragen, um zu sehen, ob es mehr vor dem Klemmen zu betrachtende Arbeit gab, es wirklich zu tun.

struct ireq {/* Struktur der eingehenden Bitte * /

kurzer ir_fc;/*-Funktion codiert * /

kurzer ir_rn;/*-Bitte-Zahl * /

langer ir_opid;/*-Eigentümerpersonalausweis, den Sie auf dem offenen oder Gestell * / gegeben

haben

langer ir_bc;/*-Byte zählt * /

langer ir_upar;/*-Benutzerparameter * /

langer ir_rad;/* Zufällige Adresse * /

ushort ir_uid;/*-Benutzerpersonalausweis * /

ushort ir_gid;/*-Benutzergruppe * /

time_t ir_time;/*-Bitte-Zeit * /

ulong ir_nph;

ulong ir_npl;/*-Knoten und Prozess-Personalausweis * /

};</Quelle>

Es gab keine besondere Beschränkung der Zahl von Bitte-Warteschlangen, die ein Prozess haben konnte. Das wurde verwendet, um Netzwerkanschlussmöglichkeiten chroot Gefängnissen zum Beispiel zur Verfügung zu stellen.

Beispiele

Eine Anerkennung des Dienstprogrammes von Dressierern an ISC Dressierern zu geben, hat bestanden für:

• ausländischer filesystems
• MS-DOS
• CD-ROM/ISO9660
• Plattenbilddateien
• RAM-Platte (für den Gebrauch mit schreibgeschützten Stiefelplatten)
• Netzwerkanschluss von Protokollen
• DNET (im Wesentlichen X.25 über Ethernet, mit der Mehrwurf-Fähigkeit)
• X.25
• TCP/IP
• DEZ LAT
• AppleTalk
• entfernter filesystems
• Der/net/machine/path/from/its/root von DNET...
• NFS
• entfernte Anmeldung
• ncu (DNET)
• telnet
• rlogin
• wcu (DNET GUI)
• X.25 POLSTER

DEZ LAT

• entfernte Ausführung
• rx (DNET)
• remsh
• rexec
• Systemerweiterung
• windowman (GUI)
• vterm (xterm ähnlicher)
• Dokument (Kontobuch) Drucker
• dmap (ruptime Analogon)
• windowmac (GUI Tor zu Macintosh)
• System flickt
• genannter Pfeife-Dressierer

Die Erweiterungen von ISC

ISC gekauft beider 5.2 (SVR2 vereinbar) und 5.3 (SVR3 vereinbar) Versionen von DNIX. Zur Zeit des Kaufs erlebte DNIX 5.3 noch Entwicklung an DIAB, so war DNIX 5.2, was aufmarschiert wurde. Mit der Zeit haben die Ingenieure von ISC die meisten Eigenschaften ihres 5.3 Kerns in 5.2, in erster Linie geteiltes Gedächtnis und IPC vereinigt, also gab es etwas Abschweifung von Eigenschaften zwischen DIAB und Versionen von ISC von DNIX. Die wahrscheinlichen 5.3 von DIAB haben fortgesetzt, mehr SVR3-Eigenschaften zu enthalten, als die 5.2 von ISC damit geendet haben. Außerdem ist DIAB zu DNIX 5.4, ein SVR4 vereinbarer OS weitergegangen.

An ISC haben sich Entwickler beträchtlich ausgestreckt ihre Version von DNIX 5.2 (nur verzeichnet sind Eigenschaften, die den Kern selbst einschließen), gestützt sowohl auf ihren Bedürfnissen als auch auf den allgemeinen Tendenzen der Industrie von Unix:

• Arbeitsplatz-Unterstützung von Diskless. Der Kern des Arbeitsplatzes filesystem wurde entfernt, und durch einen X.25-basierten Ethernet Kommunikationsstummel ersetzt. Der Dateiserver-Kern wurde auch mit einem Paarungsbestandteil erweitert, der die entfernten Bitten erhalten hat und ihnen einer Lache von Kernprozessen für den Dienst gereicht hat, obwohl ein Standarddressierer geschrieben worden sein könnte, um das zu tun. (Später in seinem Produktlebenszyklus hat sich ISC aufgestellt Standard hat Unix Server im Platz der DNIX Server SVR4-basiert. Diese haben X.25 STRÖME und ein Gewohnheitsschriftliches Dateiserver-Programm verwendet. Trotz der weniger effizienten Strukturierung hat die rohe Pferdestärke der Plattformen gemacht für einen viel schnelleren Server verwendet. Es ist unglücklich, dass dieses Dateiserver-Programm die ganze Funktionalität des heimischen DNIX Servers nicht unterstützt hat. Heikle Dinge, wie genannte Pfeifen, haben nie überhaupt gearbeitet. Das war eine andere Rechtfertigung für den genannten Pfeife-Dressierer-Prozess.)
• gdb watchpoint Unterstützung mit den Eigenschaften des MMU von ISC.
• Die asynchrone Eingabe/Ausgabe zum filesystem wurde echt gemacht. (Ursprünglich hat es irgendwie blockiert.) Kernprozesse (kprocs, oder Fäden) wurden verwendet, um das zu tun.
• Unterstützung für ein Bruchband - oder strace ähnliches Programm. Zusätzlich zu einigen Reparaturen zu Programmfehlern im Standardmechanismus des einzelnen Tretens von Unix ptrace, dieses erforderliche Hinzufügen einer vorläufigen Prozess-Adoptionsmöglichkeit, so dass das Leuchtspurgeschoss den einzeln gehenden Standardmechanismus auf vorhandenen Prozessen verwenden konnte.
• SVR4 geben Mechanismus-Erweiterungen Zeichen. In erster Linie für den neuen HALT und die CONT-Signale, aber das Umgeben des neuen Signals kontrollieren Anrufe ebenso. Wegen des Mangels von ISC am Quellcode für den adb und die sdb Testhilfeprogramme konnte der u-page nicht modifiziert werden, so konnten die neuen Signale nur blockiert werden oder das Verzug-Berühren erhalten, konnten sie nicht gefangen werden.
• Unterstützung für das Netzschnüffeln. Dieses erforderliche Verlängern des Fahrers von Ethernet, so dass ein einzelnes Ereignis mehr als eine Eingabe/Ausgabe-Bitte und bedingt das Einführen der Hardware befriedigen konnte, die in der Software durchscheint, um gemischte Weise zu unterstützen.
• Widerspiegelnde Platte. Das wurde im filesystem und nicht dem Gerät-Fahrer getan, so dass ein bisschen (oder sogar völlig) verschiedene Geräte noch zusammen widergespiegelt werden konnten. Das Widerspiegeln einer kleinen Festplatte zum Floppy Disc war eine populäre Weise, das Widerspiegeln zu prüfen, wie das Ausstoßen des Floppy Discs eine leichte Weise war, Plattenfehler zu veranlassen.
• 32 Bit inode, Dateiname-Buchstaben 30, symbolische Verbindung und klebrige Verzeichniserweiterungen auf den filesystem. Hinzugefügter/dev/zero,/dev/noise,/dev/stdxxx, und/dev/fd/x Geräte.
• Prozess-Gruppe id Listen (von SVR4).
• #! direkte Schrift-Ausführung.
• Die Serienhafen-Multiplikation mit dem Z-80 von ISC hat VMEbus Kommunikationsvorstands-gestützt.
• Bewegliche Tausch-Teilung.
• Kern-'Müllkippe'-Schnellschüsse, Prozesse zu führen. Unterstützung für den Fuser-Befehl.
• Bearbeiten Sie wiedernette Funktion. Verbundenes Time-Sharing reprioritizer Programm, um Schwimmprioritäten durchzuführen.
• Ein Weg zum 'Becher' ein Prozess, sofort es aller Speichermittel beraubend. Sehr nützlich, um zu bestimmen, wie der aktuelle Arbeitssatz, im Vergleich damit ist, was noch dafür verfügbar ist, aber nicht notwendigerweise verwendet zu werden. Das wurde mit einem GUI Dienstprogramm vereinigt, den Status aller 1024 Seiten einer Speicherkarte eines Prozesses zeigend. (Dieser, die Zahl von Speicherseiten seiend, durch den MMU von ISC unterstützt.) Im Gebrauch würden Sie 'Becher' der Zielprozess regelmäßig durch sein Leben, und dann sehen Sie zu, um zu sehen, in wie viel Gedächtnis zurück getauscht wurde. Das war nützlich, weil die Produktionsumgebung von ISC nur einige langlebige Prozesse verwendet hat, ihre Speicheranwendung kontrollierend, und Wachstum Schlüssel zum Aufrechterhalten der Leistung war.

Eigenschaften, die nie hinzugefügt wurden

Als die DNIX Entwicklung an ISC effektiv 1997 aufgehört hat, wurden mehrere geplante OS-Eigenschaften auf dem Tisch verlassen:

• Geteilte Gegenstände. Es gab zwei dynamisch geladene Bibliotheken in der Existenz, einem encryptor für DNET und die Bildaufbereitung des GUI der Bibliothek, aber die Möglichkeit wurde nie verallgemeinert. Die Maschinen von ISC wurden durch einen allgemeinen Mangel am virtuellen Adressraum charakterisiert, so wäre der umfassende Gebrauch von mit dem Gedächtnis kartografisch dargestellten Entitäten nicht möglich gewesen.
• Leichtgewichtsprozesse. Der Kern selbst hatte bereits vielfache Fäden, die einen einzelnen MMU Zusammenhang geteilt haben, sollte das Erweitern davon zu Benutzerprozessen aufrichtig gewesen sein. Die API-Implikationen wären der schwierigste Teil davon gewesen.
• Zugriffsberechtigungslisten. Trivial, um das Verwenden eines ACL Dressierers durchzuführen, ist über das Lager filesystem gestiegen.
• Vielfache Tausch-Teilungen. DNIX hat bereits freien Raum auf dem ausgewählten Volumen für das Tauschen verwendet, es wäre leicht gewesen, ihm eine Liste von Volumina zu geben, um der Reihe nach potenziell mit verbundenen Raumgrenzen zu versuchen, um es davon abzuhalten, den ganzen freien Raum auf einem Volumen vor dem Weitergehen zum folgenden zu verbrauchen.
• Das entfernte Kernbeseitigen über gdb. Alle Stücke sollten dort tun es entweder durch den üblichen Serienhafen oder über Ethernet mit dem Kern hat X.25-Verbindungssoftware eingebettet, aber sie wurden nie versammelt.
• 68030 Unterstützung. Die Prototypen von ISC wurden nie vollendet. Zwei Verarbeiter-Huckepackeinfügefunktionskarten wurden gebaut, aber wurden als mehr nie verwendet als schneller 68020's. Sie waren nicht zuverlässig, noch waren sie so schnell wie sie könnten wegen der Notwendigkeit gewesen sein, eine 68020 Steckdose einzubauen. Der schnelle Zusammenhang, der ISC MMU umschaltet, würde arbeitsunfähig verlassen (und zusammen in vorgeschlagenen Produktionseinheiten ausgelassen), und der eingebettete der 68030 sollte statt dessen mit einer Ableitung der DS90-20er-Jahre MMU Code verwendet worden sein. Während der ISC MMU sehr effizient war und sofortige Schaltung unter 32 Residentprozessen unterstützt hat, wurde es in der Adressierbarkeit sehr beschränkt. Die 68030 MMU hätten viel mehr als 8 Mb des virtuellen Bereichs in einem Prozess berücksichtigt, der die Grenze des ISC MMU war. Obwohl dieser MMU langsamer sein würde, sollte die gesamte schnellere Geschwindigkeit der 68030 ihn mehr als wettgemacht haben, so dass, wie man erwartete, eine 68030 Maschine auf alle Weisen schneller war, und viel größere Prozesse unterstützt hat.

Siehe auch

• Zeitachse von Betriebssystemen