GeneralsOnline Easy Anti-Cheat update breaks launch: wrong executable, missing EAC install step

[undead2146]

Problem

Generals Online release 060526_QFE1 added Easy Anti-Cheat (EAC) via Epic Online Services. GenHub can still download and materialise the portable, but a profile launch no longer reaches multiplayer — the client is started the wrong way and the anti-cheat runtime is never installed.

Verified against the live CDN (https://cdn.playgenerals.online/manifest.json):

{
  "version": "060526_QFE1",
  "download_url": "https://cdn.playgenerals.online/GeneralsOnline_portable_060526_QFE1.zip",
  "size": 28302710,
  "release_notes": "www.playgenerals.online",
  "sha256": "5826aee8a0722d09bb07d67ff3c9314c86e866c24c7e64407a582b9545e96b52"
}

The portable layout changed in three ways GenHub does not handle:

1. The entry point moved. The official bootstrapper is now EAC_LaunchGeneralsOnline.exe. It wraps the game binary named in EasyAntiCheat/Settings.json (GeneralsOnlineZH_60.exe). GenHub still marks only generalsonlinezh_60.exe as the launch executable:

// GeneralsOnlineManifestFactory.cs — only GeneralsOnlineZH_60.exe gets IsExecutable = true
var targetExecutable = GameClientConstants.GeneralsOnline60HzExecutable;

ManifestVariantResolver and GameLauncher resolve the process from that flag, so GenHub bypasses EAC entirely.

2. EAC must be installed, not just copied. The portable ships EasyAntiCheat_EOS_Setup.exe alongside an EasyAntiCheat/ tree (certificates, localisation, Settings.json, splash). Running the game outside the official bootstrapper, or copying files into a workspace without running the EOS setup, leaves the anti-cheat service absent. GenHub's deliverer extracts into CAS and materialises to the workspace but has no install step for the EOS setup binary.

3. New files are not accounted for in detection or documentation. Extraction already walks all non-map files recursively, so most new paths land in the manifest automatically once a user updates. However, constants and client detection still assume the pre-EAC layout:

New path	Role
EAC_LaunchGeneralsOnline.exe	Official launch bootstrapper (should be IsExecutable)
EasyAntiCheat_EOS_Setup.exe	EOS EAC installer — must run once per machine
EasyAntiCheat/	EAC runtime config (Settings.json points at GeneralsOnlineZH_60.exe)
EOSSDK-Win32-Shipping.dll	Epic Online Services SDK
plugins/easyanticheat/, plugins/goanticheat/	In-process anti-cheat plugin DLLs
cacert.pem, crashpad_handler.exe, xaudio2_9redist.dll	Supporting runtime files
GeneralsOnlineGameData/	Client data (GOSplash.bmp, MapCacheGO.ini)

GameClientConstants.GeneralsOnlineDlls and GeneralsOnlineClientIdentifier still key off generalsonlinezh_60.exe only; they do not recognise the EAC bootstrapper as the client entry point.

Why this was missed

The GeneralsOnline integration predates EAC. The manifest factory treats every extracted file as workspace content and picks the game binary as the sole executable. That was correct when GeneralsOnlineZH_60.exe was both the game and the launch target. The portable now separates bootstrapper, installer, and game binary, and GenHub has no concept of a post-extraction setup executable or a non-game launch wrapper.

Proposed work

• Mark EAC_LaunchGeneralsOnline.exe as the launch executable in the 60Hz game-client manifest; keep GeneralsOnlineZH_60.exe as a non-launch workspace file (EAC loads it per EasyAntiCheat/Settings.json).
• Run EasyAntiCheat_EOS_Setup.exe once after extraction or first launch, with idempotent detection so repeat installs are skipped. Decide whether this belongs in the deliverer, a dedicated post-install hook, or first-launch orchestration in GameLauncher.
• Extend GameClientConstants / GeneralsOnlineClientIdentifier / GeneralsOnlineDlls for the EAC-era file set so detection, import, and hash registration stay aligned.
• Surface a clear failure when EAC is required but not installed, rather than silently starting the bare game binary.
• Confirm update/reconcile flows (GeneralsOnlineProfileReconciler) re-run the EOS setup when the portable version changes.

Acceptance criteria

• A GeneralsOnline profile on 060526_QFE1 or later launches via EAC_LaunchGeneralsOnline.exe from the materialised workspace.
• EAC is installed on first use; subsequent launches skip setup when already present.
• The content manifest includes the full EAC file tree (EasyAntiCheat/, plugins/, EOS SDK, and supporting DLLs).
• Launching with only GeneralsOnlineZH_60.exe (bypassing EAC) is not the default path and produces an actionable error if attempted.
• Auto-update from a pre-EAC install to 060526_QFE1+ completes without leaving a workspace that cannot join multiplayer.

Notes

• EAC is Windows-only; this issue does not affect macOS Alpha 5 work.
• The CDN sha256 field is available for integrity verification but is not consumed by GenHub today.
• Coordinate with the Generals Online team on whether the EOS setup supports silent/unattended flags suitable for GenHub automation.

Related

• GeneralsOnline settings shown in profile despite it not being installed or used by the profile #292 — GeneralsOnline settings visibility (orthogonal, but same publisher surface)
• Version ordering is inconsistent across provider formats and application flows #306 — version ordering across provider formats (update reconcile may need to compare 060526_QFE1 correctly)

[coderabbitai]

Coding Plan

Summary

• Extend the existing manifest/detection metadata (constants, GeneralsOnlineManifestFactory, GeneralsOnlineClientIdentifier, GameClientDetector/GameClientHashRegistry, ManifestGenerationService) so the EAC bootstrapper becomes the launch executable and the full EAC file tree is captured, keeping the game binary as a non-launch workspace file.
• Add a small idempotent, version-keyed EAC/EOS setup service invoked from GameLauncher between workspace preparation and process start, reusing the existing synchronous-process/exit-code and fail-fast/failure-surfacing patterns.
• Generalize GameProcessManager's spawned-process detection to track the distinctly named wrapped game binary via manifest metadata threaded through GameLaunchConfiguration.
• Reuse the actual existing components instead of the ticket's non-existent ManifestVariantResolver/GeneralsOnlineProfileReconciler; the version-keyed setup marker naturally re-runs EOS setup after auto-updates, and a new ValidationIssueType.RequiredRuntimeMissing provides actionable failure signaling.

Design Choices

Design Choice 1: Where should `EasyAntiCheat_EOS_Setup.exe` run — deliverer, a post-install hook, or first-launch orchestration?

Options Considered:

1. Run in GeneralsOnlineDeliverer between extraction and CAS registration — installer would run from a temp folder that is immediately deleted; no per-machine idempotency; no existing hook.
2. Wire InstallationInstructions.PostInstallSteps and add a generic executor — introduces a new execution subsystem (elevation, exit-code handling) that nothing else uses; over-scoped for one publisher.
3. First-launch orchestration inside GameLauncher.LaunchProfileAsync, after workspace preparation and before process start — runs from the real materialized workspace, reuses the existing phased fail-fast pattern, and is naturally idempotent via a per-machine/per-version marker.

Chosen Option: 3

Rationale: The deliverer extracts to CAS and then deletes the temp extraction, so it is not a stable location to run a machine-level installer from. EAC/EOS setup installs a per-machine service, so it must run against the materialized workspace and be idempotent across profiles/launches. Option 3 runs against the materialized workspace, aligns with the existing launch-phase/fail-fast pattern, and provides the cleanest seam for idempotent one-time setup and actionable failure surfacing.

Design Choice 2: The ticket references `ManifestVariantResolver` and `GeneralsOnlineProfileReconciler`, which do not exist in the codebase.

Options Considered:

1. Create the named classes to match the ticket wording.
2. Implement the described behavior in the real existing components (manifest factory + workspace strategy for executable resolution; update service + version-keyed setup marker for re-run).

Chosen Option: 2

Rationale: Executable resolution is actually performed by WorkspaceStrategyBase.UpdateWorkspaceInfo (via IsExecutable), and update detection lives in GeneralsOnlineUpdateService; the only "reconciler" is the generic WorkspaceReconciler. Extending the actual existing components avoids inventing redundant abstractions and matches established patterns; the ticket names appear to be conceptual placeholders.

Design Choice 3: How to make EOS setup idempotent and re-run only on version change?

Options Considered:

1. Rely solely on the installer's own idempotency and run it on every launch — repeated shell-outs on every launch, slower startup.
2. Persist a per-machine marker keyed by GeneralsOnline version + product id under GenHub AppData; run setup only when the marker is absent or the version differs.

Chosen Option: 2

Rationale: The EOS installer is effectively unattended (EasyAntiCheat_EOS_Setup.exe install <ProductId>) and installs a machine-level service. A version-keyed marker gives fast idempotent skips on normal launches and automatically forces a re-run after an auto-update to a new portable version (satisfying the reconcile acceptance criterion) without a dedicated reconciler class.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Recognize the EAC-era portable layout (constants, manifest, detection)

This phase teaches GenHub about the new file set so the correct launch executable is flagged, the full EAC tree is captured in manifests, and local imports/detection recognize the EAC-era client. These changes are grouped because they all revolve around the manifest/detection metadata that must stay mutually consistent.

Task 1: Add EAC/EOS constants

Introduce the new filenames, folder names, and DLL/support-file lists the rest of the work keys off.

• Add EAC constants to GenHub/GenHub.Core/Constants/GameClientConstants.cs alongside the existing GeneralsOnline entries: bootstrapper name (EAC_LaunchGeneralsOnline.exe), EOS setup name (EasyAntiCheat_EOS_Setup.exe), and a new EAC-era support-file/DLL list (EOS SDK EOSSDK-Win32-Shipping.dll, cacert.pem, crashpad_handler.exe, xaudio2_9redist.dll, and the plugins/easyanticheat + plugins/goanticheat plugin DLLs).
• Add a GeneralsOnline-specific EAC section to GenHub/GenHub.Core/Constants/GeneralsOnlineConstants.cs: EasyAntiCheat folder name, Settings.json relative path, and the EOS product-id argument used to invoke setup (value to be confirmed with the Generals Online team per the ticket note).
• Keep the existing GeneralsOnline60HzExecutable (generalsonlinezh_60.exe) constant; it remains the wrapped game binary, now a non-launch workspace file.

Task 2: Flag the bootstrapper as the launch executable

Change executable selection so the EAC bootstrapper is the launch target while the game binary stays a normal workspace file.

• Update GeneralsOnlineManifestFactory.cs (UpdateManifestsWithExtractedFiles) so that, for the 60Hz variant, when EAC_LaunchGeneralsOnline.exe is present it receives IsExecutable = true and GeneralsOnlineZH_60.exe is added as a normal (IsExecutable = false) workspace file rather than being excluded.
• Preserve backward compatibility: when the bootstrapper is absent (pre-EAC portable), fall back to the existing behavior of marking the variant game binary executable.
• Ensure the EOS setup binary, EasyAntiCheat/ tree, plugins/, EOS SDK, and supporting DLLs are retained as workspace files (extraction already walks them recursively; confirm none are inadvertently excluded by the executable-exclusion continue branches).
• Record the wrapped game-binary name in the manifest metadata so the launcher/process manager can identify the spawned process later (see Phase 3).

Task 3: Recognize the bootstrapper in identification and detection

Keep filename-based detection/import aligned with the new entry point.

• Update GeneralsOnlineClientIdentifier.cs so CanIdentify/Identify also recognize EAC_LaunchGeneralsOnline.exe as a GeneralsOnline (60Hz) client entry point, in addition to the existing game-binary names.
• Update GameClientDetector.DetectGeneralsOnlineClientsAsync and GameClientConstants.GeneralsOnlineExecutableNames / GameClientHashRegistry._possibleExecutableNames so the bootstrapper is included when scanning installations.
• Update ManifestGenerationService.AddGeneralsOnlineClientFilesToManifest to include the EAC-era file set (EOS setup, EasyAntiCheat/ folder recursively, plugins/ folders, EOS SDK, and supporting DLLs) using the same best-effort File.Exists inclusion pattern already used for GeneralsOnlineDlls, and to mark the bootstrapper (when present) as the executable for local imports.

🤖 Prompt for AI agents

Implement Phase 1 of the plan: teach GenHub to recognize the new EAC-era
GeneralsOnline portable layout in constants, manifest generation, and
detection/import.

- In `GenHub/GenHub.Core/Constants/GameClientConstants.cs`, add constants for
the EAC bootstrapper name (`EAC_LaunchGeneralsOnline.exe`), the EOS setup binary
name (`EasyAntiCheat_EOS_Setup.exe`), and a new EAC-era support-file/DLL list
including the EOS SDK (`EOSSDK-Win32-Shipping.dll`), `cacert.pem`,
`crashpad_handler.exe`, `xaudio2_9redist.dll`, and the `plugins/easyanticheat` +
`plugins/goanticheat` plugin DLLs. Keep the existing
`GeneralsOnline60HzExecutable` (`generalsonlinezh_60.exe`) constant unchanged;
it now represents a non-launch wrapped workspace file.
- In `GenHub/GenHub.Core/Constants/GeneralsOnlineConstants.cs`, add a
GeneralsOnline-specific EAC section: the `EasyAntiCheat` folder name constant,
the `Settings.json` relative path constant, and the EOS product-id argument
constant used to invoke setup.
- In `GeneralsOnlineManifestFactory.cs` (`UpdateManifestsWithExtractedFiles`),
for the 60Hz variant: if `EAC_LaunchGeneralsOnline.exe` is present, set
`IsExecutable = true` on it and add `GeneralsOnlineZH_60.exe` as a normal
(`IsExecutable = false`) workspace file instead of excluding it. If the
bootstrapper is absent, fall back to the existing behavior of marking the
variant game binary as executable. Verify the EOS setup binary, `EasyAntiCheat/`
tree, `plugins/`, EOS SDK, and supporting DLLs are retained as workspace files
and not skipped by any executable-exclusion `continue` branches. Record the
wrapped game-binary name in manifest metadata for later use by the
launcher/process manager.
- Update `GeneralsOnlineClientIdentifier.cs` (`CanIdentify`/`Identify`) to also
recognize `EAC_LaunchGeneralsOnline.exe` as a valid GeneralsOnline 60Hz entry
point.
- Update `GameClientDetector.DetectGeneralsOnlineClientsAsync`,
`GameClientConstants.GeneralsOnlineExecutableNames`, and
`GameClientHashRegistry._possibleExecutableNames` to include the bootstrapper
name when scanning installations.
- Update `ManifestGenerationService.AddGeneralsOnlineClientFilesToManifest` to
include the full EAC-era file set (EOS setup binary, `EasyAntiCheat/` folder
recursively, `plugins/` folders, EOS SDK, supporting DLLs) using the same
best-effort `File.Exists` inclusion pattern already used for
`GeneralsOnlineDlls`, and mark the bootstrapper as the executable for local
imports when present.

Phase 2: Install the EAC/EOS runtime idempotently at first launch

This phase adds the actual anti-cheat installation step and surfaces a clear failure when it cannot be completed, so profiles reach multiplayer instead of silently launching the bare binary.

Task 1: Add an idempotent EAC setup service

Encapsulate running the EOS installer and tracking that it has run for a given version.

• Create a small Windows-only EAC setup service in GenHub/GenHub/Features/Content/Services/GeneralsOnline/ responsible for: locating EasyAntiCheat_EOS_Setup.exe in the materialized workspace, running it as ... install <ProductId> synchronously, checking the exit code, and persisting a per-machine/per-version marker under GenHub AppData.
• Model the process invocation on WorkspaceValidator.HasUnixExecutePermission (the existing ProcessStartInfo + WaitForExit + exit-code + try/catch template) rather than the fire-and-forget game-launch path.
• Make it idempotent: skip when the marker for the current GeneralsOnline version already exists; run (or re-run) when the marker is missing or records a different version, satisfying the update/reconcile re-run requirement without a dedicated reconciler class.
• Return a result type (success/failure with message) consistent with the codebase's OperationResult/validation-message conventions.

Task 2: Integrate the setup step into launch orchestration

Wire the setup step into the launch flow at the correct seam with clear progress and failure handling.

• Update the private GameLauncher.LaunchProfileAsync to invoke the EAC setup service after workspaceManager.PrepareWorkspaceAsync succeeds and before processManager.StartProcessAsync, only when the resolved GameClient manifest is an EAC-era GeneralsOnline client (detected via manifest metadata/publisher + presence of the setup binary).
• Add a new LaunchPhase value (e.g. InstallingDependencies/InstallingAntiCheat) and report it via progress?.Report(...) consistent with existing phases.
• On setup failure, return LaunchOperationResult<GameLaunchInfo>.CreateFailure(...) using the existing fail-fast idiom and placeholder-cleanup (launchRegistry.UnregisterLaunchAsync), producing an actionable message so the user is never silently dropped into the bare game binary.

🤖 Prompt for AI agents

Implement Phase 2 of the plan: add an idempotent EAC/EOS runtime installation
step and integrate it into launch orchestration.

- Create a new Windows-only EAC setup service under
`GenHub/GenHub/Features/Content/Services/GeneralsOnline/` that: locates
`EasyAntiCheat_EOS_Setup.exe` within the materialized workspace, invokes it
synchronously as `... install <ProductId>`, checks the resulting exit code, and
persists a per-machine/per-version marker under GenHub AppData recording that
setup has completed for the current GeneralsOnline version.
- Model the process-invocation logic on the existing
`WorkspaceValidator.HasUnixExecutePermission` pattern (`ProcessStartInfo` +
`WaitForExit` + exit-code check + try/catch), rather than the fire-and-forget
game-launch approach.
- Make the service idempotent: skip execution when a marker for the current
version already exists; run/re-run when the marker is missing or references a
different version — this satisfies the reconcile-on-update requirement without
introducing a dedicated reconciler class.
- Return a result object (success/failure with message) consistent with the
codebase's `OperationResult`/validation-message conventions.
- In the private `GameLauncher.LaunchProfileAsync`, invoke the new EAC setup
service after `workspaceManager.PrepareWorkspaceAsync` succeeds and before
`processManager.StartProcessAsync`, but only when the resolved GameClient
manifest is identified as an EAC-era GeneralsOnline client (via manifest
metadata/publisher plus presence of the EOS setup binary).
- Add a new `LaunchPhase` enum value (e.g.
`InstallingDependencies`/`InstallingAntiCheat`) and report progress through
`progress?.Report(...)` consistent with existing launch phases.
- On setup failure, return
`LaunchOperationResult<GameLaunchInfo>.CreateFailure(...)` following the
existing fail-fast idiom, performing placeholder cleanup via
`launchRegistry.UnregisterLaunchAsync`, and surface an actionable failure
message so users are never silently launched into the bare game binary without
anti-cheat.

Phase 3: Correctly track the wrapped game process

The bootstrapper spawns a differently-named game process and exits; the existing spawned-process search assumes the child shares the launcher's name, so it must be generalized.

Generalize spawned-process resolution

Allow the launcher wrapper to spawn a distinctly named game binary and still be tracked.

• Update GameProcessManager.FindSpawnedGameProcess/StartProcessAsync to accept an explicit expected spawned-executable name (falling back to the launcher's own base name when none is supplied), so EAC_LaunchGeneralsOnline.exe exiting can resolve GeneralsOnlineZH_60.exe.
• Thread the expected game-binary name from the manifest metadata (Task 1.2) through GameLaunchConfiguration and GameLauncher into the process manager.
• Confirm LaunchRegistry requires no change (it is PID-agnostic and tracks whatever GameProcessInfo.ProcessId it is given once the spawned process is resolved).

🤖 Prompt for AI agents

Implement Phase 3 of the plan: generalize spawned-process resolution so the
wrapped game binary spawned by the EAC bootstrapper can be correctly tracked.

- Update `GameProcessManager.FindSpawnedGameProcess` and `StartProcessAsync` to
accept an explicit expected spawned-executable name parameter, falling back to
the launcher's own base name when none is supplied. This allows the case where
`EAC_LaunchGeneralsOnline.exe` exits after spawning `GeneralsOnlineZH_60.exe` to
correctly resolve the actual game process.
- Thread the expected game-binary name recorded in manifest metadata (from Phase
1, Task 1.2) through `GameLaunchConfiguration` and `GameLauncher` down into the
process manager call.
- Confirm that `LaunchRegistry` requires no changes, since it is PID-agnostic
and simply tracks whatever `GameProcessInfo.ProcessId` it is given once the
spawned process has been resolved.

Phase 4: Validation surfacing and documentation

Provide a first-class "anti-cheat runtime missing" validation signal and update the reference docs to reflect the new executable/layout.

Task 1: Add a validation issue for a missing required runtime

Give detection/validation a way to flag an EAC-required-but-absent client.

• Add a new generic member (e.g. RequiredRuntimeMissing) to GenHub/GenHub.Core/Models/Enums/ValidationIssueType.cs, following the existing MissingFile/DirectoryMissing naming convention.
• Extend GameClientValidator to add a RequiredRuntimeMissing issue (Error severity) when an EAC-era GeneralsOnline client is missing the EasyAntiCheat/ tree or EOS setup binary, reusing the existing issues.Add(new ValidationIssue { ... }) pattern so it flows through the standard OperationResult/notification surfacing.

Task 2: Update reference documentation

Keep the constants/reference docs aligned with the new entry point.

• Update docs/dev/constants.md to reflect the new EAC bootstrapper/EOS setup constants and the fact that EAC_LaunchGeneralsOnline.exe is now the 60Hz launch executable while generalsonlinezh_60.exe is a wrapped workspace file.
• Note the EAC-era portable layout (EasyAntiCheat/, plugins/, EOS SDK, supporting files) where GeneralsOnline is described.

🤖 Prompt for AI agents

Implement Phase 4 of the plan: add a first-class validation signal for a missing
required anti-cheat runtime and update reference documentation.

- Add a new generic enum member (e.g. `RequiredRuntimeMissing`) to
`GenHub/GenHub.Core/Models/Enums/ValidationIssueType.cs`, following the naming
convention of existing members like `MissingFile`/`DirectoryMissing`.
- Extend `GameClientValidator` to add a `RequiredRuntimeMissing` validation
issue with Error severity when an EAC-era GeneralsOnline client is detected to
be missing the `EasyAntiCheat/` tree or the EOS setup binary. Reuse the existing
`issues.Add(new ValidationIssue { ... })` pattern so this flows through the
standard `OperationResult`/notification surfacing mechanisms.
- Update `docs/dev/constants.md` to document the new EAC bootstrapper/EOS setup
constants, noting that `EAC_LaunchGeneralsOnline.exe` is now the 60Hz launch
executable while `generalsonlinezh_60.exe` is a wrapped (non-launch) workspace
file.
- Update the GeneralsOnline description in the docs to note the EAC-era portable
layout, including the `EasyAntiCheat/` folder, `plugins/`, EOS SDK, and
supporting files.

Research

Ticket Summary

GeneralsOnline release 060526_QFE1 introduced an Easy Anti-Cheat (EAC/EOS) bootstrapper that changes the portable layout: the launch entry point is now EAC_LaunchGeneralsOnline.exe (which wraps GeneralsOnlineZH_60.exe per EasyAntiCheat/Settings.json), and EasyAntiCheat_EOS_Setup.exe must be run once to install the anti-cheat runtime. GenHub must (a) mark the bootstrapper as the launch executable, (b) run the EOS setup idempotently, (c) recognize the new EAC-era file set in detection/import, (d) correctly track the spawned game process, and (e) re-run setup after a version change.

Codebase Summary

The GeneralsOnline content pipeline lives under GenHub/GenHub/Features/Content/Services/GeneralsOnline/ (discoverer → resolver → deliverer → manifest factory → update service). GeneralsOnlineManifestFactory builds 30Hz/60Hz GameClient manifests plus a shared MapPack, choosing the launch executable by exact-filename match against GameClientConstants.GeneralsOnline60HzExecutable and setting ManifestFile.IsExecutable. GeneralsOnlineDeliverer downloads/extracts the portable, recursively hashes all files into CAS, and has no installer hook. At launch time, WorkspaceStrategyBase.UpdateWorkspaceInfo resolves the executable from the single IsExecutable flag, and GameLauncher.LaunchProfileAsync (private overload) drives phased launch with a uniform fail-fast/CreateFailure idiom. GameProcessManager.FindSpawnedGameProcess handles launcher-that-spawns-and-exits behavior, but currently searches for a spawned process sharing the launcher's own name. Detection is purely filename-based (GeneralsOnlineClientIdentifier, GameClientDetector, GameClientHashRegistry), and local imports include a fixed DLL list via ManifestGenerationService.AddGeneralsOnlineClientFilesToManifest. There is no EAC/anti-cheat concept anywhere, and the ticket-referenced ManifestVariantResolver and GeneralsOnlineProfileReconciler classes do not exist. InstallationInstructions.Pre/PostInstallSteps exist as a dormant, never-executed data model.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement Phase 1 of the plan: teach GenHub to recognize the new EAC-era
GeneralsOnline portable layout in constants, manifest generation, and
detection/import.

- In `GenHub/GenHub.Core/Constants/GameClientConstants.cs`, add constants for
the EAC bootstrapper name (`EAC_LaunchGeneralsOnline.exe`), the EOS setup binary
name (`EasyAntiCheat_EOS_Setup.exe`), and a new EAC-era support-file/DLL list
including the EOS SDK (`EOSSDK-Win32-Shipping.dll`), `cacert.pem`,
`crashpad_handler.exe`, `xaudio2_9redist.dll`, and the `plugins/easyanticheat` +
`plugins/goanticheat` plugin DLLs. Keep the existing
`GeneralsOnline60HzExecutable` (`generalsonlinezh_60.exe`) constant unchanged;
it now represents a non-launch wrapped workspace file.
- In `GenHub/GenHub.Core/Constants/GeneralsOnlineConstants.cs`, add a
GeneralsOnline-specific EAC section: the `EasyAntiCheat` folder name constant,
the `Settings.json` relative path constant, and the EOS product-id argument
constant used to invoke setup.
- In `GeneralsOnlineManifestFactory.cs` (`UpdateManifestsWithExtractedFiles`),
for the 60Hz variant: if `EAC_LaunchGeneralsOnline.exe` is present, set
`IsExecutable = true` on it and add `GeneralsOnlineZH_60.exe` as a normal
(`IsExecutable = false`) workspace file instead of excluding it. If the
bootstrapper is absent, fall back to the existing behavior of marking the
variant game binary as executable. Verify the EOS setup binary, `EasyAntiCheat/`
tree, `plugins/`, EOS SDK, and supporting DLLs are retained as workspace files
and not skipped by any executable-exclusion `continue` branches. Record the
wrapped game-binary name in manifest metadata for later use by the
launcher/process manager.
- Update `GeneralsOnlineClientIdentifier.cs` (`CanIdentify`/`Identify`) to also
recognize `EAC_LaunchGeneralsOnline.exe` as a valid GeneralsOnline 60Hz entry
point.
- Update `GameClientDetector.DetectGeneralsOnlineClientsAsync`,
`GameClientConstants.GeneralsOnlineExecutableNames`, and
`GameClientHashRegistry._possibleExecutableNames` to include the bootstrapper
name when scanning installations.
- Update `ManifestGenerationService.AddGeneralsOnlineClientFilesToManifest` to
include the full EAC-era file set (EOS setup binary, `EasyAntiCheat/` folder
recursively, `plugins/` folders, EOS SDK, supporting DLLs) using the same
best-effort `File.Exists` inclusion pattern already used for
`GeneralsOnlineDlls`, and mark the bootstrapper as the executable for local
imports when present.
===============================================================================

Task: 2

Implement Phase 2 of the plan: add an idempotent EAC/EOS runtime installation
step and integrate it into launch orchestration.

- Create a new Windows-only EAC setup service under
`GenHub/GenHub/Features/Content/Services/GeneralsOnline/` that: locates
`EasyAntiCheat_EOS_Setup.exe` within the materialized workspace, invokes it
synchronously as `... install <ProductId>`, checks the resulting exit code, and
persists a per-machine/per-version marker under GenHub AppData recording that
setup has completed for the current GeneralsOnline version.
- Model the process-invocation logic on the existing
`WorkspaceValidator.HasUnixExecutePermission` pattern (`ProcessStartInfo` +
`WaitForExit` + exit-code check + try/catch), rather than the fire-and-forget
game-launch approach.
- Make the service idempotent: skip execution when a marker for the current
version already exists; run/re-run when the marker is missing or references a
different version — this satisfies the reconcile-on-update requirement without
introducing a dedicated reconciler class.
- Return a result object (success/failure with message) consistent with the
codebase's `OperationResult`/validation-message conventions.
- In the private `GameLauncher.LaunchProfileAsync`, invoke the new EAC setup
service after `workspaceManager.PrepareWorkspaceAsync` succeeds and before
`processManager.StartProcessAsync`, but only when the resolved GameClient
manifest is identified as an EAC-era GeneralsOnline client (via manifest
metadata/publisher plus presence of the EOS setup binary).
- Add a new `LaunchPhase` enum value (e.g.
`InstallingDependencies`/`InstallingAntiCheat`) and report progress through
`progress?.Report(...)` consistent with existing launch phases.
- On setup failure, return
`LaunchOperationResult<GameLaunchInfo>.CreateFailure(...)` following the
existing fail-fast idiom, performing placeholder cleanup via
`launchRegistry.UnregisterLaunchAsync`, and surface an actionable failure
message so users are never silently launched into the bare game binary without
anti-cheat.
===============================================================================

Task: 3

Implement Phase 3 of the plan: generalize spawned-process resolution so the
wrapped game binary spawned by the EAC bootstrapper can be correctly tracked.

- Update `GameProcessManager.FindSpawnedGameProcess` and `StartProcessAsync` to
accept an explicit expected spawned-executable name parameter, falling back to
the launcher's own base name when none is supplied. This allows the case where
`EAC_LaunchGeneralsOnline.exe` exits after spawning `GeneralsOnlineZH_60.exe` to
correctly resolve the actual game process.
- Thread the expected game-binary name recorded in manifest metadata (from Phase
1, Task 1.2) through `GameLaunchConfiguration` and `GameLauncher` down into the
process manager call.
- Confirm that `LaunchRegistry` requires no changes, since it is PID-agnostic
and simply tracks whatever `GameProcessInfo.ProcessId` it is given once the
spawned process has been resolved.
===============================================================================

Task: 4

Implement Phase 4 of the plan: add a first-class validation signal for a missing
required anti-cheat runtime and update reference documentation.

- Add a new generic enum member (e.g. `RequiredRuntimeMissing`) to
`GenHub/GenHub.Core/Models/Enums/ValidationIssueType.cs`, following the naming
convention of existing members like `MissingFile`/`DirectoryMissing`.
- Extend `GameClientValidator` to add a `RequiredRuntimeMissing` validation
issue with Error severity when an EAC-era GeneralsOnline client is detected to
be missing the `EasyAntiCheat/` tree or the EOS setup binary. Reuse the existing
`issues.Add(new ValidationIssue { ... })` pattern so this flows through the
standard `OperationResult`/notification surfacing mechanisms.
- Update `docs/dev/constants.md` to document the new EAC bootstrapper/EOS setup
constants, noting that `EAC_LaunchGeneralsOnline.exe` is now the 60Hz launch
executable while `generalsonlinezh_60.exe` is a wrapped (non-launch) workspace
file.
- Update the GeneralsOnline description in the docs to note the EAC-era portable
layout, including the `EasyAntiCheat/` folder, `plugins/`, EOS SDK, and
supporting files.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

🔗 Related PRs

#261 - feat: implement content reconciliation system with CAS lifecycle management [merged]
#267 - feat: Implement copy profile functionality [merged]
#328 - feat(platform): make paths, manifests, and Unix workspaces platform-aware [merged]
#329 - feat(macos): add native host, installation detection, and CI [merged]
#332 - feat(launching): launch the native BGFX client against retail archives [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

🔗 Related PRs

#261 - feat: implement content reconciliation system with CAS lifecycle management [merged]
#267 - feat: Implement copy profile functionality [merged]
#328 - feat(platform): make paths, manifests, and Unix workspaces platform-aware [merged]
#329 - feat(macos): add native host, installation detection, and CI [merged]
#332 - feat(launching): launch the native BGFX client against retail archives [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[bobtista]

I verified the current GeneralsOnline portable against the live CDN.

• Version: 060526_QFE1
• Archive SHA-256: 5826aee8a0722d09bb07d67ff3c9314c86e866c24c7e64407a582b9545e96b52
• The calculated hash matches the CDN manifest.

EasyAntiCheat/Settings.json contains:

{
  "executable": "GeneralsOnlineZH_60.exe",
  "productid": "fc1cc0d936424212b645105f084d08b0",
  "wait_for_game_process_exit": "false",
  "hide_bootstrapper": "false"
}

The bundled EasyAntiCheat_EOS_Setup.exe supports:

• verify-installation <productid> — returns 0 when the product is installed. Unlike the install operations, its help text does not mark it as requiring administrator privileges; this should be confirmed during Windows validation.
• verify-and-install <productid> — verifies installation and, when required, spawns its own child process to request elevation. The parent returns the child’s exit code.
• --version — reports the bundled installer version.

This means GenHub does not need a custom runas implementation or its own EAC registry/service probe.

The compiled prerequisite should contain these expected values:

Product ID: fc1cc0d936424212b645105f084d08b0
Wrapped executable: GeneralsOnlineZH_60.exe
Installer: EasyAntiCheat_EOS_Setup.exe

Before running the installer, it should parse the workspace’s EasyAntiCheat/Settings.json and fail closed unless:

• productid matches the compiled product ID.
• executable matches the compiled wrapped executable.
• The installer and settings paths resolve inside the prepared workspace and correspond to manifest-backed files.

The prerequisite should then:

1. Run verify-installation fc1cc0d936424212b645105f084d08b0.
2. Continue immediately on exit code 0.
3. Otherwise run verify-and-install fc1cc0d936424212b645105f084d08b0.
4. Surface UAC cancellation, timeout, or another nonzero result as an actionable launch failure.
5. Persist no success state before completion, leaving cancellation and failure naturally retryable.

This should be compiled application behavior—IGameLaunchPrerequisite plus GeneralsOnlineEacLaunchPrerequisite—invoked after workspace preparation and before process start. Manifest-provided PostInstallSteps should remain unexecuted because the current manifest pipeline has no authenticated command-execution trust boundary.

The package also clarifies launch selection:

• wait_for_game_process_exit is false, so the bootstrapper does not own the game process’s lifetime. Explicit wrapped-process tracking is required; the current same-base-name launcher heuristic cannot find GeneralsOnlineZH_60.
• Both GeneralsOnlineZH.exe and GeneralsOnlineZH_60.exe ship in the portable. When the EAC wrapper exists, EAC_LaunchGeneralsOnline.exe must be the only launch target. Both game binaries remain non-launch workspace content.
• Direct _60 launch should only remain as fallback behavior for pre-EAC packages.

[undead2146]

This should be compiled application behavior—IGameLaunchPrerequisite plus GeneralsOnlineEacLaunchPrerequisite—invoked after workspace preparation and before process start. Manifest-provided PostInstallSteps should remain unexecuted because the current manifest pipeline has no authenticated command-execution trust boundary.

These are two different mechanisms, for two different problems. Both are needed, neither replaces the other:

1. Installation Instructions service — runs once, at content acquisition.

Use the InstallationInstructions property already on ContentManifest. It's already threaded through most of the delivery pipeline, and nothing executes it — a generic InstallationInstructionsService that enumerates and runs a manifest's PreInstallSteps/PostInstallSteps after delivery is the missing piece. This isn't GeneralsOnline-specific: any publisher may eventually need a one-time install-time action (run an installer, remove a stale file, rename an extracted artifact), so the service belongs at the pipeline level, not inside one factory. For GeneralsOnline, the only change needed at GeneralsOnlineManifestFactory.cs#L22 is to add a PostInstallStep that runs EasyAntiCheat_EOS_Setup.exe if not already installed.

Two things this needs that don't exist yet:

• InstallationStep's Command/Arguments are free-form strings today — that's unrestricted elevated command execution driven by manifest data, which is exactly the trust-boundary gap you're flagging. It needs a closed, typed Kind instead (e.g. RunVerifiedInstaller, RemoveFile, RenameFile) so any publisher's declared steps are auditable, not arbitrary.
• HttpContentDeliverer and FileSystemDeliverer currently only forward WorkspaceStrategy, not Pre/PostInstallSteps — they'd silently drop this today.

I've opened #342 for this, since it's genuinely reusable infrastructure, not something that should live only in GeneralsOnline's code path.

2. IGameLaunchPrerequisite / GeneralsOnlineEacLaunchPrerequisite — runs on every launch, staying in this issue.

GameLauncher.LaunchProfileAsync never re-invokes the deliverer after the first acquisition — every later launch just materializes files from CAS. Once GeneralsOnline's files are in CAS, any other profile, any later launch, or a workspace rebuilt after EAC gets removed by a Windows update all skip the one-time step above entirely. That means Installation Instructions service can never be the sole gate for something whose state can drift outside GenHub's content pipeline — this needs a per-launch, compiled check regardless of whether #342 lands first.

So: #342 (generic service, tracked separately) gives GeneralsOnline its one-time EAC install at acquisition time; this issue keeps the launch-target fix, explicit process tracking, and the always-on GeneralsOnlineEacLaunchPrerequisite gate. Neither one is sufficient alone.