Microsoft to push fix for patch trouble

Linking directly to hhctrl.ocx was never "allowed": No rules changed. The rule was you always load hhctrl.ocx dynamically at runtime. Just because you could get away with it before, doesn't mean you should always be able to get away with it.

How is this different than linking to, say an undocumented exported function FooBar in asdf.dll, and Microsoft later removes that function? The apps who broke the rules would break. The apps that didn't break the rules wouldn't break.

"The first problem was that Microsoft allowed this ocx to be linked to directly." How exactly are they supposed to prevent this? Have a hard-coded list of DLLs that are "allowed" and "forbidden" to be directly linked to? What about 3rd-party DLLs, where do they go? Do you know anything about how the Windows OS loader works?; Posted by: PB_z Posted on: 04/10/07 You are currently: a Guest | Members login | Terms of Use

Reply to Story Reply to Message

Subscribe to this discussion via Email or RSS

No, Rockhead, ... OButterball | 04/09/07

It ain't that simple, PB_z OButterball | 04/09/07

Uh, oh, jasonp... OButterball | 04/10/07

I'd guess 3-5 mins/day Jack-Booted EULA | 04/11/07

Here we go again! Reverend MacFellow | 04/09/07

patch the patch bfsteel@... | 04/10/07

What do you think?

Get cost-effective strategies and roadmaps on the most important issues facing IT leaders in 2010! Learn how to easily cut costs and deliver greater efficiency starting with your database, IT compliance management and data center. Visit the IT Leaders Dashboard. Visit the IT Leaders Dashboard.
Read about top issues IT decision-makers face every day, plus get cost effective solutions to real life IT problems. Oracle Topline