The MASM Forum

Pretty standard code for subclassing an edit control:
.elseif uMsg == WM_CREATE
      invoke CreateWindowEx, WS_EX_CLIENTEDGE, chr$("edit"), NULL,
         WS_CHILD or WS_VISIBLE or WS_BORDER or ES_LEFT\
         or ES_AUTOHSCROLL or ES_AUTOVSCROLL or ES_MULTILINE,
         0, 0, 280, 300,
         hWin, 123, hInstance, NULL
      mov hEdit, eax                     ; we have created an Ansi edit window
      xchg eax, ebx                     ; move the handle to a safe reg
      invoke SetWindowLong, ebx,            ; we subclass the edit control
      GWL_WNDPROC, SubEdit
      mov opSubClass, eax                  ; the old pointer
      invoke GetWindowLong, ebx,            ; we subclass the edit control
      GWL_WNDPROC
      mov xSubClass, eax
   print "WM_CREATE:", 9      ; OPT_Susy console
   print hex$(opSubClass), 9
   print hex$(xSubClass), 13, 10
    .elseif uMsg == WM_LBUTTONDOWN
   print "WM_LBDOWN:", 9
   print hex$(opSubClass), 9
   print hex$(xSubClass), 13, 10

Results:
; WM_CREATE:      7E3BB3EC        0040137D
; WM_LBDOWN:      7E3BB3EC        0040137D

Observations:
1. opSubClass is not the original pointer, it's a handle
2. xSubClass is the new pointer

But on Win7-32 xSubClass changes its value when it leaves WM_CREATE, on XP it stays the same...

Windows mysteries :badgrin:

Quote from: msdnGWL_WNDPROC: Retrieves the address of the window procedure, or a handle representing the address of the window procedure.

CallWindowProc

http://msdn.microsoft.com/en-us/library/windows/desktop/ms633571%28v=vs.85%29.aspx (http://msdn.microsoft.com/en-us/library/windows/desktop/ms633571%28v=vs.85%29.aspx)

lpPrevWndFunc ... either the address of a window or dialog box procedure, or a special internal value meaningful only to CallWindowProc

The "lp" is in any case misleading. On Win7, it is the address of the sub-windowproc inside the WM_CREATE handler, then it changes to a new "internal" value.

Afterwards, it remains constant - which could be a way of testing whether a new subclass proc has been added or not. But it's not documented that the value remains constant...

[speculation]in context to OOP it might makes more sense that they use a handle rather than pointer, because the original window procedure is maybe a non-static method, which requires a this-pointer.[/speculation]

i think it has to do with "chained" sub-classes
if you remove a "link" from the chain, it is still connected   :P

(my highly technical description - lol)

What are these strange values returned from GWLP_WNDPROC? (http://blogs.msdn.com/b/oldnewthing/archive/2003/12/01/55900.aspx)

Nice link, qWord :t

The comments are worth reading:
Benjamin: "Will Avalon really remove the message pump and do everything new? No more passing of COM-stuff through windows-messages?"

Raymond Chen: "Our research shows that many large companies are STILL running 16-bit Windows programs"

That was December 2003...

There is one thing you may find interesting: if you're getting that "internal value" (i.e. handle) instead of a pointer to a sub-classing proc, but wanted to know the precise address, then just use another-encoding-version of a Get/SetWindowLong - i.e. if you've used GetWindowLongA and have got a handle, then use GetWindowLongW to get an address; and vice versa.

The reason is: different "default" encoding for a window (control) - if the windows was created with a Unicode version of CreateWindowExW, then if you're using ANSI version of GetWindowLongA - it will return the handle, not the address. And vice versa. This is required for a message translations between Unicode and ANSI or/and vice versa; that's what I suppose. I.e. when CallWindowProc gets an address - it knows that it just needs to pass  the params it gets without touch to the specified address, when it gets the handle (its value is knowlengly not-a-valid-address for user mode, and still the handle is checked so CallWindowProc will not eat some random garbage as a "handle") it knows it needs to translate some messages from one version of encoding to the contrary version - for example WM_CHAR or WM_GET/SETTEXT message etc - for the second it needs convert the text passed in an original buffer and pass the different, converted, buffer to a calling window proc; - for example.

I.e. to get the proper WndProc for any window (inside your own process, at least), you should use such an algorithm:


EXTERN _imp__GetWindowLongA@8:DWORD
EXTERN _imp__GetWindowLongW@8:DWORD

...

invoke IsWindowUnicode,hwndWindowOfInterest
mov ecx,dword ptr _imp__GetWindowLongA@8
test eax,eax
jz @F
mov ecx,_imp__GetWindowLongW@8
@@:
push GWL_WNDPROC
push hwndWindowOfInterest
call ecx


(or version specially for a gourmands :biggrin:):

push GWL_WNDPROC
push hwndWindowOfInterest
invoke IsWindowUnicode,hwndWindowOfInterest
mov ecx,_imp__GetWindowLongA@8
xchg eax,ecx
jecxz @F
mov eax,_imp__GetWindowLongW@8
@@:
call eax



This method will work for DWL_DLGPROC, too.

At least this is how it seems to work up to XP :biggrin:

BTW, one additional note: if an app uses manifest, so its controls look neatly and in modern style, then standard windows controls you're creating even with CreateWindowExA are default Unicode (at least on XP) - that's because other common controls DLL is used which uses other approach than the older one (common controls version below 6).


This info is probably a bit off-topic but may be useful.

Quote from: Antariy on April 06, 2013, 10:27:11 AM
This info is probably a bit off-topic but may be useful.

Alex, that info is "spot on", thanks a lot :t

I've modified the code a little bit, results look like this on XP:

Where           opSub           addrSub         gwlA            gwlW
WM_CREATE:      7E3BB3EC        00401424        00401424        FFFF03BB
WM_LBDOWN:      7E3BB3EC        00401424        00401424        FFFF03BB

So the ANSI version of GetWindowLong yields the true address. Can anybody test it on Win7 please?

Win7 64bit - ran it 4 times, gwlW changed on each run.

Where           opSub           addrSub         gwlA            gwlW
WM_CREATE:      77A80BDE        00401424        00401424        FFFF08CF
WM_LBDOWN:      77A80BDE        00401424        00401424        FFFF08CF

Where           opSub           addrSub         gwlA            gwlW
WM_CREATE:      77A80BDE        00401424        00401424        FFFF086F
WM_LBDOWN:      77A80BDE        00401424        00401424        FFFF086F

Where           opSub           addrSub         gwlA            gwlW
WM_CREATE:      77A80BDE        00401424        00401424        FFFF0BC9
WM_LBDOWN:      77A80BDE        00401424        00401424        FFFF0BC9

Where           opSub           addrSub         gwlA            gwlW
WM_CREATE:      77A80BDE        00401424        00401424        FFFF0697
WM_LBDOWN:      77A80BDE        00401424        00401424        FFFF0697


Quote from: fearless on April 06, 2013, 06:28:46 PM
Win7 64bit - ran it 4 times, gwlW changed on each run.

Yes, because it's not an address but rather a handle, as the FFFF shows.

Quote from: jj2007 on April 06, 2013, 04:42:54 PM
Alex, that info is "spot on", thanks a lot :t

Thank you, Jochen :biggrin:

Here is what XP SP2 gives:

Where           opSub           addrSub         gwlA            gwlW
WM_CREATE:      77D6063A        00401424        00401424        FFFF0A8D
WM_LBDOWN:      77D6063A        00401424        00401424        FFFF0A8D
WM_LBDOWN:      77D6063A        00401424        00401424        FFFF0A8D
WM_LBDOWN:      77D6063A        00401424        00401424        FFFF0A8D


Great. So it seems that one could use the gwlA value to determine if the subclass is still the right one (or gwlW for a Unicode control, of course).

Background: There is a thread in PellesC forum (http://forum.pellesc.de/index.php?topic=5273.0) where the OP claims that "Minimum operating system: Windows XP (SetWindowSubclass api), but could be lowered after replacing SetWindowSubclass with unsafe SetWindowLong(GWL_WNDPROC)", which is in line with Raymond Chen's "what would happen if somebody else had subclassed the window"? (Safer subclassing (http://blogs.msdn.com/b/oldnewthing/archive/2003/11/11/55653.aspx)). See inter alia reply #6 ;-)

Probably it's easy to make "partially eliminating" subclasses. When we don't need to subclass some window, we check - if our subclass is on the top of the chain. If it is - we just restore an old subclass (old WndProc), if it is not, then we put some flag in the data of the program or in the data associated with that window (it's easy to use GCL_CBWNDEXTRA with SetClassLong to add 4 bytes to every window that will be created which will hold a pointer to any sized structure with any set of values/flags/etc) - the flag which means "do not process any things for this window". I.e.


subclass proc ...
... some way to get the flag "dontProcess" into eax ...
cmp eax,1
jnz @F
pop edx
push oldWndProc
push edx
jmp CallWindowProc
@@:

... some other things which will become unwanted when "dontProcess" flag is set ...

subclass endp


... somewhere in the code we can do ...

mov dontProcess,1

...


Quote from: Antariy on April 07, 2013, 11:41:12 PMit's easy to use GCL_CBWNDEXTRA with SetClassLong to add 4 bytes to every window

According to the documentation this is not possible. Using a window property would be an easy alternative.

Not sure what you mean, but this is typical thing to do. That's how RAM Clear's custom-drawn buttons work. It was limitation in extra windows' bytes in Win9x but even there there is space for ~10 such 4 byte pointers in the every window extra space.
Just make class changements before creating new windows of that class, like I said in the full text of the quoute.

yep, I probably misinterpreted the documentation for SetClassLong (http://msdn.microsoft.com/en-us/library/windows/desktop/ms633588(v=vs.85).aspx)(GCL_CBWNDEXTRA,...):

Quote from: msdnSets the size, in bytes, of the extra window memory associated with each window in the class. Setting this value does not change the number of extra bytes already allocated

The second sentence means that you can increase the value, but not decrease it  :redface:
Regardless that I prefer properties in situation where I did not registered the class: Set (http://msdn.microsoft.com/en-us/library/windows/desktop/ms633568(v=vs.85).aspx)/GetProp (http://msdn.microsoft.com/en-us/library/windows/desktop/ms633564(v=vs.85).aspx)().

qWord

Set/GetProp is a good choice, too :t It even better than extra class data if there is no need to associate some own data with every window of some class.

QuoteBefore a window is destroyed (that is, before it returns from processing the WM_NCDESTROY message), an application must remove all entries it has added to the property list.

Will that happen automatically on ExitProcess?

Quote from: jj2007 on April 08, 2013, 10:46:32 AM

QuoteBefore a window is destroyed (that is, before it returns from processing the WM_NCDESTROY message), an application must remove all entries it has added to the property list.

Will that happen automatically on ExitProcess?

IIRC, they are implemented as global atoms, which are removed with the process. However, I wouldn't bet on that and simple remove them on destruction.

EDIT: corrected

Quote from: jj2007 on April 08, 2013, 10:46:32 AM

QuoteBefore a window is destroyed (that is, before it returns from processing the WM_NCDESTROY message), an application must remove all entries it has added to the property list.

Will that happen automatically on ExitProcess?

Probably not. The point is: the string which "names" the data associated with a window is a global atom, therefore, if you register it - you should unregister it, otherwice it will not be removed from list of registered atoms untill system reboot. There are less than 65536 atoms available in the system, so, in some degree properties look like limited resource (considering that system running not only our application, but many others, and any of them can create a bunch of a properties etc etc - especially today's "heavy-GUI" applications). But it actually don't seem to have much influence on the system performance, probably that's due to small possible list "name-value" of atoms. And second atom registration with the same name will just return the previous atom value.

Edited: added a quote the post was answering to.

Seem they are nice window feature as long as handled correct  8). However, I find it a bit curios that the atoms are not automatically removed (on window destruction)¹, because it would be simple to implement that...

EDIT: [1] added

maybe not - if they are shared between processes

Quote from: dedndave on April 08, 2013, 11:51:55 AM
maybe not - if they are shared between processes

There must be some kind of list for each window, which hold the atom identifiers. Going through that list and removing the global atoms (GlobalDeleteAtom) should be no problem IMO.

Especially since FreeGlobalAtom uses a counter anyway. But it would require keeping a list of atoms used by the app so that at ExitProcess the OS knows what to release.

One problem is that MSDN uses this "you have to release" too often.
Yes, you have to release the DC if you use it in a loop (if not, ExitProcess will release the heap mem)
Yes, you have to release the brush if you use it in a loop
Yes, you have to release atoms - always
No, you don't have to remove the subclass on exit - ExitProcess will do it for you.

And M$ shies away from documenting that clearly. As a result, coders are uncertain and hide behind the argument "OMG, don't do that, it's not documented"  ;)

It's lousily documented, that's true :biggrin:

i can't be too critical - lol
it's a big OS and, overall, they documented it fairly well
i was a Logistics Engineering Technical Writer, long ago (Sperry Flight Systems)
i can sympathize with how much effort goes into documenting something so big and complex

as for freeing stuff...
my theory is, if i DO it, i generally try to UNDO it before exit
it's just a good habit to get into, particularly with GDI stuff
expecting ExitProcess to clean something up is asking for a memory leak
it's not as though it causes pain to add an extra line of code - lol

Quote from: jj2007 on April 08, 2013, 03:23:43 PMBut it would require keeping a list of atoms used by the app so that at ExitProcess the OS knows what to release.

yes, I agree. However, I was referring on destruction of a window, where is should be no problem to remove the added properties - this would not required any cleanup on process exit.

There are obviously can be some points that they want to make things a bit more obscure than they are. First of it: they want to sell their stuff for developers. One may want to buy such thing like MSVC to use MFC/.NET and to make cute-GUI apps instead of studing a bunch of entangled, sometimes unclear, and - very frequently - not full documentation.
For such things like device drivers - it's even more profitable area, there are usually a "big guys" who can pay high costs for info and tools.
So, they obviously have been doing a big job documenting something, but not all and not totally. For an instance - it is better if you buy Microsoft's Press book about "undocumented" functions and methods like native API are, than if you'd know that all for nothing. The same for "Certified courses" of any speciality which has relation to the Windows and its tools. Support of the products etc. That's just profitable business: who has more information - has more power, so, sell the information - this will always bring a profit - that is how it works. Probably.

Quote from: dedndave on April 08, 2013, 11:49:17 PM
expecting ExitProcess to clean something up is asking for a memory leak

If the memory is your own heap, no problem - it will be abandoned completely. That concerns 99% of all cases (alloc, brushes, all GDI stuff, ...).
The 1% are global atom tables. Not sure, though, if ExitProcess can handle COM & OLE:

"OleUninitialize calls the CoUninitialize function internally to shut down the OLE Component Object(COM) Library."

yah - you write a program that doesn't "balance" the GDI stuff and run it 100 times   :biggrin:

Quote from: dedndave on April 09, 2013, 02:05:36 AM
yah - you write a program that doesn't "balance" the GDI stuff and run it 100 times   :biggrin:

Here is one that launches 1,000 times a Win GUI app that creates 1,000 brushes and exits without deleting them. That's a Million "unreleased" GDI handles ;-)

Read the disclaimer. On Win XP SP3 it seems to work fine :icon_mrgreen:

select them into a DC   :biggrin:

Quote from: dedndave on April 09, 2013, 04:30:46 AM
select them into a DC   :biggrin:

:greensml:

   CASE WM_PAINT
      invoke BeginPaint, hWnd, addr ps
      xchg eax, edi
      .While ctGDI<1000
         invoke CreateSolidBrush, ctGDI
         invoke SelectObject, edi, eax
         inc ctGDI
         SetWin$ hEdit=Str$("brush #%i", ctGDI)
      .endw
      invoke EndPaint, hWnd, addr ps
      invoke SendMessage, hWnd, WM_CLOSE, 0, 0
   ENDSW

let me sign out and test it - lol

before and after
oops, i lost 3 mb RAM   :redface:

(http://img827.imageshack.us/img827/3090/beforeafteru.png)

Quote from: dedndave on April 09, 2013, 05:14:36 AM
before and after
oops, i lost 3 mb RAM   :redface:

3 bytes for a brush? Hmmm...
Probably one of your svchost processes had a hiccup. Or Firefox loaded a page more.
Try again a hundred times ;-)

3 mb

Quote from: dedndave on April 09, 2013, 06:20:11 AM
3 mb

Divided by one Million unreleased undeleted brushes = 3 bytes per brush :P

i thought we did 1000

1000 brushes per launch * 1000 launches = 1Mio

maybe brush objects is a bad example
i know i have seen problems related to GDI in some newbie programs - lol
i don't recall the exact circumstances, perhaps it was a DIB section or a DC
you run the program several times, then you have to reboot (or maybe log out/in)

I guess you have to distinguish between
1. a memory leak because of repeated GDI object creations without DeleteObject inside the same app
2. creation of GDI objects once during WM_CREATE, no DeleteObject before ExitProcess.

Case 1 may play havoc with your system, of course. Case 2 depends on whether the object had any "global" implications (atoms, for example). If the object was in the memory that was allocated to the process, then it's gone for good when ExitProcess has done its work.

There is a lot of confusion on this issue - google for memory leak exitprocess to see some of it.

Here is a horribly confused thread: "Should I delete these memory before exit process" (http://bytes.com/topic/c/answers/547088-should-i-delete-these-memory-before-exit-process), here a more solid page: "Does an Application memory leak cause an Operating System memory leak? (http://stackoverflow.com/questions/4149669/does-an-application-memory-leak-cause-an-operating-system-memory-leak?rq=1)"

See also M$ support DDEML: Memory Leak in Global Shared Memory (http://support.microsoft.com/kb/170626) - but even GlobalAlloc with the GMEM_DDESHARE flag does not use globally shared memory.