
How to ensure that your program does not run under Windows 95 (1995) [pdf] - bcaa7f3a8bbc
https://ptgmedia.pearsoncmg.com/images/9780321440303/samplechapter/Chen_bonus_ch02.pdf
======
est31
Had to smile when I read the epilogue:

> Sometime after Windows 95 shipped and became a smash hit, a group of
> prominent game developers visited Microsoft as guests of the DirectX team.
> At some point, they learned of “this guy” on the Windows 95 team who worked
> so hard at getting all their games to work that he “officially went insane.”
> Thus intrigued, they asked to be introduced to this insane guy, and they
> presented me with a letter, signed by all of them, with the message, “Thanks
> for going insane.”

> I still have that letter.

~~~
RcouF1uZ4gsC
One of the big advantages Windows had on the desktop is the absolutely
fanatical commitment to backwards compatibility. While this affected purity,
it gave businesses the assurance that the software they owned would still
continue to work.

~~~
Nursie
> One of the big advantages Windows had on the desktop is the absolutely
> fanatical commitment to backwards compatibility.

OS/360 would like a word...

;)

~~~
raverbashing
Is it actual binary compatibility? Or it is something higher-level?

(to be honest going from DOS to Windows is a different problem, though that
doesn't justify the atrocities shown in the document :) )

~~~
Nursie
They do have a binary backward compatibility date sometime in the 1960s,
possibly 1964.

But from what little I remember from my intro-to-mainframes day at big blue
many years ago, I think it's like some sort of multi-layered emulation now, to
run code that's _that_ old. But your "Hello World" program built on OS/360
released in 1964 will still run on modern Z/OS, or so I'm told.

Of course they're not desktop systems! (I'd hate to see the desk...)

------
frabcus
I felt the same in reverse trying to make a game (Creatures 3) work well on
Windows 95/98 in late 1999. We did quite a few patches after release to fix
odd compatibility bugs that came in via customer support.

Some weren't _directly_ Microsoft's fault. I remember there was a printer
driver that would change the current directory of processes that it wasn't
even being used in. I had to update the media code in the game to use absolute
paths.

It often felt like I was being paid by my company to work for Microsoft, which
felt very clever of Microsoft at the time!

Windows works because everyone, at Microsoft and outside, put in a lot of work
to make it work.

~~~
swiley
> Windows works because everyone, at Microsoft and outside, put in a lot of
> work to make it work.

Maybe that’s a general property of platforms and operating systems, it would
explain why people get so attached to them.

------
Sevaris
It seems this was one of two appendices to Raymond Chen's book "Old New
Thing". The appendix doesn't exist in printed form for some reason though.
It's a great book and definitely worth reading.

The second appendix is titled "Tales of Application Compatibility"
[http://ptgmedia.pearsoncmg.com/images/9780321440303/samplech...](http://ptgmedia.pearsoncmg.com/images/9780321440303/samplechapter/Chen_bonus_ch01.pdf)

~~~
branon
I saw "Old New Thing" and immediately wondered if this was Chen. Seen his
blogs on HN before, didn't know there was a book!!

------
montjoy
I remember terrible times trying to get some Lucasarts and Origin games going
in that era. You want a cdrom -and- a sound card? That’s crazy talk. No no
don’t use sound blaster’s driver use ours and our crazy ass memory manager
too. Oops no sound for you! You’re in Windows! Etc etc. Thank goodness for
autoexec.bat and config.sys.

~~~
ehayes
Getting Wing Commander to work with a sound card, and a joystick, and in
conventional memory was my intro to a lifetime working with computers.

~~~
montjoy
LOADHIGH my friend, LOADHIGH

------
bcaa7f3a8bbc
Summary of maxims: You can print out these two pages, fold than up, and keep
then in your pocket. Well, maybe not, since nobody is really interested in
writing MS-DOS-based games, anymore. But if you did, this would have been a
handy guide to ensuring that your game doesn’t run on Windows 95.

1\. The more confusing the error message, the better.

2\. If it doesn’t run under Windows, then it’s Windows’fault.

3\. Detect Windows, and crash.

4\. Manuals are a waste of time.

5\. Words in boldface don’t count.

6\. Just because you’re a Windows application doesn’t mean that you have to be
compatible with Windows.

7\. Performance degradation is acceptable in the greater interest of not
running on Windows 95.

8\. If you’re going to do something wrong, do it wrong in as many different
ways as possible.

9\. Find a rule and break it as blatantly as possible.

10\. The weirder your code, the harder it will be for the operating system to
detect that you are about to do something stupid and rescue you.

11\. Always look for the weirdest, most convoluted way of doing something.
That way, you stand a good chance of doing it wrong.

12\. It is better to be lucky than good.

13\. Multitasking is for wimps.

14\. Persistence may not help, but it’s fun.

15\. Thrashing is good. It reminds the user that the computer is on.

16\. Random addresses are harmless.

17\. If you’re going to fail, do so as subtly as possible.

18\. Do something that is supported only under Windows, and do it wrong.

19\. Second-guess the specification whenever possible.

20\. Knowledge of the English language is optional.

21\. Well-behaved programs are for wimps.

22\. Bite the hand that feeds you.

23\. Words in italics don’t count.

24\. If you can’t be subtle, then be blatant.

25\. Intel will never release a new CPU.

26\. Slower is better.

27\. If you can’t convince the operating system to screw you up, take matters
into your own hands.

28\. Microsoft will never release a new version of the operating system.

29\. The high words of 32-bit registers are always zero.

30\. Even business applications can benefit from a boot disk.

31\. Error checking is for wimps.

32\. Don’t bother testing the error paths. The game is already over.

33\. When faced with the unusual, self-destruct.

~~~
redis_mlc
I was a Windows developer back in the day.

After a certain Windows release, Microsoft had a Windows App Certification
checklist of features you had to use if you wanted various levels of support,
or sales to brick and mortar stores (they required that to reduce support
calls and returns.)

At first I found the checklists irritating, as they required essentially a
major application release for each Windows version - your application bit-
rotted essentially.

But in the end, it was worth it as the application was more polished, with
standardized paths, help, etc.

~~~
elwes5
The amount of crazy things people did in win3.x was pretty amazing. MS kind of
did it to themselves. Want to know what an HWIN looks like? Right there in the
header. No functions to access those items. Now you can not change that struct
without breaking hundreds of programs. I remember the other devs grumbling
that the win9x headers did not have the system structs in there. What was just
an update into an a pointer deref became 'which method do I need to change
this feature now...' game. That MS pulled that compat job off and did not
absolutely obliterate everything I have to admire.

------
gwbas1c
I remember using custom boot disks for some games...

Makes me wonder if Windows 95 should have just rebooted into DOS for older
games. Alt-tab was always sketchy anyway when a have was running.

~~~
bawolff
Didnt it? I remember "reboot in msdos mode" being a thing.

~~~
ido
It could, but most DOS games worked fine inside win95.

------
raverbashing
> Maxim 2: If it doesn’t run under Windows, then it’s Windows’ fault.

And the preceding example is just hilarious. But hey "it works on my machine!
it must be your fault!!11"

It was similar shenanigans when a lot of Windows 95/98 "stopped working" when
Windows 2000/XP worked. "What do you mean I can't write to C:/Windows whenever
I want? What do you mean I can't put my config option in some hidden corner of
the system registry?"

 _sigh_

~~~
bcaa7f3a8bbc
> Maxim 6: Just because you’re a Windows application doesn’t mean that you
> have to be compatible with Windows.

This one is more hilarious.

    
    
        pushf
        cli
        ... five instructions later ...
        popf         ; BUG!  Does not enable interrupts
    

> What makes this noteworthy is not that it contains exactly the forbidden
> code sequence, it is noteworthy because this is not an MS-DOS application
> but rather a Windows application. It’s a Windows application doing something
> that doesn’t work under Windows. That takes nerves. A certain network driver
> does essentially the same thing.

And,

> Maxim 18: Do something that is supported only under Windows, and do it
> wrong.

> Memory lock calls are ignored in the absence of virtual memory, so make sure
> to abuse lock functions as much as possible. That way, when you are run in a
> virtual memory environment, strange and wondrous things start happening that
> never happened in real mode.

> Since none of the standard DOS extenders use virtual memory by default, this
> is an excellent opportunity to begin behaving randomly. This is so important
> it’s worth restating.

~~~
raverbashing
Yeah that cli missing the sti is baffling!

What I find ironic is that while some people go on and on about gatekeeping
programming and "you're not a real programmer if..." some people are just
doing that kind of thing (and they're usually the ones making more money)

I was satisified when I found out that Vista, amongst the many things it did
wrong, did something right: started naming programs that were misbehaving (for
example, taking too long to shutdown)

------
ComputerGuru
By Raymond Chen, of course.

------
kccqzy
I thought example 50 and 51 are pretty reasonable. Pointer tagging is a valid
technique; it's a pity they chose to tag using the high bit instead of the low
bit. But then 2GB of memory was humongous in the age of Windows 95. Also,
didn't some 32-bit operating systems use to reserve the upper 2GB of the
address space for the kernel?

~~~
kevingadd
Windows carved out 2GB of address space for a very long time, there's a /3GB
flag that you could set at boot time to reduce that carve-out to 1GB (freeing
up another 1GB of address space for applications)

------
fortran77
This was a similar issue to trying to recompile OS9 programs under carbon to
work on OSX.

------
mfontani
Wow, there's _pages_ and _pages_ of programs which would have been seemingly
broken because they forget to "sti" after having "cli". It was one of those
things we were taught to always, no matter what, do in high school -- one of
those "do one thing, and always the inverse" \- like push to stack, pop back
from stack kind of thing.

Really odd to see those things "out there"!

~~~
bcaa7f3a8bbc
You missed its context.

In real mode, the interrupt enable/disable status is controlled by the global
CPU flag, in bit 9. If you saved the entire FLAGS register when interrupt was
enabled with "pushf", and later you use "popf" to restore the flags, there's
no reason to use "sti", since the interrupt bit was already restored, it was
perfectly legal in real-mode DOS. However, in protected mode under an OS, it's
unacceptable for a single program to disable interrupts of the entire CPU, so
the global CPU interrupt flag is always enabled and controlled by the OS, but
each program had its own virtual interrupt state controlled by "sti" and
"cli", and cannot be changed by "pushf" and "popf" anymore.

What actually happened: This problem was already recognized in the beginning,
documentation contains multiple warnings and examples of correct code, but
developers ignored all the warnings and instructions, continued misusing
"popf" and doing it wrong in as many different ways as possible.

~~~
mfontani
It was a bit difficult to follow and the reasons behind why things failed
weren't fully clear.

I've also not written any asm in a couple decades...

so, thank you very much for explaining this to me. It makes total sense now!

------
fouc
I briefly imagined this was going to be a treatise based on some reality where
all windows programs could be trivially made to run on windows 95. Even 25
years later.

It would be amusing to think that developers would have to take extra steps to
ensure their program does not in fact run on older windows versions.

