MicroWeb 2.1 Brings XMS and File Downloads to a Real-Mode DOS Browser

MicroWeb 2.1 was published on March 12, 2026. The FreeDOS Project highlighted it ten days later. Its release notes list four changes: XMS memory support, simple file downloads, optimized memory use, and several bug fixes. Those additions expand a graphical browser designed for 16-bit real mode without changing its explicit limits: direct HTTP only, no CSS or JavaScript, and image rendering restricted mainly to GIF.

The target begins with an 8088

MicroWeb’s official README names an Intel 8088 or compatible processor as its minimum CPU and supports CGA, EGA, VGA, Hercules, and several machine-specific video modes. A mouse is helpful but not mandatory. Networking can use a normal interface with a DOS packet driver or a serial port through EtherSLIP.

The memory wording is more nuanced than “requires 640K.” The project says 640 KiB is desirable and that the browser can run with less. Extra EMS or XMS is recommended for heavier pages and images. Conventional-memory availability depends on drivers and resident programs, so two nominally identical 640 KiB machines may leave different amounts to the browser.

Version 2.1 added XMS alongside EMS

Extended Memory Specification support lets MicroWeb place suitable data outside the conventional-memory region when an XMS manager is available. This is not protected-mode execution: the browser remains a 16-bit real-mode application and calls the memory manager through its defined interface.

The command line exposes the distinction. -noxms disables XMS, while -noems disables Expanded Memory Specification use. A low-memory troubleshooting run can selectively remove one manager and compare behavior. -noimages avoids image decoders, and -useswap enables an explicitly experimental disk-swapping mode.

XMS cannot make a page arbitrarily large. The README still warns that complex pages may be truncated when RAM is insufficient. Memory optimization in 2.1 reduces pressure; it does not remove finite buffers, real-mode address constraints, or the cost of decoding content.

Simple downloads broaden the workflow

Before file-download support, a browser could help discover a resource while requiring another DOS client to retrieve it. Version 2.1’s simple download feature closes part of that gap for ordinary HTTP links. “Simple” is the important qualifier: the release note does not promise a modern download manager, resumable transfers, sandboxing, or authenticated cloud storage.

Downloaded executables and archives are untrusted input. MicroWeb does not provide a modern browser sandbox or malware reputation service, and DOS normally gives a running program broad access to the machine. Files should be transferred from known sources, verified with a published hash when available, and tested on a disposable disk image before reaching valuable data.

Web-format support is intentionally narrow

MicroWeb lays out basic HTML but does not implement CSS or JavaScript. It renders GIF images. For PNG and JPEG it can read dimensions for layout without decoding and displaying the image itself. Large or complicated pages can be cut off, and the mouse cursor is not currently visible in Hercules mode.

These boundaries explain why a site that is technically reachable may remain unusable. Modern navigation often depends on client-side scripts, CSS-controlled visibility, web fonts, complex forms, media codecs, or application APIs. MicroWeb’s purpose is not to reproduce a current Chromium engine on an 8088; it is to make a useful subset of documents and links accessible within period-compatible constraints.

HTTP-only access is a security boundary

MicroWeb does not implement TLS, so it cannot connect directly to HTTPS servers. Plain HTTP traffic can be observed or modified by any party controlling a network segment between browser and server. Passwords, session cookies, personal information, and software downloads should not be trusted over that path.

The project documents two bridges. A proxy such as retro-proxy can fetch HTTPS content and expose HTTP to the DOS machine, and FrogFind can present a simplified view of sites. A proxy moves TLS termination to another computer; it does not create end-to-end encryption between MicroWeb and the destination. The DOS-to-proxy segment must still be treated as cleartext and isolated accordingly.

The safe pattern is a controlled local network, a proxy maintained on a supported system, and no sensitive authentication through the DOS client. Disabling security on a modern server to accommodate the browser would widen risk far beyond the retro machine.

Networking depends on mTCP and a packet driver

MicroWeb uses Michael Brutman’s mTCP library for its network stack. The machine needs a packet driver matching the physical or emulated adapter, plus valid IP configuration. An NE2000 setting in an emulator is useful only if the corresponding DOS packet driver is loaded with the correct interrupt vector.

The project publishes prepared 360 KiB and 720 KiB FreeDOS boot images configured around an NE2000 adapter. Those are convenient test environments, not universal images for arbitrary Ethernet cards. The browser can also load a local HTML file, which allows layout testing without any network at all.

A current release for deliberately old constraints

MicroWeb 2.1 demonstrates active development without pretending old hardware has modern browser capabilities. XMS support and memory optimization help it handle more content; downloads reduce the need to switch tools; and bug fixes improve the narrow supported path.

The exact chronology is March 12 for the upstream GitHub release and March 22 for the FreeDOS news item. Keeping those dates separate preserves the difference between software publication and a distribution community drawing attention to it. The result is a real 2026 browser release whose design remains honest about what an 8088, real mode, and an HTTP-only stack can safely do.

Related:

Sources: