The forgotten common controls: The ShowHideMenuCtl function

Why is the animation common control limited to RLE8-compressed animations? | Coded Style

Sat, 18 Apr 2009 06:37:26 GMT

PingBack from http://www.codedstyle.com/why-is-the-animation-common-control-limited-to-rle8-compressed-animations-15/

re: The forgotten common controls: The ShowHideMenuCtl function

Int19 — Thu, 12 Jul 2007 10:28:19 GMT

It is not a "lose-lose discussion", if you want to explain this...

Believe me, I would be glad to read your opinion on this matter and so help me correct my misunderstanding about this DLL (there is much hype on the net about it), as your book helped correct some of my mistakes on Windows API programming (by the way it’s a nice book :-)).

But since you do not feel this way, “End of Discussion” from me also, I am sorry for pointing about “DUSER.DLL” in the first place, I will not trouble you again.

Bye.. :-(

re: The forgotten common controls: The ShowHideMenuCtl function

Int19 — Thu, 12 Jul 2007 08:47:54 GMT

“Misinformed FUD?”

Well just take a peak on the loaded DLLs of “MS-Windows XP Add/Remove Programs” applet on the Control Panel, if you do so (with the help of Process Explorer for example) you will see that the software (which starts with the help of the well known “rundll.exe”) uses the “duser.dll”.

Now if you check “duser.dll” exports you'll see that it's a much useful and quiet undocumented system oriented DLL (titled in it’s version info as “Windows DirectUser Engine” wow!!) that only MS software can use and benefit from ;-)

Now, if Raymond can explain us this, then ok…

[This is a lose-lose discussion for me. People just keep making false statements and my choices are either to let them stand and make people think they're right, or correct them, and that just leads to a new false statement. So I'll try to quit the game: Your statement is incorrect but I will not correct it. End of discussion. -Raymond]

re: The forgotten common controls: The ShowHideMenuCtl function

Wilhelm Svenselius — Wed, 11 Jul 2007 09:06:58 GMT

Would the trolls go back to Slashdot please? The whole "undocumented dynamic libraries which only [Microsoft's] own programs can use" thing is misinformed FUD to begin with.

re: The forgotten common controls: The ShowHideMenuCtl function

PatriotB — Wed, 11 Jul 2007 08:33:15 GMT

Re: the 64-bit issue with this function... couldn't it have been changed to operate on an array of INT_PTRs? It would have no effect when compiling for x86, and would enable the function to work correctly in 64-bit. I imagine the time to convert INT to INT_PTR would have been trivial.

Re: DirectUI... I've mentioned it before on this blog. There's two sides to the coin: 1: Someone at Microsoft has developed some technology, and since it is property of Microsoft, any product in Microsoft should have the right to incorporate that source code. 2: Microsoft doesn't want to commit to a publicly-available (and supported forever) implementation of the technology, so to sidestep around antitrust requirements, it doesn't implement it as an exposed API but simply duplicates all the code in each relevant product.

My personal view? I'd love to see DirectUI documented, because it seems like cool technology (for those who don't want to use WPF for the same reasons that Windows itself doesn't want to use WPF). But I think they have the right to keep it private; as Raymond said it doesn't use any undocumented Windows APIs so in theory any ISV could have, with the right skills and knowledge, created the same thing.

That said, just because you *can* keep it private, doesn't mean you should. And that leads to...

Re: APIs and helper functions/controls. I'm one who loves APIs because they allow me to 1) minimize the cost of developing my own apps, and 2) be most consistent with the OS.

It's a balance between ISV usefulness, platform longevity, and affect on cost (for both the ISV and Microsoft).

With XP, I was definitely seeing a trend about reducing helper functions and exposed controls (especially compared to the ComCtl32 updates brought by IE3/4). However with Vista, I was pleasantly surprised by what I perceived as an excellent set of new Shell APIs (not quite as much with comctl32 since there isn't much new there). There are hundreds of new shell/property system functions/interfaces, ranging from large pieces like ExplorerBrowser and NamespaceTreeControl, to simple helper functions like SHCreateItemXXX. There's also some good SDK samples. (However, the SDK documentation itself is still quite sparse.)

That said there are still pieces missing--we waited for years for SHCreateShellFolderView/Ex (and company) to be officially documented. It took the DOJ to bring it about, but it finally happened in 2002. Now there's deprecation warnings on nearly all of these "settlement" APIs, which disappoints, but doesn't surprise, me.

Anyways, overall it's a balance to find which APIs are the correct ones to expose. Generally Microsoft does a pretty good job in determining this balance.

re: The forgotten common controls: The ShowHideMenuCtl function

DX — Wed, 11 Jul 2007 08:24:57 GMT

His comparison is valid Raymond, You known it but I do not expect you to accept it.. ;-)

Cheers Mate!

re: The forgotten common controls: The ShowHideMenuCtl function

Igor — Wed, 11 Jul 2007 06:24:05 GMT

"Do people complain to Lotus..."

Raymond, Lotus doesn't make an operating system with undocumented dynamic libraries which only their own programs can use, so your comparison is not valid.

[Neither is Windows, so your comparison is not valid either. -Raymond]

re: The forgotten common controls: The ShowHideMenuCtl function

Marvin — Wed, 11 Jul 2007 04:55:21 GMT

"The problem is some stupid people went crying to the DOJ..."

Not stupid people but rather people coming from a background of open source, operating system ending in ux and programming language ending in va. For them backward compatibility and not breaking existing clients are (or at least used to be) not a big priority as evidenced by their own products. Coming from such background any attempt on the part of MS to not document something is viewed as simply malicious.

menu handles

Bikedude — Wed, 11 Jul 2007 00:40:22 GMT

Oh, I forgot to add (I'm under a contract): Buy m0re v1agr4!

Rune

menu handles

Bikedude — Wed, 11 Jul 2007 00:22:55 GMT

I remember reading that window handles just use 16-bit under 32-bit Windows in order to better support Win16 apps. 64-bit Windows dropped support for Win16 apps, so now window handles use 32-bit in order to support Win32 apps better. (a huge overkill given a window manager that starts sweating bullets at 20000 windows)

Which brings me to my question: Is a 64-bit HMENU value really 64-bit? (Given 64-bit Windows -- I understand Win128 will probably change things)

Rune