The following runs perfectly on Pentium 233's, Pentium II 400 and 600's,
PIII 500's
(Generates an error and displays the messagebox), but the 733 and 800
blow with BSOD
even taking down the compiler with it.

procedure TForm1.Button1Click(Sender: TObject);
VAR
  X, Y, Z: Real;
begin
  X:=0;
  Y:=0;
  Z:=0;

  try
    Z:=(X / Y);
  except
    ShowMessage('HUM');
  end;

end;

Could someone enlighten me?  Everyone raves how great the FP performace
is on the PIII's and
I cannot find any errors of them having flawed FP units.  I am using D3
C/S patched 3.02, and
tried the same code w/ D5 trial and it fails.

Please email me at ad...@coldtech.com as I don't usualy frequent this
newsgroup.

I have encountered similar problems in one of my projects. After posting my
problem on the newsgroups I got several useful replies many of wich
suggesting a possible problem with video drivers. And while I'm sure that
the problem comes from that general area, I haven't been able to pinpoint
the component that causes the problem. I've stripped a computer with this
problem, ran it with the bare essentials and then changed the bare
essentials, but the error persisted.

Even if I was able to find the solution on one computer, it wouldn't do much
for me since it's very hard and time consuming to track down the hardware
problem. I now know of over 30 computers with this problem, and the number
is growing daily. All of them fairly new and apparently all applications,
except the ones compiled in Delphi work fine. So it's not really a viable
option to spend hours and hours looking for a problem that only crashes
Delphi programs. I reported this problem to Borland or Inprise and in the
meantime I replaced all try ... except statements with an if ... then.

I spent close to a week trying out all sorts of suggestions people gave me.
The only one that came close to a solution was somebody who suggested that I
use the Set8087CW($133F ); statement. I experimented a bit with that and,
indeed, it prevented the crash, but it also skipped the exception, seeing as
that control word disables them.

So no real solution I'm afraid...

Phil,

"Michael Mitchell" <m...@coldtech.com> schreef in bericht
news:39E3331F.373E@coldtech.com...

With several runs, the test always reports "HUM", and then continues
normally.

This does not mean I would suggest just to skip all the P-III customers,
and sell only to those who are running AMD processors:)

Markku Nevalainen

Type REAL is a software implementation of floating point and does
not use the hardware FPU.

When trying your example (using Real or Extended), compiler optimisation
effectively removed the calculation (since nothing
is done with the result) and so nothing happened.  Switching
the optimisation off produced the expected HUM on my PIII 533MHz.

Lester

Dear Lester Hanger,

you are absolutely right concerning the meaning of "real" for Delphi while
using D1, maybe D2, D3, but at least since D5 (which has been also tested by
Michael Mitchell) the meaning of "Real" is by default equal to double (you
can change this new meaning by use of {$REALCOMPATIBILITY ON} or declare the
variable with Real48) and thus uses the FPU also.

Lester Hanger schrieb:

Actually I heared of a similar problem in a german newsgroup. The reason for
this behaviour was found to be due to IDE devices which where connected to
an ATA66-Promise instead of the onboard ATA33, while both onboard IDE
channels were empty. When both IDE devices were connected to the onboard IDE
channels the problem was solved.
Someone told us to look in comp.lang.pascal.delphi.misc for the posting
titeled "try..except different behavior on NT and Win95" which describes
this phenomenon.

Yours,

Daniel Spangenberg

The problem in the posting "try..except different behavior on NT and Win95"
concerned an eOutofMemory exception. The problem here is the EZeroDivide
exception. Maybe the two problems are connected, but I encounter the problem
on such a wide range of computers that I'm not completely sure. Furthermore,
customers don't seem to have problems with other applications, just the ones
compiled in Delphi that cause an EZeroDivide exception.

Phil,

"Daniel Spangenberg" <spang...@rz.uni-duesseldorf.de> schreef in bericht
news:39E42CDF.7E8B6299@rz.uni-duesseldorf.de...