Utility to view pointer data?

put: *pointerName into the Watch window. You may also have to just cast it to the appropriate class (AppropriateClass*)pointerName.

Also make sure you're in Debug mode. Release mode with optimizations frequently lies about everything except the disassembly and register values.

-me

I apologize. I meant handle. For instance, if I try to view the contents of an HWND, I get the memory location as well as the value, if any, in the integer "unused" (see WinNT.h).

I'v tried what you said, but I get the same results.

The structure and content of a HWND is opaque. However, VS has a memory view in the Debug menu during debugging (Windows -> Memory 1..4) which will take arbitrary addresses and display the memory at those addresses. You can guess that that HWND value contains or represents a pointer and use that value as an address, although you're not likely to get much useful out of it, as the structure is not documented.

What are you *really* trying to solve?

In short, "handle" doesn't equate to "pointer". Handles are "opaque". They are implementation defined access points to some resource. The could actually point to a resource, but more likely they index into some table being held by the object that gave you the handle. In most cases (and i think HWND is one of them), you won't be able to access any information through a handle in the debugger.

edit: jpetrie beat me to that...

If you're interested in spying on HWND's, check out WinSpy++ 1.7.

Win32 has had me so frustrated lately that I though that maybe some low level hacking/viewing might prove useful and/or informative. I find MSDN so obtuse, poorly written and categorized that it is almost useless. I don't expect to gain anything more than a little insight into how and why Windows does what it does.

My frustration level has reached the point that I am seriously considering throwing my Windows 7 machine in the garbage and getting a Mac. I am planning on getting a Mac anyway for iPhone/iPad development. I have a growing respect for sane, professional Windows developers.

Quote:

Original post by LessBread If you're interested in spying on HWND's, check out WinSpy++ 1.7.

That is interesting, but I get the idea that they just use Windows routines to get the data. What I wanted was the ability to to view the hex data from a point in memory, try to compare it with known data and then see what happens when a change is made. You know, hacking. HWND was just an example.

The problem is that is that many of those opaque handles are actually either pointers into kernel memory or indices into kernel memory tables. If you tried reading those values you'd get a nice access violation because kernel memory is not accessible from application code.

Quote:

What are you *really* trying to solve?

You really need to answer this question rather then venting your frustration, as that does not help us solve your problem. Generally speaking, you shouldn't need to peek at the contents of an HWND to do most basic tasks in Win32. This is a flag that indicates that you might be doing something wrong. While it may certainly not be your fault, a tirade about Macs does not get us any closer to helping you.

Edit: Wait, you are angry with Win32 because you think it is difficult to hack? This does not exactly sound like an issue with either the MSDN or Win32, as they are not going to explain how to hex edit memory that may potentially lie in the kernel pages.

Quote:

My frustration level has reached the point that I am seriously considering throwing my Windows 7 machine in the garbage and getting a Mac. I am planning on getting a Mac anyway for iPhone/iPad development. I have a growing respect for sane, professional Windows developers.

Yeah, that won't help you. Development on the Mac can be just as frustrating, especially if -- as you appear to be doing now -- you let your frustration get to you.

Try not to blame your tools. While MSDN has some issues, it is generally quite good -- on par with or better, in many cases, than Apple's documentation, certainly.

Apple has a long history of treating developers as necessary evils, unfortunately, in the eyes of many long-term programmers for the platform (myself included). At least relative to Microsoft's treatment of developers.