Hubbry Logo
AARD codeAARD codeMain
Open search
AARD code
Community hub
AARD code
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
AARD code
AARD code
AARD code
View on Wikipedia
from Wikipedia

An example of the error message the AARD code would produce

The AARD code was a segment of code in a beta release of Microsoft Windows 3.1 that would issue a cryptic error message when run on the DR DOS operating system rather than the Microsoft-affiliated MS-DOS or PC DOS. Microsoft inserted the code in an attempt to manipulate people into not using competing operating systems; it is an example of the company's fear-uncertainty-doubt tactics.

Description

[edit]

This XOR-encrypted, self-modifying, and deliberately obfuscated x86 assembly code used a variety of undocumented MS-DOS structures and functions to detect if a machine was running DR DOS. The code was present in the installer, in the WIN.COM file used to load Windows, and in several other EXE and COM files within Windows 3.1.[1]

The AARD code was discovered by Geoff Chappell on 17 April 1992 and further analyzed and documented in a joint research effort with Andrew Schulman.[2][3][4][5][6] The name "AARD code" came from the letters "AARD" that were found in a hex dump of the Windows 3.1 installer; this turned out to be the signature of Microsoft programmer Aaron R. Reynolds (1955–2008).[7][8][9]

Microsoft disabled the AARD code for the final release of Windows 3.1, but did not remove it so it could be later reactivated by the change of a single byte.[5]

DR DOS publisher Digital Research released a patch named "business update" in 1992 to bypass the AARD code.[10][11][12]

Memos

[edit]

The rationale for the AARD code came to light when internal memos were released during the United States v. Microsoft Corp. antitrust case in 1999. Internal memos released by Microsoft revealed that the specific focus of these tests was DR DOS.[1][13][14] At one point, Microsoft CEO Bill Gates sent a memo to a number of employees that said, "You never sent me a response on the question of what things an app would do that would make it run with MSDOS and not run with DR-DOS. Is there [sic] feature they have that might get in our way?"[12][15] Microsoft Senior Vice President Brad Silverberg later sent another memo, saying, "What the [user] is supposed to do is feel uncomfortable, and when he has bugs, suspect that the problem is dr-dos and then go out to buy ms-dos."[12][15]

After Novell bought DR DOS and renamed it "Novell DOS", Microsoft Co-President Jim Allchin wrote in a memo, "If you're going to kill someone there isn't much reason to get all worked up about it and angry. Any discussions beforehand are a waste of time. We need to smile at Novell while we pull the trigger."[16][12][15]

Lawsuit and settlement

[edit]

Novell DOS changed hands again. The new owner, Caldera, Inc., began a lawsuit against Microsoft over the AARD code, Caldera v. Microsoft,[12][17][18][19] which was later settled.[15][20][21][22] It was originally believed that the settlement was around $150 million,[a][23] but in November 2009, the settlement agreement was released, and the total was revealed to be $280 million.[b][24][21][22][25]

See also

[edit]

Footnotes

[edit]

References

[edit]

Further reading

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

AARD code

View on Grokipedia
from Grokipedia
The AARD code was a segment of deliberately obfuscated embedded in beta releases of , such as build 068, that performed compatibility checks to detect execution on non- DOS variants like from . Upon identifying through discrepancies in DOS interrupt handling—such as unique responses to INT 21h function 33h—the code triggered a "Non-fatal 102" message, advising users to contact beta support and implying system instability to discourage use of alternatives to . Named after the string "AARD" embedded within it, referencing programmer Aaron R. Reynolds who initialed his contributions, the code appeared in components including the setup , WIN.COM, and device drivers like . First analyzed externally by software reverse engineer Geoff Chappell in early 1992 and publicly dissected by Andrew Schulman in later that year, it exemplified 's tactics to safeguard its monopoly during intense competition in the early 1990s DOS market. Though deactivated in the final release—where tests ran silently without errors—the AARD code's obfuscation and targeted sabotage fueled perceptions of anti-competitive behavior, contributing evidence in subsequent antitrust actions such as Caldera, Inc. v. Corp. (1999).

Historical Context

Origins of DR-DOS and MS-DOS Competition

Digital Research, founded in 1976 by Gary Kildall to commercialize CP/M—the dominant operating system for 8-bit microcomputers—initially positioned itself as the leading OS provider for emerging 16-bit systems. When IBM sought an operating system for its personal computer in 1980, it approached Digital Research for an adaptation of CP/M known as CP/M-86. Negotiations faltered due to scheduling conflicts and disagreements over licensing terms, prompting IBM to turn to Microsoft, which lacked a suitable OS but quickly licensed 86-DOS (originally QDOS, a CP/M-inspired system developed by Tim Paterson at Seattle Computer Products) in late 1980. Microsoft adapted 86-DOS, releasing MS-DOS 1.0 in August 1981 as PC-DOS for the IBM PC 5150, bundled at no extra cost with hardware, which propelled MS-DOS to market dominance amid the IBM PC's rapid sales growth. Digital Research's delayed launch in late 1982 came too late and at a premium price of $495, compared to 's effective zero when bundled, allowing to capture developers and users in the burgeoning PC ecosystem. To regain footing, Digital Research shifted strategy toward compatibility, releasing DOS Plus in 1985—a single-user multitasking extension of 2.11—and culminating in 3.31 on May 28, 1988, initially for OEMs, which introduced enhancements like FAT16 support, command-line history, and improved file management absent in contemporary versions. A retail version, 3.41, followed in June 1989, adding utilities such as management via , positioning as a feature-rich alternative amid 4.0's buggy reception and limited availability. The competition escalated with 5.0's release in May 1990, which included disk caching, file compression, load-high utilities for better memory use, and the ViewMAX graphical interface, all at a lower price point than equivalents, earning acclaim as a superior, forward-looking DOS that previewed features Microsoft would later adopt. Microsoft's 5.0, launched in June 1991, incorporated similar memory management and undelete tools, directly responding to 's innovations, while 6.0 in September 1991 added multitasking via TASKMAX and advanced compression with SuperStor, further pressuring 's market share in the early 1990s as PC clones proliferated and users sought cost-effective upgrades. This rivalry, rooted in Digital Research's legacy but fueled by 's compatibility and extras, threatened Microsoft's control just as Windows emerged as a DOS-dependent shell.

Microsoft's Windows Strategy in the Early 1990s

In the early , Microsoft accelerated its shift toward graphical user interfaces with the release of on May 22, 1990, which significantly boosted PC sales and established Windows as a key platform atop . To counter competitive pressures from Digital Research's , which offered multitasking and disk compression features ahead of 5.0's June 1991 release, pursued a multifaceted strategy emphasizing compatibility exclusivity and market deterrence. This included upgrading to parity while leveraging Windows development to impose technical barriers on rivals. A core element involved OEM licensing agreements that mandated testing and certification of Windows solely with , effectively discouraging hardware vendors from promoting alternatives like . Internally, viewed as an existential threat to its DOS revenue stream, with executives directing efforts to generate (FUD) through announcements of forthcoming enhancements and compatibility warnings. These tactics aimed to preserve 's near-monopoly in DOS, projected to yield over $1 billion annually by 1992, while positioning Windows as the premium overlay requiring a "trusted" underlying OS. For , codenamed "" and entering beta testing in late 1991, incorporated deliberate detection code—later known as the AARD code—to identify environments and trigger cryptic error messages, such as "Non-fatal error detected," during setup. This sabotage mechanism, active from December 1991 beta builds, sought to undermine user confidence in 's Windows compatibility without overt admission, aligning with broader internal directives to "kill any future versions" through incompatibility. By July 1991, had ceased including in Windows beta testing protocols, further isolating competitors. These measures contributed to DR-DOS's market decline, as OEMs and consumers favored the seamless /Windows bundle, enabling to maintain pricing power and ecosystem control ahead of Windows 3.1's April 6, 1992 commercial launch. Despite DR-DOS's technical merits, 's strategic orchestration of perceived instability eroded its viability, as evidenced in subsequent antitrust scrutiny over exclusionary practices.

Technical Details

Mechanism of Detection and Sabotage

The AARD code, implemented in the setup executable of Windows 3.1 beta releases such as build 3.10.068 distributed in December 1991, performed a series of obfuscated machine code tests to detect the underlying DOS variant. These tests targeted precise behavioral differences between Microsoft MS-DOS and competitors like DR-DOS, examining undocumented aspects such as interrupt 21h responses, memory data structures like the Disk Parameter Block (DPB), and handling of extended memory services via the XMS driver. DR-DOS, seeking compatibility, implemented additional or altered features—such as enhanced multitasking or file system behaviors—that deviated from MS-DOS norms, triggering detection when these tests yielded unexpected results. Upon positive identification of a non-MS-DOS environment, the code initiated sabotage by halting the installation process and displaying a cryptic non-fatal , such as "Invalid device driver interface" or a variant prompting users to contact Windows beta support for assistance with untested configurations. This message, embedded in components like WIN.COM or (version 3.03), effectively prevented Windows from loading on systems while allowing continuation on genuine , thereby enforcing platform exclusivity without overt incompatibility claims. The obfuscation, including encrypted comparisons and non-standard assembly sequences initialed "AARD" after developer R. Reynolds, was designed to evade and circumvention by competitors. Microsoft internal rationale framed the mechanism as a protective measure to alert beta testers to potential risks from unverified DOS variants, relying on "very precise behavioral characteristics" beyond standard APIs to distinguish authentic . However, the targeted deviations exploited -specific enhancements, rendering the check functionally discriminatory rather than generically cautionary, as evidenced by successful circumvention patches in 6.0 that rearranged internal structures to mimic responses. In final releases on March 9, 1992, the error display was suppressed, leaving the detection logic quiescent to mitigate backlash after public exposure in April 1992.

Code Implementation and Obfuscation

The AARD code was embedded within multiple executable files in the beta version of , specifically including WIN.COM, , SMARTDRV., SETUP., and MSD.. This implementation allowed the code to execute during key initialization phases, such as Windows startup and setup processes, where it performed compatibility checks on the underlying DOS environment. Upon detection of a non-Microsoft DOS variant like , the code triggered a non-fatal numbered 2726, stating: "Non-Fatal error detected: error #2726, Please contact beta support." In the retail release of , the code remained present but was rendered quiescent through a control byte set to zero, preventing without modification. At its core, the implementation relied on interrogating undocumented DOS internal structures accessed via interrupt 21h with AH=52h, retrieving the SysVars pointer to examine fields such as drive parameter blocks (DPBs), current directory structures (CDS), file control block to system file table offsets (FCB-SFT), and case-mapping segments. Specific tests verified non-null pointers, paragraph-aligned addresses, and zero offsets for FCB-SFT linkages—criteria met by MS-DOS but failed by DR-DOS due to structural differences, such as non-paragraph-aligned FCB-SFT pointers and absent CDS entries. Failure of any test initiated the error sequence, embedding plaintext signatures like "AARD" and "RSAA" within the encrypted payload to identify the module's purpose upon decryption. Obfuscation was achieved through XOR of the detection logic, requiring runtime decryption to reveal operational , combined with self-modifying instructions that altered execution flow dynamically. Additional anti- measures included overwriting vectors for single-step (INT 1), NMI (INT 2), and (INT 3) interrupts with invalid values, halting execution under debuggers or emulators attempting stepwise tracing. These techniques rendered static disassembly ineffective and dynamic challenging, resembling tactics used in malicious software to evade detection, though here purposed to conceal compatibility enforcement rather than propagate harm. The encrypted form obscured the arbitrary nature of the tests, which imposed non-standard compatibility requirements without corresponding technical justification beyond distinguishing DOS variants.

Internal Communications

Key Memos and Emails from Engineers

Internal communications from the early 1990s, later disclosed during the v. antitrust , revealed discussions among engineers and executives about implementing detection mechanisms to hinder compatibility with Windows. On September 27, 1991, Brad Silverberg, a vice president, emailed Paul Allchin stating that "has problems running windows today, and I assume will have more problems in the future." Allchin replied, "You should make sure it has problems in the future. :-)", indicating an intent to perpetuate incompatibilities. On September 30, 1991, David Cole, head of Windows development, emailed Phil Barrett emphasizing the need to restrict to or OEM variants, proposing code to detect version 6 and refuse loading with an such as "Invalid interface." Cole further suggested in related correspondence that this approach would "put competitors on a treadmill" by forcing ongoing compatibility efforts. In the same timeframe, Cole discussed embedding a concealed bug to disrupt systems, which developer Aaron Reynolds implemented as the obfuscated AARD detection code, triggering freezes or cryptic errors to erode user confidence in the rival OS. By 1992, Brad Silverberg articulated the strategic rationale in an , explaining that the error messaging was designed so "the [user] is supposed to do is feel uncomfortable, and when he has bugs, suspect that the problem is and then go out to buy ." This echoed earlier 1991 internal debates on adding -specific warnings in beta setups, though some engineers expressed reservations, with one noting, "I hate this whole thing. I think it's totally rude, reinforces the image that users have of us as the evil ones, etc." Brad Chase, another vice president, cautioned that any detection code "better be perfect. Otherwise you could be in a heap of trouble," highlighting risks of exposure. These exchanges, spanning 1989 to 1992—including a 1989 query from on exploiting app behaviors incompatible with —demonstrated coordinated efforts to leverage technical barriers against competition, though the AARD code itself was confined to beta versions and omitted from the commercial release.

Evidence of Intentional Design

The AARD code consisted of obfuscated routines embedded in beta versions of , including modules such as and WIN.COM, designed to perform targeted checks for the presence of versus alternative operating systems like . These checks exploited differences in how emulated undocumented internal functions, such as specific responses to calls and timing behaviors, triggering a "non-fatal error" message only when executed on non- environments. The deliberate selection of these -specific traits, rather than standard compatibility tests, indicates an intent to exclude competitors by simulating instability without providing transparent failure modes. Obfuscation techniques, including encrypted strings, redundant jumps, and dispersal across multiple files without comments, further evidenced purposeful concealment of the detection mechanism, as such complexity served no apparent necessity for beta testing but effectively hid the code's discriminatory function from scrutiny. This approach was implemented by November 8, 1991, and tested within seven days, then distributed to over 12,000 beta sites in December 1991 as a marketing tool to foster doubt about reliability. Internal Microsoft documents from the Caldera v. litigation, including depositions and exhibits, confirmed the code's role in generating vague, alarming errors like "Non-fatal error detected: error #2726" to imply untested OS risks, aligning with a broader strategy to discomfort users and drive adoption of . Supporting communications revealed explicit directives for incompatibility; for instance, an email from September 30, 1991, instructed to "detect dr 6 and refuse to load," while Paul Allchin responded to reports of DR-DOS issues by stating, "You should make sure it has problems in the future. :-)". Brad Silverberg, in a February 10, 1992, internal note, advocated using the errors to make DR-DOS users "uncomfortable" and encourage switching, corroborating the code's deployment as a tactical measure rather than an inadvertent bug. The U.S. District Court in Caldera, Inc. v. Microsoft Corp. (1999) denied summary judgment on these claims, recognizing the AARD code as potential evidence of monopolistic conduct under Section 2 of the Sherman Act due to its targeted exclusionary design.

Discovery and Initial Reactions

Exposure During Beta Testing

During beta testing of in early 1992, users running the beta software on versions 5 and 6 encountered non-fatal error messages and compatibility failures, particularly in components like , which were absent when using . These issues manifested as cryptic warnings, such as indications of unsupported full-screen editing or , designed to signal incompatibility and discourage usage. Software analyst Geoff Chappell first uncovered the AARD code on April 17, 1992, by disassembling version 3.03 from a beta distribution, revealing a detection mechanism that specifically targeted through checks for unique internal behaviors and structures not present in . The code employed obfuscation techniques, including XOR encryption of strings and intentional debug traps, to evade straightforward and conceal its intent. Beta builds such as 050, 058, 060, 061, and 068 incorporated the AARD code, which triggered diagnostic output under but remained dormant on , confirming the targeted nature of the detection during testing phases. Initial exposure prompted private analysis among developers, with the first known public discussion emerging in June 1992 on the Compulink Information Exchange conferencing system, where details of the code's functionality were shared. This revelation highlighted Microsoft's deliberate compatibility barriers, as the errors were not generic but keyed to DR-DOS-specific identifiers.

Immediate Industry and Competitor Responses

, developer of , promptly addressed the AARD code's sabotage by issuing a patch termed the "business update" in early 1992 for 6.0. This update modified the operating system's handling sequence—specifically, reordering calls to INT 21h functions—to evade the detection tests in beta setup and core files like WIN.COM, allowing installation and execution without the "non-fatal error" message. Novell, which acquired Digital Research in July 1991 and rebranded subsequent releases under its name, supported the patch effort internally but avoided immediate public escalation. The focus remained on technical circumvention to preserve market viability amid 's anticipated dominance, rather than lodging formal complaints or seeking regulatory intervention at that stage. Broader industry reactions were subdued, with no documented collective outcry from competitors or analyst firms in late 1991 or early 1992; instead, the episode reinforced private skepticism about 's compatibility claims for non-MSDOS environments. deactivated the error-triggering aspect of the AARD code prior to the final release on April 6, 1992, though detection logic persisted in binaries like TASKMAN.EXE for potential future use.

Caldera v. Microsoft Lawsuit

, Inc., a Utah-based software company that acquired the intellectual property rights to from on July 23, 1996, filed an antitrust lawsuit against Corporation on July 24, 1996, in the United States District Court for the District of Utah (Case No. 2:96CV645B). The suit alleged violations of Sections 1 and 2 of the , claiming engaged in a pattern of anticompetitive conduct from the late through the mid-1990s to eliminate as a rival to and preserve 's dominance in the PC operating system market, which exceeded 90% share by the early s. sought for lost sales, estimated in the hundreds of millions, attributing 's market decline— from over 1 million units sold by to near —directly to 's tactics. Central to the allegations was Microsoft's deliberate creation of technical incompatibilities targeting DR-DOS, including the AARD code embedded in the final beta release of Windows 3.1, distributed to more than 12,000 test sites in early 1992 ahead of its commercial launch on April 6, 1992. This code functioned as an environmental check during setup: upon detecting a non-Microsoft DOS kernel, such as DR-DOS 5.0 or 6.0, it triggered a cryptic "non-fatal error detected" message (e.g., "Error number 10305") advising users to contact Windows beta support, implying instability without causing an actual failure, thereby eroding user confidence in DR-DOS compatibility with Windows. The code was absent from the final retail version but served to discourage DR-DOS adoption during the critical beta phase, when Digital Research was excluded from testing starting in July 1991, limiting opportunities for compatibility patches. Evidence of intent emerged from internal Microsoft documents cited in the complaint, including an email from Windows executive Brad Silverberg stating the code's goal was to "make [the user] feel uncomfortable, and when he has bugs, suspect that the problem is and then go out to buy ." argued this exemplified a broader scheme of sabotage, encompassing altered APIs (e.g., DOSMGR callouts), misleading error prompts in Windows applications, and false public statements by Microsoft executives denying support for , despite internal awareness of workable fixes. These measures, combined with predatory per-processor licensing fees as low as $1 per unit (versus 's $49 retail) and exclusive OEM contracts requiring bundling, allegedly constituted and unlawful tying of to Windows, stifling competition in violation of antitrust law. The case featured contentious discovery, with U.S. District Judge Ronald N. Boyce ordering Microsoft in July 1998 to disclose Windows 95 source code within five days to allow Caldera to verify claims of embedded incompatibilities extending the Windows 3.1 tactics. Microsoft contested the scope, leading to further disputes, but complied under penalty of sanctions. In May 1999, the court denied Microsoft's motions for partial summary judgment on key claims, ruling that the AARD code and related conduct, when aggregated, provided sufficient evidence of predatory intent under Section 2, distinguishing it from mere product disparagement and permitting the case to advance toward trial.

Settlement Terms and Outcomes

The v. Microsoft antitrust lawsuit, filed in July 1996 and alleging including sabotage of via mechanisms like the AARD code, was settled out of court on January 10, 2000, weeks before a scheduled on February 1. The agreement resolved all claims without Microsoft admitting liability or agreeing to changes in its licensing, bundling, or compatibility practices. Key terms centered on a confidential monetary from to , estimated at $275 million—far below Caldera's initial demand of $1.6 billion in damages. accounted for the settlement with a one-time pre-tax charge of about $155 million, or 3 cents per share, against earnings in its fiscal first quarter ending March 31, 2000. Outcomes included the immediate dismissal of the suit, ending a three-year legal battle that had spotlighted internal Microsoft documents on DR-DOS incompatibility. , which had acquired DR-DOS assets from , received funds that supported its operations amid the product's declining market viability, though the company later pivoted away from DOS-related efforts. The resolution did not yield broader remedies like injunctions against Microsoft's DOS/Windows integration, leaving such issues to contemporaneous U.S. Department of Justice antitrust proceedings.

Impact and Legacy

Effects on DR-DOS and Digital Research

The AARD code, present in the beta version of Microsoft distributed to original equipment manufacturers (OEMs) and developers in early 1992, triggered setup error messages on systems, falsely implying fundamental incompatibility and prompting warnings about potential system instability. This behavior undermined confidence in 6.0, which had been positioned as a superior alternative to with features like built-in disk compression and multitasking support, leading OEMs to conduct compatibility tests that failed due to the code's detection mechanisms. One major corporation explicitly cited the beta test failures as grounds for rejecting 6.0 in favor of , illustrating how the code influenced procurement decisions during a period when held approximately 10% of new OS shipments by late 1990. The resulting reputational damage accelerated a sharp decline in DR-DOS sales, which fell from $24.7 million in fiscal year 1991 to $15.5 million in fiscal year 1992, coinciding with the AARD code's exposure and Microsoft's dominance in the DOS market. , the developer of DR-DOS, faced intensified financial strain as OEM partnerships eroded and contracted amid perceptions of unreliability with emerging Windows environments; the company had already been navigating competitive pressures since DR-DOS 5.0's release in November 1990, but the AARD incident exacerbated foreclosure from the DOS ecosystem. Although issued patches to circumvent the detection—such as a 1992 "business update" for DR-DOS—these measures proved insufficient to restore momentum, as trust in long-term compatibility had been compromised. For as a whole, the AARD code contributed to a broader erosion of viability in the operating systems market, culminating in the sale of its assets to in July 1991 for an undisclosed sum amid ongoing revenue pressures. , upon acquiring , attempted to leverage it against through pricing and feature enhancements but encountered persistent barriers, including lingering compatibility skepticism; by the mid-1990s, 's relevance waned further as Windows solidified as the , leading to divest the product to in 1996. The episode, while not the sole factor in 's decline—exacerbated by internal challenges following founder Gary Kildall's departure—highlighted how targeted technical measures could decisively tilt competition, reducing to a niche player unable to challenge MS-DOS's near-monopoly by the era.

Broader Implications for Antitrust and Software Competition

The AARD code exemplified how a dominant firm in the operating system market could employ hidden, discriminatory technical features to erode competitors' viability, thereby preserving monopoly power through engineered incompatibilities rather than superior product merits. By embedding obfuscated detection routines in beta that triggered deceptive error messages specifically under —such as warnings implying systemic instability— created artificial barriers to multi-vendor interoperability, which deterred OEMs and end-users from adopting alternatives despite DR-DOS's lower pricing and functional equivalence. This approach not only accelerated DR-DOS's market decline from a peak share exceeding 20% in 1990 but also signaled to rivals the risks of challenging incumbents reliant on proprietary APIs and undocumented calls. In antitrust enforcement, the episode highlighted the evidentiary hurdles in software cases, where reverse-engineering exposed intent otherwise concealed in encrypted code segments spanning multiple binaries, prompting FTC investigations into Microsoft's broader pattern of sabotage via "undocumented interfaces." It informed private litigation like v. Microsoft (filed 1996, settled 2000 for $100 million without admission of liability), which alleged violations of Sections 1 and 2 of the Sherman Act through technical exclusion, and echoed in U.S. v. (1998), where courts scrutinized similar leveraging of Windows dominance to stifle innovation. Regulators and scholars subsequently emphasized the need for behavioral remedies targeting obligations, as structural divestitures proved infeasible in network-effect-driven markets, influencing guidelines on assessing "technological tying" under antitrust doctrine. For software competition policy, the AARD code underscored systemic risks in ecosystems where OS control enables selective compatibility enforcement, discouraging entrants by raising switching costs and eroding trust in cross-vendor standards. It contributed to a legacy of heightened scrutiny on dominant platforms' API governance, evident in later probes into Microsoft's bundling practices (e.g., Media Player case, 2004 fine of €497 million), and parallels modern debates on gatekeeping or lock-in, where verifiable technical sabotage remains rare but pretextual "quality" pretexts persist. Empirical analyses post-incident linked such tactics to reduced DOS innovation, with Microsoft's share surging to over 90% by 1993, validating concerns that unchecked exclusion distorts R&D incentives toward defensive rather than value-creating efforts.

References

  1. https://www.geoffchappell.com/notes/windows/archive/aard/index.htm
  2. http://fringe.davesource.com/Fringe/NonZen_Companies/Microsoft/Tactics/1993.09.01.Locks_Out_DrDOS.html
  3. https://www.geoffchappell.com/notes/windows/archive/aard/drdos/index.htm
  4. https://www.geoffchappell.com/notes/windows/archive/aard/firstpublic.htm
  5. https://www.digitalresearch.biz/HISZMSD.HTM
  6. https://lunduke.substack.com/p/quick-and-dirty-the-story-of-86-dos
  7. https://www.abortretry.fail/p/the-history-of-dr-dos
  8. https://winworldpc.com/product/dr-dos/5x
  9. https://www.cnet.com/tech/tech-industry/microsoft-emails-focus-on-dr-dos-threat/
  10. https://www.theregister.com/1999/11/05/how_ms_played_the_incompatibility/
  11. https://www.techmonitor.ai/technology/did_microsofts_vaporware_fud_incompatibility_kill_dr_dos
  12. https://law.justia.com/cases/federal/district-courts/FSupp2/72/1295/2336233/
  13. https://www.wired.com/1999/05/caldera-ms-cheated-in-dos-war/
  14. https://jacobfilipp.com/DrDobbs/articles/DDJ/1994/9401/9401o/9401o.htm
  15. https://web.archive.org/web/19991128084349/http://www.ddj.com/articles/1993/9309/9309d/9309d.htm
  16. https://www.deseret.com/1998/8/28/19398715/old-e-mail-haunts-microsoft-in-lawsuit/
  17. https://www.digitalresearch.biz/DR/Info/fullstory/factstat.html
  18. https://fringe.davesource.com/Fringe/NonZen_Companies/Microsoft/Tactics/1993.09.01.Locks_Out_DrDOS.html
  19. https://www.geoffchappell.com/notes/windows/archive/aard/research.htm
  20. https://betawiki.net/wiki/Windows_3.1_build_068
  21. https://www.geoffchappell.com/notes/windows/archive/aard/drdos/research.htm
  22. https://www.digitalresearch.biz/DR/Info/fullstory/ca_sues_ms.html
  23. http://www.techlawjournal.com/courts/caldera/Default.htm
  24. https://www.wired.com/1998/07/caldera-obtains-win95-code/
  25. https://www.zdnet.com/article/us-report-microsoft-ordered-to-turn-over-code-to-caldera/
  26. https://www.cnet.com/tech/tech-industry/microsoft-caldera-settle-long-standing-lawsuit/
  27. https://www.marketwatch.com/story/microsoft-settles-caldera-lawsuit
  28. https://www.nytimes.com/2000/01/11/business/microsoft-and-caldera-settle-antitrust-suit.html
  29. http://news.bbc.co.uk/2/hi/business/599133.stm
  30. https://www.wsj.com/articles/SB947543007415899052
  31. https://www.latimes.com/archives/la-xpm-2000-jan-11-fi-52790-story.html
  32. http://news.bbc.co.uk/2/hi/business/600488.stm
  33. https://www.researchgate.net/publication/312511222_Microsoft_Plays_Hardball_The_Use_of_Exclusionary_Pricing_and_Technical_Incompatibility_to_Maintain_Monopoly_Power_in_Markets_for_Operating_System_Software
  34. https://news.ycombinator.com/item?id=43575884
  35. https://www.stuarttaylorjr.com/content-what-do-microsoft-monster/
  36. https://www.ecis.eu/documents/Finalversion_Consumerchoicepaper.pdf
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.