During coding a custom progressbar i ended analysing the way comctls32.dll works for this class.
After some work i ended finding that on WinXP (and on Vista and 7, probably) comctl32.dll still have several unchanged coding since win95.
For example at address 05D096AFE it is the location of the function UpdatePosition responsable for the progressbar msgs PBM_DELTAPOS, PBM_SETRANGE32, PBM_SETRANGE, PBM_SETPOS, PBM_STEPIT. Inside this funtion we have an usual (and very very old code) that belongs to Win95 kernel called "MyNotifyWinEvent" (at 05D09650F).
The impressive stuff is that instead comctl just make a simple call to NotifyWinEvent it simply left there the old routine existent since Win95 that looks like this:
[s_pfnNotifyWinEvent: D$ 0]
Proc MyNotifyWinEvent:
Arguments @event, @hwnd, @idContainer, @idChild
mov eax D$s_pfnNotifyWinEvent
...If eax = 0
call 'KERNEL32.GetModuleHandleW' {U$ "USER32", 0}
If eax <> 0
call 'KERNEL32.GetProcAddress' eax, {B$ "NotifyWinEvent", 0}
mov D$s_pfnNotifyWinEvent eax
End_If
mov eax D$s_pfnNotifyWinEvent
If eax = 0
inc eax
mov D$s_pfnNotifyWinEvent eax
End_If
...End_If
If eax <> 1
call D$s_pfnNotifyWinEvent D@event, D@hwnd, D@idContainer, D@idChild
End_If
EndP
This code is exactly the same as in windows kernel c source "progress.c" (actually this function belongs to cutils.c)that is:
// --------------------------------------------------------------------------
//
// MyNotifyWinEvent()
//
// This tries to get the proc address of NotifyWinEvent(). If it fails, we
// remember that and do nothing.
//
// NOTE TO NT FOLKS:
// Don't freak out about this code. It will do nothing on NT, nothing yet
// that is. Active Accessibility will be ported to NT for Service Pack #1
// or at worst #2 after NT SUR ships, this code will work magically when
// that is done/
//
// --------------------------------------------------------------------------
void MyNotifyWinEvent(UINT event, HWND hwnd, LONG idContainer, LONG_PTR idChild)
{
static NOTIFYWINEVENTPROC s_pfnNotifyWinEvent = NULL;
if (!s_pfnNotifyWinEvent)
{
HMODULE hmod;
if (hmod = GetModuleHandle(TEXT("USER32")))
s_pfnNotifyWinEvent = (NOTIFYWINEVENTPROC)GetProcAddress(hmod,
"NotifyWinEvent");
if (!s_pfnNotifyWinEvent)
s_pfnNotifyWinEvent = DONOTHING_NOTIFYWINEVENT;
}
if (s_pfnNotifyWinEvent != DONOTHING_NOTIFYWINEVENT)
(* s_pfnNotifyWinEvent)(event, hwnd, idContainer, idChild);
}
I can´t stop thinking...Why the hell M$ programmers left this stuff on comctl32 for XP and later, instead simply making a call to NotifyWinEvent ?
The same problem exists on other functions such as:
xGetSystemMetrics that is simply the function GetSystemMetrics
There are very likely to be many examples like this where things could be updated and 'made better,' but what would be microsoft's benefit (from their point of view.) It would cost in labour and time to rewrite this code, and for what gain? It would still do exactly the same (from an external point of view.)
Old code that already works is expensive to rewrite (it already cost to be written the first time,) and this isn't generally done for the sake of cleanliness. You could ask them to rewrite windows so it's 'better,' but it's unlikely this will happen. "If it ain't broke, don't fix it."
Yep, basically every feature starts with minus 100 points (http://blogs.msdn.com/b/ericgu/archive/2004/01/12/57985.aspx) and needs to overcome that through some benefit to customers before it will even be considered.
I feel I should also point out that "old code inside WinXP" should generally be assumed, though it's probably not safe to assume it's unchanged through to Win7 (especially since so much of the UI changed between then and now).
Cheers,
Zooba :t
On seven, i´m still analysing the code...but, it do contains some old coding. Once i finish the analysis i´ll post here what i´ve found.