GenHub

The Problem

The Command & Conquer: Generals and Zero Hour ecosystem is fragmented across multiple retail distributions: Steam, EA App, Origin, the First Decade DVD, and legacy CD installs.

Each distribution uses different directory hierarchies, registry keys, and binary patch levels (1.04 vs 1.08). Historically, community modifications directly overwrote base game files in the install directory. When players switched between total conversions or joined online matches, modified files caused multiplayer desynchronization crashes and corrupted installations.

Six Architectural Pillars

GenHub organizes business logic into six decoupled services:

Core Engineering Decisions

1. Workspace isolation with zero disk duplication

Instead of copying 10 to 30 GB of base game files per mod, GenHub constructs an isolated workspace sandbox in under 200ms using directory junctions and symbolic links. Base .BIG archives remain read-only, while mod assets are dynamically overlaid on launch.

2. Binary archive inspection & INI patching

GenHub includes a custom BigReader engine that parses BIGF and BIG4 FourCC archive headers without loading full multi-gigabyte archives into RAM. The engine performs byte-stream searching and endian-aware patching of camera parameters (such as MaxCameraHeight) directly within binary payloads.

3. CPU affinity & legacy stability

The legacy SAGE game engine suffers from timing race conditions on multi-core modern processors. GenHub’s process orchestrator applies CPU affinity masks during process spawning to lock execution to specific physical cores, eliminating timing crashes during multiplayer matches.

4. Explicit error handling with the Result pattern

All service boundaries return typed Result<T> and Result structures instead of throwing runtime exceptions:

public async Task<Result<GameInstallation>> DetectInstallationAsync(InstallationSource source)
{
    var pathResult = await locatorService.FindInstallPathAsync(source);
    if (!pathResult.IsSuccess)
    {
        return Result<GameInstallation>.Failure(pathResult.Error);
    }

    var manifestResult = await validatorService.ValidateDirectoryAsync(pathResult.Value);
    if (!manifestResult.IsSuccess)
    {
        return Result<GameInstallation>.Failure(manifestResult.Error);
    }

    return Result<GameInstallation>.Success(new GameInstallation(pathResult.Value, source));
}

This pattern makes failure paths visible in method signatures, prevents unhandled runtime exceptions, and enforces explicit error handling in UI view models.