Skip to content
FreeDOSDeep Dive Published Updated 7 min readViews unavailable

DOS Network Redirectors: INT 21h Assign Lists Versus Packet Drivers

Trace DOS network-drive mapping through the historical INT 21h redirector contract and distinguish remote filesystems from packet-driver TCP/IP access.

A DOS network connection can mean two different things. A packet driver exposes link-layer frames to a TCP/IP stack such as mTCP. A network redirector makes remote files or printers participate in DOS’s file/device namespace and provides the DOS kernel with the network-specific behavior needed to service those names. A successful PING through a packet driver does not imply that F: or a remote printer can be mapped, and a mapped DOS drive does not prove that a TCP/IP application can reach the Internet.

This article focuses on the historical Microsoft Networks INT 21h assign-list interface, especially function 5Fh, subfunctions 03h and 04h. The MS-DOS Encyclopedia documents 5F/03 as creating an assignment-list entry that redirects a local printer or disk drive to a network device. The reference explicitly states that Microsoft Networks must be running with file sharing loaded for the subfunction to work. Treat that as a redirector-specific DOS contract, not as a built-in FreeDOS network-filesystem guarantee.

The namespaces are different

A packet driver is normally discovered through a software interrupt selected when its resident adapter driver loads. It moves network frames for a client. A TCP/IP stack and application add IP addressing, routing, DNS, and protocols such as FTP. None of those layers necessarily teach DOS how to open a remote path such as F:\DATA\REPORT.DAT.

A redirector integrates at the DOS filesystem/device boundary. When an application asks DOS to open, read, write, or query a mapped path, the redirector participates in the file operation and communicates with a remote server or peer. The details depend on the network product. Microsoft Networks, LAN Manager, NetWare, and other historical products did not all share one universal installation procedure or server protocol, even when their DOS-facing compatibility overlapped.

The distinction prevents a common troubleshooting mistake: configuring a packet driver and then expecting a network drive letter to appear automatically. The packet API and DOS redirector API solve different problems. They may coexist in one system, but one does not subsume the other’s contract.

What function 5Fh/03h represents

The historical MS-DOS system-call reference describes function 5Fh, subfunction 03h, as “Get/Make Assign-List Entry.” In the documented call, BL selects a device type: 03h for printer and 04h for drive. DS:SI points to an ASCIIZ local device name buffer, and ES:DI points to the remote network device name. CX carries user data associated with the redirector’s entry. The call creates the assignment when the required network software is present. The related subfunction 02h can query assign-list entries by index in BX, but the documented successful return for 5F/03 does not specify an index register; do not assume that 5F/03 returns one.

Function 5Fh/04h cancels a previous redirection using an ASCIIZ local device name or network path in DS:SI, not the lookup index. The exact name limits, error behavior, and whether a particular redirector implements the service must be checked in that redirector’s documentation. Do not infer that every DOS kernel implements the network function itself; the call may be intercepted or serviced by a network redirector, and it can fail when the required network software is absent.

The call is not a command-line equivalent of modern net use in every environment. It is an API boundary for software that already has a compatible network redirector. A standalone FreeDOS installation with an Ethernet packet driver and mTCP tools has proved only the packet/TCP-IP path. It has not proved support for the Microsoft Networks assign-list contract, a remote drive filesystem, authentication, server shares, or file locking.

Map an assignment with explicit preconditions

Before calling a redirector function, establish the exact product and version, whether its file-sharing component is loaded, and the device names it accepts. The MS-DOS Encyclopedia’s documented precondition for 5F/03 is specific to Microsoft Networks; it should not be generalized to any program that happens to use TCP/IP. Use the redirector’s installation check and diagnostics rather than probing random subfunctions.

An illustrative conceptual request is:

AH = 5Fh       DOS network function family
AL = 03h       make an assignment-list entry
BL = 04h       drive device type in the documented interface
DS:SI -> ASCIIZ local device name buffer
ES:DI -> ASCIIZ remote name buffer
CX = redirector-defined user data
INT 21h

This is a register-level outline, not portable source code. A real implementation must use the exact network product’s published structure and buffer lengths, check the carry flag and error result, and preserve all registers required by its calling convention. The remote name is not safely constructed by concatenating unvalidated user input, and the example omits product-specific naming rules deliberately.

If software queries the list through subfunction 02h, treat the supplied BX index as an enumeration key for the running redirector’s list, not as a stable drive identity across reboot. Re-establish mappings after startup according to the redirector’s documented procedure, then verify that DOS can open and close a test file through the mapped path.

Operational validation from bottom to top

Test each layer independently:

  1. Confirm the adapter driver loads and its packet-driver interrupt responds.
  2. Verify link-level traffic and configure the chosen TCP/IP stack using its own guide.
  3. Confirm that the intended network client or redirector is installed and reports its required service available.
  4. Create a test assignment using the product’s documented interface or command.
  5. Open, read, write, close, and re-open a disposable test file through the mapped DOS path.
  6. Verify server-side contents and sharing behavior independently.

If step 2 passes but step 3 fails, changing packet-driver vectors is unlikely to create a missing filesystem redirector. If the mapping succeeds but OPEN fails, inspect the share name, server permissions, redirector state, local device table, and network error. A successful directory listing alone does not prove a write path, file-lock path, or safe handling of an interrupted transfer.

Network files introduce failure conditions absent from a local floppy: server loss, timeouts, partial writes, stale assignments, and sharing conflicts. The DOS call may return an error, but an application must still decide whether to retry, close state, preserve partial output, or ask an operator. Capture the immediate DOS error and use the redirector’s diagnostics for further detail. Do not retry a non-idempotent write blindly after an ambiguous disconnect, because the remote side may have committed some or all of it.

Boundaries for FreeDOS deployments

FreeDOS documentation describes packet-driver-based TCP/IP networking and mTCP workflows. That documentation is evidence for those clients, not evidence that a generic network drive redirector is included or that the Microsoft Networks 5F/03 call succeeds on every FreeDOS image. A FreeDOS environment may have third-party network software, a compatible redirector, or none of these. Record the installed packages and test the actual service required.

Avoid saying “networking works” after a single ping. State precisely whether the test established link frames, IP reachability, name resolution, an application protocol, or DOS filesystem redirection. This vocabulary makes incident reports actionable and prevents a packet-driver success from being mistaken for a working shared-drive integration.

For legacy software that requires a mapped drive, select a redirector whose published DOS interface and server protocol match the application. For an application designed around TCP/IP sockets, configure a packet driver and compatible stack. If the application uses DOS file calls, verify the redirector’s file-sharing and locking semantics under the real workload. These paths can be combined, but only through explicit compatible components.

The assign-list interface is valuable historical context for understanding how DOS network products connected local names to remote resources. Its operational lesson is more durable than any one function number: test the layer you actually need. A packet driver moves packets; a TCP/IP stack speaks network protocols; a DOS redirector translates file/device operations. Reliable operation requires evidence at each boundary and a recovery plan for partial or disconnected work.

Related:

Sources:

Comments