← Back to Blog
Architecture 2025-09-12 8 min read

Building the Helper Bridge: Native Desktop Integration for EVE Frontier

One of the most ambitious features we've shipped for EF-Map is the Helper Bridge—a native Windows application that connects the browser-based map to the EVE Frontier game client. This creates a seamless experience where routes calculated on the map automatically sync to an in-game overlay, and your current location in-game updates the map in real-time.

Building this required bridging three completely different technology stacks: React/TypeScript (web), Win32/C++ (native desktop), and DirectX 12 (game overlay). Here's how we made it work.

The Problem: Crossing the Browser Sandbox

Modern browsers run in a security sandbox that prevents web pages from accessing your local system—for good reason. But this creates a challenge for game tools: how do we let a website communicate with a native game client without compromising security?

Traditional solutions involve clunky workflows: export a file from the website, manually import it into the game, repeat for every route change. We wanted something better: bidirectional real-time sync with zero manual file shuffling.

Architecture: Three Pieces Working Together

Our solution uses a three-component architecture:

1. Helper Application (Native Windows Service)

A lightweight C++ application that runs in your system tray. It handles:

The helper is the "glue" that connects the web app to the game. It's signed with a Microsoft certificate and distributed through the Microsoft Store, so Windows trusts it to access system APIs.

2. Web App Integration (Browser)

The React frontend detects if the helper is running by making a lightweight HTTP request: 

const detectHelper = async (): Promise<boolean> => {
    try {
        const response = await fetch('http://127.0.0.1:38765/api/status', {
            method: 'GET',
            signal: AbortSignal.timeout(1000)
        });
        return response.ok;
    } catch {
        return false; // Helper not running
    }
};

If detected, the UI shows a "Sync to Game" button. When clicked, we send route data to the helper: 

const syncRoute = async (route: RouteData) => {
    await fetch('http://127.0.0.1:38765/api/route', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
            waypoints: route.systems,
            jumps: route.jumps,
            distance: route.distance_ly
        })
    });
};

This looks like a normal HTTP API, but it's talking to a native app running on localhost. No cloud service involved—all communication stays on your machine.

3. DirectX 12 Overlay (In-Game Rendering)

The most technically complex piece: a DLL that hooks into the EVE Frontier rendering pipeline. When the helper detects the game process, it injects this overlay module, which:

This is the same technique used by popular tools like Discord overlay, MSI Afterburner, and Steam's in-game UI. We're rendering inside the game's DirectX context, so there's no performance penalty from running a separate window.

Security Considerations

Injecting code into another process is powerful—and potentially dangerous. We implemented several safeguards:

1. Code signing: Both the helper EXE and overlay DLL are signed with an Extended Validation (EV) certificate. Windows validates these signatures before allowing injection.

2. Localhost-only API: The helper HTTP server binds to 127.0.0.1 exclusively, so it's not exposed to the network. Only apps running on your machine can access it.

3. Process allowlist: The helper only injects into exefile.exe (EVE Frontier's process name). It won't touch other games or system processes.

4. Minimal permissions: The overlay DLL has read-only access to game memory. It can render UI but can't modify game state or send inputs.

5. User consent: Installation requires explicit permission (Microsoft Store install flow). The system tray icon shows when the helper is active, with a right-click menu to exit.

We also worked closely with CCP (the game developer) to ensure our approach aligns with their policies. The overlay provides information only—no automation, no gameplay advantages, just better navigation.

Protocol Design: Custom URL Scheme

We use a custom protocol (ef-overlay://) for one-click route sending. When you click "Open in Game" on the website, it triggers a URL like: 

ef-overlay://route?waypoints=J100422,J212103,J313204&jumps=15

Windows sees the ef-overlay:// prefix, looks up the registered protocol handler (our helper app), and launches it with the URL as an argument. The helper parses the route data and displays it in-game.

This creates a magic link experience: share a route URL with a corpmate, they click it, and it instantly appears in their overlay. No copy-paste, no manual input.

Performance Optimization

Running a DirectX hook inside the game requires extreme attention to performance. Every frame (at 60+ FPS), our overlay code executes. Any slowdown is immediately noticeable as stuttering or framerate drops.

We optimized aggressively:

1. Minimal rendering: We only draw UI when the overlay is visible (toggle with hotkey). When hidden, our hook returns immediately.

2. Cached textures: Route waypoint icons are loaded once at injection time and reused every frame.

3. Batched draw calls: We combine all ImGui elements into a single draw call per frame instead of multiple separate calls.

4. No allocations in hot path: All strings and vectors are pre-allocated. We never call new or malloc during rendering.

Benchmark results: our overlay adds <0.5ms per frame (0.03ms typical). At 60 FPS, this is imperceptible—users report no performance difference with overlay active vs. inactive.

Cross-Process Communication Challenges

One tricky aspect: the web app, helper service, and injected overlay are three separate processes. Keeping them synchronized requires careful state management:

We use a lock-free atomic exchange for shared memory updates to avoid race conditions: 

// Helper writes route data
std::atomic<RouteData*> g_sharedRoute;
g_sharedRoute.store(newRoute, std::memory_order_release);

// Overlay reads route data
RouteData* route = g_sharedRoute.load(std::memory_order_acquire);
if (route) {
    renderWaypoint(route->next_system);
}

This guarantees the overlay always sees either the old complete route or the new complete route—never a half-written hybrid state.

Real-World Usage Stats

Since launching the helper bridge, we've tracked adoption and performance:

The feature is particularly popular among scout pilots (who navigate frequently) and logistics coordinators (who share routes with fleets).

Lessons from Building Native-Web Bridges

This project taught us several principles for connecting web apps to native desktop software:

1. Localhost HTTP is your friend. It's simpler than custom binary protocols and works with standard web APIs (fetch, WebSocket).

2. Protocol handlers enable magic. Custom URL schemes (myapp://) make browser→desktop transitions seamless.

3. Security is non-negotiable. Code signing, localhost-only APIs, and minimal permissions are table stakes for user trust.

4. Performance testing is critical. Hooks that run 60+ times per second need microsecond-level optimization.

5. Distribution matters. Microsoft Store signing was complex but essential—users trust the blue checkmark.

Future Enhancements

We're working on several improvements to the helper bridge:

The helper bridge is a foundation for richer integrations between EF-Map and the game. Every feature we add makes the boundary between "web tool" and "game client" more blurred—and the user experience more seamless.

Want to try the overlay yourself? Download the helper from the Microsoft Store and experience synchronized navigation across web and game.

Related Posts

native integrationwindows developmentipcprotocol handlersdesktop apps