Windows WTF



  • Just found this while reading the MSDN documentation on the IsThemeActive() function:


    Remarks:

    Do not call this function during DllMain or global objects contructors. This may cause invalid return values in Windows Vista and may cause Microsoft Windows XP to become unstable.


  • Lovely....

     

    So could this "instability" in XP indicate a security vulnerability?

    I mean cheking if a theme is active shouldn't destabilize the OS.

    Besides, if they know there's a problem with this function, why don't they fix it or put a sanity test at the beginning that senses this? 



  • In working with Infragistics 2006 Vol 3 for WinForms we've had instances where the Zune XP theme causes Infragistics to blow chunks, and more recently an XP machine with the Windows Classic theme and the Tulips background to blow up some specific Infragistics components.

     

    Maybe they're making that call?  :-{



  • I guess every system needs "the ultimate kill button"... Windows XP has IsThemeActive()...



  •  Well, DllMain is a bit special and there are some pretty restrictive rules about what can and cannot be done inside any DllMain.

     More info in the DllMain "Remarks" section, and there's even a white paper on this topic...

    (oh hi BTW, long time reader, first time poster) 



  • @Carnildo said:

    MSDN documentation
     

    Thanks for the link!



  • @MasterPlanSoftware said:

    @Carnildo said:

    MSDN documentation
     

    Thanks for the link!

    You're not familiar with MSDN, are you? They reorganize it at random, and every time they do, most of the links to it stop working. Your best bet is to do a Google search for "IsThemeActive site:msdn.microsoft.com".



  • @MasterPlanSoftware said:

    @Carnildo said:

    MSDN documentation
     

    Thanks for the link!

     

    [url=http://msdn.microsoft.com/en-us/library/bb759813(VS.85).aspx]you're welcome[/url] 



  • @Carnildo said:

    You're not familiar with MSDN, are you? They reorganize it at random, and every time they do, most of the links to it stop working.

    Obviously a huge problem since this thread will be up for many years and if the link stopped working at any point everyone would hate you.

     

    It's a bit WTFy that this causes system instability in XP and doesn't just crash your app.  There are all kinds of problems with dependencies in C++ static object constructors, though, so I'd imagine this is just an extension of that.  In general, you can't do a lot in global constructors without running into some problems and this function (and a few others I found in a similar vein) all return info on the current app's window properties which probably hasn't been set up before main is invoked.  It's well-documented and other than the problem with it causing "system instability" in XP, seems quite reasonable.  Still, if anyone has more of an idea about the why behind this (esp. the instability part) I'd love to hear it.  I'm not a Windows or C++ dev, so don't take my word as gospel.



  • @Carnildo said:

    @MasterPlanSoftware said:

    @Carnildo said:

    MSDN documentation
     

    Thanks for the link!

    You're not familiar with MSDN, are you? They reorganize it at random, and every time they do, most of the links to it stop working. Your best bet is to do a Google search for "IsThemeActive site:msdn.microsoft.com".

     

    Or... YOU could do it. Since you POSTED it.



  • Global objects in DLL are constructed in DllMain context, too, so that part is redundant.

    Because of restriction of what DllMain can call (answer: pretty much only kernel32.dll functions), such remark shuld be assumed for most other functions. It looks like some piece of soft actually called the function in question, causing system indigestion.

    About WinXP becoming unstable: I suspect some display driver could not handle it.



  • @morbiuswilters said:

    @Carnildo said:

    You're not familiar with MSDN, are you? They reorganize it at random, and every time they do, most of the links to it stop working.

    Obviously a huge problem since this thread will be up for many years and if the link stopped working at any point everyone would hate you.

    I don't like posting links if I can't be sure they'll still work tomorrow.



  • @Carnildo said:

    I don't like posting links if I can't be sure they'll still work tomorrow.

    This must be very hard for you since most of the Web is fairly dynamic and there's no guarantee a link will work in the future.  Look, MSDN isn't going to update tonight and they did it nobody would jump on your ass for posting a bum link.  If sentient cockroaches unearth your post in 3179 and the link doesn't work, they'll probabaly be smart enough to use Google or their sentient cockroach equivalent.  However, we are in the year now() and we are lazy and there is no reason to not provide a link.  Stop trying to pretend you had some strong moral conviction against posting a goddamn link and just admit you forgot.  Or better yet, stfu about it because the link has already been posted and nobody cares anyway.



  • @Carnildo said:

    I don't like posting links if I can't be sure they'll still work tomorrow.
     

    Here, I will help you out since you seem to be challenged by this seemingly simple task.

    MSDN article (Google.com first result)

    Cached article

    MSDN Article (currently)



  • @morbiuswilters said:

    and nobody cares anyway.
     

    Indeed, I thought it was a simple request.

    Really though, the OP is pretty mug worthy altogether.

     

    OMG! You can cause unpredictable behavior with bad codez!!!



  • Additionally in the DllMain docs, in order to make an initialization routine that is only called once, their suggestion is "the initialization routine can create a file with an ACL
    that restricts access, and each routine in the DLL would call the
    initialization routine if the file does not exist." Is there really no better way to do this? No say global variable you can create?



  • @Talchas said:

    Additionally in the DllMain docs, in order to make an initialization routine that is only called once, their suggestion is "the initialization routine can create a file with an ACL
    that restricts access, and each routine in the DLL would call the
    initialization routine if the file does not exist." Is there really no better way to do this? No say global variable you can create?

    In Unix one of the most common ways to create a mutex across processes is an exclusively-created file.  The file isn't usually written to disk but only cached in memory by the kernel.  Don't know what options are available under Windows, but I wouldn't be surprised if the idiom were the same there. 



  • @morbiuswilters said:

    an exclusively-created file
     

    No way! Globals!



  • @Talchas said:

    Additionally in the DllMain docs, in order to make an initialization routine that is only called once, their suggestion is "the initialization routine can create a file with an ACL that restricts access, and each routine in the DLL would call the initialization routine if the file does not exist." Is there really no better way to do this? No say global variable you can create?

    This is quite cumbersome approach and only makes sense if you want to uniquely initialize something systemwide, in which case it would be very unwise to do that in DllMain. The better way would be then to create a global named volatile object, which could be any kernel object, or volatile (non-persistent across reboot) registry key.

    Actually, DllMain is only called once with DLL_PROCESS_ATTACH code, and this call is serialized vs all other DllMain in the given process. You don't need any other means of serialization for that.



  • @MasterPlanSoftware said:

    No way! Globals!

    When is ammoQ going to wise up and finally ban you?  Maybe he's just not man enough to make that move, but I remember a German who was man enough...  He led the German people out of a major economic depression and towards world domination.  Some called him a murderer, others a hero.  Perhaps ammoQ is afraid he won't live up to the expectations his nationality has set, but I believe he will come through for us.  Amen.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.