Sehe, you and Btcc22 chose to ignored my posts and questioning my skills repeatly. Be sure to re-read again because we are talking about same thing except you're just adding to what I'm saying.
I'll re-interpret the sentence into a text picture for you to undersand. Not saying you're an idiot, just a helper example.
For example:
Type Name Complier requirement is sharing the requirement? General H-Ext.dll VS C++ 2005 None No Plugin RP Mod.eao VS C++ 2008 mvscr90.dll Nothing to share with other plugin Plugin Remote Control.eao VS C++ 2012 mvscr100.dll Yes, sharing with Teleportation.eao Plugin Teleportation.eao VS C++ 2012 mvscr100.dll Yes, sharing with Remote Control.eao Plugin MySQL DB.eao VS C# 2012 .Net Framework 4.5 Nothing to share with other plugin
NOTICE: This is not accure information above.
So H-Ext has no reason to use mvscr__.dll at all of which all Add-on API interfaces are C language. So you do understand something like GetProcAddress, LoadLibrary, CreateWindow, etc ARE C language interfaces? Since C#, Visual Basic, F#, etc can even use this interfaces as well.
Yes, and we again, again, are being careful not to lose the expectation of what developers wants with GetProcAddress, GetModuleHandle, and so on. We may will have to get the Windows to read the memory directly instead of read from the module's file and register it as a module. This will be done after checking the export names. Although, later will be change into a structure variable in order to maintaince any API hook name changes including remove almost all of the GetProcAddress for each hook names. All of the plugin developers don't even need to be concerned about this.
And yes we are trying to determine where to make a verify version check on specific API sections even though there hasn't been any changes on minor updates from S-Ext releases. Such as Native MDB 1.0 support from 0.3.0.0 to 0.3.2.3's API while 2.0 do support 0.4.0.0 to 0.4.2.2's API. The only differences were the standard for command function parameters has been changed. And some other additions in the process.
As for kernel32.dll, it is very small chances the AntiVirus, in-game messenger (such as xfire and steam), etc will call for kernel32.dll in a working directory instead of directly from the system32's directory. I have verified this with version.dll which is a system module on this computer and the virtual machine with original operating system (no extra third-party installed) and halo.
I am assuming DX is DirectX, yes it is very possible with any Windows OS. I'm not exactly sure why it check the working directory instead of system directory and gave me a big confusion.Although, it doesn't get to load on executable startup either.
Bookmarks