Quote Originally Posted by sehe View Post
Well yeah ofc, if they whine about 1MB RAM then obviously they don't like SAPP which adds 1MB + some more if they use No-Lead mode.
Just pointing out your grammar isn't define of what you are trying to say. Also, yes I am aware of difference between /MT and /MD due to separate dlls and /MD make my dll smaller. And I do preferred to be in one dll instead of separate dlls due to big difference in Visual Studio's complier. It won't be compatible for other plugins that's using a different complier including new/old version of the complier as well.

I looked into CRT and it is a system dll which is acceptable. Although, it doesn't seems to be using the CRT's dll version as if it is using the integrated. I'll need to check into this. If it is integrated, then I'll have to find out a work-around to remove the integrated CRT into shared CRT dll which Windows' system have.

Yes Amit, contributor is the word I'm looking for. Thanks for correcting my grammar.

urbanyoung, assuming Oxide, I was actually taught not to use the CRT from one of our contributor. Although, we are considering to use the CRT's dll usable shared library. No, we are using the new/delete as the memory manager and we have corrected our memory leaks in H-Ext. The reason we want to replace the LoadLibrary is to verify the dll do contains the functions requirement in order to be a "valid" plugin. If not, it doesn't get to be actual load as active plugin. LoadLibrary just plain add the module and activate it directly without our verification check requirement. That is a big nono for us. We do want to protect our users from using the older plugin that is not compatible. Including potential scammed modules which is not specifically for H-Ext. So that's a big benefit for us and our users, and we know we're loading the kernel32.dll since there are some functions being used from it.

We can, as stated before in this post, 1st paragraph, 3rd and last sentences are our general reason.