ResGuard for Framework C

[Biterider]

Hi
Yesterday I found something when I was looking for a leak. 

I have not considered GDI+ until now and thus, everything that is allocated there as GDI system object, leads to a leak. It took me a long time to realize this, but now I have included some GDI+ APIs from the flat API. 

Of course I also have to consider other allocations in addition, but that will come a bit later. 

Biterider

[HSE]

Hi Biterider!

Working perfectly in standard Masm64 SDK project

I was sure about the introduction of some leaks in the codeedit project, but 497 is a little to much 

Regards, HSE.

[Biterider]

Hi HSE

Working perfectly in standard Masm64 SDK project

Thank you for checking this out. 
I have prepared a demo in simple MASM, but it is only a demo and not real code. ResGuard is not finished yet, if it ever gets "finished". Today I want to add the rest of the GDI+ APIs. The rest will then be added bit by bit.

but 497 is a little to much

That is absolutely true. It happened to me too, and it's overwhelming when you have a couple of leaks at the same time. I need to think of a way to reduce the output, for example by grouping all the leaks that were triggered at the same code address (just an idea). 

Biterider

[Biterider]

Hi HSE
I added the aggregation of calls and now the output looks much better. 
The number of calls is now shown in square brackets after the API name.



Biterider

[HSE]

Hi Biterder!

That look better 

HSE

[Biterider]

Hi
I just uploaded the new code with the aggregation code and the relevant GDI+ APIs.

Biterider

[HSE]

 

[Biterider]

Hi
There is still a problem with the current implementation. 

In the past, ResGuard would have been allowed to continue running after a Show command. However, now that we are doing the aggregation, this is no longer possible. 
I have not used ResGuard this way, but in the past it could have been done this way. 

To restore this state you need a slightly different strategy, which is quite possible, but will take some time to implement.

Biterider

[Biterider]

Hi
I have completed the last update by adding and testing the reverse aggregation feature so that the original start/stop functionality is restored. 

The update is uploaded to the repo.

Biterider

[Biterider]

Hi
New update with the 2 APIs from this post from fearless
https://masm32.com/board/index.php?topic=11265.msg123856#msg123856

Biterider

[HSE]

Hi Biterider!

Address that ResGuard show it's not call address (like old version, if I remember well). I presume now show invoke beginning. Is that correct?

Thanks in advance, HSE

[Biterider]

Hi HSE
The address shown after the symbol name of the calling frame is the return address of the call instruction.
My original intention was to show the calling address, but I would need my own disassembler to decode the calling OP-code bytes. If you simply see the call instruction using a disassembler, it is easy to check what is happening.

BTW, it's the same thing that VS debugger shows.

Biterider

[Biterider]

Hi
A stable version has been uploaded to the repository. 
The behaviour is now identical on 32- and 64-bit targets, despite the calling differences. 
The initialisation interface is now identical on both targets and a plain 32-bit MASM example has been added.
 
Full documentation will follow soon. 

Biterider