CydandClaude Fable 5
3fd637c58a
vPOD impersonates a Tesla game client (rpl4opt.exe / btl4.exe) so the Red Planet and BattleTech operator consoles can be exercised without real cockpit hardware. New net48 WinForms project under Console\vPOD: - MungaPodServer: the server half of the Munga control protocol (TCP 1501). The vendored MungaSocket is client-only, so this reimplements the identical framing ([16-byte header][12-byte base + body], dispatched by ClientID+MessageID) for the listening side, reusing the vendored message classes' WriteTo/BinaryReader serialization. - PodSimulator: the ApplicationState machine driven by the console's messages - answers StateQuery, reassembles the streamed egg and acknowledges it, and walks WaitingForEgg -> LoadingMission -> WaitingForLaunch -> RunningMission and back on Run/Stop/Abort/Suspend/Resume. - VPodForm: live display of listening/connection status, the colour-coded ApplicationState, an egg viewer (fields + summary), and a newest-first protocol log. A Red Planet / BattleTech toggle changes which ApplicationID the pod reports, live, so one vPOD stands in for either game. - PodArguments: parses the real client's launch flags (-net/-app/-lc/-mr/ -host/-res). Deployable from Manage Site -> Install Product: a catalog product in RedPlanet\Apps.xml (Game Client / Live Camera / Mission Review entries) plus pack.ps1, which builds dist\vPOD.zip laying out vPOD\vPOD.exe for the launcher to extract to C:\Games\vPOD. CatalogTests updated to 5 products / 11 entries with the four vPOD entry assertions (88/88 pass). TeslaConsole.csproj excludes vPOD\** from its **/*.cs glob; the project is added to the solution. Verified end-to-end over real TCP: a console-role client using the vendored MungaSocket drives connect -> WaitingForEgg -> stream egg -> (ack) -> WaitingForLaunch -> Run -> RunningMission -> Stop -> WaitingForEgg, with vPOD reporting the correct state at each step. MungaGame (what the console's game windows use) is a thin wrapper over MungaSocket, so this exercises the exact wire behaviour. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
TeslaConsole.DiffTests — differential equivalence suite
Verifies that the reconstructed TeslaConsole.exe (built from the decompiled
source in this repo) behaves identically to the original reference binary in
original/TeslaConsole.exe.
How it works
The suite loads each assembly into its own child AppDomain
(DifferentialFixture) and drives it through a MarshalByRefObject proxy
(Invoker). This is why the project targets net48 — AppDomains are a .NET
Framework feature. The original is the 4.11.3.37076 baseline; the recovered
build is the modernized 4.11.4.x line (same TeslaConsole assembly name, an
intentionally newer version). Because the two versions differ, the public-member
comparison strips Version= stamps before diffing — it compares type/member names,
not assembly versions.
Each child domain is given a probe directory (the recovered build's output, which ships every dependency DLL) so the original — which is distributed without its proprietary dependencies — still resolves its references for metadata inspection.
What is compared
-
Public API surface (
PublicApiSurfaceTests) Every public type and public member (signature-for-signature) exposed by the original must also be exposed by the recovered build. Compiler-generated members and property/event accessor methods are excluded — the README at the repo root notes those legitimately differ between a decompilation and the lost sources. -
Recovered-only characterization (
CatalogTests,BTGoldenEggTests) Features that were added in the reconstruction have no counterpart in the original exe, so these run against the recovered build only:CatalogTests— the data-driven product catalog reproduces the exactLaunchDatathe old hardcoded code emitted.BTGoldenEggTests— the newTeslaConsole.BattleTechmission builder is diffed field-by-field against two golden eggs captured from the original consoles (BattleTech/cavern.egg,BattleTech/TESTARN.EGG). The comparison is per-section and order-independent (the pod parses eggs INI-style; the two golden eggs themselves disagree on field order). Font-rendered name-bitmap pixel rows are excluded, but TESTARN's ordinal art — identical to the RP-inherited rows — is compared byte-exactly. Also covers theEggFileMessagewire framing (NUL-delimited ASCII, 1000-byte chunks, byte-exact reassembly), role-block de-duplication, the No Return mode (samescenario=freeforall, different role), and the shippedBattleTech\BTConfig.xmlcatalog contents.
-
Behavioral output (
BehavioralEquivalenceTests) The same deterministic, dependency-free methods are invoked in both assemblies over a battery of inputs and the results must match byte-for-byte:RPStrings.GetTimeString(mm:ss formatting + 0.5 s rounding)HostTypeHelper.Parse(...).ToString()(incl. invalid-input exceptions)PlasmaBitmaps.ConvertBitmap(1-bpp packing of a known pixel pattern)PlasmaBitmaps.GenerateString(full GDI text → 1-bpp plasma pipeline)RPMap/RPVehicleXML parsingSiteManagementwell-known application GUID constantsTuple.Create<,>generic factory
A negative-control test (
Harness_Distinguishes_Different_Outputs) proves the harness can actually see a difference, so a green run is never vacuous.
The project also carries two byte-compatibility guards — not original-vs-recovered comparisons, but checks that the modernized protocol/crypto stays compatible with the original binaries:
PodRpcProtocolTests— round-trips the framed-JSON RPC (Contract/PodRpcProtocol.cs) in-process: every request/response shape encodes and decodes back to the same values.SecureConfigCompatTests— asserts the source-builtOFBCryptoStreamproduces byte-identical ciphertext to the originalTeslaSecureConfiguration.dll, so the pod provisioning handshake stays wire-compatible.
Running
dotnet test tests/TeslaConsole.DiffTests/TeslaConsole.DiffTests.csproj
A project reference builds the reconstruction first, and the suite always tests
the most recently built bin/{Debug,Release}/net48/TeslaConsole.exe.
Scope / limitations
This compares deterministic logic. It deliberately does not drive the WinForms UI, the pod networking, secure-configuration, or hardware-facing code — those require the live console, its pods, and the proprietary services, and are not reproducible in a unit test. The API-surface test still asserts those types exist with matching signatures even though their behavior isn't exercised.