stascorp/rdpwrap

1. This repository is a Windows-only RDP enablement toolkit centered on a wrapper DLL. The wrapper sits between Service Control Manager and Terminal Services so termsrv.dll stays untouched while the system behaves like it supports Remote Desktop Host and concurrent sessions.

2. The main runtime component is the wrapper library itself. There are two implementation lines:

- src-x86-binarymaster for the Delphi x86 build

- src-x86-x64-Fusix for the C++ x86/x64 port

Both are focused on the low-level hooking/wrapping logic and ship as the core binary used by the rest of the tools.

3. Version-specific behavior is externalized into INI-based configuration, not hardcoded in the DLL. The files under res/ — especially rdpwrap.ini and rdpwrap-arm-kb.ini — act as the support matrix and patch/offset database for specific termsrv.dll builds. This is the key data boundary in the system.

4. src-installer is the packaging and deployment layer. It builds RDPWInst.exe, which handles installation, uninstall, updates, and unattended deployment. The repo also includes WiX source in res/RDPWInst.wxs, indicating an MSI packaging path in addition to the executable installer.

5. The top-level batch scripts in bin/ are operational entry points for users and automation:

- install.bat

- uninstall.bat

- update.bat

These are thin wrappers around the installer workflow and are meant for admin execution on the target machine.

6. src-rdpconfig is the configuration UI. RDPConf.exe provides a GUI for checking wrapper status and changing supported settings such as session behavior and related policy values. The presence of LicenseUnit and the main form units suggests a classic Delphi desktop app with bundled diagnostics and configuration editing.

7. src-rdpcheck is a minimal test client. RDPCheck.exe is not a full-featured remote desktop client; it exists to verify that loopback RDP works locally. The README notes it uses 127.0.0.2 and is intentionally limited compared with mstsc.exe.

8. The runtime data flow is: installer deploys the wrapper and supporting files, then the wrapper consults the local INI to determine whether the current termsrv.dll build is supported and which offsets/settings to use. If the build is unknown, the system shows [not supported] until the INI is updated.

9. Update flow is separate from installation. The repo supports an “online mode” where the installer can fetch the latest INI from GitHub, and update.bat refreshes support data without rebuilding binaries. This makes the INI repository the main mutable compatibility layer.

10. The config tool and checker are operational consumers of the same underlying wrapper state. RDPConf reads status and exposes diagnostics; RDPCheck validates local connection behavior; both depend on the wrapper being installed and configured correctly.

11. Build/tooling is split by language and target:

- Delphi projects (.dpr, .dproj) for the installer, checker, config tool, and the x86 wrapper

- Visual Studio C++ solution/project files for the x86/x64 wrapper port

- WiX source for MSI packaging

This repo is therefore a multi-toolchain Windows desktop codebase, not a single unified build system.

12. Architecturally, the important boundaries are:

- low-level wrapper code vs. version data in INI

- installer/deployment vs. runtime wrapper

- diagnostics/configuration UI vs. functional test client

- local machine state vs. online compatibility updates from GitHub

That separation is what makes the project maintainable across many Windows builds without changing the core DLL every time.