I don't think I was among the first to experience the 'divide overflow'
problem. I'd heard rumours about it and was concerned, but didn't have
personal experience about it until 11:30 one night. (I think it was October
12th 1997.) AH, the perils of working from home. One of my company's service
people was at a customer site in Montreal, replacing a crashed web server
with a new machine. He called to tell me that he couldn't run our
Foxpro-based CGI application on it.
To understand some of what follows you need to know how the problem occurs.
In the run-time library Foxpro 2.x uses there's a small function written in
assembler that tries to estimate the CPU speed of the machine, probably for
the sake of "timing loops". It uses the BIOS's 18hz interrupt clock (yup,
that's right, 18.2 interrupts per second, 55MS per tick, handled by the ROM
BIOS on the original IBM PC) to figure out how many loops it can execute per
millisecond. It does this using the following algorithm:
- Load a big number (0=0xFFFFFFFF+1) into a 32-bit register;
- Wait for the BIOS clock to change, so it knows a tick has started;
- Loop like mad, decrementing the counter, until the timer changes again;
- Complement the counter to see how many loops it executed;
- Divide by 55 to get a number of loops per millisecond.
The problem was that with a new fast CPU, the divide by 55 resulted in a
number bigger than
64K loops per millisecond, which meant the divide operation overflowed.
Poof, no program!
After hanging up with the technician, I started researching it on the web.
Thanks to the active developer community there were lots of reports of the
problem already, and a pointer to a fix called SlowStart. (Sorry, I don't
recall who did SlowStart, I'm sure you can look it up.) SlowStart worked by
stealing CPU cycles so that the application (sometimes) didn't count enough
loops to cause the problem. Unfortunately our web server was a dual
processor machine, so all SlowStart would have done was tie up one CPU while
the other one went madly on, counting down to destruction.
Someone - and I'm sorry I can't remember who - posted the 'more detail'
information provided by Windows NT on a discussion forum, giving me the
bytes in program memory where the problem occurred as well as the program
Now, I'm an old assembler guy. I programmed my Sol-20, a 1976-vintage kit
computer, in machine code because it wasn't possible to run an assembler in
the standard 2K of RAM. I've also done more than my share of 8086 assembler,
so the information that anonymous poster provided was very useful. I ran a
little utility that's still part of Windows that no one seems to use any
more, debug.exe. I was able to open the .ESL file, find the same bytes the
poster had listed, and by trial, error, and with the aid of my
half-forgotten experience, disassembled the entire timer function. Sure
enough, the error occurred at a divide instruction. What next?
More fiddling. I figured out that if I modified the loop to count up instead
of down, and so didn't have to complement the result, it saved a few bytes.
It happened that those few bytes were enough to add the instructions to trap
the overflow condition before the divide, and paste a 'clamped' value into
the result register. It was 3 A.M. and I still had no way to test this
(other than that my own programs still ran correctly on my slow machine), so
I hand-patched the .ESL file and emailed it to the tech in Montreal. Then I
went to sleep.
I called him about 10 A.M., and he told me the problem was solved. I wrote a
Foxpro program to perform the patch, with documentation, and posted it
anonymously that afternoon, inviting folks to give it a try. Of course, it
required that a slow machine be used to patch a copy of the ESL or
Foxprow.exe before transferring the patched file to another machine. After a
few folks reported success, I sent an email to Microsoft, but didn't really
know who to reach, so it went unanswered.
I was very aware that what I'd done was a violation of the EULA: people
applying the patch today should be aware of the same thing. On the other
hand, a multi-million dollar business relied on getting a solution that
would give us time to port all of our applications to VFP. I plead the
defense of necessity.
I started seeing reports from other folks with the same problem, some quite
desperate, and helping folks run the FP-based patch started taking lots of
time from my work, so I wrote a program in C++ to perform the patch on any
Foxpro version and packaged it and posted it, with a readme file, this time
not anonymously. A few months later Microsoft released their patch using the
same technique I developed. They asked me to remove my version from
circulation, which I did, so that everyone could be legal again. It was a
relief. Some time after Microsoft released their patch I bought a new
computer, and was actually able to reproduce the problem for myself.
In the process of this I've been impressed and surprised by the response of
the Foxpro community. Many people posted the patch on their web sites as a
public service, before Microsoft published their replacement. I've received
hundreds of emails of thanks from all over the world; from the all branches
of the U.S. armed forces, the U.S. House of Representatives, from
programmers and managers and military personnel on every continent. (I also
get occasional emails from people asking for free technical support for
commercial products and even military systems that I've never even heard
of.) I've dozens offers of drinks "if you're ever in my part of the world",
that I won't be able to collect now because I've lost most of the emails in
a disk and tape crash. It's a measure of the strength of our little
community that the response to my few hours' work was so large and so
generous. Remember, folks, that initially, it was my own behind that I was
trying to save. Many, many people put in much more effort to help fellow
Foxers and get less thanks than I did. My hat is off to them.
See also: People That Helped FoxPro to Become a Legend: Andrew Forber