Send patches - preferably formatted by git format-patch - to patches at archlinux32 dot org.
summaryrefslogtreecommitdiff
path: root/floppy/doc/www.os2museum.com_wp_a-brief-history-of-unreal-mode.txt
diff options
context:
space:
mode:
authorAndreas Baumann <mail@andreasbaumann.cc>2022-09-02 09:18:52 +0200
committerAndreas Baumann <mail@andreasbaumann.cc>2022-09-02 09:18:52 +0200
commit52be99d8c0862ff87db9a4f9ccec1ac4b5f7caed (patch)
tree1a1a1c98090afd8459cc8f045f9de2d4a7cba5ab /floppy/doc/www.os2museum.com_wp_a-brief-history-of-unreal-mode.txt
parent15adaba9eaa6a98c8b55bc5c5f73c3a9e0e55e7a (diff)
added a quite unsorted first version of a floppy boot loader
Diffstat (limited to 'floppy/doc/www.os2museum.com_wp_a-brief-history-of-unreal-mode.txt')
-rw-r--r--floppy/doc/www.os2museum.com_wp_a-brief-history-of-unreal-mode.txt1626
1 files changed, 1626 insertions, 0 deletions
diff --git a/floppy/doc/www.os2museum.com_wp_a-brief-history-of-unreal-mode.txt b/floppy/doc/www.os2museum.com_wp_a-brief-history-of-unreal-mode.txt
new file mode 100644
index 0000000..a02d0be
--- /dev/null
+++ b/floppy/doc/www.os2museum.com_wp_a-brief-history-of-unreal-mode.txt
@@ -0,0 +1,1626 @@
+ #[1]OS/2 Museum » Feed [2]OS/2 Museum » Comments Feed [3]OS/2 Museum »
+ A Brief History of Unreal Mode Comments Feed [4]alternate [5]alternate
+ [6]alternate
+
+ [7]OS/2 Museum
+ OS/2, vintage PC computing, and random musings
+ [8]Skip to content
+ * [9]Home
+ * [10]About
+ + [11]Wanted List
+ * [12]OS/2 History
+ + [13]OS/2 Beginnings
+ + [14]OS/2 1.0
+ + [15]OS/2 1.1
+ + [16]OS/2 1.2 and 1.3
+ + [17]OS/2 16-bit Server
+ + [18]OS/2 2.0
+ + [19]OS/2 2.1 and 2.11
+ + [20]OS/2 Warp
+ + [21]OS/2 Warp, PowerPC Edition
+ + [22]OS/2 Warp 4
+ + [23]OS/2 Timeline
+ + [24]OS/2 Library
+ o [25]OS/2 1.x SDK
+ o [26]OS/2 1.x Programming
+ o [27]OS/2 2.0 Technical Library
+ + [28]OS/2 Videos, 1987
+ * [29]DOS History
+ + [30]DOS Beginnings
+ + [31]DOS 1.0 and 1.1
+ + [32]DOS 2.0 and 2.1
+ + [33]DOS 3.0, 3.1, and 3.2
+ + [34]DOS 3.3
+ + [35]DOS 4.0
+ + [36]DOS Library
+ * [37]NetWare History
+ + [38]NetWare Timeline
+ + [39]NetWare Library
+ * [40]Windows History
+ + [41]Windows Library
+ * [42]PC UNIX History
+ + [43]Solaris 2.1 for x86
+
+ [44]<- USB 0.9
+ [45]ANOMALY: meaningless REX prefix used ->
+
+A Brief History of Unreal Mode
+
+ Posted on [46]June 15, 2018 by [47]Michal Necasek
+
+ After a run-in with a particularly crazy manifestation of unreal mode
+ (Flat Assembler, or [48]fasm), I decided to dig deeper into the history
+ of this undocumented yet very widely used feature of 32-bit x86
+ processors.
+
+ For the purposes of this discussion, unreal mode is a variant of the
+ x86 real mode with non-standard segment limits and/or attributes,
+ different from the processor state at reset. To recap, real mode on the
+ 286 and later CPUs has much more in common with protected mode than
+ with the real (and only) mode of the 8086. Notably, undefined opcodes
+ raise exceptions, segment limit overruns cause general protection or
+ stack faults, and (on the 386 and later) 32-bit registers and 32-bit
+ addressing can be used--subject to limit checks.
+
+ The origins of unreal mode are shrouded in the mists of time. But
+ enough is known that certain outlines are quite clearly defined. Let's
+ present a rough timeline of unreal mode.
+ * 1985--the Intel 386 became available in silicon. Like the 286, the
+ 386 was not designed to switch from protected back to real mode.
+ Intel's idea was presumably that users should either leave the 386
+ in real mode, reset the CPU to get back to it (like a 286), or use
+ the 386's new V86 mode. This may sound like a crazy claim, but it's
+ not. In the October 15, 1991 issue of PC Magazine, page 436
+ ("Stepping Up"), Jeff Prosise [49]wrote quite clearly: "The very
+ first 80386 chips that rolled off the line (A-step chips) could not
+ be switched from protected to real mode." Indeed the confidential
+ Intel iAPX 386 Architecture Specification, revision 1.8 from June
+ 1985, had only this to say on the subject of switching from
+ protected back to real mode: "Disabling protection by loading a 0
+ into the PE bit in CR0 (assuming the current value is 1) will have
+ unpredictable effects." In other words, the original 386 design
+ tracked the 286: in real mode, segment limits and attributes retain
+ their initial reset values and cannot be changed.
+ * 1985?--someone or someones (Microsoft? Compaq?) convinced Intel to
+ relent and allow switching from protected to real mode by clearing
+ the PE bit in control register CR0; this was no doubt inspired by
+ the headaches the 286 was causing. It is unclear if there was
+ actual silicon change or only a documentation change. While a
+ transition to V86 mode always carefully loads all segment
+ registers, making any funny business impossible, the act of
+ clearing the PE bit in CR0 does almost nothing. It affects future
+ segment register loads in real mode, it affects interrupt and
+ exception dispatching, but it has near zero impact on the immediate
+ CPU state. Crucially, it does not change the current segment limits
+ or attributes, which allows the currently executing code to
+ continue running. Note that the I/O Permission Bitmap (applicable
+ in protected mode) was an even later addition to the 386 design.
+ * October 1985--The 386 datasheet (80386 High Performance
+ Microprocessor with Integrated Memory Management, Intel order no.
+ 231630-001), says in section 2.3.5: "In Real Address Mode, only the
+ base address is updated directly (by shifting the selector value
+ four bits to the left) [when loading segment registers], since the
+ segment maximum limit and attributes are fixed in Real Mode." In
+ section 2.3.4, the document says: "In Real Address Mode, the
+ maximum segment size is fixed at 64 Kbytes." In other words, this
+ document both explains why unreal mode works and claims that it
+ does not exist. The datasheet also declares in section 2.3.6 that
+ switching back to real mode is possible, but no additional detail
+ is given: "If PE [bit in CR0 register] is reset, the processor
+ operates again in Real Mode. PE may be set by loading MSW or CR0.
+ PE can be reset only by a load into CR0."
+ * January 8, 1986--Intel writes a confidential memo titled Returning
+ to real mode on the 80386. This memo explains not only how to set
+ up a canonical real-mode environment on return from real mode, but
+ also why it is necessary: "While operating in REAL mode, the 80386
+ uses exactly the same memory management functions as in protected
+ mode. However, when the part resets into real mode the values
+ loaded into the descriptors appear as if they were 8086 style
+ segments. In real mode, when a segment register is loaded, only the
+ base field is changed, in particular the value placed into the base
+ is selector*16. Since only the base is changed, it is necessary to
+ set the access rights while still in protected mode." The memo
+ proceeds to explain the required segment attribute setup,
+ information which appeared in the official 1986 PRM (Programmer's
+ Reference Manual) for the 80386. What the memo also says, and the
+ PRM does not, is that the code segment (CS) cannot be made writable
+ in protected mode, but "an architectural feature reloads real mode
+ attributes into the CS descriptor during real mode far jumps". This
+ memo explains real-mode operation of the 386 far better than the
+ official documentation, and serves unreal mode on a silver platter
+ to anyone willing to experiment even just a little.
+ * April 1986--The updated 386 datasheet, Intel order no. 231630-002,
+ offers a tantalizing hint of unreal mode in section 2.3.6:
+ "Resetting the PE bit [in CR0] is typically part of a longer
+ instruction sequence needed for proper transition from Protected
+ Mode to Real Mode." The quoted text was not present in the original
+ October 1985 edition of the datasheet, and presumably refers to the
+ information first published in the Jan '86 memo.
+ * 1986--The 1986 Intel 80386 Programmer's Reference Manual says that
+ to switch from protected to real mode, the programmer must among
+ other things transfer control to a code segment with 64K limit, and
+ load SS, DS, ES, FS, and GS segment registers with selectors that
+ have a 64K limit, are byte granular, expand-up, writable, and
+ present. Only then can CR0.PE be cleared. In other words, Intel was
+ practically begging programmers to see what happens when they don't
+ do that. The PRM publishes the how-to information from the Jan '86
+ memo, but none of the background explanation.
+ * 1987--In the 1987 edition of the 80386 System Software Writer's
+ Guide (Intel order no. 231499-001), in section 9.2 on page 9-3 (4th
+ para), Intel hints: "Because, except for base address, descriptor
+ register values cannot be loaded in real mode, 8086-compatible
+ attributes must be loaded into the data segment descriptor
+ registers before switching to real mode."
+ * January 15, 1988--Phoenix 386 BIOS with this date employs unreal
+ mode to emulate some aspects of the 286 LOADALL instruction, by
+ returning to real mode with segment bases not corresponding to the
+ segment register value. The date is tentative; this was the oldest
+ 386 BIOS using this technique available for analysis. More below.
+ * August 4, 1988--Microsoft adds 386 "Big Mode" or "Real Big Mode"
+ code to implement 386 extended memory moves in HIMEM.SYS 2.04.
+ Microsoft's method is quite clever, using an exception handler to
+ recover from anyone resetting the segment limits behind HIMEM's
+ back. Extended memory copying can thus be run with interrupts
+ enabled, with no impact on interrupt latency (that was a
+ significant problem on 286 CPUs). The term "unreal mode" is not
+ used. This change can be dated exactly, thanks to comments in
+ HIMEM.ASM. At the same time, LOADALL support was added to the HIMEM
+ 286 extended memory move.
+ * August 15, 1988--Microsoft makes an archive of the HIMEM.SYS 2.04
+ source code, with LOADALL usage removed but unreal mode code left
+ in place. It is unclear how widely this code was distributed at the
+ time. In 1992, the source archive from 1988 was published on
+ Softlib as part of [50]XMS.EXE, which contains the new XMS 3.0
+ specification. In the late 1980s and early 1990s, Microsoft
+ published the HIMEM.SYS source code together with the XMS 2.0
+ specification (the first published version was 2.01, before the
+ unreal mode code was added).
+ * February 7, 1989--Microsoft [51]publishes HIMEM.SYS version 2.06
+ source code as XMS20.ARC; unlike the previous release, this one
+ produces an exact match of the official binary, because the source
+ code includes 386 Real Big Mode and 286 LOADALL (yes, really!)
+ support.
+ * March 21, 1989--Microsoft publishes an updated HIMEM.SYS version
+ 2.06 source archive as S12023.EXE, formerly XMS20.ARC. This one
+ [52]survived to the present. Although the 1989 source code releases
+ were public, they seem to have gone more or less completely
+ unnoticed.
+ * 1989--In the 386 SX Microprocessor Programmer's Reference
+ Manual (order no. 140331-001), section 14.5 (Switching Back to
+ Real-Address Mode), Intel drops another big hint. To the paragraph
+ describing how to load segment registers when transitioning from
+ protected back to real mode, the following sentence is added: "Note
+ that if the segment registers are not reloaded, execution continues
+ using the descriptors loaded during protected mode." The same text
+ is also added to the updated 1990 edition of the 386 DX PRM, and
+ appears in the 1990 i486 PRM and all subsequent Intel programming
+ manuals.
+ * November 1989--In the November/December issue of Programmer's
+ Journal, Thomas Roden (a software engineer at AST Research, one of
+ the big PC OEMs) publishes an article titled Four Gigabytes in Real
+ Mode (page 89). This is the oldest known public description of
+ unreal mode, although the term "unreal mode" is never used. Unreal
+ mode is described, including the exception handler technique to
+ handle other code resetting the segment limits. Thanks to his
+ position at AST Research, Mr. Roden was already able to confirm
+ that unreal mode works not only on the 386DX and SX, but also on
+ the then-brand-new Intel 80486. The article mentions that it may be
+ possible to set the D-bit of the code segment to run in real mode
+ with 32-bit CS. There is no explicit mention or even a hint that
+ Mr. Roden was aware that HIMEM.SYS was already using unreal mode.
+ * January 1990--In the German c't magazine, Harald Albrecht publishes
+ an article titled Grenzenlos: Vier Gigabyte im Real Mode des 80386
+ adressieren (Boundless: Addressing four gigabytes in 80386's real
+ mode). Mr. Albrecht suggests that the 386 documentation directly
+ challenges programmers to not follow the prescribed
+ return-to-real-mode method exactly. The article is notable for
+ documenting that in real mode, a far jump partially changes CS
+ attributes, and also that after a switch to/from protected mode, a
+ near jump is sufficient to flush the prefetch queue (a far jump is
+ not necessary). Mr. Albrecht does not name the non-standard real
+ mode but presents a TSR which implements a fast INT 15h/87h block
+ move routine which uses 4GB selector limits, runs with interrupts
+ enabled, and does not disable the A20 gate when done. The author
+ incorrectly claims that (paraphrasing) no one needs the A20 gate
+ disabled, something that others learned the hard way not to be
+ true. Mr. Albrecht also notes that the segment limit extension
+ technique is unusable in V86 mode, and that 32-bit code or stack
+ segments are not practical due to corruption of the high word of
+ EIP/ESP. The article was probably written at about the same time as
+ Mr. Roden's PJ article; it may be an independent discovery,
+ although Mr. Albrecht's earlier article in the November 1989 issue
+ of c't (Odyssee im Adressraum) explicitly mentions the HIMEM.SYS
+ source code provided in Microsoft's XMS Developer's Kit.
+ * July 1990--In the July 1990 issue of Dr. Dobb's Journal, Al
+ Williams publishes an article titled DOS + 386 = 4 Gigabytes! (page
+ 62), again describing unreal mode. The article is by all
+ appearances another independent discovery of unreal mode, as there
+ are no hints Mr. Williams was aware of either HIMEM.SYS or the
+ Nov/Dec '89 PJ article. Again, the term unreal mode is not used.
+ * October 1990--In the October 1990 issue of DDJ (page 12), a reader
+ letter from Thomas Roden appears, pointing out minor problems with
+ the July '90 DDJ article about unreal mode. It is clear from the
+ letter that Mr. Roden had access to an ICE (In-Circuit Emulator),
+ which no doubt greatly eased unreal mode experimentation. An
+ editor's note identifies Mr. Roden as the author of the Nov/Dec '89
+ PJ article.
+ * January 1991--On page 176 of the 1/91 issue of German DOS
+ International magazine, an article titled Vier GByte im Real Mode
+ unter MS-DOS (Four Gigabytes in Real Mode under MS-DOS) by Martin
+ Althaus explains in detail how to change segment limits to enable
+ full 4GB addressing in real mode. The necessity of enabling the A20
+ gate is discussed, and complete example code is presented; the
+ article also notes that the technique does not work when EMM386 (or
+ V86 mode in general) is in use. The article does not explore what
+ might happen if segment attributes in real mode are changed in
+ other ways, beyond setting the G bit. The author does not claim to
+ have invented the unnamed technique, but also does not give any
+ references to earlier publications.
+ * March 1991--In Chapter 18 of Assembly Language Programming for the
+ Intel 80XXX Family, William B. Giles describes in detail (page 676
+ and following) how to program 386 real-mode selectors such that
+ they cover the entire 4GB address space. Example code is also
+ presented. The [53]code samples are dated September 4, 1990. The
+ '89 PJ article is referenced as the source of information on
+ expanding real-mode selector limits.
+ * March 1991--In Chapter 18 of DOS 5: A Developer's Guide, Al
+ Williams again describes unreal mode, with code examples. Note that
+ the exact publication date is unclear; March, August, September,
+ and October 1991 are given. A [54]1992 review of the book discusses
+ Chapter 18 in some detail, together with referencing the '90 DDJ
+ and '89 PJ articles.
+ * 1991--In 80×86 Architecture & Programming Volume II: Architecture
+ Reference (page 72), Rakesh K. Agarwal (a former member of the
+ 80386 design team) clearly explains what all the official Intel
+ documentation carefully doesn't: "When [switching from protected to
+ real mode] is done, the only action taken by the 80×86 is to clear
+ the PE flag. In particular, the current state of the descriptor
+ registers is left undisturbed." And further: "Such a pseudo REAL,
+ or UNREAL, execution mode can cause a REAL mode system to crash,
+ unless used very carefully" (capitalization in original). This may
+ be the first published use of the term "unreal mode".
+ * April 16, 1992--Origin releases [55]Ultima VII: The Black Gate, a
+ game using a custom DOS extender appropriately named "Voodoo".
+ Ultima VII is a proof that unreal mode is a terrible idea for DOS
+ applications; the game requires a significant amount of free
+ conventional memory, but is incompatible with 386-based DOS
+ extenders, as well as with any DOS-compatible advanced operating
+ systems.
+ * 1992--German DOS Extra Nr. 20 (supplement of the DOS International
+ magazine) publishes the HugeRealMode driver, enabling larger than
+ 64K code segments in unreal mode, with restrictions (more below).
+ * June 29, 1993--In his Tutor column starting on page 302, Jeff
+ Prosise [56]wrote a section on "accessing 4GB from real mode"
+ without using LOADALL. "Recently, another method of accessing 4GB
+ [...] was brought to my attention by a reader on PC MagNet." The
+ text gives a brief overview of unreal mode and refers to Chapter 18
+ of DOS 5: A Developer's Guide by Al Williams (also the author of
+ the 1990 DDJ article).
+ * January 1994--Chapter 8 (Extended Memory Access from Real Mode) of
+ Geoff Chappell's DOS Internals provides a very detailed description
+ of unreal mode and HIMEM's use of it. There is talk of "unreal"
+ segment properties (quotes in original, page 356), but the chapter
+ is about "real-mode Flat Memory Model", and "Big Real Mode" is also
+ gets a mention. The chapter also provides a detailed treatment of
+ 286 and 386 LOADALL. It is probably the best description of the
+ inner workings of HIMEM.SYS. Curiously, in Chapter 12 (page 443)
+ Mr. Chappell grumbles that only the outdated HIMEM.SYS 2.01 source
+ code is available on CompuServe (apparently uploaded by Steve
+ Gibson of InfoWorld). Clearly, Microsoft's 1989 and 1992 HIMEM.SYS
+ source code releases did a very good job of flying under the radar
+ when they escaped Mr. Chappell's laser-like attention.
+ * September 21, 1994--IBM files patent application 309,862 titled
+ Method for expanding addressable memory range in real-mode
+ processing to facilitate loading of large programs into high
+ memory. [57]U.S. patent 5,642,491 was granted on June 24, 1997. The
+ patent describes unreal mode, and mentions Chappell's DOS
+ Internals, pages 355-385. The patent makes strange references to a
+ "64-kbyte wrapping feature associated with true 8086 real mode";
+ that might refer to stack wrapping when PUSH and POP instruction
+ are used, but no such wrapping is used for data segments. The
+ patent suggests using unreal mode during operating system
+ initialization only, not at run-time.
+ * 1993-1995--Unreal mode becomes a thing and every up-and-coming
+ programmer writes a [58]utility or [59]library to use it. It is
+ popular among demo coders, who are dismayed when [60]EMM386 use is
+ mandated for Assembly '95, interfering with unreal mode.
+ * November 11, 1994--Italian programmer Daniele Paccaloni
+ [61]publishes UNREAL.EXE, a utility to enable unreal mode on a 386
+ or later CPU, and UNREAL.DOC, a document explaining how unreal mode
+ works. In a continuation of the recurring theme, Mr. Paccaloni
+ appears to have been completely unaware of the fact that unreal
+ mode had been in use for years, or the growing body of literature
+ about it. It appears that Mr. Paccaloni also independently
+ re-invented the term "unreal mode".
+ * September 1995--Robert R. Collins writes an article (NB: The exact
+ date is uncertain, Sep '95 is a guess based on source file
+ timestamps) titled [62]Descriptor Cache Register Anomalies; this is
+ probably the definitive description of unreal mode. Mr. Collins
+ thoroughly explored the CPU behavior using LOADALL for 386 CPUs,
+ and also using SMM together with an ICE on 486, Pentium, and
+ Pentium Pro CPUs. Mr. Collins showed that real mode is much closer
+ to protected mode than one would be led to believe, and most
+ protections are in fact in place. Mr. Collins also found that CS
+ register attributes are handled differently on different CPUs
+ generations. On older processors, far jumps change the CS
+ attributes as described in the Jan '86 memo, while newer CPUs
+ preserve the CS attributes but ignore them in real mode.
+ * February 1996--In the book Protected Mode Software
+ Architecture (chapter 5, page 61), Tom Shanley purportedly
+ describes "Big Real Mode", yet makes the ridiculous claim that
+ segment offsets are still restricted to 64K (while the segment base
+ can be set to any 32-bit address before returning to real mode).
+ Perhaps this is just shows that unreal mode is not well understood,
+ despite numerous authors' attempts to explain it.
+ * September 20, 1996--Phoenix and Intel publish the POST Memory
+ Manager Specification version 1.0 (PMM specification), which
+ mandates the use of "big real mode" (aka unreal mode). Big Real
+ Mode is not explained in detail, presumably because readers already
+ know how it works. The PMM specification is later adopted by the
+ PXE and PCI firmware 3.0 standards. Intel thus manages the
+ astonishing feat of specifying and mandating the use of unreal
+ mode, while simultaneously denying that it exists. Although the
+ original 1.0 PMM specification may be lost, the touched-up [63]PMM
+ 1.01 is available.
+ * August 1998--Dr. Dobb's Journal does not publish an article titled
+ [64]The Segment Descriptor Cache by Robert R. Collins. The article
+ says that "[u]nreal mode has been used commonly since it was
+ discovered on the 80386. Unreal mode is so commonly used, in fact,
+ that Intel has been forced to support this mode as part of legacy
+ 80×86 behavior, though it's never been documented."
+ * August 2004--(This entry is only included for completeness.) In The
+ Unabridged Pentium 4, Tom Shanley correctly describes unreal mode,
+ saying that it "is sometimes referred to as Big Real Mode, Flat
+ Real Mode, Real Big Mode and UnReal Mode" (italics in original).
+ Unfortunately the author makes new, although minor, incorrect
+ claims, namely that CS:IP and SS:SP are always used in real mode,
+ precluding larger than 64K code and stack segments. Larger than 64K
+ code and stack segments are indeed in practice unusable in unreal
+ mode, but for different reasons.
+
+But... Is Unreal Mode Any Good?
+
+ Yes and no. As a general-purpose programming technique it is unusable,
+ because it absolutely cannot function in V86 mode. Transitions to V86
+ mode always force real-mode compatible segment limits and attributes.
+ That means unreal mode cannot be used together with EMM386 or other DOS
+ memory managers utilizing V86 mode. Unreal mode also cannot be used in
+ the DOS boxes of 386 Enhanced Mode Windows 3.x, in the DOS boxes of
+ OS/2 2.x, Windows NT, or Windows 9x. That is an extremely serious
+ drawback.
+
+ The reason why the Voodoo memory manager in Origin's Ultima VII games
+ is unique is that no one else wanted to repeat the same mistake. The
+ Ultima VII: The Black Isle credits capture the situation rather well:
+ Ultima VII's Voodoo Memory Management System
+
+ On the other hand, when unreal mode can be used, it is very useful.
+ HIMEM.SYS uses unreal mode to speed up extended memory access, and
+ perhaps more importantly, preserve normal interrupt latency. Firmware
+ can and does use unreal mode for accessing memory beyond 1 MB during
+ initialization; it avoids switching between real and protected mode,
+ and in firmware there is no danger of segment limits being reset.
+
+ Basic unreal mode (data segments with up to 4G limits, as well as data
+ segments with non-standard base) has become a standard part of the x86
+ architecture.
+
+Unreal LOADALL
+
+ At least as far back as January 1988, Phoenix 386 BIOS combined two
+ undocumented favorites, using unreal mode to emulate the 286 LOADALL
+ instruction. When handling an invalid opcode fault, the BIOS checks
+ whether the faulting instruction is a 286 LOADALL (opcode 0Fh 05h); if
+ so, it examines the provided LOADALL state buffer at address 800h and
+ checks whether the segment bases for ES and/or DS are 1MB or higher. If
+ so, the BIOS builds descriptors with the appropriate bases, loads them
+ in protected mode, and returns to real mode with these "unreal" values
+ in the segment descriptor cache (segment base other than 16 times
+ segment value). The segment bases will get overwritten as soon as ES or
+ DS gets reloaded in real mode, but that is entirely consistent with
+ LOADALL behavior.
+
+ The LOADALL emulation is very limited, but it is sufficient to support
+ the [65]use of LOADALL in OS/2, and possibly others.
+
+ The detailed history of this method is unclear. What's known is that
+ the first 386 BIOS, shipped with the Compaq DeskPro 386 in 1986, did
+ not use unreal mode. Compaq was clearly on good terms with Intel and
+ got the secret memo describing the 386 LOADALL instruction. The Compaq
+ 386 BIOS emulated 286 LOADALL rather accurately using the 386 LOADALL
+ instruction, going at least as far back as September 1986 and
+ continuing to use the same method at least until 1989 (it would no
+ longer work on a 486 CPU).
+
+ IBM's PS/2 Model 80 BIOS did not emulate LOADALL at all, and is
+ therefore uninteresting.
+
+ There are also known to have been more or less no-name 386 systems sold
+ around 1987 which used effectively a 286 BIOS and had no provisions to
+ emulate LOADALL, nor did they use 386 instructions at all.
+
+ It is unknown when Phoenix first introduced unreal mode usage to
+ emulate LOADALL, or if other vendors did that before Phoenix. Clone 386
+ BIOS images from before 1988 are rather difficult to find.
+
+Unreal Mode Compatibility
+
+ Basic unreal mode with extended DS, ES, FS, and/or GS segment limits is
+ widely compatible across all 32-bit x86 CPU implementations. After all
+ that's what is mandated by PMM and by extension, PXE and PCI 3.0
+ Firmware specifications, all standards created with a significant
+ involvement of Intel.
+
+ Extending data segment limits in fact causes shockingly few problems,
+ as evidenced by the fact that HIMEM.SYS does just that. On an 8086,
+ referencing a word at offset 0FFFFh causes a wrap-around and the second
+ byte is fetched from offset zero. The 286 is already incompatible with
+ this behavior, causing a #GP fault. On a 386, any attempt to address
+ beyond 64K likewise causes #GP faults, which are typically fatal.
+ Therefore, functioning software does not do it and extending the
+ segment limit has no visible impact.
+
+ Anything else gets more complicated, and interrupts are the number one
+ enemy. For example, Intel CPUs typically support non-standard data
+ segment attributes; it's possible to make DS read-only, but that won't
+ be terribly useful when running real-mode software. It is likewise
+ possible to set the segment limit smaller than 64K, but that won't make
+ 16-bit software happy.
+
+ It is possible to extend the CS limit up to 4GB and use 32-bit EIP in
+ unreal mode. In practice that is not very usable because interrupts in
+ real mode only save 16-bit IP and restore it on return. The German DOS
+ Extra magazine presented a [66]hair-raising scheme to solve the
+ problem, using the CR3 register to store the high word of EIP so that
+ it could be restored on return from interrupts, but this requires
+ software to manually keep track of the high word. In practice, larger
+ than 64K code segments are unusable in unreal mode because the
+ complications very quickly outweigh any benefits unreal mode might
+ have.
+
+ It is also possible to set the D bit in CS, changing the default
+ operand size to 32-bit. This may reduce the size of unreal code if it
+ is largely 32-bit (by obviating the need for overrides). Unfortunately,
+ this again causes serious trouble with interrupts, because existing
+ 16-bit code cannot run correctly with the D bit set. It is possible to
+ switch to protected mode, clear the D bit, and execute the 16-bit
+ handler every time an interrupt occurs, and in fact it's [67]exactly
+ what fasm does (or at least did in some versions), but with so much
+ mode switching and complexity, the advantages of unreal mode are
+ rapidly lost.
+
+ Similar trouble strikes when attempting to use larger than 64K stack
+ segments. It is possible, but again destroys compatibility with
+ existing 16-bit real-mode code. The complications are such that one
+ might as well use a regular DOS extender and skip all the unreal mode
+ incompatibilities.
+
+ A larger problem is that the "advanced" aspects of unreal mode may not
+ be implemented identically across CPU generations and vendors,
+ precisely because they have never been documented. It is not specified
+ anywhere exactly which segment attributes are ignored and which are
+ honored in real mode. Protected mode, on the other hand, works
+ consistently.
+
+What Does It All Mean?
+
+ Unreal mode is almost certainly an accident of history, a side effect
+ of the fact that the initial 386 design had no architected way of
+ switching from protected mode back to real mode. Once the technique
+ started being used, instead of clearly documenting how it works, Intel
+ in its typical fashion documented only certain aspects of it, such that
+ only programmers who already know about unreal mode find traces of it
+ in the official documentation.
+
+ On the other hand, Intel did leave enough hints in the public
+ documentation that unreal mode appears to have been independently
+ discovered a number of times. What is fascinating is that Microsoft
+ apparently implemented unreal mode support in HIMEM.SYS and made its
+ source code available before any literature on unreal mode was
+ published. Starting in late 1989, articles describing unreal mode were
+ written without knowing of each other, and likely without knowing of
+ Microsoft's prior published work. Reinventing wheels may be satisfying,
+ but in the end it's just not very productive.
+
+ PS: Images of 386 clone BIOSes (other than Compaq and IBM) from 1987
+ and earlier would be worth checking for LOADALL emulation and possible
+ other unreal mode use.
+
+ Feb 2021 Update: The original 231630-001 datasheet has now been
+ recovered and this post updated accordingly.
+ This entry was posted in [68]386, [69]Corrections, [70]Microsoft,
+ [71]PC history, [72]Undocumented. Bookmark the [73]permalink.
+ [74]<- USB 0.9
+ [75]ANOMALY: meaningless REX prefix used ->
+
+43 Responses to A Brief History of Unreal Mode
+
+ 1. [76]Neozeed says:
+ [77]June 15, 2018 at 5:38 am
+ The PCem folks are doing a good job of getting numerous 286/386
+ BIOS running on their framework, they ought to have quite a number
+ of images.
+ 2. [78]Yuhong Bao says:
+ [79]June 15, 2018 at 6:35 am
+ The fun thing is that they never changed the LMSW instruction. I
+ wonder why/
+ 3. dosfan says:
+ [80]June 15, 2018 at 8:33 am
+ Good article but why were you using fasm ? What fasm is doing
+ (32-bit real mode and relocating the IVT via LIDT) is crazy as it's
+ too much effort for too little gain and too many compatibility
+ issues. I'm not sure which is crazier, that or attempting to use
+ real mode paging on the 386 (which isn't allowed on 486 or later
+ CPUs).
+ 4. God says:
+ [81]June 15, 2018 at 1:59 pm
+ Love these sorts of "software archaeology" articles Michal - always
+ informative (and a pleasure) to read. However, something of a typo
+ jumped out at me:
+ >August 1998--Dr. Dobb's Journal does NOT publish an article titled
+ The Segment Descriptor Cache
+ 5. Michal Necasek says:
+ [82]June 15, 2018 at 7:07 pm
+ Presumably because someone was calling it in protected mode with
+ the PM bit clear, and expected to stay in protected mode...
+ 6. Michal Necasek says:
+ [83]June 15, 2018 at 7:07 pm
+ Oh, there are zillions of BIOS images out there. But 386 BIOS
+ images from 1986-87? Nada...
+ 7. Michal Necasek says:
+ [84]June 15, 2018 at 7:09 pm
+ I wasn't, I think the author is certifiably insane But someone else
+ using it made me aware of certain curious behaviors.
+ 8. Michal Necasek says:
+ [85]June 15, 2018 at 7:09 pm
+ It's not a typo. I could find no evidence that the article was ever
+ published in DDJ.
+ 9. Richard Wells says:
+ [86]June 15, 2018 at 9:18 pm
+ Early 386 BIOSes: Don Maslin's collection of ROMs includes the AMI
+ BIOS copyright 1987. I don't believe anyone has collected the
+ Phoenix BIOS used in the 1986 ALR 386 system.
+ While an interesting collection of the history, I believe you
+ overlooked one minor article. The October 1988 issue of Doctor
+ Dobbs had an article entitled "80386 PROTECTED MODE INITIALIZATION"
+ by Neal Marguiles (Intel employee). That title is a misnomer. It
+ covers the allocation of a 4 GB address space followed by a return
+ to real mode plus some other interesting concepts.
+ [87]http://www.drdobbs.com/80386-protected-mode-initialization/1844
+ 08010
+ 10. Rugxulo says:
+ [88]June 16, 2018 at 1:37 am
+ Actually, latest stable FASM seems to be 1.73.04, which silently
+ omits the unreal hack, hence you basically have to always use the
+ DPMI fallback nowadays. Not exactly sure why, he didn't (AFAIR)
+ publicly mention dropping it or why, nor whether it will come back
+ (somewhat unlikely, but he was always proud of his hack). Maybe it
+ (again) conflicted with his (Linux) 64-bit hosted version hack
+ (fasm.x64). Dunno, it's very complicated!
+ 11. dosfan says:
+ [89]June 16, 2018 at 2:17 am
+ A gross hack like that belongs in a technology demo, not production
+ software.
+ I'm not sure why anyone would bother with fasm in the first place ?
+ If you're writing assembly language code for DOS or Windows then
+ there's no reason not to use MASM which was *the* industry standard
+ or the highly MASM-compatible JWasm (or whatever its successor is).
+ 12. [90]Yuhong Bao says:
+ [91]June 18, 2018 at 2:47 am
+ Thinking about it, I wonder if reloading the real mode CS
+ attributes was the main change that allowed switching back to real
+ mode. It is unfortunate that writable code segments did not make
+ even the 80386 BTW.
+ 13. techfury90 says:
+ [92]June 18, 2018 at 3:33 am
+ Unreal mode seems to have been known to PC-98 programmers to an
+ extent as well. Oldest reference I can find is from April 1995:
+ [93]http://www.tsg.ne.jp/buho/189/tsg189.html#8086
+ Author may have discovered it independently. There may be earlier
+ examples in books and/or magazines, but I have yet to uncover them.
+ Their description of their first cited source is slightly
+ ambiguous: it's possible that they learned about unreal mode from
+ them. The stumbling block is that I cannot seem to find their name
+ for unreal mode in general. I don't think they adopted the name we
+ assigned to it, if there is even a "well-known" name.
+ 14. dosfan says:
+ [94]June 18, 2018 at 5:11 am
+ Why is it referred to as "unreal mode" anyway ? That's a foolish
+ and terrible name. Considering that it is referred to as "big real
+ mode" in an Intel doc and it involves setting the big bit in the
+ segment descriptor that should be the official name (not that it
+ really matters today). Certainly "flat real mode" is reasonable
+ alternative since you have direct access to the entire flat 4GB
+ address space.
+ 15. Richard Wells says:
+ [95]June 18, 2018 at 8:53 am
+ "Big real mode" suggests that existing code works exactly the same
+ except that the segments can be larger. "Unreal mode" showcases the
+ differences.
+ Those interested in a more intentional version of a similar concept
+ of accessing 32-bit memory for >64K allocations from 16-bit code
+ could look at 1980 Data General MV 8000 documentation especially
+ the section "MV/8000 C/350 Program Combinations" and the following
+ section "Anomolies."(sic) Some of the issues DG discovered were
+ similar to ones that programmers using Intel chip noticed a decade
+ later.
+ 16. [96]Yuhong Bao says:
+ [97]June 18, 2018 at 11:38 am
+ In this case, the only difference is that the segment limit is
+ larger, and existing real mode code do work the same.
+ 17. Michal Necasek says:
+ [98]June 18, 2018 at 3:03 pm
+ Hmm, I don't see anything about unreal mode in that article. It
+ only says that "to assure proper operation after returning to real
+ mode, the segment registers must be loaded with real mode type
+ selectors while still in protected mode", which is the official
+ Intel party line. And the sample code does exactly that.
+ I think I looked at that AMI BIOS and it's much newer than 1987.
+ It's somewhat common that the copyright message is older than the
+ BIOS date. The opposite also happens. I'm sure there had to be
+ clone BIOSes in 1986-87 but so far I've been unable to locate any.
+ 18. Michal Necasek says:
+ [99]June 18, 2018 at 3:06 pm
+ I know why, It's actually automatic. The unreal mode stuff is only
+ used if the code segment is smaller than 64K. In the newer fasm
+ versions there's more code than that, so the unreal mode code path
+ doesn't get compiled in (or at least not used). For that reason
+ it's very unlikely to come back, because using > 64K unreal mode
+ code segments brings another, much nastier layer of complications.
+ 19. Michal Necasek says:
+ [100]June 18, 2018 at 4:12 pm
+ That sounds quite plausible. It would be a silicon change, but a
+ very localized one, and only visible from switching from protected
+ back to real mode.
+ 20. Michal Necasek says:
+ [101]June 18, 2018 at 4:18 pm
+ Unreal mode because it's real mode, but not conforming to Intel's
+ definition of real mode. "Big real mode" is descriptive but it's
+ unclear whether it covers 32-bit code segments, or code or stack
+ segments with > 64K limits. Same problem with "flat real mode". I
+ suppose you could call it "not-real" mode, or "non-protected mode",
+ but "unreal mode" is really better.
+ To be clear, at least in this article, I use the term "unreal mode"
+ to mean any non-canonical real mode usage. I don't think the terms
+ "big real mode" or "flat real mode" were used to mean anything
+ other than 4G data segment limits, but there's more to unreal mode
+ than that. For example, unreal mode would cover running with
+ segment limits smaller than 64K (just because it's useless doesn't
+ mean it can't be done).
+ 21. Michal Necasek says:
+ [102]June 18, 2018 at 4:20 pm
+ "Breaking the wall", I kind of like that.
+ 22. dosfan says:
+ [103]June 18, 2018 at 8:08 pm
+ Big real mode (4GB address space) is the only thing that was ever
+ useful. Changing the default bit of the code segment would break
+ everything. If anything should be called "unreal mode" it's that
+ since it's still real mode per-se (no protections) but no regular
+ 16-bit real mode program would run properly.
+ 23. Michal Necasek says:
+ [104]June 19, 2018 at 2:02 pm
+ The other thing that was clearly useful (as in widely utilized) was
+ 64K segments with bases at or beyond 1MB. The rest is more about
+ understanding how the damn architecture actually works than about
+ having practical value.
+ 24. dosfan says:
+ [105]June 19, 2018 at 8:22 pm
+ I thought that particular trick was only done via 286 LOADALL. It
+ is of limited use since interrupts have to be disabled because once
+ the segment register is reloaded the base is changed and access
+ beyond 1MB is lost. Big real mode makes that trick impractical.
+ 25. Michal Necasek says:
+ [106]June 19, 2018 at 10:34 pm
+ 286 LOADALL... and the emulation thereof on 386s. Just about every
+ BIOS in the late 1980s and in the 1990s does that. Disabling
+ interrupts for a short time is still much better than resetting the
+ CPU, which isn't fast. Big real mode is certainly much better, but
+ doesn't emulate 286 LOADALL.
+ 26. M says:
+ [107]June 20, 2018 at 12:16 pm
+ I am wondering if the 64K wrap-around alluded to in the IBM patents
+ could be a clumsy reference to A20-behavior?
+ 27. Michal Necasek says:
+ [108]June 20, 2018 at 3:33 pm
+ That would be really clumsy, but as an explanation it makes as much
+ sense as anything
+ 28. M says:
+ [109]June 20, 2018 at 10:34 pm
+ @Michal: Yes - and it is inconsistent with what they write about
+ being compatible with only pmode and real-mode apps not relying on
+ the wrap-around etc. and the A20 wrap-around indeed does exist (and
+ would not be possible to emulate w paging in unreal-mode, as is
+ done in V86). But yeah, definitely clumsy
+ 29. Richard Wells says:
+ [110]June 20, 2018 at 11:13 pm
+ All 16-bit segments wrap around unless concealed behind the complex
+ logic of a 16-bit huge library. Some programs depended on it;
+ sometimes, it just concealed a bug. IBM's note in the patent on
+ wrap around boils down to keeping the standard 16-bit behavior for
+ all programs except those that specifically expect the big segments
+ of unreal mode. Otherwise, a program may be caught accessing memory
+ it didn't plan to leading to interesting results.
+ [111]https://www.pcjs.org/pubs/pc/reference/microsoft/kb/Q58987/
+ shows that wrap around has nothing to do with A20.
+ 30. Michal Necasek says:
+ [112]June 21, 2018 at 12:00 am
+ No, 16-bit segments do not wrap on a 286 or later (except for a
+ special case with stack pushes and pops). If you try to address
+ past the end of a segment, you get a #GP fault. The KB article
+ talks about 16-bit pointers wrapping around, which is a different
+ issue, and more likely than not avoids addressing past the end of a
+ segment.
+ 31. Chris M. says:
+ [113]June 21, 2018 at 4:11 am
+ AMI used dates instead of version numbers for their HiFlex BIOS
+ cores, hence why you would see two dates on a POST screen. One was
+ the "core" date/revision, and one was the built date/revision that
+ the vendor created. I think this changed when the WinBIOS was
+ introduced, but so many vendors went running to Award after that
+ disaster that nobody really noticed when they released a new
+ revision!
+ That 1988 Phoenix core was around for a long time, that 486
+ EISA/VLB board has it despite being from 1993! (it also has the
+ stupid 16MB RAM limitation when ROM shadowing is enabled) I think
+ Dell might have used it for a long time on their custom
+ motherboards as well (later stuff was mostly Intel OEM).
+ 32. Richard Wells says:
+ [114]June 22, 2018 at 11:45 pm
+ 16-bit relative near jumps will be done modulo 64k. That happens
+ according to the documentation even with latest chips. There may be
+ an exception triggered but most real mode systems should wind up
+ ignoring the exception. Otherwise, code involving relative 16-bit
+ jumps would have failed since it required overflow/underflow
+ wrapping to get to the more distant parts of the segment.
+ Memory access is a bit different because Intel decided not to
+ follow the 8086 practice of turning any incorrectly aligned word
+ access into a pair of byte accesses which had a side effect of
+ handling a word that occupied both the first and last bytes of a
+ segment. Speed beat out correctly handling an edge case. Some
+ programs seemed to still work with the exception being ignored
+ because I remember 1990s reports of people finally noticing the
+ exception. (Seemed to work because who knows what was in the second
+ byte of that word.)
+ 33. Michal Necasek says:
+ [115]June 24, 2018 at 2:22 pm
+ Relative jumps are signed and sign-extended, so there's normally no
+ overflow and no truncation. #GP faults are fatal, in real mode they
+ lead to hangs (the BIOS does nothing special, the
+ interrupt/exception handler will likely return but it will just
+ re-trigger the exception immediately) or visible fatal errors
+ (EMM386, QEMM, NTVDM).
+ I don't know if with the split-word access speed beat out
+ compatibility or if Intel decided that it was a quirk not worth
+ preserving. At any rate it was a well documented difference between
+ the 8086 and later CPUs; how much software it affected in practice
+ I don't know.
+ 34. Pingback: [116]Michael Tsai - Blog - A Brief History of Unreal Mode
+ 35. [117]Yuhong Bao says:
+ [118]July 8, 2018 at 1:00 am
+ Thinking about it, I think virtual 8086 mode was designed before
+ they officially supported switching the 80386 to real mode, right?
+ 36. Michal Necasek says:
+ [119]July 8, 2018 at 11:31 am
+ Yes, definitely. And the transitions into and out of V86 mode are
+ clean, with no way to leave junk in segment registers. It's
+ apparent that Intel's idea was that with V86 mode, no one needed
+ real mode anymore. But in the absence of a V86 monitor built into
+ the BIOS(?), that wasn't so simple.
+ 37. Michal Necasek says:
+ [120]July 10, 2018 at 4:16 pm
+ Found this in a 1985 IEEE Micro paper by El-Ayat and Agarwal called
+ The Intel 80386-Architecture and Implementation: "Real mode is
+ useful for initialization and for configuration of the processor
+ data structures needed to run in native 80386 protected mode. The
+ recommended method for running 8086 code is called virtual 86
+ mode." Intel's idea clearly was that real mode was for bring-up
+ only and no one would want to switch in and out. If you wanted to
+ run 8086 code, you were supposed to do that in a V86 monitor. Yet
+ another plan that did not survive first contact with reality.
+ 38. Al Williams says:
+ [121]July 29, 2018 at 7:47 am
+ Nice walk down memory lane. The original DDJ article was written on
+ my Intel Inboard 386 plugged into an XT-style motherboard. This did
+ not switch A20 like a "real" PC/AT and so my original code actually
+ would only work on the Inboard but I didn't know that. Later
+ versions (like in the book) would correct that.
+ I was looking. I got an e-mail from an Italian researcher that had
+ used the technique in some scholarly paper and referenced my
+ article for some kind of SEM or spectroscopy, but I couldn't find
+ that and I don't remember the exact year.
+ In addition -- and again, I can't remember the year -- a guy at
+ Software Development cornered me to tell me how he had started a
+ company based on the mode. I think he was selling a library or
+ something. I don't think he had much success. That had to be right
+ after it published within a year or so. I think he advertised with
+ a small ad in a couple of DDJs.
+ As for Necasek's comment, my DOS Extender PROT did run all the real
+ mode code like BIOS/DOS calls in V86 mode. As far as I know, it may
+ have been the first to do that in a nontrivial way.
+ 39. Michal Necasek says:
+ [122]July 31, 2018 at 4:14 pm
+ I saw the updates to your article... as I like to say, the A20 gate
+ is the most expensive bit in history. It never occurred to me but
+ of course the Inboard had to have a different A20 gate control
+ mechanism.
+ Do you remember anything about the unreal mode origins? Was that
+ something you independently discovered, or was it something that
+ was already common knowledge in certain circles?
+ 40. [123]Myself says:
+ [124]August 30, 2018 at 12:09 am
+ Bummer, I only have the third edition of the i386 datasheet
+ (231630-003, Nov. 1986).
+ In page 2, there is the "update notice" which lists updated
+ paragraphs.
+ If you have the version -002, maybe there are hints about changes
+ in the paragraphs you are emphasizing.
+ 41. [125]Al Williams says:
+ [126]August 30, 2018 at 5:19 pm
+ No I had been tantalized by the discussions in the Intel doc
+ warning you to set up the segment registers before switching. Like
+ you mentioned, they all but told you how to do it and then stopped
+ short. It reminded me of the old story about during prohibition
+ where you could buy a "grape block" that had a warning label:
+ Warning: Do not place in 2 quarts of water in a cool dark place for
+ 3 weeks or an illegal alcoholic beverage will result."
+ I have been experimenting with protected mode programs and
+ naturally had to try it out. The lead times in the publishing
+ business at the time means I probably was writing that about the
+ time the PJ article hit the streets if not a little before.
+ Consider it took us 3 months to publish a letter to the editor! By
+ the time an article went through the snail mail, the contracts came
+ back, then the editing and typesetting with galleys in the mail. So
+ I don't remember an exact date, but I do remember being surprised
+ when the PJ article was called out. None of us had heard of it as
+ PJ was not a major competitor so we were not tracking them the way
+ we did some of the other magazines.
+ 42. Michal Necasek says:
+ [127]August 31, 2018 at 10:16 am
+ Indeed there is. The -002 edition is at
+ [128]http://www.bitsavers.org/components/intel/80386/231746-001_Int
+ roduction_to_the_80386_Apr86.pdf and page 63 in the PDF (page 2 of
+ the actual datasheet) lists the changes, though with no detail.
+ Some of the relevant sections were "revised", but that's all we
+ know until the -001 edition turns up.
+ 43. Michal Necasek says:
+ [129]August 31, 2018 at 12:17 pm
+ Thanks for remembering! And the grape block bit, I've not heard of
+ that. Yeah, the Intel docs were like that, daring developers to see
+ what happens if they don't follow the recipe exactly.
+ It's hard to imagine how long the publishing turnaround was was
+ back then, but that's how it was. Entirely possible that someone
+ wrote an article and someone else independently came up with the
+ same thing before it was published. It's quite likely that the
+ articles in foreign press were also independent discoveries; I dug
+ into the German archives a little but I doubt they were the only
+ ones.
+
+Leave a Reply
+
+ Your email address will not be published. Required fields are marked *
+
+ Comment *
+ _____________________________________________
+ _____________________________________________
+ _____________________________________________
+ _____________________________________________
+ _____________________________________________
+ _____________________________________________
+ _____________________________________________
+ _____________________________________________
+
+ Name * ______________________________
+
+ Email * ______________________________
+
+ Website ______________________________
+
+ Post Comment
+
+ D
+ _____________________________________________
+ _____________________________________________
+ _____________________________________________
+ _____________________________________________
+ _____________________________________________
+ _____________________________________________
+ _____________________________________________
+ _____________________________________________
+
+ This site uses Akismet to reduce spam. [130]Learn how your comment data
+ is processed.
+ * Archives
+ + [131]June 2022
+ + [132]May 2022
+ + [133]April 2022
+ + [134]March 2022
+ + [135]February 2022
+ + [136]January 2022
+ + [137]December 2021
+ + [138]November 2021
+ + [139]October 2021
+ + [140]September 2021
+ + [141]August 2021
+ + [142]July 2021
+ + [143]June 2021
+ + [144]May 2021
+ + [145]April 2021
+ + [146]March 2021
+ + [147]February 2021
+ + [148]January 2021
+ + [149]December 2020
+ + [150]November 2020
+ + [151]October 2020
+ + [152]September 2020
+ + [153]August 2020
+ + [154]July 2020
+ + [155]June 2020
+ + [156]May 2020
+ + [157]April 2020
+ + [158]March 2020
+ + [159]February 2020
+ + [160]January 2020
+ + [161]December 2019
+ + [162]November 2019
+ + [163]October 2019
+ + [164]September 2019
+ + [165]August 2019
+ + [166]July 2019
+ + [167]June 2019
+ + [168]May 2019
+ + [169]April 2019
+ + [170]March 2019
+ + [171]February 2019
+ + [172]January 2019
+ + [173]December 2018
+ + [174]November 2018
+ + [175]October 2018
+ + [176]August 2018
+ + [177]July 2018
+ + [178]June 2018
+ + [179]May 2018
+ + [180]April 2018
+ + [181]March 2018
+ + [182]February 2018
+ + [183]January 2018
+ + [184]December 2017
+ + [185]November 2017
+ + [186]October 2017
+ + [187]August 2017
+ + [188]July 2017
+ + [189]June 2017
+ + [190]May 2017
+ + [191]April 2017
+ + [192]March 2017
+ + [193]February 2017
+ + [194]January 2017
+ + [195]December 2016
+ + [196]November 2016
+ + [197]October 2016
+ + [198]September 2016
+ + [199]August 2016
+ + [200]July 2016
+ + [201]June 2016
+ + [202]May 2016
+ + [203]April 2016
+ + [204]March 2016
+ + [205]February 2016
+ + [206]January 2016
+ + [207]December 2015
+ + [208]November 2015
+ + [209]October 2015
+ + [210]September 2015
+ + [211]August 2015
+ + [212]July 2015
+ + [213]June 2015
+ + [214]May 2015
+ + [215]April 2015
+ + [216]March 2015
+ + [217]February 2015
+ + [218]January 2015
+ + [219]December 2014
+ + [220]November 2014
+ + [221]October 2014
+ + [222]September 2014
+ + [223]August 2014
+ + [224]July 2014
+ + [225]June 2014
+ + [226]May 2014
+ + [227]April 2014
+ + [228]March 2014
+ + [229]February 2014
+ + [230]January 2014
+ + [231]December 2013
+ + [232]November 2013
+ + [233]October 2013
+ + [234]September 2013
+ + [235]August 2013
+ + [236]July 2013
+ + [237]June 2013
+ + [238]May 2013
+ + [239]April 2013
+ + [240]March 2013
+ + [241]February 2013
+ + [242]January 2013
+ + [243]December 2012
+ + [244]November 2012
+ + [245]October 2012
+ + [246]September 2012
+ + [247]August 2012
+ + [248]July 2012
+ + [249]June 2012
+ + [250]May 2012
+ + [251]April 2012
+ + [252]March 2012
+ + [253]February 2012
+ + [254]January 2012
+ + [255]December 2011
+ + [256]November 2011
+ + [257]October 2011
+ + [258]September 2011
+ + [259]August 2011
+ + [260]July 2011
+ + [261]June 2011
+ + [262]May 2011
+ + [263]April 2011
+ + [264]March 2011
+ + [265]January 2011
+ + [266]November 2010
+ + [267]October 2010
+ + [268]August 2010
+ + [269]July 2010
+
+ * Categories
+ + [270]286
+ + [271]386
+ + [272]3Com
+ + [273]3Dfx
+ + [274]486
+ + [275]8086/8088
+ + [276]Adaptec
+ + [277]AGP
+ + [278]AMD
+ + [279]AMD64
+ + [280]Apple
+ + [281]Archiving
+ + [282]Assembler
+ + [283]ATi
+ + [284]BIOS
+ + [285]Books
+ + [286]Borland
+ + [287]BSD
+ + [288]Bugs
+ + [289]BusLogic
+ + [290]C
+ + [291]C&T
+ + [292]CD-ROM
+ + [293]Cirrus Logic
+ + [294]CompactFlash
+ + [295]Compaq
+ + [296]Compression
+ + [297]Conner
+ + [298]Corrections
+ + [299]CP/M
+ + [300]Creative Labs
+ + [301]Crystal Semi
+ + [302]Cyrix
+ + [303]DDR RAM
+ + [304]Debugging
+ + [305]DEC
+ + [306]Development
+ + [307]Digital Research
+ + [308]Documentation
+ + [309]DOS
+ + [310]DOS Extenders
+ + [311]Dream
+ + [312]E-mu
+ + [313]Editors
+ + [314]EISA
+ + [315]Ensoniq
+ + [316]ESDI
+ + [317]Ethernet
+ + [318]Fakes
+ + [319]Fixes
+ + [320]Floppies
+ + [321]Graphics
+ + [322]Hardware Hacks
+ + [323]I18N
+ + [324]IBM
+ + [325]IDE
+ + [326]Intel
+ + [327]Internet
+ + [328]Keyboard
+ + [329]Kryoflux
+ + [330]Kurzweil
+ + [331]LAN Manager
+ + [332]Legal
+ + [333]Linux
+ + [334]MCA
+ + [335]Microsoft
+ + [336]MIDI
+ + [337]NetWare
+ + [338]Networking
+ + [339]NeXTSTEP
+ + [340]NFS
+ + [341]Novell
+ + [342]NT
+ + [343]OS X
+ + [344]OS/2
+ + [345]PC architecture
+ + [346]PC hardware
+ + [347]PC history
+ + [348]PC press
+ + [349]PCI
+ + [350]PCMCIA
+ + [351]Pentium
+ + [352]Pentium 4
+ + [353]Pentium II
+ + [354]Pentium III
+ + [355]Pentium Pro
+ + [356]Plug and Play
+ + [357]PowerPC
+ + [358]Pre-release
+ + [359]PS/2
+ + [360]QNX
+ + [361]Quantum
+ + [362]Random Thoughts
+ + [363]RDRAM
+ + [364]Roland
+ + [365]Ryzen
+ + [366]S3
+ + [367]SCO
+ + [368]SCSI
+ + [369]Seagate
+ + [370]Security
+ + [371]Site Management
+ + [372]SMP
+ + [373]Software Hacks
+ + [374]Solaris
+ + [375]Sound
+ + [376]Sound Blaster
+ + [377]Source code
+ + [378]Standards
+ + [379]Storage
+ + [380]Supermicro
+ + [381]TCP/IP
+ + [382]ThinkPad
+ + [383]Trident
+ + [384]UltraSound
+ + [385]Uncategorized
+ + [386]Undocumented
+ + [387]UNIX
+ + [388]UnixWare
+ + [389]USB
+ + [390]VGA
+ + [391]VirtualBox
+ + [392]Virtualization
+ + [393]VLB
+ + [394]Watcom
+ + [395]Wave Blaster
+ + [396]Western Digital
+ + [397]Windows
+ + [398]Windows 95
+ + [399]Windows XP
+ + [400]Wireless
+ + [401]WordStar
+ + [402]x86
+ + [403]Xenix
+ + [404]Xeon
+ + [405]Yamaha
+
+ [406]OS/2 Museum
+ [407]Proudly powered by WordPress.
+
+References
+
+ Visible links:
+ 1. http://www.os2museum.com/wp/feed/
+ 2. http://www.os2museum.com/wp/comments/feed/
+ 3. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/feed/
+ 4. http://www.os2museum.com/wp/wp-json/wp/v2/posts/4169
+ 5. http://www.os2museum.com/wp/wp-json/oembed/1.0/embed?url=http%3A%2F%2Fwww.os2museum.com%2Fwp%2Fa-brief-history-of-unreal-mode%2F
+ 6. http://www.os2museum.com/wp/wp-json/oembed/1.0/embed?url=http%3A%2F%2Fwww.os2museum.com%2Fwp%2Fa-brief-history-of-unreal-mode%2F&format=xml
+ 7. http://www.os2museum.com/wp/
+ 8. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#content
+ 9. http://www.os2museum.com/wp/
+ 10. http://www.os2museum.com/wp/about/
+ 11. http://www.os2museum.com/wp/about/wanted-list/
+ 12. http://www.os2museum.com/wp/os2-history/
+ 13. http://www.os2museum.com/wp/os2-history/os2-beginnings/
+ 14. http://www.os2museum.com/wp/os2-history/os2-1-0/
+ 15. http://www.os2museum.com/wp/os2-history/os2-1-1/
+ 16. http://www.os2museum.com/wp/os2-history/os2-1-2-and-1-3/
+ 17. http://www.os2museum.com/wp/os2-history/os2-16-bit-server/
+ 18. http://www.os2museum.com/wp/os2-history/os2-2-0/
+ 19. http://www.os2museum.com/wp/os2-history/os2-2-1-and-2-11/
+ 20. http://www.os2museum.com/wp/os2-history/os2-warp/
+ 21. http://www.os2museum.com/wp/os2-history/os2-warp-powerpc-edition/
+ 22. http://www.os2museum.com/wp/os2-history/os2-warp-4/
+ 23. http://www.os2museum.com/wp/os2-history/os2-timeline/
+ 24. http://www.os2museum.com/wp/os2-history/os2-library/
+ 25. http://www.os2museum.com/wp/os2-history/os2-library/os2-1-x-sdk/
+ 26. http://www.os2museum.com/wp/os2-history/os2-library/os2-1-x-programming/
+ 27. http://www.os2museum.com/wp/os2-history/os2-library/os2-2-0-technical-library/
+ 28. http://www.os2museum.com/wp/os2-history/os2-videos-1987/
+ 29. http://www.os2museum.com/wp/dos/
+ 30. http://www.os2museum.com/wp/dos/dos-beginnings/
+ 31. http://www.os2museum.com/wp/dos/dos-1-0-and-1-1/
+ 32. http://www.os2museum.com/wp/dos/dos-2-0-and-2-1/
+ 33. http://www.os2museum.com/wp/dos/dos-3-0-3-2/
+ 34. http://www.os2museum.com/wp/dos/dos-3-3/
+ 35. http://www.os2museum.com/wp/dos/dos-4-0/
+ 36. http://www.os2museum.com/wp/dos/dos-library/
+ 37. http://www.os2museum.com/wp/netware-history/
+ 38. http://www.os2museum.com/wp/netware-history/netware-timeline/
+ 39. http://www.os2museum.com/wp/netware-history/netware-library/
+ 40. http://www.os2museum.com/wp/windows-history/
+ 41. http://www.os2museum.com/wp/windows-history/windows-library/
+ 42. http://www.os2museum.com/wp/pc-unix-history/
+ 43. http://www.os2museum.com/wp/pc-unix-history/solaris-2-1-for-x86/
+ 44. http://www.os2museum.com/wp/usb-0-9/
+ 45. http://www.os2museum.com/wp/anomaly-meaningless-rex-prefix-used/
+ 46. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/
+ 47. http://www.os2museum.com/wp/author/michaln/
+ 48. https://en.wikipedia.org/wiki/FASM
+ 49. https://books.google.de/books?id=tSLe3yMjc-AC&lpg=PP1&pg=PT437#v=onepage&q&f=false
+ 50. http://www.gaby.de/ftp/pub/win3x/archive/softlib/xms.exe
+ 51. http://www.megalextoria.com/usenet-archive/news095f1/b118/comp/binaries/ibm/pc/d/00002158.html
+ 52. https://archives.scovetta.com/pub/power_programming/MICROSFT/
+ 53. https://vetusware.com/download/Assembly%20Language%20Programming%20for%20the%20Intel%2080XXX%20Family%201/?id=15869
+ 54. https://link.springer.com/content/pdf/10.3758/BF03203592.pdf
+ 55. https://en.wikipedia.org/wiki/Ultima_VII:_The_Black_Gate
+ 56. https://books.google.com/books?id=gCfzPMoPJWgC&pg=PA304&lpg=PA304&source=bl&ots=rnelM7Nq98&sig=NwfNst9V6yPrUqTMu4oSayD2594&hl=en&sa=X&ved=0ahUKEwinjISbjKjbAhXQZ1AKHfF3D3UQ6AEIPDAC#v=onepage&f=false
+ 57. https://patents.google.com/patent/US5642491
+ 58. http://ftp.lanet.lv/ftp/mirror/x2ftp/msdos/programming/memory/
+ 59. http://ftp.lanet.lv/ftp/mirror/x2ftp/msdos/programming/libs/
+ 60. http://dgi_il.tripod.com/gemmis.txt
+ 61. https://ftp.sunet.se/mirror/archive/ftp.sunet.se/pub/simtelnet/msdos/asmutl/unreal10.zip
+ 62. http://www.rcollins.org/Productivity/DescriptorCache.html
+ 63. https://web.archive.org/web/20051111084304/http://www.phoenix.com/NR/rdonlyres/873A00CF-33AC-4775-B77E-08E7B9754993/0/specspmm101.pdf
+ 64. http://www.rcollins.org/ddj/Aug98/Aug98.html
+ 65. http://www.os2museum.com/wp/more-on-loadall-and-os2/
+ 66. http://www.delorie.com/djgpp/doc/rbinter/it/91/37.html
+ 67. https://board.flatassembler.net/topic.php?t=11940
+ 68. http://www.os2museum.com/wp/category/386/
+ 69. http://www.os2museum.com/wp/category/corrections/
+ 70. http://www.os2museum.com/wp/category/microsoft/
+ 71. http://www.os2museum.com/wp/category/pc-history/
+ 72. http://www.os2museum.com/wp/category/undocumented/
+ 73. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/
+ 74. http://www.os2museum.com/wp/usb-0-9/
+ 75. http://www.os2museum.com/wp/anomaly-meaningless-rex-prefix-used/
+ 76. http://virtuallyfun.com/
+ 77. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347786
+ 78. https://yuhongbao.blogspot.com/
+ 79. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347787
+ 80. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347790
+ 81. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347796
+ 82. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347801
+ 83. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347802
+ 84. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347803
+ 85. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347804
+ 86. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347808
+ 87. http://www.drdobbs.com/80386-protected-mode-initialization/184408010
+ 88. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347810
+ 89. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347812
+ 90. https://yuhongbao.blogspot.com/
+ 91. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347858
+ 92. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347860
+ 93. http://www.tsg.ne.jp/buho/189/tsg189.html#8086
+ 94. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347861
+ 95. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347862
+ 96. https://yuhongbao.blogspot.com/
+ 97. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347864
+ 98. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347865
+ 99. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347866
+ 100. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347867
+ 101. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347868
+ 102. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347869
+ 103. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347872
+ 104. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347964
+ 105. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347974
+ 106. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347978
+ 107. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-347996
+ 108. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-348003
+ 109. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-348035
+ 110. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-348037
+ 111. https://www.pcjs.org/pubs/pc/reference/microsoft/kb/Q58987/
+ 112. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-348040
+ 113. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-348048
+ 114. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-348117
+ 115. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-348188
+ 116. https://mjtsai.com/blog/2018/07/03/a-brief-history-of-unreal-mode/
+ 117. https://yuhongbao.blogspot.com/
+ 118. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-348565
+ 119. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-348575
+ 120. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-348630
+ 121. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-348979
+ 122. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-349002
+ 123. http://temlib.org/
+ 124. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-349848
+ 125. http://www.awce.com/
+ 126. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-349870
+ 127. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-349883
+ 128. http://www.bitsavers.org/components/intel/80386/231746-001_Introduction_to_the_80386_Apr86.pdf
+ 129. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/#comment-349890
+ 130. https://akismet.com/privacy/
+ 131. http://www.os2museum.com/wp/2022/06/
+ 132. http://www.os2museum.com/wp/2022/05/
+ 133. http://www.os2museum.com/wp/2022/04/
+ 134. http://www.os2museum.com/wp/2022/03/
+ 135. http://www.os2museum.com/wp/2022/02/
+ 136. http://www.os2museum.com/wp/2022/01/
+ 137. http://www.os2museum.com/wp/2021/12/
+ 138. http://www.os2museum.com/wp/2021/11/
+ 139. http://www.os2museum.com/wp/2021/10/
+ 140. http://www.os2museum.com/wp/2021/09/
+ 141. http://www.os2museum.com/wp/2021/08/
+ 142. http://www.os2museum.com/wp/2021/07/
+ 143. http://www.os2museum.com/wp/2021/06/
+ 144. http://www.os2museum.com/wp/2021/05/
+ 145. http://www.os2museum.com/wp/2021/04/
+ 146. http://www.os2museum.com/wp/2021/03/
+ 147. http://www.os2museum.com/wp/2021/02/
+ 148. http://www.os2museum.com/wp/2021/01/
+ 149. http://www.os2museum.com/wp/2020/12/
+ 150. http://www.os2museum.com/wp/2020/11/
+ 151. http://www.os2museum.com/wp/2020/10/
+ 152. http://www.os2museum.com/wp/2020/09/
+ 153. http://www.os2museum.com/wp/2020/08/
+ 154. http://www.os2museum.com/wp/2020/07/
+ 155. http://www.os2museum.com/wp/2020/06/
+ 156. http://www.os2museum.com/wp/2020/05/
+ 157. http://www.os2museum.com/wp/2020/04/
+ 158. http://www.os2museum.com/wp/2020/03/
+ 159. http://www.os2museum.com/wp/2020/02/
+ 160. http://www.os2museum.com/wp/2020/01/
+ 161. http://www.os2museum.com/wp/2019/12/
+ 162. http://www.os2museum.com/wp/2019/11/
+ 163. http://www.os2museum.com/wp/2019/10/
+ 164. http://www.os2museum.com/wp/2019/09/
+ 165. http://www.os2museum.com/wp/2019/08/
+ 166. http://www.os2museum.com/wp/2019/07/
+ 167. http://www.os2museum.com/wp/2019/06/
+ 168. http://www.os2museum.com/wp/2019/05/
+ 169. http://www.os2museum.com/wp/2019/04/
+ 170. http://www.os2museum.com/wp/2019/03/
+ 171. http://www.os2museum.com/wp/2019/02/
+ 172. http://www.os2museum.com/wp/2019/01/
+ 173. http://www.os2museum.com/wp/2018/12/
+ 174. http://www.os2museum.com/wp/2018/11/
+ 175. http://www.os2museum.com/wp/2018/10/
+ 176. http://www.os2museum.com/wp/2018/08/
+ 177. http://www.os2museum.com/wp/2018/07/
+ 178. http://www.os2museum.com/wp/2018/06/
+ 179. http://www.os2museum.com/wp/2018/05/
+ 180. http://www.os2museum.com/wp/2018/04/
+ 181. http://www.os2museum.com/wp/2018/03/
+ 182. http://www.os2museum.com/wp/2018/02/
+ 183. http://www.os2museum.com/wp/2018/01/
+ 184. http://www.os2museum.com/wp/2017/12/
+ 185. http://www.os2museum.com/wp/2017/11/
+ 186. http://www.os2museum.com/wp/2017/10/
+ 187. http://www.os2museum.com/wp/2017/08/
+ 188. http://www.os2museum.com/wp/2017/07/
+ 189. http://www.os2museum.com/wp/2017/06/
+ 190. http://www.os2museum.com/wp/2017/05/
+ 191. http://www.os2museum.com/wp/2017/04/
+ 192. http://www.os2museum.com/wp/2017/03/
+ 193. http://www.os2museum.com/wp/2017/02/
+ 194. http://www.os2museum.com/wp/2017/01/
+ 195. http://www.os2museum.com/wp/2016/12/
+ 196. http://www.os2museum.com/wp/2016/11/
+ 197. http://www.os2museum.com/wp/2016/10/
+ 198. http://www.os2museum.com/wp/2016/09/
+ 199. http://www.os2museum.com/wp/2016/08/
+ 200. http://www.os2museum.com/wp/2016/07/
+ 201. http://www.os2museum.com/wp/2016/06/
+ 202. http://www.os2museum.com/wp/2016/05/
+ 203. http://www.os2museum.com/wp/2016/04/
+ 204. http://www.os2museum.com/wp/2016/03/
+ 205. http://www.os2museum.com/wp/2016/02/
+ 206. http://www.os2museum.com/wp/2016/01/
+ 207. http://www.os2museum.com/wp/2015/12/
+ 208. http://www.os2museum.com/wp/2015/11/
+ 209. http://www.os2museum.com/wp/2015/10/
+ 210. http://www.os2museum.com/wp/2015/09/
+ 211. http://www.os2museum.com/wp/2015/08/
+ 212. http://www.os2museum.com/wp/2015/07/
+ 213. http://www.os2museum.com/wp/2015/06/
+ 214. http://www.os2museum.com/wp/2015/05/
+ 215. http://www.os2museum.com/wp/2015/04/
+ 216. http://www.os2museum.com/wp/2015/03/
+ 217. http://www.os2museum.com/wp/2015/02/
+ 218. http://www.os2museum.com/wp/2015/01/
+ 219. http://www.os2museum.com/wp/2014/12/
+ 220. http://www.os2museum.com/wp/2014/11/
+ 221. http://www.os2museum.com/wp/2014/10/
+ 222. http://www.os2museum.com/wp/2014/09/
+ 223. http://www.os2museum.com/wp/2014/08/
+ 224. http://www.os2museum.com/wp/2014/07/
+ 225. http://www.os2museum.com/wp/2014/06/
+ 226. http://www.os2museum.com/wp/2014/05/
+ 227. http://www.os2museum.com/wp/2014/04/
+ 228. http://www.os2museum.com/wp/2014/03/
+ 229. http://www.os2museum.com/wp/2014/02/
+ 230. http://www.os2museum.com/wp/2014/01/
+ 231. http://www.os2museum.com/wp/2013/12/
+ 232. http://www.os2museum.com/wp/2013/11/
+ 233. http://www.os2museum.com/wp/2013/10/
+ 234. http://www.os2museum.com/wp/2013/09/
+ 235. http://www.os2museum.com/wp/2013/08/
+ 236. http://www.os2museum.com/wp/2013/07/
+ 237. http://www.os2museum.com/wp/2013/06/
+ 238. http://www.os2museum.com/wp/2013/05/
+ 239. http://www.os2museum.com/wp/2013/04/
+ 240. http://www.os2museum.com/wp/2013/03/
+ 241. http://www.os2museum.com/wp/2013/02/
+ 242. http://www.os2museum.com/wp/2013/01/
+ 243. http://www.os2museum.com/wp/2012/12/
+ 244. http://www.os2museum.com/wp/2012/11/
+ 245. http://www.os2museum.com/wp/2012/10/
+ 246. http://www.os2museum.com/wp/2012/09/
+ 247. http://www.os2museum.com/wp/2012/08/
+ 248. http://www.os2museum.com/wp/2012/07/
+ 249. http://www.os2museum.com/wp/2012/06/
+ 250. http://www.os2museum.com/wp/2012/05/
+ 251. http://www.os2museum.com/wp/2012/04/
+ 252. http://www.os2museum.com/wp/2012/03/
+ 253. http://www.os2museum.com/wp/2012/02/
+ 254. http://www.os2museum.com/wp/2012/01/
+ 255. http://www.os2museum.com/wp/2011/12/
+ 256. http://www.os2museum.com/wp/2011/11/
+ 257. http://www.os2museum.com/wp/2011/10/
+ 258. http://www.os2museum.com/wp/2011/09/
+ 259. http://www.os2museum.com/wp/2011/08/
+ 260. http://www.os2museum.com/wp/2011/07/
+ 261. http://www.os2museum.com/wp/2011/06/
+ 262. http://www.os2museum.com/wp/2011/05/
+ 263. http://www.os2museum.com/wp/2011/04/
+ 264. http://www.os2museum.com/wp/2011/03/
+ 265. http://www.os2museum.com/wp/2011/01/
+ 266. http://www.os2museum.com/wp/2010/11/
+ 267. http://www.os2museum.com/wp/2010/10/
+ 268. http://www.os2museum.com/wp/2010/08/
+ 269. http://www.os2museum.com/wp/2010/07/
+ 270. http://www.os2museum.com/wp/category/286/
+ 271. http://www.os2museum.com/wp/category/386/
+ 272. http://www.os2museum.com/wp/category/3com/
+ 273. http://www.os2museum.com/wp/category/3dfx/
+ 274. http://www.os2museum.com/wp/category/486/
+ 275. http://www.os2museum.com/wp/category/8086-8088/
+ 276. http://www.os2museum.com/wp/category/adaptec/
+ 277. http://www.os2museum.com/wp/category/agp/
+ 278. http://www.os2museum.com/wp/category/amd/
+ 279. http://www.os2museum.com/wp/category/amd64/
+ 280. http://www.os2museum.com/wp/category/apple/
+ 281. http://www.os2museum.com/wp/category/archiving/
+ 282. http://www.os2museum.com/wp/category/assembler/
+ 283. http://www.os2museum.com/wp/category/ati/
+ 284. http://www.os2museum.com/wp/category/bios/
+ 285. http://www.os2museum.com/wp/category/books/
+ 286. http://www.os2museum.com/wp/category/borland/
+ 287. http://www.os2museum.com/wp/category/bsd/
+ 288. http://www.os2museum.com/wp/category/bugs/
+ 289. http://www.os2museum.com/wp/category/buslogic/
+ 290. http://www.os2museum.com/wp/category/c/
+ 291. http://www.os2museum.com/wp/category/ct/
+ 292. http://www.os2museum.com/wp/category/cd-rom/
+ 293. http://www.os2museum.com/wp/category/cirrus-logic/
+ 294. http://www.os2museum.com/wp/category/compactflash/
+ 295. http://www.os2museum.com/wp/category/compaq/
+ 296. http://www.os2museum.com/wp/category/compression/
+ 297. http://www.os2museum.com/wp/category/conner/
+ 298. http://www.os2museum.com/wp/category/corrections/
+ 299. http://www.os2museum.com/wp/category/cp-m/
+ 300. http://www.os2museum.com/wp/category/creative-labs/
+ 301. http://www.os2museum.com/wp/category/crystal-semi/
+ 302. http://www.os2museum.com/wp/category/cyrix/
+ 303. http://www.os2museum.com/wp/category/ddr-ram/
+ 304. http://www.os2museum.com/wp/category/debugging/
+ 305. http://www.os2museum.com/wp/category/dec/
+ 306. http://www.os2museum.com/wp/category/development/
+ 307. http://www.os2museum.com/wp/category/digital-research/
+ 308. http://www.os2museum.com/wp/category/documentation/
+ 309. http://www.os2museum.com/wp/category/dos/
+ 310. http://www.os2museum.com/wp/category/dos-extenders/
+ 311. http://www.os2museum.com/wp/category/dream/
+ 312. http://www.os2museum.com/wp/category/e-mu/
+ 313. http://www.os2museum.com/wp/category/editors/
+ 314. http://www.os2museum.com/wp/category/eisa/
+ 315. http://www.os2museum.com/wp/category/ensoniq/
+ 316. http://www.os2museum.com/wp/category/esdi/
+ 317. http://www.os2museum.com/wp/category/ethernet/
+ 318. http://www.os2museum.com/wp/category/fakes/
+ 319. http://www.os2museum.com/wp/category/fixes/
+ 320. http://www.os2museum.com/wp/category/floppies/
+ 321. http://www.os2museum.com/wp/category/graphics/
+ 322. http://www.os2museum.com/wp/category/hardware-hacks/
+ 323. http://www.os2museum.com/wp/category/i18n/
+ 324. http://www.os2museum.com/wp/category/ibm/
+ 325. http://www.os2museum.com/wp/category/ide/
+ 326. http://www.os2museum.com/wp/category/intel/
+ 327. http://www.os2museum.com/wp/category/internet/
+ 328. http://www.os2museum.com/wp/category/keyboard/
+ 329. http://www.os2museum.com/wp/category/kryoflux/
+ 330. http://www.os2museum.com/wp/category/kurzweil/
+ 331. http://www.os2museum.com/wp/category/lan-manager/
+ 332. http://www.os2museum.com/wp/category/legal/
+ 333. http://www.os2museum.com/wp/category/linux/
+ 334. http://www.os2museum.com/wp/category/mca/
+ 335. http://www.os2museum.com/wp/category/microsoft/
+ 336. http://www.os2museum.com/wp/category/midi/
+ 337. http://www.os2museum.com/wp/category/netware/
+ 338. http://www.os2museum.com/wp/category/networking/
+ 339. http://www.os2museum.com/wp/category/nextstep/
+ 340. http://www.os2museum.com/wp/category/nfs/
+ 341. http://www.os2museum.com/wp/category/novell/
+ 342. http://www.os2museum.com/wp/category/nt/
+ 343. http://www.os2museum.com/wp/category/os-x/
+ 344. http://www.os2museum.com/wp/category/os2/
+ 345. http://www.os2museum.com/wp/category/pc-architecture/
+ 346. http://www.os2museum.com/wp/category/pc-hardware/
+ 347. http://www.os2museum.com/wp/category/pc-history/
+ 348. http://www.os2museum.com/wp/category/pc-press/
+ 349. http://www.os2museum.com/wp/category/pci/
+ 350. http://www.os2museum.com/wp/category/pcmcia/
+ 351. http://www.os2museum.com/wp/category/pentium/
+ 352. http://www.os2museum.com/wp/category/pentium-4/
+ 353. http://www.os2museum.com/wp/category/pentium-ii/
+ 354. http://www.os2museum.com/wp/category/pentium-iii/
+ 355. http://www.os2museum.com/wp/category/pentium-pro/
+ 356. http://www.os2museum.com/wp/category/plug-and-play/
+ 357. http://www.os2museum.com/wp/category/powerpc/
+ 358. http://www.os2museum.com/wp/category/pre-release/
+ 359. http://www.os2museum.com/wp/category/ps2/
+ 360. http://www.os2museum.com/wp/category/qnx/
+ 361. http://www.os2museum.com/wp/category/quantum/
+ 362. http://www.os2museum.com/wp/category/random-thoughts/
+ 363. http://www.os2museum.com/wp/category/rdram/
+ 364. http://www.os2museum.com/wp/category/roland/
+ 365. http://www.os2museum.com/wp/category/ryzen/
+ 366. http://www.os2museum.com/wp/category/s3/
+ 367. http://www.os2museum.com/wp/category/sco/
+ 368. http://www.os2museum.com/wp/category/scsi/
+ 369. http://www.os2museum.com/wp/category/seagate/
+ 370. http://www.os2museum.com/wp/category/security/
+ 371. http://www.os2museum.com/wp/category/site-management/
+ 372. http://www.os2museum.com/wp/category/smp/
+ 373. http://www.os2museum.com/wp/category/software-hacks/
+ 374. http://www.os2museum.com/wp/category/solaris/
+ 375. http://www.os2museum.com/wp/category/sound/
+ 376. http://www.os2museum.com/wp/category/sound-blaster/
+ 377. http://www.os2museum.com/wp/category/source-code/
+ 378. http://www.os2museum.com/wp/category/standards/
+ 379. http://www.os2museum.com/wp/category/storage/
+ 380. http://www.os2museum.com/wp/category/supermicro/
+ 381. http://www.os2museum.com/wp/category/tcp-ip/
+ 382. http://www.os2museum.com/wp/category/thinkpad/
+ 383. http://www.os2museum.com/wp/category/trident/
+ 384. http://www.os2museum.com/wp/category/ultrasound/
+ 385. http://www.os2museum.com/wp/category/uncategorized/
+ 386. http://www.os2museum.com/wp/category/undocumented/
+ 387. http://www.os2museum.com/wp/category/unix/
+ 388. http://www.os2museum.com/wp/category/unixware/
+ 389. http://www.os2museum.com/wp/category/usb/
+ 390. http://www.os2museum.com/wp/category/vga/
+ 391. http://www.os2museum.com/wp/category/virtualbox/
+ 392. http://www.os2museum.com/wp/category/virtualization/
+ 393. http://www.os2museum.com/wp/category/vlb/
+ 394. http://www.os2museum.com/wp/category/watcom/
+ 395. http://www.os2museum.com/wp/category/wave-blaster/
+ 396. http://www.os2museum.com/wp/category/western-digital/
+ 397. http://www.os2museum.com/wp/category/windows/
+ 398. http://www.os2museum.com/wp/category/windows-95/
+ 399. http://www.os2museum.com/wp/category/windows-xp/
+ 400. http://www.os2museum.com/wp/category/wireless/
+ 401. http://www.os2museum.com/wp/category/wordstar/
+ 402. http://www.os2museum.com/wp/category/x86/
+ 403. http://www.os2museum.com/wp/category/xenix/
+ 404. http://www.os2museum.com/wp/category/xeon/
+ 405. http://www.os2museum.com/wp/category/yamaha/
+ 406. http://www.os2museum.com/wp/
+ 407. https://wordpress.org/
+
+ Hidden links:
+ 409. http://www.os2museum.com/wp/a-brief-history-of-unreal-mode/ultima-vii-voodoo/