[PROJECT/RESOLVER] Discuss Resolver approach in relation to restricted compatibility to MSVC2005

[TheRedDaemon]

NOTE: This discussion entirely depends on what we do if it turns out we need different compilers for different parts.

---

This one is created in relation to #91 and only relevant should we try to handle non-MSVC2005 code, if it exists in an amount we want to handle.

Fundamentally, the resolvers as they are now rely a lot on the way MSVC2005 behaves, a lot of undefined behaviour also.

Attempting to use the current codebase with another older compiler (MSVC2002/MSVC7.00) results in a lot of first preprocessor, then compiler errors, that are not easily fixed, since MSVC2002 had a lot of template problems and I assume the older compilers are even worse.

This issue is therefore to discuss the case and what to do in this case. Multiple options exists and they do not even have to be general if parts of the code need to be split out. A general approach however makes the project more cohesive.

• Reworking the resolvers:
  • Likely a mess
  • MSVC2002 already falls over in case of nested template arguments and requires a very flat hierarchy, additionally is has a very broken template specialization.
  • The preprocessor works worse and has a lot of issues with the current macros.
  • That would be something someone else (then @TheRedDaemon) would need to try, since passing function pointers through as template parameters seems fundamentally broken and it would require a new system.
• Reducing scope, focus on detouring
  • Basically remove the wrapper function
  • Might still not work nicely with older compilers, but less functions means more reasonable scope
  • That would be something someone else (then @TheRedDaemon) would need to try, since passing function pointers through as template parameters seems fundamentally broken and it would require a new system.
• Switch approach in general
  • Very annoying at this stage
  • We had other methods in development that do not rely on templates
  • Even Macro based methods could be used
    • Macro calls can not define macros
    • Instead of delegating to a template, the macro would instead create the call structure that returns the ptr directly
      • Required information would be: FuncPtrType, CALL_CONVENTION, implemented, gameAddress, funcAddress
      • Wrapper would only be possible if FuncPtrType specializations works to properly extract the type.
    • It might be possible to receive full functionality using a single macro base structure that in addition to the config (true, wrapper) takes the return, the number of parameters and all parameter types. While big, it could just generate the static structure required.
• Mixture of the mentioned ways
• Drop resolver in general and handle as default reccmp project (no dll support in this case).