Announcement

Collapse
No announcement yet.

DLL's 32bit & 64bit

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • DLL's 32bit & 64bit

    I'm about to start work on a DLL project (part of our free downloads) and beforehand I decided to do a little research on the current situation ...

    32bit:

    A few years ago I discovered that initially it was intended that each "new DLL(...)" EFS statement, would create a separate instance of the DLL for each EFS. So each EFS would have it's own unique copy of the DLL data.

    but there was a technical constraint outside the control of eSignal EFS ...

    Each time a DLL object is created in EFS, internally ::LoadLibrary is called. This is a function of the Win32 SDK. LoadLibrary does create brand new copies of the DLL if it is called from two separate programs (aka processes). But if LoadLibrary is called multiple times in the same program (aka process, ie eSignal), then each call would be pointing to the same copy of the DLL being loaded. Therefore 2 or more charts using the same DLL could all be working on the same data potentially causing some confusion.

    This problem was overcome using a DLL function to create a unique class instance and return a pointer to it that would be stored in the EFS. So any EFS DLL calls would include the pointer to make sure it was using data unique to the chart.

    Can anyone enlighten me on the current 32bit and 64bit situation?
    Paul Williams
    Strategy & Applications
    www.futurenets.co.uk

  • #2
    from kb ...

    eSignal version 10.6 or earlier:

    File location
    To simplify the DLL load, place the DLL into \Program Files\eSignal. Then when loading the DLL, just use DLL Name w/o a path.

    var d = new DLL("FileName.dll")

    It will look into the 'current' (ie Program Files\eSignal) first.


    eSignal version 11.0 or later:

    File location
    The DLL files must be located in either:
    1. The same folder as the EFS or in the FunctionLibrary folder.
    In this case it is not required to define a path in the DLL call. The EFS engine will first search the folder containing the EFS and if no DLL is found it will search the FunctionLibrary folder.
    2. A sub-folder of the folder containing the EFS or a sub-folder of the FunctionLibrary folder.
    In this case a path is required in the DLL call. The path must be relative to the folder containing the EFS or to the FunctionLibrary folder.
    Absolute paths are not allowed.
    DLLs cannot be called if they are located outside of the Formulas or FunctionLibrary root folders, so any path that specifies a location outside of these folders will cause an error eg

    var myVar = new DLL(“../myDLL.dll”); // generates an error

    Specifying a relative path using parent references '../' is not recommended, it can be denied in future releases.

    var myVar = new DLL(“myFolder/../myDLL.dll”); // not recommended


    64bit and 32bit
    1. For the 64bit application the file needs to be a 64bit dll. The file name must have the characters x64 appended to it for example myDLLx64.dll
    In the DLL() call the x64 suffix used in the file name must be omitted eg

    var myVar = new DLL(“myDLL.dll”);


    The formula engine will sense the 64bit environment and will automatically append the x64 suffix to the DLL call.
    2. For the 32bit application the file needs to be a 32bit dll. No special file naming is required

    This arrangement allows developers to include DLL files for both environments without the need to provide separate formulas
    Paul Williams
    Strategy & Applications
    www.futurenets.co.uk

    Comment

    Working...
    X