HadesMem and MinGW-w64

In an earlier post, I mentioned that HadesMem v2 now works under GCC and Clang (both of which use the MinGW-w64 runtime on Windows). This is still true, but the question now is, for how long? I have been trying recently to get GCC and Clang to play nice on a personal project of mine which uses a lot of COM and ATL code, but it seems to be a lost cause. There are entire header files which are missing from MinGW-w64, and a lot of COM APIs which are missing from the existing header files.

Up until now, supporting GCC and Clang in HadesMem has been a bit of a maintenance headache, but nothing that couldn't be overcome with some simple workarounds and #ifdefs. Now however, it seems that I need to pick between having full access to the Windows APIs, or having support for MinGW-w64 (I simply don't have the time nor the motivation to add support for all these APIs to MinGW). For the lower level components it seems that MinGW-w64 contains everything I need, but problems quickly arise when trying to write higher-level code (using the Shell COM interfaces, ATL, WTL, etc), which is of interest to me for HadesMem because I'd like to write a couple of basic GUI tools on top of the library.

So, I guess the point of this whole post is to find out whether there is actually any interest from library users in support for compilers other than MSVC. If there is please let me know, using whatever method suits you best (the comments, email, etc). I haven't made up my mind yet, but it seems that the drawbacks are very quickly piling up against the benefits...

EDIT:

It is of course possible I could simply continue to support all compilers for the library portion, then make the tools written on top of it MSVC-only, but then that becomes a pain when maintaining the build system. The other alternative is to simply 'suck it up' and rewrite all the code (where possible) to support MinGW, and where it isn't to actually fix/extend MinGW, however I'm not sure I really want to put that much work into a platform I don't really use other than to make sure my code is as portable as possible.

[Planetside 2] v0.483.26.180118 Update

A new and rather large patch was released last night, and I was curious whether they had fixed the teleport hack so I updated it. They haven't...

Download for v0.483.26.180118.

[Planetside 2] Teleport and Below Ground Hack

Abused this for a couple of days, now I'm bored with it. This is just a very basic teleport hack, and also a hack that will let you either walk under the ground or 'skywalk'.

The main reason I'm releasing this is that Planetside 2 is really boring, and that this hack was so easy to write that I wouldn't be surprised if 50% of Planetside players were already teleporting around. I could probably teach my cat to find the player coordinates and change them with a memory editor.

It's all pretty straight forward, run the hack from a command prompt once you've launched the game, then use the following controls:
Numpad+ = Walk higher
Numpad- = Walk lower
Numpad/ = Reset height
Numpad* = Teleport to personal waypoint

The teleport hack is a tad buggy because occasionally the pointer(s) I'm using to read out the personal map waypoint will decide to change. Just go into your map then do a "Clear Waypoints" then reset it to whatever waypoint you want and it will work again.

As for the walking height hack, I have no clue what's going on there as far as the physics engine is concerned. I found it by accident whilst looking for something else so I didn't bother investigating what's actually going on. It's really weird and buggy if you try to walk underneath vehicles etc (read: it will teleport you up in the air and likely kill you), but if you're careful you should be able to go on an insane killing spree. For example, I went 350-0 on my server before getting bored and killing myself. It's a little glitchy though when you're walking under the terrain, so you'll need to practice and learn where you can and can't go, how to get past certain walls (usually just go really really low then pop back up), where to get ammo down (typically inside rocks, on stairwells, etc, you normally don't need to come back up to ground level to get it down), etc.

Anyway, code and binary below. The code is disgusting and I don't care (code is bad and I should feel bad, etc). I whipped it up really quickly as a PoC for some friends, then got bored with it when we realized how boring Planetside was. This hack has survived at least 3 client patches that I'm aware of without needing to be updated, so it should be fairly 'low maintenance'. Nevertheless, don't expect updates from me, the hack is extremely trivial to update for even the most dimwitted of monkeys (any old memory scanner and debugger should do). That being said, if you actually go to the trouble of finding a more reliable way to read the personal waypoint (there's probably an engine function for it, but I haven't looked) or find something else useful please do post it here for others.

Now I'm rambling to the point where this post has nearly taken longer to write than the actual hack, so I'll shut up now...

Enjoy!

Download:
Planetside2 v0.473.22.176761 **SHIPPING**
Planetside2 v0.483.26.180118 **SHIPPING**


14/12/12:
Uploaded updated hack for new client patch (Planetside2 v0.483.26.180118 **SHIPPING**).

HadesMem v2 Compiler Support

So, it's been a while since I've started work on HadesMem v2 and I wanted to give a status update. So far everything is going relatively smoothly... I'm still working on rewriting and reintegrating all the v1 components (fixing bugs and adding minor features along the way), however one of the biggest changes made so far is that HadesMem now compiles and runs (examples and tests) on every major C++ compiler for Windows. This means that HadesMem now works under the latest versions of MSVC (11), Intel C++ (13), GCC (4.7), and even Clang (3.1)! Please note that support for compilers other than MSVC is still considered experimental and subject to change, but I'm quite happy with the state of things now, so I believe I will be able to maintain compatibility across all compilers from this point onward (however when v2 is finally 'finished' the required compiler versions will probably be newer than those listed here).

More information on other new developments to come Soon.

Boost Addressof Warning/Error under Intel C++ 13

Another quick post to provide a patch which fixes a warning in Boost.Utility/Addressof. This warning occurs under Intel C++ 13 (and probably other versions) when compiling at the highest warning level. Unlike other warnings though, it apparently cannot be disabled with #pragma directives, so if you compile with warnings as errors it results in an error which you cannot disable.

The root of the problem seems to be that the compiler thinks an rvalue is being passed to a function taking a non-const reference, however in this case it is a false positive (the rvalue has an implicit conversion operator which returns a reference to the underlying lvalue which it is wrapping). I have worked around it by turning the wrapper into an lvalue and passing that instead.

Boost.Test Warning under Intel C++ 13 Beta Update 2

Just a quick post to provide a patch to fix a warning that I was unable to silence with pragmas when using Boost.Test under ICC v13 Beta Update 2 (does not happen on all uses of Boost.Test, I'm unsure of the exact trigger).

HadesMem v2 Work Has Started

I have finally returned to working on HadesMem, and at long last I am starting work on v2. This means I will hopefully be able to address some of the long-standing requests that require breaking changes to fix. Because of this I recommend you continue to use v1.6.0 until trunk is more stable. For the time being, trunk is going to be a bit of a minefield, but it will be worth it in the end. ;)

Boost.Signals Compile Error under VC11 Developer Preview

To keep with the theme of providing patches for issues in Boost I have discovered which are yet to be fixed upstream, I have one final patch which addresses a compilation error in Boost.Signals under VC11.

This patch is extremely trivial, as there is already MSVC specific workaround code in place for this particular error, however it only covers up to VC10. The patch simply bumps the version number to that of VC11.

Boost.Interprocess under GCC via MinGW-w64 Pedantic Warnings

When compiling projects consuming Boost.Interprocess for Windows using GCC via MinGW-w64, if you have both pedantic warnings and warnings as errors enabled, then a warning is generated in Boost.Interprocess that is impossible to disable via the GCC diagnostic pragmas.

I am providing a quick and dirty patch to work around that. Be warned however that the header in question is a mess, and full of 'suspect' code. This patch does nothing to address that, it simply works around the warning in the simplest manner I could see (another alternative would be to perform the cast responsible for the error with a union instead of a reinterpret_cast, however that just adds to the standards conformance violations).

The missing blog Part #10b?

Recently I have been working on a project relating to keyboards and the translation of keyboard input to its associated character output. Basically, I want to cache all possible input combinations so I can look them up at runtime without having to call the ToUnicodeEx API with potentially 'tainted' state, which was causing problems with dead keys when I called it from a keyboard hook (or other similar mechanisms).

I have been working on this with the help of Michael Kaplan's blog and his amazingly detailed and helpful series Getting all you can out of a keyboard layout. So far I have just been porting the code to C++, one step in the series at a time, to gain a better understanding of how everything works. When I reached part 10a however I noticed that there seemed to be a missing part 10b. I raised this with Mr Kaplan on his blog and he has graciously agreed to write the final piece of the series.

No code from me yet (I do wish however to eventually post my port of the code to C++), but I wanted to give a shout-out to Mr Kaplan and encourage others to check out his awesome blog. If you're interested in i18n/l10n, languages, keyboards, etc you will probably find yourself going back and reading years worth of archives like I did.

Boost with Intel C++ (12.1.3.300) on Windows

Intel's standard library headers are disgusting and are committing the cardinal sin of defining macros which may interfere with user code (which in this case they have).

The problem is simple to repro:

#include <atomic>
#include <boost/shared_ptr.hpp>
int main() { }

Or:

#include <atomic>
#include <boost/thread.hpp>
int main() { }

This issue has been reported previously to Intel, but remains even in the latest version of the compiler (created and released well after the bug report):

I am using two patches locally, one for Boost.SmartPtr, and one for Boost.Thread.

The patches have been sent to the Boost developer mailing list, but I have not yet received a response. They are also on the Boost bug tracker as #6842 and #6843. They're pretty disgusting themselves, but at least compiling code using Boost on Intel C++ works now. At the very least they probably require a bit of extra wrapping to detect affected versions and configurations (e.g. v12 with C++0x mode).

I still get the feeling though that there is a better workaround, so if anyone has any ideas I'd love to hear them.

New Blog

As you may have noticed my site was down for some time and has now been moved to Blogger.

Long story short is that Wordpress is a fail that I don't have the patience to deal with, and I was also having trouble keeping away the occasional DDoS attacks I receive... So now it's Google's problem!

Hoping to get the old content imported when I get some spare time, but until then if you need anything desperately you can email me.

New content coming Soon™.