_Msgcore_UseExamples

Worked examples for Msgcore — the MSCS message content library: a self-describing tree of named, typed cells packed into a relocation-safe heap that can be saved, addressed by position, and shipped.

This repository holds four trees. They are not four different subjects — they are the same eight subjects, four times over, once for each way a caller can reach the library. That is the whole point of the layout: put the four side by side and the difference you are looking at is the binding, never the material.

There is no solution at this root, by design. Each tree builds on its own — different toolchain, different prerequisites, different failure modes — and a solution spanning all four would claim a build relationship that does not exist. Start in the tree you care about; its own README is the documentation.

The same list in all four trees, in this order. Each builds on the one before.

Every harness in every tree keeps the same exit-code contract, so one runner reads the same in all four:

Eight MFC-dynamic console harnesses written straight against the exported C++ classes (P3PmsgData, P3PmsgField, P3PmsgList, P3PmsgVect, P2PmsgMgr) and against the flat C ABI in Msgcore_c.h. They link Msgcore.lib, and the two networked ones link Targetcore.lib as well.

This is the reference tree: the other three are measured against it, and it is the only one that documents each harness in its own README — eight of them, linked from the tree README. Read it first.

Every harness rewritten on MsgFacade, the flat-vtable facade DLL over Msgcore's object model. Same eight subjects, same section order, same exit codes, so the two trees read side by side — and everything underneath changes: no MFC, no CWinApp, no stdafx.h, no kernel headers, no assert trap.

What it exists to show is that the facade's ABI 2 (paging, and the node value stack) really does cover the model, and what it costs to say the same thing through HRESULTs instead of exceptions.

Eight harnesses that reach the model through COM interfaces on MsgcoreCom, the ATL dual-interface server that sits over the facade, plus a late-bound PowerShell client under script\.

The distinguishing property, and the reason this tree is worth its weight: these executables link nothing of MSCS. Not Msgcore.lib, not MFC, not ATL — only ole32, oleaut32, uuid and a generated type-library header. If they pass, the COM surface is genuinely self-contained.

The same eight subjects in C#, over the same COM server, both early-bound by vtable and late-bound through IDispatch. Built by Roslyn csc out of build.ps1 — there is no .csproj and no MSBuild in this tree.

It is where the managed/native seam gets measured: what the CLR does to an HRESULT, what a COM-callable wrapper does to apartment marshalling, and which of those are properties of .NET rather than of the server.

Each tree builds independently and documents its own prerequisites. In outline:

cd DirectExamples ; .\run_all.ps1                  # build + run Debug
cd FacadeExamples ; .\run_all.ps1 -Config Release
cd ComExamples    ; .\run_all.ps1 -IncludeScripts  # also the PowerShell client
cd dotNetExamples ; .\run_all.ps1

Each run_all.ps1 builds its tree, runs all eight harnesses, prints a pass/fail table, and exits with the number of failures.

None of these trees builds standalone, and that is a property of the material rather than an oversight. Every path below is relative, resolved from a project file at <repo>/<Tree>/<Harness>/, and assumes this repository is checked out inside the parent MSCS solution as MSCS\_Msgcore_UseExamples:

Three leading ..\ and not two. Each tree used to be a repository of its own, sitting directly under MSCS\; combining them put every tree one directory deeper. .github/ci/check_repo_invariants.py pins these paths per tree for exactly that reason: a level lost in a move fails there, on a runner with no compiler, in seconds — instead of surfacing as LNK1181 on somebody's machine.

vsutils\ is not published anywhere, and Msgcore, MsgFacade, Targetcore and TargetFacade are private repositories. See CONTRIBUTING.md and the two workflows for what that means for CI.

Stated plainly, because a green tick that verified nothing is worse than no tick at all:

• ci.yml runs on every push and compiles nothing. It runs .github/ci/check_repo_invariants.py, which checks bookkeeping only: solution/project parity for both configurations in all three MSBuild trees, that every source named exists, that the pinned outward paths and the paths built in the .props files are unchanged, and that the shipped Markdown does not link to files that are gone.
• solution-build.yml is the one that really builds and runs, and it is workflow_dispatch-only because it needs sibling checkouts that cannot be supplied automatically.

The sibling repository _Targetcore_UseExamples is laid out the same way and covers the other half: moving messages between hubs rather than what is in one. Where a question here is about the mesh — hubs vs pumps, thread affinity, the login handshake — it is answered there, in ArchitectureFAQ.md, and is not re-explained in this repository.

Copyright 2026 Khrustal & Mann, MELBOURNE, VICTORIA, AUSTRALIA, 3000. Licensed under the Apache License, Version 2.0. See LICENSE for the full text.