Prepare main branch for building using the exports by gynt · Pull Request #41 · sourcehold/OpenSHC

gynt · 2026-02-25T23:15:26Z

adds polyfill for C++03 style assertion checks on struct sizes
adds addresses and constants for shc steam version
fix issue with undefined3 in ghidra typedefs
improve reccmp setup for dual exe and dll checks
closes [ADDRESS] Manage function and struct addresses via enum #10

…stants and addresses

…her dll builds or exe builds

…ds it

TheRedDaemon · 2026-02-26T20:05:19Z

CMakeLists.txt

+# We could reinstate this later:
+## set(OPEN_SHC_DLL_DEST "${CRUSADER_DIR}/ucp/modules/${OPEN_SHC_NAME}-${OPEN_SHC_VERSION}" CACHE PATH "Path for OpenSHC.dll and OpenSHC.pdb")
+# For now it is easier to put it in a dll subfolder
+set(OPEN_SHC_DLL_DEST "${CMAKE_BINARY_DIR}/dll" CACHE PATH "Path for OpenSHC.dll and OpenSHC.pdb")


What is the issue that is solved here? Does reccmp not follow Symlinks?

I would contest that a bit, since it breaks the "debugging with game" flow.
The main reason for the DLL is the partial replacement and being able to run the game with it.
The flow "reimplement and check reimplementation state" could be done exe only.

There is no big issue. What it solved was that I couldn't find the dll file, as the path to the _original/ucp/modules/OpenSHC-1.41.0 folder makes the location of the dll file in an unexpected place for reccmp. I can also adapt reccmp of course. It is kind of the question of what should work "out of the box" and what is an advanced usage users need to configure. I had the thought that the reccmp flow on the dll should work out of the box (as building the exe doesn't work without all reimplementations for known functions). But I can see clearly the argument for "debugging with game" flow to be optimal.

What about adding a cmake statement to also copy the dll and pdb to the build-RelWithDebInfo/dll/ subdirectory that reccmp expects? Then the "debugging with game" is default but the other situation also works.

In this case I actually really want to have my cake and eat it, because I feel it should be possible.

So, I assume you tried to set the reccmp-build.yml of the dll to basically this:

project: . targets: STRONGHOLDCRUSADER: path: ../../_original/ucp/modules/OpenSHC-1.41.0/OpenSHC.dll pdb: ../../_original/ucp/modules/OpenSHC-1.41.0/OpenSHC.pdb

and it did not work?
Strangely enough it works with pointing to the game exe in reccmp-user.yml.

I would prefer two options and of them A:
A. It would just work.
B. Copying the files to another place for scan.

Can you ask the reccmp people again, why this does not work?
Unless it is actually an entirely different problem?

Let's go this route:

project: . targets: STRONGHOLDCRUSADER: path: ../../_original/ucp/modules/OpenSHC-1.41.0/OpenSHC.dll pdb: ../../_original/ucp/modules/OpenSHC-1.41.0/OpenSHC.pdb

I will test if it works just fine!

Tested it on my setup. Should work. If you manage to confirm this, please change the reccmp-build.yml and remove the change in the CMakeLists.txt.

README.md

TheRedDaemon · 2026-02-26T20:15:48Z

src/precomp/addresses-SHC-3BB0A8C1.hpp

Is this the hash of the game in the file name and every enum?

Also, I remember the discussion from here: #10
Did you conclude that a difference in naming between struct and func would not be helpful?

Yes, it is the file version independent way of getting a source of truth. Currently the steam exe is the source of truth, so this hash is in the enum. Future versions we support (if we ever go there, currently we decided against it), get their own file with their hash in the file name. The enum will consist of mostly the same enum names as the steam exe, but of course different enum values as addresess are different.

Regarding data versus code, the first .data section of the .exe starts at 0x59e000, so anything lower is func, and everything higher is struct. The usage context of the enum names is obvious enough to know the distinction, so I think it is fine without F and D

Alright. Add a "Closes #10" to the description then. This was what closes it directly with the merge, right?

You can resolve this comment here yourselve then.

reccmp/exe/run.bat

src/precomp/polyfills/assertion.h

src/precomp/common.hpp

TheRedDaemon · 2026-02-26T20:28:54Z

src/precomp/constants-SHC-3BB0A8C1.hpp

What is this enum for?
Are these really completely general, or should they rather be part of or be themselves a normal game enum?
I also feel the precomp is not be good place, since unlike the addresses or the Ghidra data types, these are not really "unchangeable" meta structures.

Why are they not "unchangeable"? Because we could expand the list in the future triggering a rebuild of all files? Or because we need to change it when we go 800x800 on maps?
I considered this file for constant integer values that are systematically used across the code but never used as an enum (e.g. in a switch-case statement). Constants we deduce from what they must have used as a macro or constant at some point in the source code but which has been completely inlined. What could be added is the amount of preallocated space for the unit array, etcetera.

I think I should have added more focus on the "meta structures" part.
At the moment I see the Precomp as place for the meta structures and basically Windows.h and would prefer to keep the game related logic out of it. So the addresses enum is fine (it is reasonably big anyway), but these constant would see use in the actual game logic and I would prefer it to be with other game code as well as only imported where they are really used.

Also, I think we should not have a Constants enum. If values are logically related and of an integer type (and also not stored somewhere, then we would have the size enum thing), then they should be grouped in a properly named enum, alternatively in a Namespace (which would need to happen if they are not integer or sized).
In any other case, they should just be "normal" constants.

In fact, maybe we should add these structures in a OpenSHC::Constants namespace anyway and maybe also split the files. The reality is that we choose the route of many files anyway.

I see your point, anything that pops up in actual code lines should be inside OpenSHC namespace. Makes sense!

.gitignore

TheRedDaemon · 2026-02-26T20:38:07Z

.gitignore

+/reccmp/**/*.json
+
+# Users should use git add --force for these:
+/cmake/openshc-sources.txt


I would prefer if we can create a flow that does not involve such git tricks.
What is the issue and intention behind this?

It is laziness. I usually do git add . and commit. However, the cmake/openshc-sources.txt that is upstream should reflect the required state for the latest buildable binary. Locally, it can have fewer, or additional lines, depending on what is being worked on (to reduce rebuild times). Auto adding the local developing state of that file when doing git add . would be annoying.

I can remove this feature on the upstream .gitignore and only use this trick locally. Fine by me!

Good. I think this trickery would be confusing for others.

Using an alternative source file though might be practical, if only for testing. I created this issue: #42

However, one thing: Is this branch still lacking an empty openshc-source.txt?

Good points. I will revert after the weekend and close this then. Further discussion goes into #42

I will revert after the weekend and close this then.

This confuses me. You already remove the gitignore trick. The only thing leaving me confused was the missing openshc-sources.txt?

Might already have a solution for #42 with #44

tools/mcp/decomphelper.py

sourcehold added 4 commits February 26, 2026 00:12

add polyfill for C++03 assertion style for structs, add enums for con…

0d45c1c

…stants and addresses

fix cpp-linter issues

fa805ea

split reccmp folder into dll and exe to permit easy comparison of eit…

fb48279

…her dll builds or exe builds

make OpenSHC.dll land in dll subdirectory such that reccmp easily fin…

ec2fc70

…ds it

gynt requested a review from TheRedDaemon February 25, 2026 23:50

sourcehold added 2 commits February 26, 2026 12:15

update mcp server to use new reccmp subfolder

904815b

refine gitignore to include reccmp/*.json and cmake/openshc-sources.txt

167edda

TheRedDaemon requested changes Feb 26, 2026

View reviewed changes

sourcehold added 2 commits February 26, 2026 23:48

[DOCS] clarify location of reccmp/exe/setup.bat and its usecase

7f2ce1f

document gitignore and remove git add force trick

1419e5f

Conversation

gynt commented Feb 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gynt Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gynt Feb 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheRedDaemon Feb 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gynt Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheRedDaemon Feb 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheRedDaemon Feb 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

gynt commented Feb 25, 2026 •

edited

Loading

gynt Feb 26, 2026 •

edited

Loading

gynt Feb 28, 2026 •

edited

Loading

TheRedDaemon Feb 28, 2026 •

edited

Loading

gynt Feb 26, 2026 •

edited

Loading

TheRedDaemon Feb 27, 2026 •

edited

Loading

TheRedDaemon Feb 28, 2026 •

edited

Loading