Ttdfjt

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

DOSSYM.ASM:

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

ALLOC.ASM:

;
; xenix memory calls for MSDOS
;

MSHEAD.ASM:

; 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?

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

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.

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.

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.