Bad Programming Design you've seen in Commercial Software

[UserNameGoesHere]

I don't mean simply bugs (buffer overflows, failure to clean up/release resources, etc...). I mean the design itself is bad -- not just needs to be debugged.
I also don't mean things which are intentionally broken by design, such as DRM.

Things I've seen in commercial games:

Relying on undocumented processor behavior and/or processor bugs.
Relying on exact processor speed, especially when requiring "not too fast and not too slow".
Hard-coding and assuming that D: is your CD-ROM drive.
Hard-coding and assuming that C: is the root of your Windows installation.
Relying on undocumented Windows functions or behavior.
Hybrid DOS/Windows game which required Windows for init, then rebooted into DOS to run.

Where they were seen and why they were bad design even in their day:

1) Seen on some DOS games. Play them on a DOS machine which has an 80286 or newer processor and they won't work.
2) Seen on some DOS games. Play them on a DOS machine with a processor which is either slower or faster than the exact speed range they expect, and they won't work.
3) Seen on some Windows9x games. Play them on a Windows9x machine whose CD-ROM or DVD drive is other than D: and they won't work. For example, if D: is a second hard drive and E: is your CD-ROM.
4) Seen on many Windows games AND software from Microsoft! Though it usually is the case Windows is somewhere on your "C:" drive, it doesn't have to be. Play them on a Windows machine where it's elsewhere and it won't work.
5) Seen on some Windows9x games. Play them on a different revision of the same OS and they might not work. Play them on newer Windows and they almost definitely won't work.
6) Seen on a Windows9x-era "Windows" game. Not only it won't work on newer Windows, but it won't even work on Windows9x if your machine can't reboot into DOS.

What they should have done:

1) Program only according to officially documented processor behavior.
2) Program a "speed-sensing" routine which would adjust things accordingly. (It's not hard to do and lots of well-programmed DOS games did exactly this)
3) Query Windows for location of the CD or DVD drive. It will tell you.
4) Query Windows for location of Windows install. It will tell you.
5) Program only according to officially documented OS behavior and functions.
6) There was no reason for the Windows portion of this game. It should have just been coded as a straight-up DOS game.

[FissionMailed1]

Re: Bad Programming Design you've seen in Commercial Software

Hard-coded input mappings.

SINGLE THREADED APPLICATIONS WHEN A MAJORITY OF PROCESSORS ARE MULTICORE/THREADED makes me so mad.