diff options
Diffstat (limited to 'doc/www.os2museum.com_wp_a-brief-history-of-unreal-mode.txt')
| -rw-r--r-- | doc/www.os2museum.com_wp_a-brief-history-of-unreal-mode.txt | 1626 |
1 files changed, 1626 insertions, 0 deletions
diff --git a/doc/www.os2museum.com_wp_a-brief-history-of-unreal-mode.txt b/doc/www.os2museum.com_wp_a-brief-history-of-unreal-mode.txt new file mode 100644 index 0000000..a02d0be --- /dev/null +++ b/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/ |