Native library remoting

Run your DLL on
another computer.

Keep your application in place and run its native library beside the device. RemoteDLL connects Windows and Linux systems through an explicit API contract.

How it works↘Download the demo

Remote native libraries for Windows & Linux.

Experience in banking, industry and healthcare

RemoteDLLCall path

01APPLICATION COMPUTER

LabClient.exe

// same native interface
LD_Open();
LD_Write(handle, data, 6);
LD_Read(handle, buffer, 64);

Adapter A LabDevice.dllNATIVE PROXY

TCP / TLS 1.2+

↓

02DEVICE COMPUTER

Adapter B ABI ADAPTER

→

▥LabDevice

Windows / LinuxEXPLICIT API CONTRACTC ABI

Integration experience

Banking, industry and healthcare

Banking peripherals

Experience integrating passbook printers, cash recyclers, ATMs, and network printers and scanners.

Industrial machinery

Experience integrating machines that depend on security dongles and native manufacturer libraries.

Healthcare systems

Integration experience with Kardex and Pyxis systems.

Architecture

From the application to the device

Replace the application-facing library with an adapter built for its interface. Calls cross the network; the original library executes beside the device on Windows or Linux.

Intercept the call

The application loads Adapter A through its expected native interface. A local broker manages the connection to the remote host.

Application → Adapter A → Broker

Transport the arguments

A defined contract turns buffers and handles into messages. TLS protects the connection; bounded frames and deadlines control each exchange.

Request ID · TLS · Response

Execute by the device

The host adapter calls the original library, copies output buffers back and returns the result to the waiting application.

Host → Adapter B → Native library

Connections

Direct connection or AWS relay

Connect directly over TCP with TLS, or use the AWS Docker relay over HTTPS/WebSocket on port 443. The relay accepts outbound connections from both computers.

01ApplicationAdapter A + Broker

TLS↔

02Device hostAdapter B + LabDevice

LabDevice demo

Try it with LabDevice

LabDevice is a simulated peripheral. The same executable runs against the original DLL or a replacement that forwards calls to a remote host.

Open and close session-owned handles
Read and write binary buffers
Check status and buffer capacity
Receive synchronous completion callbacks

Download the prototype↓

Windows evaluation binaries. See README for setup and prototype limits.

REMOTEDLL LABDEVICEEXAMPLE SESSION

# Same client. Replace only the DLL.
> LabClient.exe

01  LD_Open()                  → handle
02  LD_Write(handle, data, 6)  → 6
03  LD_Read(handle, buffer, 64)→ 6
04  LD_Close(handle)           → 0

00 01 7F 80 FF 2A
binary payload · same bytes returned

Platforms and integration

Windows and Linux

RemoteDLL is being developed for Windows and Linux. Each device host uses the native library for its operating system: DLL on Windows, shared library (.so) on Linux.

An adapter for your interface

The adapter preserves the interface your application expects. Data types, buffers, handles and callbacks are mapped to a defined contract for each library.

What the demo includes

LabDevice demonstrates a Windows x86/x64 client with a Windows or Linux device host and a Linux Docker relay. The current download contains the Windows evaluation binaries.

Remote DLL integration: common questions

Can I run a DLL on another computer?

A compatible adapter can forward application calls to a host that loads the original library. Arguments, buffers and handles need an explicit contract for that library.

Can Windows and Linux communicate?

The transport protocol is independent of the operating system. A Windows host loads a Windows DLL; a Linux host needs a compatible native shared library (.so).

Do both computers need public IP addresses?

No. With the AWS relay, both computers open outbound HTTPS/WebSocket connections on port 443. Calls remain protected by an inner TLS session between the endpoints.

Discuss your DLL integration

Send us the library interface, target operating systems and device details. We will review what is needed to build the adapter.

Run your DLL onanother computer.