Browsing MS-DOS sources on GitHub, I often see mentions of XENIX:


; XENIX calls all return error codes through AX.  If an error occurred then the    
; carry bit will be set and the error code is in AX.  If no error occurred then    
; the carry bit is reset and AX contains returned info.


; xenix memory calls for MSDOS


; 1.40 06/15/82 Tree structured directories.  XENIX Path Parser MKDIR CHDIR
;               RMDIR Xenix calls

There are even files called XENIX.ASM and XENIX2.ASM.

What's the story here? Did XENIX and DOS share source code?

  • It wouldn't shock me if MS-DOS was cross-compiled from XENIX at some point in time, here is a History of Xenix which might be illuminating. Of note, XENIX came first. Commented Aug 18, 2019 at 2:09

4 Answers 4


They didn't share any source, no. However, the TITLE directive twenty lines or so down from the top in both XENIX.ASM and XENIX2.ASM explains what this is:

TITLE   XENIX - IO system to mimic UNIX

Pre-2.x MS-DOS was somewhere between heavily inspired by CP/M and a complete rip-off of it. But with 2.x they decided to go in a quite different direction, and one of the huge differences was using directories and subdirectories, rather than user areas, to make it easier to organize files on disks expected to hold hundreds or even thousands of files.

Unfortunately, the CP/M API was entirely unsuited to this. The main problem was that CP/M (and MS-DOS 1.0) used file control blocks in the memory space of the program to hold information about files and their current state; changing the format of these was a breaking API change. (They couldn't be extended because older programs assumed they were a specific length, and nor could the "public" fields be changed without breaking older programs' expectations.)

Rather than just randomly rolling their own new API the MS-DOS 2.x developers looked elsewhere for inspiration, in this case at Unix via its derivative Xenix, a port of Unix to Intel processors done by Microsoft. Since the new API was modeled on the Unix/Xenix file I/O API, these new API calls were called "XENIX calls."

As well as providing an API that could handle the extra information about directories, this also changed the API to use "file handles" referencing data structures owned by DOS, rather than in the program's memory space, thus allowing these structures to be further changed in the future without breaking compatibility with older software. (APIs that had previously been direct manipulation of the FCB by the program now became functions that took and returned file handles, with the OS updating the data structures it owned.)

  • 23
    So sort of like "POSIX compliant", except not POSIX and not compliant :-) Commented Aug 15, 2019 at 2:40
  • 4
    @manassehkatz They wanted it to be POSIX compliant. They had to make concessions to IBM and CP/M compatibility. This was a time when MS thought UNIX is the future :)
    – Luaan
    Commented Aug 15, 2019 at 8:56
  • 16
    @Luaan: at the time that MS-DOS was written there was no such thing as "POSIX compliant". MS-DOS 1.0 dates to 1981. (And as 86-DOS it goes back to 1980). MS-DOS 2.0 came out in 1983. PC-DOS 3.0 was released in 1984. The POSIX standard came out in 1988. Commented Aug 15, 2019 at 11:39
  • 10
    Even though MS no longer thinks so, it turns out that UNIX is the future. :-) Commented Aug 15, 2019 at 19:13
  • 5
    @JohnBollinger: You're a few years behind the times. Now MS does think unix is the future again, which is why they have WSL/WSL2 - they just want you to be running it on top of their system. Commented Aug 17, 2019 at 18:29

The source code files in question appear to have the implementation for the MS-DOS 2.0 'XENIX-style' APIs to open/close/etc. files without a File Control Block used in MS-DOS 1.0 and CP/M.

I strongly suspect the authors used 'XENIX' as a shorthand for 'those new-fangled IO methods'.

Nowadays, of course, everyone uses the 'new-fangled' APIs and the FCB APIs have long since been removed.

  • 5
    16-bit FCB API was supported in Windows all the time until the whole 16-bit subsystem has been removed from 64-bit Windows. You could still use FCB API nowadays in a 16-bit DOS application running under 32-bit Windows 7. Commented Aug 15, 2019 at 8:23
  • 3
    @EgorSkriptunoff And 64-bit Windows only really removed the 16-bit subsystem because of Intel's decision to remove support for 16-bit code running in 64-bit mode on their CPUs. It's an annoying compatibility break, given how long both Intel and MS managed to support ancient DOS applications .)
    – Luaan
    Commented Aug 15, 2019 at 8:57
  • 1
    FCB's described the CP/M 8+3 filenames. XENIX probably refers to Unix path name strings instead. Commented Aug 15, 2019 at 9:45
  • 2
    @Gábor It's an observation that fits available data, but that makes it a mere correlation, without any causal links. 32 was compatible with 16 because it was possible, and Microsoft wanted to keep compatibility (because they understand it's the applications that sell OSes). 64 is not compatible with 32 because the CPU doesn't support that. There's no point in having a 16-bit subsystem if you can't actually run it on the CPU. Keep in mind that 64-bit Windows (except for XP) still have the full 32-bit Windows system; 16-bit support was already there, and had to be removed.
    – Luaan
    Commented Aug 15, 2019 at 11:36
  • 2
    @EricBrown. No. Virtual machines of today are not emulating the hardware, they are capable of providing the environment, with massive support from the CPU itself, so that a program running doesn't even know it runs in a box in a box in a box. But the individual CPU instructions and the hardware in general is not emulated, it's used directly (hence the native speed; actual emulators like the old PowerPC ones or later, Android emulators on Windows did emulate, together with the associated huge speed reduction).
    – Gábor
    Commented Aug 15, 2019 at 17:41

The major relationship between MS-DOS and Xenix is that both were Microsoft products. MS-DOS was originally 86-DOS, from Seattle Computer Products, and was licensed by MS to develop PC-DOS. Xenix was a version of Unix which Microsoft licensed from Bell Labs (which was legally prohibited from selling software to consumers) and re-sold.

  • 1
    And so when MS-DOS 2.0 imitated Unix features in its system calls, they used the word Xenix in the source code instaed, because that was a Microsoft trademark name they could safely use. To someone reading the code it's obviously that Xenix is a code word denoting "features cribbed from Unix".
    – Kaz
    Commented Aug 16, 2019 at 21:56
  • @kaz At that time it was probably unthinkable that the source code would ever be viewed outside of Microsoft. As BBC reported, a source code leak contained a lot of profanity news.bbc.co.uk/2/hi/technology/3485545.stm Commented Apr 4 at 12:46

I found the following in the history section of The MS-DOS Encyclopedia (around "Version 2"). Sorry for the long text but I could not find a good way to trim it without losing relevant details. Emphasis is mine.

In developing the first version, the programmers had had two primary goals: running translated CP/M-80 software and keeping MS-DOS small. They had neither the time nor the room to include more sophisticated features, such as those typical of Microsoft's UNIX-based multiuser, multitasking operating system, XENIX. But when IBM informed Microsoft that the next major edition of the PC would be the Personal Computer XT with a 10- megabyte fixed disk, a larger, more powerful version of MS-DOS--one closer to the operating system Microsoft had envisioned from the start--became feasible.

There were three particular areas that interested Microsoft: a new, hierarchical file system, installable device drivers, and some type of multitasking. Each of these features contributed to version 2.0, and together they represented a major change in MS-DOS while still maintaining compatibility with version 1.0.


Ultimately, it was a hierarchical file system that found its way into MS-DOS 2.0 and eventually convinced everyone that it was, indeed, the better and more flexible solution to the problem of supporting a fixed disk. The file system was logically consistent with the XENIX file structure, yet physically consistent with the file access incorporated in versions 1.x, and was based on a root, or main, directory under which the user could create a system of subdirectories and sub- subdirectories to hold files. Each file in the system was identified by the directory path leading to it, and the number of subdirectories was limited only by the length of the pathname, which could not exceed 64 characters.

In this file structure, all the subdirectories and the filename in a path were separated from one another by backslash characters, which represented the only anomaly in the XENIX/MS-DOS system of hierarchical files. XENIX used a forward slash as a separator, but versions 1.x of MS-DOS, borrowing from the tradition of DEC operating systems, already used the forward slash for switches in the command line, so Microsoft, at IBM's request, decided to use the backslash as the separator instead. Although the backslash character created no practical problems, except on keyboards that lacked a backslash, this decision did introduce inconsistency between MS-DOS and existing UNIX- like operating systems. And although Microsoft solved the keyboard problem by enabling the user to change the switch character from a slash to a hyphen, the solution itself created compatibility problems for people who wished to exchange batch files.

Another major change in the file-management system was related to the new directory structure: In order to fully exploit a hierarchical file system, Microsoft had to add a new way of calling file services.

Versions 1.x of MS-DOS used CP/M-like structures called file control blocks, or FCBs, to maintain compatibility with older CP/M-80 programs. The FCBs contained all pertinent information about the size and location of a file but did not allow the user to specify a file in a different directory. Therefore, version 2.0 of MS-DOS needed the added ability to access files by means of handles, or descriptors, that could operate across directory lines.

In this added step toward logical device independence, MS-DOS returned a handle whenever an MS-DOS program opened a file. All further interaction with the file involved only this handle. MS-DOS made all necessary adjustments to an internal structure--different from an FCB- -so that the program never had to deal directly with information about the file's location in memory. Furthermore, even if future versions of MS-DOS were to change the structure of the internal control units, program code would not need to be rewritten--the file handle would be the only referent needed, and this would not change.

Putting the internal control units under the supervision of MS-DOS and substituting handles for FCBs also made it possible for MS-DOS to redirect a program's input and output. A system function was provided that enabled MS-DOS to divert the reads or writes directed to one handle to the file or device assigned to another handle. This capability was used by COMMAND.COM to allow output from a file to be redirected to a device, such as a printer, or to be piped to another program. It also allowed system cleanup on program terminations.


At IBM's request, version 2.0 of MS-DOS also possessed the undocumented ability to perform rudimentary background processing--an interim solution to a growing awareness of the potentials of multitasking.

Background print spooling was sufficient to meet the needs of most people in most situations, so the print spooler, PRINT.COM, was designed to run whenever MS-DOS had nothing else to do. When the parent application became active, PRINT.COM would be interrupted until the next lull. This type of background processing, though both limited and extremely complex, was exploited by a number of applications, such as SideKick.

To summarize:

  1. With bigger disks, hierarchical organization of files has become necessary and MS chose the directory tree used by XENIX.
  2. The MS-DOS 1.x FCB APIs could not deal with directories, so they added new APIs which operated on file paths (instead of just name.ext) and returned handles, again apparently inspired by XENIX.
  3. [conjecture] To properly support print spooler, the free-for-all memory management of DOS 1.x ("all memory after the load address belongs to the user program") was no longer usable and DOS needed a way to track which memory area was used by which program. Apparently the memory management code was also borrowed from/inspired by XENIX.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .