billroper: (Default)
[personal profile] billroper
It turns out that my program isn't working because the ATL COM DLL that the other guys created isn't correctly inserting itself into the DLL chain with the result that none of the MFC resources (like say, our strings DLL) are available to the DLL or any of the DLLs that it's calling into. It seems that I need to invoke a bit of MFC magic to get the thread that contains the CWinApp object to initialize its module state correctly.

Unfortunately, I haven't quite figured out the correct incantation.

I recognize that this is complete mumbo jumbo to most of you; sadly, it appears to have been the same to the rest of our development team or this would already be working.

For the moment, I'm deferring this problem to tomorrow and heading home.

Date: 2007-12-28 02:35 am (UTC)
From: [identity profile] tigertoy.livejournal.com
There was a time a few years ago when I understood that shit well enough that I could have advised you usefully. But these days, Windows arcana have a half life in my memory measured in minutes; I can remember just enough to understand your post.

I'm half convinced that Microsoft intentionally makes it hard to write non-trivial applications for Windows because they don't actually want people to do anything with computers other than run standard Microsoft apps.

Date: 2007-12-28 02:54 am (UTC)
mdlbear: (borg)
From: [personal profile] mdlbear
I do believe you're right. Part of being a monopoly, I suppose.

Glad I don't have to deal with Microsoft DLL hell -- Java classpath hassles and crypto providers in signed .jar files were bad enough. I've been writing a lot of Perl these days.

Profile

billroper: (Default)
billroper

February 2026

S M T W T F S
1 2 3 4 5 6 7
891011121314
15161718192021
22232425262728

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Feb. 9th, 2026 01:00 am
Powered by Dreamwidth Studios