Update master and include Hook_XWACockpitLook as submodule

[morallo]

I propose some changes:

• Update master to the latest changes from Release_1_1_5 branch, to keep master as the main development branch and the one that should be used to start new features.
  • Once a version is released, create a Tag. For any bugfix/maintenance and backport of new relevant features, create a branch from the tag.
• Include Hook_XWACockpitLook as a submodule of this repo.
• Include the cockpitlook project in the VS solution and reference it from ddraw, to be able to call some of its exported functions from ddraw.dll (for a pending change related to tracking synchronization)

[Prof-Butts]

I've got essentially the same comment here: shouldn't I first do a PR from the Release_1_1_5 branch to master? Then I can add the CockpitLookHook as a project in a separate commit.

[morallo]

I already did it locally, trying to save you some time. I can change the PR target if you want :)

[morallo]

PR updated to the new master HEAD.

[Prof-Butts]

I just added a shared memory object to pass information between the CockpitLook hook and ddraw. We don't need to put both projects under the same solution anymore or do dynamic loading: since all DLLs share the heap, we can pass a void* between these two guys and share whatever we want.

[morallo]

I have removed the hook from the VS solution, but keeping the hook as submodule is interesting to maintain the versions in sync. The submodule changeset is included in the commit for the superproject, so any changes in the hook need to be commited to ddraw as a change.

But they still need to be built separately in Visual Studio.

What do you think @Prof-Butts ?

[Prof-Butts]

@morallo I had never heard of submodules before. How can I pull changes from, say, Jeremy's ddraw in the future? Is that going to change?

What happens when we modify something in the hook? Can I still push stuff into the hook's git repo separately?

[morallo]

A submodule is just a folder containing another git repository, and the .gitmodules file with the reference to the remote URL.

Since they don't exist in Jeremy's repo and don't touch any of his files, they should not generate conflicts when merging his changes into your version.

For him to merge any of your changes, he will probably cherry pick a commit. We just need to ensure that specific change does not touch the hook folder and .gitmodule file.

You still have to manage the submodule repo changes separately. It stays an independent repository that you need to commit on, pull or push, by entering the folder and using git.

If you change it, you will get an 'unstaged change' in the superproject, mentioning the new changeset for the hook.

You then git add Hook_XWACockpitLook to add the modified submodule folder to the staged files, and commit to record that the changeset/state for that submodule has been updated.

[Prof-Butts]

OK, let's do this. I'll learn more about submodules on the go :)