If you don't built it, they may come anyway
A perennial problem in maintaining widely-used platforms is backwards compatibility. Windows suffers more than most in this respect, both because of Microsoft’s unusual degree of commitment to backwards compatibility and the degree to which the platform has changed over time, from a 16 bit collection of libraries with cooperative multitasking running under MS DOS on a single 8086 processor with 640k to 32 or 64 bit pre-emptive multitasking operation on multi-core Xeons with gigabytes of RAM.
They’ve had to jump through endless hoops (NTVDM.EXE, anyone?) just to get those old applications running on operating systems created two decades later on radically different hardware. Further hoops, though, are imposed by applications relying on undocumented characteristics of components – sometimes, as Raymond Chen likes to point out, through laziness when someone just can’t be bothered putting in the effort to use the proper, documented method for something – but in other prominent cases like the MSI SlowInfoCache, an undocumented 552 byte binary block which controls how entries appear in Add/Remove Programs, and showing or hiding the Quick Launch bar, because Microsoft chose not to document an official way to do something out of fear “bad” people would use it. Needless to say, this just means they use undocumented methods instead!
Like many battles, there is merit on both sides. Within Microsoft’s walls, logic like Whether the Quick Launch bar is shown or hidden is an end user setting, and programs should not be overriding the user’s preferences. Explorer consciously does not expose an interface for showing and hiding taskbar bands because it would just be a target for abuse has prevailed. Because someone in Microsoft thinks programs (other programs, that is: clearly their own – Explorer, in this case – get treated differently) should not be tampering with this “user” setting, they choose not to make it easy for programs to do that.
On the other side of the fence, however, there are people who need, or at least want, to change that setting programmatically for some reason. Perhaps to impose a standard corporate desktop (many corporate IT administrators seem to believe “user” settings should actually be “Administrator” settings wherever possible, imposed centrally by them rather than allow mere end users any say in their work environments), or to implement some other feature – perhaps even one the users themselves have requested, having neglected to read Microsoft’s memo telling them they didn’t really want that.
The end result, of course, is usually that the feature gets implemented anyway. In the example above, you can use FindWindow to get the handle of Shell_TrayWnd, then send it message WMTRAY_TOGGLEQL (WM_USER+237) with WPARAM set to 0 and LPARAM set to 1 or 0 to enable or disable the Quick Launch bar respectively. Now, in this particular case, sending WMTRAY_TOGGLEQL messages seems unlikely to pose a future compatibility headache for Raymond and co to work around – but there are less straightforward examples out there: the MSI packaging system, for example, uses undocumented blocks of data 552 bytes long in the Registry (values named SlowInfoCache, under Microsoft\Windows\CurrentVersion\AppManagement\ARPCache) to interact with the Add/Remove Programs Control Panel applet. Since this block controls some of the details shown for your application’s entry in ARP, it is hardly surprising that people want to parse and manipulate this data – but being undocumented, how can we know there isn’t some undocumented flag in there which matters? With people relying on direct access to an undocumented binary block, extended that data structure in future will be painful as well.
Undocumented blocks of binary data. Just say no.
