A.M. Hoornweg

It would be a can of worms for me I'm afraid. I am thinking of all my Delphi COM DLL's that expose interfaces and class factories (see image). Each interface is basically an object that can have dozens of methods so we're not talking about just a few functions, it's more like hundreds of exposed methods. And many of these methods call each other, which complicates matters further because setfpcr/restorefpcr would have to support nesting. And multi-threading would make matters even more complicated.

"Take control on entry and restore on exit" would be very cumbersome in the case of DLL's written in Delphi. It would need to be done in every exposed function / method. (edit) or at least in every method that has to do with FP calculations.

OK, that massively simplifies matters. My fear was that the FPCR would be a shared resource among threads.

I have no way of knowing. In the distant past the FPU (80x87) used to be an expensive separate chip. I simply don't know if the fpu is now part of each cpu core.

That is not what I mean, since a "context switch" is done when the scheduler switches from one thread to another (so one is halted, its state is saved and the next thread resumes after its state was restored). My question is about threads literally running simultaneously on different CPU cores, does each core always have an independent FPU + FPCR so one thread cannot jeopardize another ?

Since threads run concurrently on multi-core systems, isn't the fp control state global to all threads? Or does every cpu core have its own fpu core?

Sure it is documented. But it may be off the radar that existing binaries such as DLL's may suddenly behave differently if they were written in Delphi. I use some third-party DLL's that were written in Delphi.

Hello all, I've noticed that an application I'm working on was behaving differently when compiled in Delphi 11 or 12. In Delphi 12 I was getting all sorts of overflows and unexpected behavior. It took me a while to figure out the cause. Now the surprising thing: The cause wasn't even in this executable I was working on, it was in a DLL that my program is using. This DLL was built with a previous version of Delphi. This particular DLL expects that a FP error such as a division by zero will throw an exception. A breaking change in Delphi 12 is that the executables it produces mask the FP exceptions. This change in behavior affects all code running in the process, including all DLLs. In other words, this DLL no longer threw exceptions where it was supposed to. My workaround was to re-enable FPU exceptions in the executable and the situation instantly went "back to normal". But it got me thinking, how does one write code that copes with both FP situations and can run safely with *any* Delphi version? Should I do something like this? Try c:=SomeHighlyComplexCalculation(); if IsNan (c) then raise eDivByZero.Create('Something went wrong'); except // the exception is triggered either automatically (Old Delphi version) or manually (New Delphi version) end; Currently, my gut feeling tells me to manually enable FPU exceptions in all my Delphi exe projects to prevent such nasty surprises in the future. I use tons of tried-and-tested DLLs written in Delphi and I really don't want them to break.

As far as I can see you can't download from that site though.

I am getting "Disconnected Session" all the time whilst working on a 64-bit project. Never had this problem in 12.0. The error dialog window contains this information: [69E0B1C0]{dbkdebugide290.bpl} Debug.TDebugKernel.msgBox (Line 5951, "Debug.pas" + 30) + $0 [2BCC6EB3]{bordbk290.dll} Unknown function at DllUnregisterServer + $5037 [2BD3B88C]{bordbk290.dll} Unknown function at @isDbkLoggingOn$qv + $619B4 [2BD3B90B]{bordbk290.dll} Unknown function at @isDbkLoggingOn$qv + $61A33 [2BD3C351]{bordbk290.dll} Unknown function at @isDbkLoggingOn$qv + $62479 [2BD3C5A1]{bordbk290.dll} Unknown function at @isDbkLoggingOn$qv + $626C9 [2BD6C3D3]{bordbk290.dll} Unknown function at @isDbkLoggingOn$qv + $924FB [69E0B6FD]{dbkdebugide290.bpl} Debug.TThread.DoGetCurAddr (Line 6080, "Debug.pas" + 1) + $4 [2BCD9D72]{bordbk290.dll} Unknown function at DllUnregisterServer + $17EF6 [2BD6A91D]{bordbk290.dll} Unknown function at @isDbkLoggingOn$qv + $90A45 [2BD3C577]{bordbk290.dll} Unknown function at @isDbkLoggingOn$qv + $6269F [2BD3C7E0]{bordbk290.dll} Unknown function at @isDbkLoggingOn$qv + $62908 [2BCC6A4B]{bordbk290.dll} Unknown function at DllUnregisterServer + $4BCF [2BD5AB32]{bordbk290.dll} Unknown function at @isDbkLoggingOn$qv + $80C5A [2BD5AB3C]{bordbk290.dll} Unknown function at @isDbkLoggingOn$qv + $80C64 [69E17AFD]{dbkdebugide290.bpl} Debug.GetNextEvent (Line 11764, "Debug.pas" + 1) + $24 [6DC6037A]{rtl290.bpl } System.@IsClass (Line 18904, "System.pas" + 1) + $8 [69E185E1]{dbkdebugide290.bpl} Debug.TDebugger.UpdateEventLog (Line 11776, "Debug.pas" + 9) + $1 [69E11931]{dbkdebugide290.bpl} Debug.TProcess.ntfyNewEventLogData (Line 9020, "Debug.pas" + 1) + $7 [2BD5B3A0]{bordbk290.dll} Unknown function at @isDbkLoggingOn$qv + $814C8 [2BD3B90B]{bordbk290.dll} Unknown function at @isDbkLoggingOn$qv + $61A33 [2BD3C577]{bordbk290.dll} Unknown function at @isDbkLoggingOn$qv + $6269F [2BD570FB]{bordbk290.dll} Unknown function at @isDbkLoggingOn$qv + $7D223 [2BD57136]{bordbk290.dll} Unknown function at @isDbkLoggingOn$qv + $7D25E [2BD6C4C7]{bordbk290.dll} Unknown function at @isDbkLoggingOn$qv + $925EF [2BCD9D72]{bordbk290.dll} Unknown function at DllUnregisterServer + $17EF6 [2BD3B8B0]{bordbk290.dll} Unknown function at @isDbkLoggingOn$qv + $619D8 [2BD3C7E0]{bordbk290.dll} Unknown function at @isDbkLoggingOn$qv + $62908 [2BCE4247]{bordbk290.dll} Unknown function at @isDbkLoggingOn$qv + $A36F [625AA5EA]{CnWizards_D120A.DLL} Unknown function at __dbk_fcall_wrapper + $788AA [6CB305FD]{vcl290.bpl } Vcl.Themes.TStyleHook.WndProc (Line 7733, "Vcl.Themes.pas" + 38) + $6 [6CC598FC]{vcl290.bpl } Vcl.Styles.TStyleEngine.HandleMessage (Line 3616, "Vcl.Styles.pas" + 20) + $C [6340DEA9]{mmx_bds23.dll} IDEEdtHooks.GetMessageHook (Line 66, "IDEEdtHooks.pas" + 7) + $12 [6279DE04]{CnWizards_D120A.DLL} Unknown function at INITWIZARD0001 + $17CC00 [6CB7392F]{vcl290.bpl } Vcl.Forms.TApplication.ProcessMessage (Line 13284, "Vcl.Forms.pas" + 25) + $1 [6CB73952]{vcl290.bpl } Vcl.Forms.TApplication.ProcessMessages (Line 13304, "Vcl.Forms.pas" + 1) + $4 [00487F2B]{bds.exe } AppMain.TAppBuilder.ApplicationActivated + $7 [6CBCD24F]{vcl290.bpl } Vcl.AppEvnts.TCustomApplicationEvents.DoActivate (Line 210, "Vcl.AppEvnts.pas" + 1) + $16 [6CBCD8ED]{vcl290.bpl } Vcl.AppEvnts.TMultiCaster.DoActivate (Line 438, "Vcl.AppEvnts.pas" + 5) + $10 [6CB72DD0]{vcl290.bpl } Vcl.Forms.TApplication.WndProc (Line 12854, "Vcl.Forms.pas" + 140) + $C [6DD8477C]{rtl290.bpl } System.Classes.StdWndProc (Line 19085, "System.Classes.pas" + 9) + $2 [6CB73927]{vcl290.bpl } Vcl.Forms.TApplication.ProcessMessage (Line 13282, "Vcl.Forms.pas" + 23) + $1 [6CB7396A]{vcl290.bpl } Vcl.Forms.TApplication.HandleMessage (Line 13312, "Vcl.Forms.pas" + 1) + $4 [6CB73CA9]{vcl290.bpl } Vcl.Forms.TApplication.Run (Line 13451, "Vcl.Forms.pas" + 27) + $3 [004D8AD2]{bds.exe } bds.bds + $DE

There are ways to achieve that (passing an EMF cross-process) but yes, it would be ugly. It would be like re-inventing the RDP protocol.

If you'd ask me to attempt a thing like that, I'd first look for a suitable bidirectional RPC framework. Something having capabilities like COM. COM was used by IDE's such as Visual Basic to host (in-process) VBX controls but it works across processes as well. The "helper processes" would only need to contain the designtime part of the components, at runtime they do nothing. Such an approach would move the design time components out of the address space of the IDE. Also, the "bitness" of the helper processes and the IDE would be independent from each other.

My preference would be to have the component packages in separate helper processes.

Please remember that all installed design time packages (BPL files) and their associated runtime packages must be compiled to the same architecture and bitness as the IDE itself. BPLs are just DLLs and the IDE loads them directly, in-process. This means that moving away from 32-bit x86 would be a huge breaking change for the deployment of third party components. Frankly, I've never understood why the design time packages are hosted in the IDE process itself because bugs in components will affect the IDE. Many of us will know the phenomenon that the IDE may throw an AV exception in some BPL when you terminate Delphi.

Can't you make a read-only property out of it instead of a plain method? That way you could make it show up in the watch list of the debugger.