Add comprehensive Windows 11 25H2 and 26H1 support plus latest Windows 10 updates#4062
Add comprehensive Windows 11 25H2 and 26H1 support plus latest Windows 10 updates#4062sjackson0109 wants to merge 53 commits into
Conversation
Major Updates: - Updated timestamp to 2026-01-25 - Added missing patch code 'mov_eax_1_nop_2' for newer Windows builds - Complete Windows 11 25H2 support (builds 10.0.26100.6899 through 10.0.26100.7623) - Windows 11 26H1 Insider Preview support (builds 10.0.28000.x) - Latest Windows 10 configurations for recent security updates New Windows 11 Builds Supported: - 10.0.26100.6899, 10.0.26100.7051, 10.0.26100.7262 - 10.0.26100.7271, 10.0.26100.7296, 10.0.26100.7309 - 10.0.26100.7344, 10.0.26100.7523, 10.0.26100.7535 - 10.0.26100.7623 (latest January 2026 build) - 10.0.28000.1340, 10.0.28000.1362, 10.0.28000.1371 Fixes: - Resolves 'Not Supported' errors for Windows 11 25H2 users - Addresses issues stascorp#4061, stascorp#4060, stascorp#4059, stascorp#4056, stascorp#4049, stascorp#4042, stascorp#4036 - All configurations verified by community testing Technical Details: - All configurations include proper SLInit blocks - Full x64 support with correct offset mappings - Community-verified configurations from trusted contributors - Future-ready structure for easy addition of new builds Closes: stascorp#4061 Related: stascorp#4060, stascorp#4059, stascorp#4056, stascorp#4049, stascorp#4042, stascorp#4036
|
and the latest is also fixed: |
- Complete step-by-step process for analyzing termsrv.dll - Tool recommendations and setup instructions - Function identification and offset extraction methods - INI configuration creation and testing procedures - Community contribution guidelines and best practices - Troubleshooting common challenges (ASLR, code signing, optimizations) - Advanced techniques for comparative analysis This documentation will help community members contribute new Windows build support more effectively and reduce the learning curve for reverse engineering RDP Wrapper configurations.
- analyse instead of analyze - licence instead of license (when used as noun) - optimisations instead of optimizations - reorganisation instead of reorganization - behaviour instead of behavior Maintains consistency with British English conventions.
|
@binarymaster - please can you review, test and approve this PR? |
|
See the timestamp of the last push into master branch (this is not going to change in near future). The project is officially on the community support, INI sections are provided on termsrv.dll version basis, one GitHub issue per build. |
|
Thx @sjackson0109 |
|
Just for your info. |
|
@kuronekonokuro @binarymaster Requiring one pull request per offset does not reduce risk or improve code quality. It increases process overhead without adding meaningful control. Review effort scales linearly with the number of pull requests, while the technical change remains identical in nature. This creates unnecessary friction and actively discourages contributors from submitting fixes, particularly when the work is repetitive and mechanical. Fragmenting this work across multiple pull requests also weakens traceability. A single consolidated change set makes it easier to understand what is currently supported, what was fixed at a given point in time, and how offsets evolve together. Multiple micro PRs obscure that context and make the project harder, not easier, to maintain. This pull request consolidates all currently missing offsets into one consistent update. The scope is clear. The changes are methodical. Verification is straightforward. If there is a specific technical or long term maintenance concern with merging this as a single PR, please state it explicitly so it can be addressed. Otherwise, I would appreciate a review and decision on the current submission. |
|
The problem is not about pull requests. |
|
if it's been given to the community to support - then why can't we (heavy contributors) take over the ownership role, and progress with PRs. Else an abandoned project should be marked abandoned - so no contributions/issues/discussions etc can then be raised/updated. this seems more half-way abandoned |
|
Massive shame, this tool is really useful. |
It's how it is. I have my own vision for the project future, stuff that I'd want to rewrite in a better way, using CI and covering with tests. But that's not going to happen in near future, there are other priorities.
There are long term community supporters, who participate in the Telegram support chat, and help with issues here. I usually grant moderation permissions to these people, still on my own preference though of course. I'm not planning to transfer ownership to anyone. |
|
I'll just use and advertise my fork, retaining the license and i'll improve it on my own time. thanks for not approving this pr and educating me in the fact it's a dead product. |
|
Thanks @doomsday616
… On 20 Feb 2026, at 03:38, Alex ***@***.***> wrote:
doomsday616
|
[WIP] Set upstream origin to GitHub repository
I had a problem after my Windows updated; I forgot to disable Windows Update. |
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
…-gen feat: CI/CD pipelines, auto-INI update, auto-offset generation
- actions/checkout@v4 → @v6 (Node.js 24 support) - microsoft/setup-msbuild@v2 → @V3 (Node.js 24 support) - Add FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true env for softprops/action-gh-release@v2, actions/upload-artifact@v4, and actions/download-artifact@v4 Agent-Logs-Url: https://github.com/sjackson0109/rdpwrap/sessions/6bd972e4-d369-4b43-bbe0-ea754bc00662 Co-authored-by: sjackson0109 <38080190+sjackson0109@users.noreply.github.com>
…de-24 Update GitHub Actions to Node.js 24
fix: bundle RDPWrapOffsetFinder exe and Zydis.dll into per-arch zips
fix: mark releases as non-prerelease so downloads badge resolves correctly
…setFinder.zip on every INI release
feat: commit RDPWrapOffsetFinder binaries to tools/ and use them in CI
# Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the commit.
# Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the commit.
Add src-csharp/ solution structure for the Delphi-to-C# migration: Solution & projects: - RDPWrap.sln (VS 2022, x86/x64 configurations) - Directory.Build.props (net8.0-windows, shared TFM/platform settings) - RDPWrap.Common.csproj - shared class library - RDPWInst.csproj - console installer (stub) - RDPConf.csproj - WinForms config UI (stub) - RDPCheck.csproj - WinForms RDP tester (stub) RDPWrap.Common helpers (all translated from Delphi source): - NativeMethods.cs - all P/Invoke: kernel32, advapi32, winsta.dll - ArchHelper.cs - arch detection + WOW64 redirection - RegistryHelper.cs - HKLM typed read/write with WOW64 view support - ServiceHelper.cs - SCM wrappers (start-type, start, state, enum) - FileVersionHelper.cs - file version reading via BCL FileVersionInfo - ProcessHelper.cs - ExecWait (hidden) + KillProcess - HttpHelper.cs - HttpClient replacing WinInet (sync + async) - ResourceHelper.cs - embedded manifest resource extract/read - IniHelper.cs - INI section presence check + support level - SecurityHelper.cs - SID/ACL (GrantSidFullAccess) + token privileges Also adds TODO.md tracking the full 44-item migration plan.
Complete translation of src-installer/RDPWInst.dpr (1,464 lines) to C#:
Program.cs — entry point
- Banner + usage text matching Delphi originals
- Arg parsing: -l / -i [-s] [-o] / -u [-k] / -w / -r
- OS version and architecture guards
- Dispatches to InstallerEngine
InstallerEngine.cs — all installer logic
- CheckInstall() registry TermService validation
- CheckTermsrvProcess() EnumServicesStatusEx loop + auto-start
- CheckTermsrvDependencies() CertPropSvc / SessionEnv enable
- CheckTermsrvVersion() file version + support-level classification
- TSConfigRegistry() fDenyTSConnections, EnableConcurrentSessions,
AllowMultipleTSSessions, AddIns sub-keys
- TSConfigFirewall() netsh advfirewall add / delete rule
- ExtractFiles() install-dir creation, ACLs, INI, rdpw32/64,
rdpclip, rfxvmt optional helpers
- SetWrapperDll() REG_EXPAND_SZ write + Vista reg.exe workaround
- ResetServiceDll() restore termsrv.dll on uninstall
- DeleteFiles() remove rdpwrap.ini + DLL + folder
- TryAutoGenerateOffsets() download OffsetFinder + Zydis, run, clean up
- CheckUpdate() date-compare INI, kill/restart svc, write new INI
- Install() / Uninstall() / Update() / Restart() orchestration
app.manifest — requireAdministrator UAC elevation
RDPWInst.csproj — ApplicationManifest + conditional EmbeddedResource items
Resources/README.md — documents expected binary payload placement
Workflow changes: - Rename publish-ini.yml -> build-and-release.yml; all refs updated - Split build-and-release.yml into 6 parallel jobs: build-dll / build-offsetfinder / download-sergiye (parallel), build-csharp (needs build-dll), build-msi (needs build-csharp), release (needs all) with environment gate - Add build-csharp.yml, build-cpp.yml, build-offsetfinder.yml PR checks - Add build-msi-check.yml: WiX syntax check on msi/** PRs - Add actions/cache@v4 NuGet step to all workflows using dotnet - Pin softprops/action-gh-release to SHA 153bb8e (v2) - Add concurrency guard, msi/** path filter, source path triggers - Extended INI validation: check LocalOnlyPatch+SLInitHook per section - Delete update-finder-tools.yml (superseded) Automation & tooling: - Add .github/CODEOWNERS (maintainer review on all PRs) - Add .github/dependabot.yml (github-actions, nuget, gitsubmodule) - Add tools/build-local.ps1, make-icons.ps1, sergiye-hashes.json, update-sergiye-hashes.ps1 - Add docs/BUILDING.md, CODE-SIGNING.md, SUBMODULE-UPDATE.md - Add msi/ WiX v5 project (RDPWInst.wxs, RDPWInst.wixproj, global.json) C# source: - Migrate all projects from RDPWrap.Common -> RDPWrap library - Add RDPCheck, RDPConf, RDPOffsetFinder C# projects - Dynamic version via Directory.Build.props MSBuild expression - Enable RestorePackagesWithLockFile; generate packages.lock.json for all 4 projects - Dynamic banner version read from assembly at runtime - .gitignore: ignore staged resources and msi build artifacts Legacy cleanup: - Remove Delphi source (src-installer, src-rdpcheck, src-rdpconfig, src-x86-binarymaster), old res/ directory, bin/*.bat, technical.txt, tools/RDPWrapOffsetFinder/ prebuilt binaries (now built from submodule)
stdafx.cpp had PrecompiledHeader=Create for Debug|Win32, Debug|x64, Release|Win32, Release|x64 but not Release|ARM64. MSBuild fell through to the ItemDefinitionGroup default of Use, tried to open a PCH that was never generated, and all four TUs failed with C1083. dllmain.cpp also lacked the empty-PrecompiledHeader override for Release|ARM64 (disabling PCH for that TU), inconsistent with the other three platforms where it deliberately does not use the PCH.
Feature/csharp migration
RDPWrapOffsetFinder.vcxproj uses \ for both include paths (zydis/include, zydis/dependencies/zycore/include, zydis/msvc) and for the linker's AdditionalDependencies (zydis/msvc/bin/ReleaseX*/Zydis.lib). When msbuild targets the vcxproj directly SolutionDir defaults to the vcxproj's own directory (RDPWrapOffsetFinder/), making all those paths point at a non-existent sibling - hence C1083 on every TU. Fix: build RDPWrapOffsetFinder.sln /t:RDPWrapOffsetFinder so MSBuild sets SolutionDir to the submodule root (src-csharp/RDPOffsetFinder/) where zydis/ actually lives. Zydis.dll is still compiled first via its own standalone vcxproj (which has no SolutionDir dependency).
- build-and-release.yml: build RDPWrapOffsetFinder via .sln target so \ resolves to the submodule root (src-csharp/RDPOffsetFinder/) where zydis/ lives; building the vcxproj directly sets SolutionDir to the vcxproj folder causing C1083 on all include and lib paths - RDPWrap.vcxproj: add missing Release|ARM64 overrides on stdafx.cpp (PrecompiledHeader=Create) and dllmain.cpp (empty, disables PCH) so the ARM64 DLL build does not fail with C1083 missing .pch
fix(ci+cpp): OffsetFinder SolutionDir resolution and ARM64 PCH overrides
fix(ci): build RDPWrapOffsetFinder via .sln not .vcxproj
- build-and-release.yml: \ now points to SolutionDir/<Platform>/Release/ (the .sln build outputs there, not <ProjectDir>/<Platform>/Release/) - build-offsetfinder.yml: build via RDPWrapOffsetFinder.sln /t:RDPWrapOffsetFinder so \ resolves to the submodule root where zydis/ lives; fix matching \ output path - Remove pull_request paths: filters from all four PR check workflows so required status checks always run on every PR and never block merges
The solution GlobalSection only declares Release|x86 and Release|x64. Passing Platform=Win32 to msbuild with a .sln target is invalid and causes: MSB4126: The specified solution configuration 'Release|Win32' is invalid. Add sln_platform (x86/x64) used only for the .sln invocation; keep Platform=Win32 for the Zydis vcxproj build and the output path lookup (vcxproj maps x86->Win32 for its OutDir so finder_plat=Win32 stays correct). Affects both build-offsetfinder.yml and build-and-release.yml.
The vcxproj has no custom OutDir so MSBuild uses the default: Platform\Config\. When building via .sln with /p:Platform=x86 the platform value propagated to the vcxproj is 'x86' (the CLI override wins over the solution's Win32 mapping), so the exe lands in x86\Release\, not Win32\Release\. - build-offsetfinder.yml: finder_plat: Win32 -> x86 - build-and-release.yml: exeSrc path uses SlnPlatform (x86) not Platform (Win32) Zydis.vcxproj is still invoked directly with Platform=Win32 - unchanged.
Confirmed by local build (linker /OUT: argument): - Win32: OutDir = Release\ (no platform prefix - MSVC default for Win32) - x64: OutDir = x64\Release\ Replace finder_plat/SlnPlatform guesses with explicit out_dir field: Win32 -> out_dir: Release x64 -> out_dir: x64/Release Also remove the temporary diagnostic step.
fix(ci): correct OffsetFinder exe output path and remove PR path filters
…256) WiX ICE24 rejects '2026.4.2' because MSI requires major<256 and 2026>255. Derive msiVer by stripping the century prefix: '2026.4.2' -> '26.4.2'. The full yyyy.M.d version is still used for release tag names and file names.
…gger - concurrency.group: 'release' -> github.workflow + github.ref_name Fixed group name caused any two runs to queue against each other regardless of branch. A manual dispatch would wait behind a failed push-triggered run. - Remove '.github/workflows/build-and-release.yml' from push path filters Merging a workflow-fix PR was auto-triggering a full release build every time. Release builds should only fire on source/INI changes or manual dispatch.
fix(ci): use 2-digit year for MSI PackageVersion
|
Please head over to my fork (sjackson0109/rdpwrwp)..SimonOn 4 May 2026, at 12:35, Mathias ***@***.***> wrote:derKosi left a comment (stascorp/rdpwrap#4062)
Yeah, sergiye Version seems a bit scetchy (I pull compiled it inside a VM and pushed the exe to VirusTotal.
May be a false positive though. Guess I Fork the original and mod it.
https://www.virustotal.com/gui/file/8a3d3c753f8261dc7569f2342ff874e9eb993c7836701531eaad7735f1d3c2b9/detection
@sjackson0109 Or could you provde the compiled exe so i don't need to add C++ Stack just for one tool? (and maybe a short Start here section, what to install and how to configure) ?
Cheers
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Overview
This PR adds comprehensive support for Windows 11 25H2 and 26H1 Insider Preview builds, along with the latest Windows 10 updates. All configurations are based on verified community contributions and testing.
Major Changes
Windows 11 25H2 Support (10.0.26100.x)
Windows 11 26H1 Insider Support (10.0.28000.x)
Latest Windows 10 Updates
Technical Improvements
Issues Resolved
This PR directly addresses multiple open issues:
Community Impact
Verification
All configurations sourced from:
Testing Recommendations
Note: This contribution represents months of community effort and addresses the most critical compatibility gaps affecting the majority of current Windows 11 users.