Xeon
Beta Tester
|
I'm not sure how many people care about the technical details, but the culprit appears to be "aimapi.dll". It's doing some API calls from it's DllMain that should not be getting called from that method.
According to Microsoft documentation making calls to CoInitialize/CoRegisterClassObject from within DllMain can cause deadlocks.
https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-best-practices
I disassembled aimapi.dll and managed to find a conveniently placed flag it uses to bypass any kind of initialization at startup.
Here's a patched version of aimapi.dll, all I did was a spot check though, there may be other compatibility problems still lurking.
http://s000.tinyupload.com/index.php?file_id=36461591432016390960 (AIM 5.9.6089 only)
If you don't trust the DLL, you can manually patch the file with a hex editor, just write 0x01 to address 0x163AC, and AIM should start up fine.
Here's an optional patched Aimres.dll if you want that ugly broken advert box gone off the buddylist.
http://s000.tinyupload.com/index.php?file_id=15052617666399897428 (AIM 5.9.6089 only)
To use these patched files just replace the existing ones located at "C:\Program Files (x86)\AIM", or wherever you installed AIM to.
I'm not 100% sure on what functionality you're losing with this patch (still going through the disassembled code); I have a feeling its something to do with AIM Expressions because it's registering "aolbart" as a protocol handler. I also saw some references to AIM setting itself as the default AIM client. Since AIM Expressions are pretty much dead and gone, this might not be a problem.
I'll update you if I come up with something more elegant so that no functionality is lost.
Also if anyone has another version of AIM they want the patch offset to, I can try to provide one.
|
![[Reply]](img/forum/topicreply2.png)