Remove blowfish.dll dependency

[ZivDero]

By default, the game's executable attempts to load blowfish.dll using COM and uses it for encryption and decryptio, which causes ceratin issues on modern operating systems. This PR removes the game's dependency on blowfish.dll.

This PR include code by CCHyper/tomsons26 from Vinifera which is derived from C&C Remastered Collection sources and is licensed under GPLv3, and as such, requires relicensing Phobos under GPL.

[github-actions]

Nightly build for this pull request:

• compiled-dll-1b241135d99283b255e0d17e07a0e2ee5ea00117.zip
  These artifacts will expire in 90 days and will not be available for download after that time.

This comment is automatic and is meant to allow guests to get latest nightly builds for this pull request without registering. It is updated on every successful build.

[chaserli]

• It should be discussed whether straws and pipes should be put into yrpp, and if yrpp should change its license
• iirc BF in BlowStraw and BlowPipe were something like BlowfishEnginePtr * and had a COM interface. So I assume you're redefining these 2 classes, then you might just use normal smart pointers.

[ZivDero]

• It should be discussed whether straws and pipes should be put into yrpp, and if yrpp should change its license
• iirc BF in BlowStraw and BlowPipe were something like BlowfishEnginePtr * and had a COM interface. So I assume you're redefining these 2 classes, then you might just use normal smart pointers.

1. IMO they should not; YRpp contain bindings, not reimplementations, and this isn't even present in gamemd.exe
2. What's the point? This is vanilla code, which works fine. I see no significant reasons to alter it in any way. ALso, it might cause issues, because the memry is being deleted by the game's code, but by our come, so we need to use the game's memory allocator.

[chaserli]

2. What's the point? This is vanilla code, which works fine. I see no significant reasons to alter it in any way. ALso, it might cause issues, because the memry is being deleted by the game's code, but by our come, so we need to use the game's memory allocator.

If my analysis were correct, BF in blowstraw/blowpipe were something like BlowfishEngine** not BlowfishEngine*, and the size was 0x1099. Allocation/deallocation were handled by blowfish.dll instead of gamemd. Here you've taken over the entire process so you can use local allocator.

[ZivDero]

2. What's the point? This is vanilla code, which works fine. I see no significant reasons to alter it in any way. ALso, it might cause issues, because the memry is being deleted by the game's code, but by our come, so we need to use the game's memory allocator.

If my analysis were correct, BF in blowstraw/blowpipe were something like BlowfishEngine** not BlowfishEngine*, and the size was 0x1099. Allocation/deallocation were handled by blowfish.dll instead of gamemd. Here you've taken over the entire process so you can use local allocator.

Actually, that's not the case, which is something I learnt experimentally. Since the code was borrowed from Vinifera, it originally contained new, which I was forced to replace with GameCreate after the game crashed in vanilla unpactched code attempting to free memory.

Let's just leave legacy code as it is, there is 0 need to any anything about it.

[ZivDero]

I've gone ahead and
a) Removed the replacements for BlowStraw and BlowPipe, and instead patched the places where BlowfishEngine is allocated.
b) Replaced blowfish.h and blowfish.cpp with those from the Red Alert sources, with minimal adjustments.

Note for @chaserli : It is absolutely valid to replace the COM proxy with the actual class, the only thing that needs to be taken into account is the memory allocation. Having done what I did, it works just fine.

[Metadorius]

Where's the actual license change? :P

[ZivDero]

Where's the actual license change? :P

#1567