Ivyware/Platforms
Platforms & languages
One source tree builds the kernel and the store on Windows and Linux, with I/O completion ports and io_uring behind a single interface. One flat C ABI, one macro-free facade and one COM server put a hub within reach of C++, C, Java, C#, PowerShell, VBScript, VBA and anything else that can create an object. Hub peers written in Java, PHP and browser JavaScript join the same address space over WebSocket.
And a store written on one operating system loads on the other with no conversion, because the image is byte-identical. That claim has a hash.
Each card names the route and what has been verified on it. Nothing here is a plan: every entry has an example tree that exits with the number of failed checks, and the number is zero.
A Msgcore store is one contiguous, offset-addressed heap, and the strings inside it are pinned to UTF-16 code units regardless of what the host calls wchar_t. So a store written by the Windows build and one written by the Linux build from the same program are not merely compatible. They are the same bytes.
Golden test
The cross-platform golden test writes the same store under MSVC x64 and under GCC 15 on Linux and compares the files. Same length, zero differing bytes, same SHA-256. It runs clean under AddressSanitizer and UndefinedBehaviorSanitizer on the production shared object.
Width
Every wide-character entry point has a UTF-8 twin. Inside the image the string width does not move; at the API boundary a caller picks whichever encoding its language already speaks. Astral characters survive the round trip as surrogate pairs on both platforms.
Sentinel
An endian sentinel travels with every image and doubles as its layout generation. A store from a different byte order or addressing width is refused with a reason rather than silently followed into the wrong offsets.
The kernel was built on Windows I/O completion ports: one port per pump thread, overlapped reads and writes, a completion key per connection. The Linux port keeps that model exactly and puts io_uring under it, so the routing code above the platform layer is the same source on both.
| Concern | Windows | Linux |
|---|---|---|
| Completion model | One IOCP per pump thread | One io_uring ring per pump thread; completions carry the same key |
| Wake a pump from elsewhere | PostQueuedCompletionStatus | Multi-producer queue plus eventfd |
| TCP | WinSock, ConnectEx, AcceptEx | Sockets through the ring |
| Local pipes | Named pipes with a protected DACL, remote clients rejected | AF_UNIX sockets in a mode 0700 directory |
| Serial | COM ports, overlapped | termios |
| Cryptography | Windows CNG | OpenSSL 3, pinned to CNG by a known-answer test |
| Running as a service | Service control manager, event log | systemd unit, sd_notify, journal |
| Build | Visual Studio 2022 projects, authoritative for the Windows product | CMake presets, GCC or Clang, ASan, UBSan and TSan configurations |
| Strings | UTF-16 wchar_t | UTF-16 pinned in the image; char16_t at the boundary |
Same numbers, independently. Ten thousand hubs on four worker threads open eleven descriptors before and eleven after on Linux, because a hub is a mailbox and a strand, not a thread and a socket. The Windows build was measured to the same two numbers first. Thread-per-peer is not a cost on either platform.
A hub does not have to be C++. Peers written in Java, PHP and JavaScript implement the same routing rules over the same hierarchical addresses, and a front door built from the C++ kernel serves them to the web.
Specified
The wire frame and the store image are written up as format specifications with a canonical form, and a corpus of conformance vectors is generated from the C++ tree and read, never copied, by every other implementation.
Reproduced
Clean-room re-implementations of the message kernel in Rust and in Zig, written from the format documents alone, reproduce the fourteen conformance vectors byte for byte on the first run, on Linux and on Windows. A format two strangers can reproduce is one you can keep for decades.
Continued
Those ports are a research track that informs the C++ product, and they are described here as exactly that. What ships is the C++ kernel and store on Windows and Linux, with the bindings above. What the track proves is that the formats do not depend on one compiler's idea of a struct.
| Component | Windows | Linux | Shape |
|---|---|---|---|
| Msgcore | VS 2022 v143, x64 and Win32, Debug and Release | CMake, GCC 15 or Clang, x86-64 | MFC extension DLL or static archive; shared object or static archive |
| TargetCore | VS 2022 v143, x64 and Win32, plus static-library variants | CMake, io_uring, liburing 2.5 or later on kernel 6.1 or later | DLL or static archive; shared object or static archive |
| TargetFacade · MsgFacade | VS 2022, x64 and Win32 | Facade ABI is platform-neutral; the Linux build consumes the flat C ABI today | DLL with one exported factory |
| TargetCom · MsgcoreCom | ATL in-process servers, per-user registration, no elevation | Not applicable | Dual interfaces, connection points |
| P2PeerWeb | Reference build only | Release target: CMake, systemd, ACME | One process, many sites |
| Chartboard | Windows 10 or later, x64, Python 3.11 bundled | Not applicable | Desktop application |
| Java, PHP, JavaScript peers | JDK 22+; PHP 8.1 to 8.5; any modern browser | Same | Maven, Composer, ES modules |
One rule about linking, on both platforms. Every module in one process must reach Msgcore the same way, all importing the one shared library or exactly one module absorbing the archive. Mixing the two compiles, links, runs and then corrupts data, because an offset minted against one copy's heap resolves against the other's. The Msgcore reference says why.