nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How can LoadDLL a 32-bit DLL through JSL?

lala

My operating system is 64-bit Windows 10.One software, HailiLive.EXE, is still 32-bit.There is Drv.dll;
How can I use JSL of 64-bit JMP software to call the 32 bit Drv.dll of this software HailiLive.EXE?

Thanks Experts!

Accepted answers

lala

32bit 14.3JMP

All comments

lala

A message is displayed:

Access or Assign,LoadDLL = /*###*/Load DLL("I:\HailiLive\Drv.dll") /*###*/ evaluation "cannot load external dll" I:\HailiLive\Drv.dll".%1 is not a valid Win32 application.

jthi

Scripting Guide > Extending JMP > Dynamic Link Libraries (DLLs)

Note: 64-bit JMP cannot load 32-bit DLLs. You must recompile a 32-bit DLL for JMP to be able to load it.

lala

Note: 64-bit JMP cannot load 32-bit DLLs. You must recompile a 32-bit DLL for JMP to be able to load it.

lala

32bit 14.3JMP

Paul_Nelson

There is a COM solution to the issue of loading a 32-bit DLL into a 64-bit application. JMP's JSL supports COM Automation on Windows. However, this would be a lot of work to wrapper the DLL using COM.

My Google Search:

using COM to marshal a 32-bit dll for a 64-bit application

AI response:

To call a 32-bit DLL from a 64-bit application, you need to use COM (Component Object Model) in an out-of-process server setup. This involves creating a separate 32-bit COM server application that acts as a wrapper for the 32-bit DLL. The 64-bit application can then communicate with this server through COM's inter-process communication mechanisms.

Here's a breakdown of the process:

1. Create a 32-bit COM Server Application:

New ATL Project:

Create a new ATL (Active Template Library) project in Visual Studio, specifically configured as an executable (not a DLL).
Add ATL Simple Object:

Add a new ATL Simple Object to the project. This will be the core of your COM server.
Implement Interfaces:

Define the interfaces (using .idl files) that the 64-bit application will use to interact with the 32-bit DLL.
Forward Calls:

Within the COM object's methods, forward the calls to the corresponding functions in the 32-bit DLL. This may involve marshalling data between the two processes.

2. Register the COM Server:

DllSurrogate:

You'll need to register the COM server using DllSurrogate. This allows the 64-bit process to instantiate the 32-bit COM object out-of-process.
Registry Entries:

Ensure the necessary registry entries are created to allow the 32-bit in-process server to be loaded by the system's DllSurrogate.

3. Consume the COM Server in the 64-bit Application:

Create a COM Client:
.
In your 64-bit application, create a COM client that connects to the 32-bit COM server. You will use the COM interfaces defined in the .idl file.
Inter-process Communication:
.
COM handles the inter-process communication, marshalling data between the 64-bit and 32-bit processes.

Key Considerations:

Interface Definitions:

Ensure the interfaces defined in the 64-bit application's COM client and the 32-bit server are compatible, including data types and method signatures. Consider using IDL (Interface Definition Language) to define the interfaces.
Marshalling:

COM handles the marshalling of data between the two processes. If you have complex data structures, you may need to explicitly marshal them using the Marshal class or MarshalAsAttribute, according to Learn Microsoft.
Performance:

While COM provides inter-process communication, it introduces overhead. For performance-critical applications, consider the impact of this overhead.
Alternatives:

If recompiling the 32-bit DLL is an option, that is generally the preferred approach, according to Stack Overflow.

By using this approach, you can successfully integrate a 32-bit DLL into your 64-bit application, leveraging the power of COM for inter-process communication and data marshalling.

lala

Thanks Experts!

grok3:
Simple Background
The user wants to receive real-time L1 five-level order book snapshot data (updated every 3 seconds) from the "Tornado" interface (StockDrv.dll), which only supports 32-bit applications. Originally, this was achieved in 32-bit JMP 14.3 using a custom Bridge.dll and JSL script. Now, the goal is to replicate this in 64-bit JMP, which cannot directly load 32-bit DLLs.

Core Solution
Use a 32-bit agent (agent32.exe) to load Bridge.dll, fetch data from StockDrv.dll, and send it via TCP socket to 64-bit JMP, which receives and parses it into a table.

Implementation
32-bit Agent (agent32.exe):
Loads Bridge.dll, calls Bridge_Init(0x9001), and sends 158-byte RCV_REPORT_STRUCTExV3 data via TCP (port 5000).
Compile:
batch

cd /d I:\DZH\Agent
"I:\mingw32\bin\i686-w64-mingw32-g++.exe" -std=c++20 -O2 -Wall -I. -DWIN32 -static-libgcc -static-libstdc++ agent32.cpp -o agent32.exe -luser32 -lkernel32 -lws2_32
64-bit JMP JSL:
Connects to socket, reads 158-byte data, parses fields (e.g., stock code, price, five-level bids/asks), and writes to table.

Key JSL snippet:
sock = Open("|tcp:127.0.0.1:5000");
dt = New Table("L1_Snapshot", New Column("Code", Character), New Column("Epoch", Numeric), New Column("NewPrice", Numeric), /* Add B1-5_P/V, S1-5_P/V */);
blob = Blob();
While(1, bytes = sock << Read(blob, 158); If(bytes == 158, /* Parse and write to dt */));

Notes
Ensure agent32.exe accesses Bridge.dll and StockDrv.dll.
Use set PROCESSOR_ARCHITECTURE=x86 for 32-bit execution.
Handle data duplication by updating table rows based on stock code.

lala

Thanks Experts!

Ultimately, it was through asking OpenAI o3

A relay DLL was recompiled in C++ to specifically provide data for JMP.But only a 32-bit JMP can be used

The problem is that the data reading in the JMP table cannot display Chinese correctly.

The AI has modified CPP multiple times but failed. Even when different character sets were used in the Settings of JMP, it still didn't work and remained garbled.

Names Default To Here(1);

dll = Load DLL("I:\\DZH\\Bridge\\Bridge.dll");
dll << Declare Function("Bridge_Init@4",     Convention(STDCALL), Alias("Bridge_Init"),     Arg(UInt32),      Returns(Int32));
dll << Declare Function("Bridge_Quit@0",     Convention(STDCALL), Alias("Bridge_Quit"),                       Returns(Void));
dll << Declare Function("Bridge_GetCount@0", Convention(STDCALL), Alias("Bridge_GetCount"),                   Returns(Int32));
dll << Declare Function("Bridge_ReadTSV@4",  Convention(STDCALL), Alias("Bridge_ReadTSV"),  Arg(Int32),       Returns(AnsiString));

If(dll << Bridge_Init(36865) != 1, Throw("Bridge_Init失败"));

dt = New Table("L1_Snapshot",
 New Column("Name",     Character, "Nominal"),
 New Column("Epoch",    Numeric,   "Continuous"),
 New Column("NewPrice", Numeric),
 New Column("B1_P", Numeric), New Column("B1_V", Numeric),
 New Column("S1_P", Numeric), New Column("S1_V", Numeric),
 New Column("B2_P", Numeric), New Column("B2_V", Numeric),
 New Column("S2_P", Numeric), New Column("S2_V", Numeric),
 New Column("B3_P", Numeric), New Column("B3_V", Numeric),
 New Column("S3_P", Numeric), New Column("S3_V", Numeric),
 New Column("B4_P", Numeric), New Column("B4_V", Numeric),
 New Column("S4_P", Numeric), New Column("S4_V", Numeric),
 New Column("B5_P", Numeric), New Column("B5_V", Numeric),
 New Column("S5_P", Numeric), New Column("S5_V", Numeric)
);

While(1,
 cnt = dll << Bridge_GetCount();
 For(i=0, i<cnt, i++,
  line = dll << Bridge_ReadTSV(i);
  If(Is Missing(line)==0 & Contains(line, "\t"),
    vals = Words(line, "\t");
    If(N Items(vals)==23,
      dt << Add Rows(1);
      r = N Rows(dt);
      Column(dt,1)[r] = vals[1];
      Column(dt,2)[r] = Num(vals[2]);
      Column(dt,3)[r] = Num(vals[3]);
      idx=4;
      For(c=4, c<=23, c++,
        Column(dt,c)[r] = Num(vals[idx]); idx++;
      );
    );
  );
 );
 Wait(0.1);
);

lala

Thanks Experts!
Another AI made this suggestion; here is the original wording: “I get it now—this isn’t a ‘GBK → UTF-8’ problem at all. It’s a memory-misinterpretation issue that scrambles both numbers and Chinese text. Those weird glyphs (e.g., ↗?C, 镃毂镃叓) look like JMP grabbed a wrong pointer from the DLL and decoded the raw binary of a floating-point field as if it were GBK text. My suspicion: 1. Structure layout mismatch Your `RCV_REPORT_STRUCTExV3` in Bridge.cpp doesn’t match the byte alignment (`packing`) used inside StockDrv.dll. If the `#pragma pack` settings differ, the data shifts and the Chinese you read is actually garbage from a float. 2. Stock code is not a plain char[8] In some versions of DZH the code field is `char m_szLabel[16]` or even wide-char (2-byte GB2312). If you `memcpy` it as single-byte, you get half-cut Han characters. 3. DLL interface version mismatch If StockDrv.dll is returning a V4 structure while you’re reading it as V3, everything will be off. Here’s what I suggest: - Force the same `#pragma pack(push, 1)` that StockDrv.h uses. - Verify the actual length of `m_szLabel` (`STKLABEL_LEN`). - Skip any UTF-8 conversion; dump the raw bytes straight to CSV. - Make sure floats and ints land in their correct offsets—no shifting. I’ll write you a complete, alignment-correct version with key points commented; just drop it in.”