Jump to content

David Heffernan

Members
  • Content Count

    3427
  • Joined

  • Last visited

  • Days Won

    169

Posts posted by David Heffernan


  1. These microbenchmarks for floating point typically are of quite limited use. I remember making a bunch of changes based on such benchmarks and then finding absolutely no impact in the actual program, presumably because the bottleneck was memory.


  2. I think that's about right. The issue you were facing though is 2 rather than 1. The type that matters here is the handle type. LPPPLFHANDLE is a pointer to a handle. You were managing the pointer to correctly, but your handle was wrong.

     

    You could actually declare your function like this:

    // an out param
    function pp_lfopen(filename: LPSTR; lfflags: LONG; lftype: LONG; password: LPSTR; out handle: PPLFHANDLE): LONG; stdcall;
    
    // or a var param
    function pp_lfopen(filename: LPSTR; lfflags: LONG; lftype: LONG; password: LPSTR; var handle: PPLFHANDLE): LONG; stdcall;
    

    Either of these would work. I show these to give a view on conceptually what that handle param is doing. 

     

    I usually prefer having a literal header translation so the version in my previous message is how I would do it. And for some function you want to be able to pass nil to indicate that you don't need the function to return a handle. In this case I'm pretty sure you'd never want to do that, you always want the handle, and so the out param version would be a reasonable translation.

     

    Hope that helps!


  3. The key here is that PPLFHANDLE is 32 bits in a 32 bit process and 64 bits in a 64 bit process. So you need a type that has the same property. For instance any pointer, or NativeInt or NativeUInt.

     

    Now, in this case it seems that the expedient thing to do is to declare PPLFHANDLE as HGLOBAL. And in the Delphi winapi units HGLOBAL will be declared as a type that switches size based on process bitness. Actually it's NativeUInt but that's actually a detail you don't really need to know. Although it's nice to know it and help confirm the understanding!

     

    So I would do this:

    type
      PPLFHANDLE = HGLOBAL;
      LPPPLFHANDLE = ^PPLFHANDLE;
    
    function pp_lfopen(filename: LPSTR; lfflags: LONG; lftype: LONG; password: LPSTR; handle: LPPPLFHANDLE): LONG; stdcall;

    Here I am using the same types as the header file. I generally think that it's preferable to keep an API translation as close to the original as possible.

     

    The header file is a bit odd in the way it defines these types:

    #ifndef PPLFHANDLE
    	#ifdef _WIN64
    		#define PPLFHANDLE  HGLOBAL
    	#else
    		#define PPLFHANDLE  LONG
    	#endif
    #endif
    
    #ifndef LPPPLFHANDLE
    	#ifdef _WIN64
    		#define LPPPLFHANDLE    HGLOBAL *
    	#else
    		#define LPPPLFHANDLE    LPLONG
    	#endif
    #endif

    It looks like an earlier version wrongly declared PPLFHANDLE as LONG and then they've kept that mistake as they catered for 64 bit. This header code should really look like this:

    #ifndef PPLFHANDLE
        #define PPLFHANDLE  HGLOBAL
    #endif
    
    #ifndef LPPPLFHANDLE
        #define LPPPLFHANDLE  PPLFHANDLE *
    #endif

     

    • Like 1

  4. 30 minutes ago, Ron Howard said:

    Since there are both 32-bit and 64-bit versions of the DLL, I thougth I could get away with a single function definition, but apparently that is wrong.

    No, you can have a single definition. You just need to get it right.

     

    31 minutes ago, Ron Howard said:

    The LPPPPLFHANDLE is also a pointer to a LONG.

    I doubt that. Where is the header file? Or can you show enough of it so that we can see the declaration of LPPPPLFHANDLE?


  5. 10 hours ago, Anders Melander said:

    It's beyond me why they haven't implemented basic numerical functions such as Trunc, Round, Abs, etc. as compiler intrinsics so we at least can get them inlined.

    I mean, they've shown no interest in performance whatsoever, and even less interest in floating point code. It's as much as they can manage to vaguely support all the different compilers they have and keep them functioning. 


  6. 6 hours ago, DelphiUdIT said:

    I think the problem is the project options: in the new 11.3 (like 12) environment the additional setting about ASLR are ON, try to deselect them.

    This isn't the problem. The problem is in the incorrect header file translation. The project settings that you highlight should not be changed. They are just the reason why the code has been exposed as being incorrect. That exposure should be celebrated! It's very wrong headed to try to ignore such a mistake as you propose here. 


  7. Looks like this has always been broken but you just got lucky because the 64 bit handles happened to have values that weren't changed when your code truncated them to 32 bits. 

     

    With the latest delphi your luck ran out because the values are now being changed by truncation, for whatever reason. But your code was always broken and you just got away with it. Be thankful for the new delphi version highlighting this. 

     

    The mistake is in your translation of the header code. There are going to be a bunch of pointer sized types that you have erroneously translated as 32 bit longint or integer. 


  8. 19 minutes ago, DelphiUdIT said:

    @pcoder, @Stefan Glienke

    I think he wants to try a general function, also for others rounding modes (he inserts other masks to the function).
    But you are right, there are also other native CPU instructions that do that specif works (like that you exposed).

     

    Would be weird to want to truncate a single (a well defined task) and insist on doing so in an inefficient way.


  9. 4 hours ago, Lajos Juhász said:

    No. The change was made to follow the Windows standard. Other languages assume or will change the exception masks. That was fragile in previous versions of the Delphi. They made the change to follow other languages and minimalize the possibilities to have problems when calling an external DLL.

     

    The price is that we have to adjust our code.

    The point I think is that FMX projects masked exceptions previously by accident rather than design. 

     

    Why should making an empty FMX project bring in all those units and change the floating point control state? 

     

    I understand why the change to the default was made. I kind of agree with it. 

     

    But changing your code to match isn't always going to be easy. I think it would be a huge task for any code base that is heavily numerical. I certainly wouldn't change. 


  10. 57 minutes ago, Rollo62 said:

    Thanks for pointing to this nice page, which shows the overview of old and new behaviour nicely.

    http://docwiki.embarcadero.com/RADStudio/Athens/en/Floating_Point_Operation_Exception_Masks

     

    I've tried to summarize that and make the relevant differences even more visible in this overview:

     

    image.thumb.png.e09b4071e5cf37e4eababdfb4ae65bfd.png

     

     

     

    I was interested to see different behaviour between VCL and FMX on Windows, in pre Delphi 12.

     

    I'm not sure that this is especially intentional. It happens because FMX.Platform.Win uses FMX.WebBrowser which uses FMX.WebBrowser.Win which uses System.Win.InternetExplorer which does this in its initialization

      FSetExceptMask(femALLEXCEPT);

    I guess it does this because this the IE library implementation expects exceptions to be masked.

     

    Similarly a default FMX app will use Winapi.EdgeUtils which also masks exceptions for the same reason.

     

    I actually think it makes sense to have all platforms behaving the same way and exceptions being masked by default. That being the platform standard on all of these platforms.

     

    Myself, I'm going to keep unmasking exceptions because my codebase relies on that. I hope that the Delphi RTL will continue supporting being used with exceptions unmasked.


  11. 34 minutes ago, shineworld said:

    So, to use a 3rd part DLL made with C++, eg: MSVC or C++Builder itself,  it is necessary to create a Proxy C DLL with C++ Builder.

    I don't think that's the case. If you need to interface with a C++ codebase, then you need to create either a C wrapper, or a COM wrapper, but in each case you aren't limited to C++Builder. Whichever compiler you use to compile the C++, you compile the C wrapper, or the COM wrapper. The point is that the C or COM wrappers are compiler agnostic. But C++ code is, in general, not compiler agnostic. So you just need to compile your wrapper in the same toolchain as the C++ library.

     

    There are actually tools to create such wrappers. I'm thinking of SWIG.

     

    But there's no way that there's going to be a Delphi produced which can consume C++ libraries compiled by some arbitrary C++ compiler.


  12. How much are you prepared to pay? What exactly does the job entail? You may be better asking directly on sites that are designed to put together people looking for contract programmers.

     

    Are you asking any more than you did here: 

     

×