David Heffernan

That nobody is me too. I also have a bunch of ripped CDs, and purchased mp3s. Most of my use is with streaming services which clearly don't suck. But we are in a tiny minority. I guess if David is writing an app for old people like us then maybe it will work out. Sure, but this is a forum here, not SO. Yeah, which is why the average user uses streaming services so they don't have to think about this.

Nobody has songs on their mobile devices in that form these days anyway. People use streaming services like Spotify, YT, etc.

The alternative that you propose would have been far worse.

This wasn't a mistake. This reflects the underlying platform. It's wrong to blame Emba for all the programmers using Integer as though it was pointer sized. Your argument is akin to wanting char to be 4 bytes on 64 bit. It's just a non sequitur. There's literally no reason for integer to be pointer sized. It's a completely different thing.

OK, but it would obviously be far easier to just recompile than make some new out of proc add in tech for design time.

Wouldn't they ship 32 and 64 bit IDEs and users could choose which they used. You have to recompile packages for new versions anyway. It would just be a recompile for 64 bit. I don't think it would be so bad. I know that I can compile all the design time packages I use for 64 bit quite easily.

What's the way to replicate MDI like behaviour in VCL today?

Given the number of people that struggle without of memory errors, then I'd say the answer is yes.

Put the python code in a bpl and have everything access it that way. But I guess you'll all be sharing the same python interpreter. I think that's essentially the python design.

Ironically I'd benefit from this but I agree it seems like an odd change of tack having refused to entertain MDI for years now.

@FabDev yes that's exactly the same issue

The original question is for Windows. And the program I posted demonstrates behaviour with and without invalid op masked. As stated repeatedly above the original question concerns behaviour that is determined by fp exception masks. @Minox was talking about Android.

So for the original question that's not an issue because that is for Windows. For @Minox on Android then IsNaN is what is needed.

Do you understand how fp exceptions masks work?

The solution is to set the exception mask to unmask fp exceptions that you want converted into runtime exceptions. That said, I don't know how exception masks work on non x86 platforms. Your code has the problem that if the division returns -1 then it will treat that as an error, but what do you think happens when you do -1 / 1? If you are going to hack it the way you are doing then at least use a boolean. Although see below. If your platform doesn't handle exception masks as windows does then use IsNaN.

Imagine not being able to make a 64 bit IDE

I'm honestly not sure why this topic is still open. It's the exception mask. Something is changing it. You don't have complete control over it. Other modules that are loaded into your process can change it. It's quite messy. It's been covered ad nauseum here, Borland forums, SO, etc. Run this program to demonstrate how the different exception masks influence behaviour: {$APPTYPE CONSOLE} uses System.SysUtils, System.Math; procedure Main; var x, y: Double; Mask: TArithmeticExceptionMask; begin x := 0; y := 0; Mask := GetExceptionMask; SetExceptionMask(Mask + [exInvalidOp]); Writeln(x / y); SetExceptionMask(Mask - [exInvalidOp]); Writeln(x / y); end; begin try Main; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; Readln; end. For your scenario, when NaN is produced, clearly invalidop is masked. When the exception is raised it is unmasked.

Whatever problem this is attempting to solve, this isn't the solution

And also introduce large numbers of obscure bugs that will take forever to debug.

Enable range checking, at least in debug builds

Anyway you should use the debugger to inspect this. Enable debugging for the release build.

> 'for i:= 0 to 4' does 6 loops when not in Debug mode No it doesn't.

Check what the floating point exception mask is. I'm sure you'll find that invalid op is unmasked. Some code in your process is doing this.

FWIW this doesn't match what I see in my list

It's not slow in virtual mode. VirtualTreeView is the usual alternative.