HadesMem v1.0.0 (SemVer)

[Cypher]

As part of the move to finally move HadesMem out of the PoC phase I am in the process of a rewrite and am initiating semantic versioning.


The first version of this rewrite is now available. Unfortunately the only component completed at the moment is the ‘MemoryMgr’ class. That being said, it is now fully documented, and the existing API will remain stable until the next major version release. New minor and patch versions will be released regularly as new components are stabilized and have documentation written.


Post here if you have a component that you believe to be higher priority than the rest, and I’ll see what I can do about expediting its inclusion.


The new builds are available from SVN under /tags/vX.Y.Z, as well as from packages posted in the project page’s download section.


Keep in mind that the old builds with the full range of components are still available from SVN under /tags/Old/, and if you find a bug I should be able to fix it for you until the SemVer port is complete and the old builds are deprecated.

Project page: hadesmem - Windows memory hacking library - Google Project Hosting

[Serpious]

As part of the move to finally move HadesMem out of the PoC phase I am in the process of a rewrite and am initiating semantic versioning.


The first version of this rewrite is now available. Unfortunately the only component completed at the moment is the ‘MemoryMgr’ class. That being said, it is now fully documented, and the existing API will remain stable until the next major version release. New minor and patch versions will be released regularly as new components are stabilized and have documentation written.


Post here if you have a component that you believe to be higher priority than the rest, and I’ll see what I can do about expediting its inclusion.


The new builds are available from SVN under /tags/vX.Y.Z, as well as from packages posted in the project page’s download section.


Keep in mind that the old builds with the full range of components are still available from SVN under /tags/Old/, and if you find a bug I should be able to fix it for you until the SemVer port is complete and the old builds are deprecated.

Project page: hadesmem - Windows memory hacking library - Google Project Hosting

I think I read somewhere that hadesmem removed some features to increase stability.

Did I just dream that or did you actually do that?

If so, what features were removed?

[Cypher]

I think I read somewhere that hadesmem removed some features to increase stability.

Did I just dream that or did you actually do that?

If so, what features were removed?

Higher level components are removed whilst their lower level counterparts are being rewritten. They will be readded over the next month or two. Everything is still present under /tags/Old though.

[Cypher]

HadesMem v1.1.0

New Features

• Move support for MemoryMgr.
• Version macros.
• Documented copy/assignment/move constructors/operators for MemoryMgr.
• Added new Module APIs.

Bug Fixes

• Fixed build scripts for users who did not have BJam installed in their %PATH%. This was a bug introduced when Boost.Build changed BJam's name to B2.

Changes

• Improved compiler detection.
• Improved build scripts to allow architecture selection.
• Changed MemoryMgr::Call to use the new Module APIs for increased stability.
• Improved Boost build scripts to only build the libraries that are used by HadesMem. This results in a much faster build time.
• Updated Boost to latest trunk.
• Added build scripts for Intel. Please note that this platform is still unsupported (as per the documentation). The scripts are there so users can help with the porting process (as are the Clang scripts).

[Serpious]

Are you still looking for anyone who can program D3D10 and/or D3D11?

I do not wish to give you any false hope, since I do not jack about it, but I thought it might be worth mentioning.

[flo8464]

Very nice!
Prebuilt binaries, especially for the Python part, would be comfortable, you might add them.

[Serpious]

Maybe change the title to v1.1.0?

[Cypher]

HadesMem v1.2.0

New Features

• Added CreateProcess overload for argument lists (to ensure correct quoting).
• Move support for AllocAndFree.

Bug Fixes

• Ensure COM is initialized and cleaned up in CreateProcess.
• Fixed documentation for HADES_VERSION_FULL_STRING. Format is vXX.YY.ZZ, not vXXYYZZ.
• Fix critical bug causing problems opening processes other than the current process.

Changes

• 
  

[_Mike]

I believe I have found a bug..

in hades\Src\Memory\Memory\Detail\Process.cpp lines 40-59

      // Constructor
      explicit Impl(DWORD ProcID) 
        : m_Handle(), 
        m_ID(0), 
        m_IsWoW64(false)
      {
        // Open process
        if (GetCurrentProcessId() == ProcID)
        {
          m_Handle.reset(new EnsureCloseHandle(GetCurrentProcess()));
          m_ID = GetCurrentProcessId();
        }
        else
        {
          Open(m_ID);
        }
        
        // Set WoW64 member
        SetWoW64();
      }

Open() will always be called with pid 0

Edit:
Forgot to mention, I'm using the latest revision 1411

[Cypher]

I believe I have found a bug..

in hades\Src\Memory\Memory\Detail\Process.cpp lines 40-59

      // Constructor
      explicit Impl(DWORD ProcID) 
        : m_Handle(), 
        m_ID(0), 
        m_IsWoW64(false)
      {
        // Open process
        if (GetCurrentProcessId() == ProcID)
        {
          m_Handle.reset(new EnsureCloseHandle(GetCurrentProcess()));
          m_ID = GetCurrentProcessId();
        }
        else
        {
          Open(m_ID);
        }
        
        // Set WoW64 member
        SetWoW64();
      }

Open() will always be called with pid 0

Edit:
Forgot to mention, I'm using the latest revision 1411

Already reported by another user and fixed for v1.2.0 (see the Changelog - "Fix critical bug causing problems opening processes other than the current process").

From my WC:

      explicit Impl(DWORD ProcID) 
        : m_Handle(), 
        m_ID(ProcID), 
        m_IsWoW64(false)
      {
        // Open process
        if (GetCurrentProcessId() == m_ID)
        {
          m_Handle.reset(new EnsureCloseHandle(GetCurrentProcess()));
          m_ID = GetCurrentProcessId();
        }
        else
        {
          Open(m_ID);
        }

        // Set WoW64 member
        SetWoW64();
      }

Current work is being done under /branches/v1.0.0. Maybe you're using /trunk? I haven't merged back to trunk in a while, sorry about that.

Thanks for reporting.

[_Mike]

Already reported by another user and fixed for v1.2.0 (see the Changelog - "Fix critical bug causing problems opening processes other than the current process").
....
Current work is being done under /branches/v1.0.0. Maybe you're using /trunk? I haven't merged back to trunk in a while, sorry about that.

Thanks for reporting.

Yeah I was using trunk. In my inexperience with svn I thought that trunk always held the newest changes regardless of branches.
I'll switch branch then, thanks for the info.

[Cypher]

Yeah I was using trunk. In my inexperience with svn I thought that trunk always held the newest changes regardless of branches.
I'll switch branch then, thanks for the info.

Typically it does, but then again, typically version control systems are being used by more than one person, so pushing to /trunk then merging downstream makes sense. However when it's just me, committing directly to the branch I'm working from reduces my workload (and the less I have to muck with my VCS the more I can actually code).

Anyway, I've merged everything back to /trunk (it's currently being committed, give it a few minutes). Thanks again.

EDIT:

To clarify, typically /trunk is work on the next major version, and bug fixes and other non-breaking changes are merged into the stable branches. However given it's just me working on the project and the stable branch has only just started, there is no work yet on v2.0.0, so everything is currently being done on v1.0.0, which is in a branch.

If there was more than one dev then using /trunk would make sense, but when it's just me it's kind-of a pain in the ass to have to merge to a branch constantly.

[_Mike]

If there was more than one dev then using /trunk would make sense, but when it's just me it's kind-of a pain in the ass to have to merge to a branch constantly.

No worries, I just realized I can look at the commit log on google code to see where the work is being done. And switching branches in TortoiseSVN was quick and easy.

Just one question, which doesn't really have anything to do with HadesMem but with boost..
When I build and link with libMemory.lib the msvc linker implicitly tries to link with libboost_<libraryname>.lib and when I built the boost libraries with with the included Build_MSVC100_IA32.bat it names them boost_<libraryname>.lib. Is there any way I can change this naming scheme?
It's easy enough to just batch rename them and add the "lib" prefix, but it would be nice to have it done at compile time.

[Cypher]

libboost_library is the statically linked library, boost_library is the dynamically linked library. I recently changed whether I was static vs dynamic linking. Can you please try a 'clean' build? Update to the latest revision, delete Bin and Dist from HadesMem, delete the bin.v2, dist, and stage folders from /Src/Dependencies/Boost, build Boost using the Build_MSVC100_IA32 script, then build Hades using the Build_MSVC_IA32 script.

You shouldn't be getting linker errors. Let me know how that goes and if you're still getting linker errors I'll do a rebuild myself and look at the Jam files and see if I can fix them.

Thanks.

[_Mike]

Yeah it works now with a clean rebuild. I guess I must have had some leftover files which messed up the build. Last time I updated the svn tree before today was sometime back when you were using boost 1.46 I think it was.

Thank you for the help sorting it out.