Slash Boxes

SoylentNews is people

posted by janrinok on Friday November 12 2021, @04:53PM   Printer-friendly
from the leopards-don't-change-their-spots dept.

Software analyst Geoff Chappell was the expert hired by Caldera to dig into the infamous AARD code. Recently he made a review of the discovery, publication, earlier work, personal work, and scale of effort involved in analyzing the AARD code, from a historical perpective. He doesn't adress the ethical or political repercussions of the code. However, being a principal in the analysis, he is able to set the record straight on some technical and legal facts.

The AARD code is from back when MS Windows was still just a graphical shell on top of a text-based disk operating system (DOS) and existed briefly as some XOR-encrypted, self-modifying, deliberately obfuscated machine code and using a variety of undocumented DOS structures and functions. The purpose of the code was to detect competing DOSes, specifically, the then popular DR-DOS, and throw up an unnecessary warning when detected.

Some programs and drivers in some pre-release builds of Windows 3.1 include code that tests for execution on MS-DOS and displays a disingenuous error message if Windows is run on some other type of DOS. The message tells of a "Non-fatal error" and advises the user to "contact Windows 3.1 beta support". Some programs in the released build include the code and the error message, and even execute the code, performing the same tests, but without acting on the result to display the error message.

The code in question has become known widely as the AARD code, named after initials that are found within. Although the AARD code dates from the start of the 1990s, it returned to controversy at the end of the 1990s due to its appearance in a suit at law between Caldera and Microsoft. Caldera was by then the owner, after Digital Research and Novell, of what had been DR DOS. It has ever since been treated as a smoking gun in analyses of anti-competitive practices by Microsoft.

It is not my intention here to comment on the rights or wrongs that I may or may not perceive in the AARD code's existence. However, I must declare a financial interest: in 1999 when this note was first published, I was engaged indirectly by Caldera to assist with their understanding of MS-DOS and Microsoft Windows for the suit just mentioned.

What I do intend here is to put on the public record a few points of history.

The AARD code, during its short tenure, was particularly effective in scaring the public away from DR-DOS.

Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by bzipitidoo on Friday November 12 2021, @10:11PM (3 children)

    by bzipitidoo (4388) on Friday November 12 2021, @10:11PM (#1195760) Journal

    What killed it for me was not just MS's untrustworthy code and ways. It was the Borland C++ compiler. Had several really horrendous bugs. Like, if your program used more than 64K RAM, the Borland C++ executable would just reuse the same 64K segment! This bug persisted to at least version 4.5, and I think into 5.0. One option was to pay lots more money for MS Visual C++. Switched to gcc on Linux, and never looked back.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by DannyB on Friday November 12 2021, @10:23PM

    by DannyB (5839) Subscriber Badge on Friday November 12 2021, @10:23PM (#1195766) Journal

    The one C++ compiler that was a disaster for me, on Power Mac, was the Symantec C++ compiler version 8. Prior to that it worked great. And I also had used THINK C and MetroWerks CodeWarrior.

    What really did it in for me (mid-late 90's) was that no two platforms C++ compiler implemented the same subsets of the language. Thus I couldn't expect to make some large subset of my code generic across both Mac and PC.

    Now I'm sure that situation changed over time. But by then I had moved on to (something else) and then to Java.

    I had some thoughts about lasers, but they were incoherent.
  • (Score: 0) by Anonymous Coward on Saturday November 13 2021, @03:20PM (1 child)

    by Anonymous Coward on Saturday November 13 2021, @03:20PM (#1195932)
    You should have bought the conpiler and the manuals, instead of purating it. You eere limited to 64k in tiny memory model (combines code and data into one segment) mode, 128k (separate code and data segments ) in small memory model, then you had compact, medium, large, and huge memory models.

    Reminds me of the time I was talking with the guys at Matrox, and they were complaining that Borland was optimizing away certain variables and replacing them with static values. This was actually a defect in the Microsoft compiler, which didn't have a "volitile" keyword for variables modified outside the programs control, such as an external clock or video hardware. So they wouldn't optimize out any variables that COULD be replaced by static values.

    That you thought the 64k limit was a compiler defect shows that you were incompetent. It was VERY easy to seitch memory model, especially in the IDE.

    • (Score: 3, Interesting) by bzipitidoo on Saturday November 13 2021, @10:40PM

      by bzipitidoo (4388) on Saturday November 13 2021, @10:40PM (#1195987) Journal

      You troll, but I'll respond anyway.

      I did buy it. Why did you assume otherwise? And I tried every one of those memory models, hoping to fix the problem. Not even "huge" avoided the flaw. Borland C++ is a toy compiler, okay for small school projects that stay well under 64K data. Even if your contention is correct that it was an intentional crippling to punish piracy, such treacherous design is stupidly risky. A false positive can too easily happen, and screw the paying customer. Sneakily injecting a flaw that could take much time to discover, rather than up-front telling the user of a licensing problem, is the height of treachery. Damned unfair to downstream users who had no part in any alleged piracy of the compiler by the developers. One has to wonder what else the compiler is doing? Maybe inserting back doors in the binary? Compilers must never abuse that trust. One reason it took me so long to figure out the problem is that I trusted the compiler, and thought that whatever was wrong was my mistake, in my code.

      One flaw in version 2 that was fixed by 4.5 was its inability to handle the =<< and =>> shift assignment operators. Version 2 would throw up a screen of x86 assembly showing either SHL AX,n or SHR AX,n respectively, and those instructions aren't supposed to have a immediate amount, it can be only a shift of 1, or the amount in CL. At least, that's the way it was in pre-64bit days, not sure now with the frequent extensions of the x86 instruction set. Easily worked around by using the slightly more verbose notation "y = x >> 1;" but not something to inspire confidence in the compiler.