[PROJECT] Decide on repo and source code structure

[TheRedDaemon]

While my branch demo-visual-studio-build-test has outgrown its name, it was still just a testing branch.

We still have to decide on the "final" structure of the project folder.
Moving any reimplementation code into a src folder is one thing, but CMake also would need to be configured to properly use everything from it.
There is also the question whether the parts I added should keep there names an positions once our real main branch it build up.

This issue is meant to cover this task.

[TheRedDaemon]

I am not sure if this fits here, but I am wondering on how to sort the "resolver" logic together with struct declarations and the reimplementations. If there are no changes of concept, one "system" basically has the following parts:

• The struct and function declarations
• The struct proxy reference declaration (StructResolver)
• The function proxy reference declaration (FunctionResolver)
• The struct reference definition (only for EXE target)
• The function implementations/definitions (using the function and struct proxy references instead of the direct reference)

In my test-branch I tried to split them, but I am wondering if it makes more sense to use a simple compact file approach:

• The header (.h) get the struct and function declarations (1), the struct proxy reference declaration (2) and the function proxy reference declaration (3) in this order
• The implemenation file (.cpp) will receive the struct reference definition (4) and the function implementations/definitions (5), although I am not sure about the order. Maybe the struct definition should go last, since it is bound the happen in the last phase of the project?

[gynt]

What I currently had in mind was multiple files for the "system". See here: these templates are used by this. Note the ones starting with Class, they form one system. Every class has its own hpp file and a subdirectory with hpp and cpp files.

[TheRedDaemon]

Ok, before I misinterpret anything:
Are those templates created in a generic way to support general Ghidra exports, or with the your original plan for the reimplementation method in mind? Or something else?

[TheRedDaemon]

Answer received during a conversation with gynt:

The templates I referenced on GH are for my approach, which targets supporting copy-paste decompiled code from ghidra

We will see how we go on about this.
But if I get you right, then you developed the general logic to export the Ghidra structures, etc.
So, in the end, I assume we need to decide how one "system" should work/look under the consideration of the template proxy tools.
Regardless of the chosen structure, the step after that would be adjusting the templates to generate the files for the project.

I would still throw my "packed" approach in the ring, at least for every singleton based structure. It would allow to handle less headers and definition files for them, since every position that needs access to them would import the header of "SingletonA", and would receive:

• The declarations
• The Struct reference(s)
• The function proxies
  Assuming we do not get unwanted and not yet discovered bugs of the proxy logic, singleton usage would go down to one header. Downside would of course be how "big" they could get, but I would find this acceptable for a reimplementation. Functions will only be added if we missed them in the code so far, after all.
  Downside, should we go with the template proxies, we would really need to decide on the naming, and I am not sure if it would be possible in any way to replace the calls inside the functions with their proxies. This might end up as "manual" task (depending on once automation tools).

Enums should likely get their own files unless they are very much bound to their singleton, but attaching them would likely be manually.

Simple data structs without logic could be sorted to their "singleton", should they have one, but this might end up being case by case.

Same could be said about non-member functions. They could be grouped if it fits, but this would also likely be manually.

Now, @gynt, whats your opinion? 🙂

[TheRedDaemon]

The current plan regarding the general files structure, based on a discussion between me and @gynt (feel free to correct me, if something is wrong):

• Almost any part receives its own file, with multiple contents being the exception. So the file types are:
  • Single Struct declaration (Header)
  • Single Function declaration (even for member functions) (Header)
  • Multiple Struct Resolver Declarations of the same type (Header)
  • Single Function Resolver Declaration (Header)
  • Multiple Struct Resolver instance-Function definitions for the Struct Resolvers of the same type (Implementation)
  • Single Function Resolver Definition (Implementation)
• The struct resolvers are an exception to the single content rule.
• The #include-Logik works in general like this:
  • Static Function:
    Function Declaration is included by FunctionResolver is included by Function Definition
  • Member Function:
    Struct Declaration is included by Function Declaration is included by FunctionResolver is included by Function Definition
  • Struct Instance:
    Struct Declaration is included by StructResolver is included by Struct Instance Method Definition OR Function Definition
• The definition files will only ever include resolver files of
  • current struct for structs
  • current function and used other functions or structs for functions
• Excluded in this listing are currently utility and information files, which are included as needed, like:
  • Resolvers
  • Address Enums
  • Other helper code

[TheRedDaemon]

@gynt : Just as a note: Once the method is finally decided, it might be a good idea to copy the hack.md table + the final decision somewhere into the project for documentation. A note regarding this is definitly part of this task.