H-Ext (Halo Extension), Support for Trial, PC, and CE! Both client and dedi!

[urbanyoung]

I really cannot understand why you didn't want to use the CRT. What are you using as a memory manager, Windows' HeapAlloc? Also, why would you ever want to replace LoadLibrary? There is absolutely no benefit in doing that for your use case - you're loading kernel32.dll anyway, and as btcc22 mentioned, most system dlls don't physically get loaded into memory just for you (other processes are already using them).

By the way if you don't want to install the redistributable that Kornman linked to, and you're using msvc10+, then you can simply include the dlls along with your code.

[RadWolfie]

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.

[Btcc22]

What's this compatibility problem you keep talking about? The main thing you have to avoid doing is freeing memory across module boundaries (potentially using one version of the runtime to allocate and another to free) and that's an easy problem to solve without resorting to ditching the CRT. Either export a couple of wrapper functions for memory that's going to be allocated/freed across boundaries or use an external allocator like LocalAlloc.

Additionally, the CRT is versioned, hence names like msvcr100.dll. If somebody compiles a plugin using a different version, you just get another DLL loaded in. If you've got msvcrt.dll in mind, you're not supposed to be using that even if plenty of older applications do so. It's supposed to be strictly for system use.

[RadWolfie]

msvcr___.dll; Again I already explained our vision for the plugin system to be expected to work with. Some rather work with C++, C# (working on this), F# (not tested), VB (not tested), or any of the languages that are supportive for C native language interface. I won't enforce them to expect use C++ and must be specific complier version in order for it to work with our H-Ext.

After creating a plugin in Visual Studio 2008 (not the same version as H-Ext), I experenced with new/delete issues with our header. We have included the new/delete in the header which are exported to be used either from directly or one of our header that do required it in order to transfer the data between the plugin and H-Ext.

Hmm... so you're saying we're not allow to use kernel32.dll, ole32.dll, user32.dll, or any of the system dlls? Pretty sure they're not "only system use" since Microsoft provide them for us, developers, to use since it is integrated with Window's operating system. Must have read it wrong on the document specific for CRT's. So CRT is out of question now and isn't needed at all.



Everyone, please do not discuss anymore about "why we excluded the CRT and standard library" which is self-explained again in first paragraph of this post. We already made the final decision about this before the development on H-Ext, 3rd generation., has started. If the developer of the plugin wished to use the CRT and/or standard library, they can do so. We do not protest this at all.

Since we have plenty of time before the release date, we will go ahead and remove the final std library variables. Also, we have updated the Add-on API 3.0's events documentation on our Bug Tracker section.

[sehe]

Just pointing out your grammar isn't define of what you are trying to say.

Funny that someone who speak English even worse than me points out my grammar (which was NOT ambiguous at all [just asked Btcc to be sure and he's from UK] lol).

I don't understand why you have to "point it out" anyways, I didn't point out either that 80% of your posts that makes no sense at all or contradicts each other cuz of your bad english or simply because it's just moronic.

Everyone, please do not discuss anymore about "why we excluded the CRT and standard library" which is self-explained again in first paragraph of this post. We already made the final decision about this before the development on H-Ext, 3rd generation., has started. If the developer of the plugin wished to use the CRT and/or standard library, they can do so. We do not protest this at all.

Not sure if I should cry or laugh.

[RadWolfie]

Hmm, that's completely off topic so this is what I will say.

Well, spoken english isn't going great with big words and which I don't actually use spoken english. My actual primary language is American Sign Language, try learn that since it is hard for hearing people to learn or some are successful whom are motivated to learn ASL.


80% of my posts are programmer talk, if you don't understand programmer talk, then you're not caught up yet. Or you just don't have experence enough with slightly advanced plugin which is competely different from single standalone executable and modules. In order to have better experence with plugin interface, you will have to create your own plugin interface in different complier versions, optimizations, and possible other different language that is able to use the same plugin interface. Oh by the way, you failed english due to 2-3 sentences in one single sentence. So, learn your mistake and improve it. That's all you have to do.


Cry, as you do understand as you have the similar experenced as I do. Laugh, as you are completely clueless of what I have experenced in past 2 years and what I am trying to achieve.


Any more of off topic will be competely ignored. Now, back on topic.

[sehe]

Yes we are laughing at how far you reached despite you have no clue what are you actually doing LOL.

80% of my posts are programmer talk, if you don't understand programmer talk, then you're not caught up yet.

You ignored everything we said and ended up asking not to discuss about it anymore.
Most of your sentences simply doesn't make sense AT ALL but we blamed your bad english and acted like we do not think you are a retard.

Basically (from what I understood of your posts, [and no, not because it's "programmer talk", but because it's simply makes no sense]) you removed CRT and STD since some hosting company you still did not named figured out that extra 1MB is too much that CRT and STD (?) adds to your extension. Oh and because they do "useless things that no-one wants" that slows down loading by 10ms LMAO. We still did not see actual numbers/benchmarks tho.
So instead, you decided to write everything from the scratch adding shitload of memory leaks and exploits to your extension and decided to use custom load (but why?) even tho LoadLibrary is in the kernel32.dll which is loaded into every application and has nothing to do with the CRT or STD.
Edit: Right, to protect your users. Then tell them to don't use your extension perhaps.

Although I know its totally useless, let me explain the difference between /MT and /MD one more time.
If you use the /MT switch, compiler will static link the CRT library into your extension, while whit the /MD switch it uses dynamic linking, that means you will have to include the msvcrxxx.dll and the msvcpxxx.dll to your extension or put a link to the readme.txt that they have to download the C++ redistributable package if they don't have it already. However, these dlls only loaded into the memory ONCE, because they are SHARED. This means if ANY application in the PC uses these, they will be loaded into the memory, ONCE. So basically if only one of your plugins use these (which is very likely) your work removing the CRT was ABSOLUTELY TOTALLY USELESS since it will be loaded into the memory anyways. Actually with static linking your "own CRT", your extension will probably consume even more memory, not even talking about the memory leaks and the unstable code. Also you have no proper documentation either since "it's using too many space on the HDD".

Plus the file size for including the documentation with the Add-on API are very costy for our server to host (our harddrive isn't that big and is actually a mini computer).

I'm still trying to interpret your following sentence:

Also, standard library are not compatible with older/current/newer complier as they are very different due to "msvcxx.dll" files. This is not a C native langauge either too. Our inferfaces are C native language which expect almost all complier (that works with C native interface) to work normally.

???

Also:

Supportive C language expanson (Basically support C, C++, C#, etc Add-ons)
Plus allow the developers to use their preferred compilier version instead of "must be" specific compilier version. We are still trying to figure out with C# lanuage to work with our API interfaces.

Do you know that C# has nothing to do with C++ apart the actual "style" because it's a managed language and it needs CLR to run? Better not mentioning the memory usage of that.

In conclusion: You are either a complete moron or a troll.
It's quite obvious for everyone here that you are the one who does not understand of what we are trying to explain to you.
Ignorance is a bliss huh...

PS. My English is still better than your's, tho my native language is Hungarian which is one of the hardest language on the earth. :P

[Kornman00]

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.

You want to replace LoadLibrary in order to perform the function of yet another preexisting win32 function, GetProcAddress?

Frankly, you sound like Windows store with all this 'control/verify all the things!'. If you want to be open, link to approved plugins. Require the plugins to be open source. Assuming anyone even writes plugins for a framework which is only partially open. You're worried about someone potentially scamming modules, when the system itself can be scammed as well.

API versioning can be easily handled by exporting a proc which returns the version the plugin was built with. Think smarter, not harder.

Someone could create a kernel32.dll hook which forwards the calls you need, just as people create DX hooks.

[RadWolfie]

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.

[Btcc22]

Even with your table, I still can't see why you're so determined not to use the CRT. Your logic appears to be, "because other modules use the CRT, we won't".

Here's the key question that you haven't really answered: Why would you reimplement all of the functionality provided by the CRT instead of just using it like you claim the add-ons will be able to?

You original cited speed and memory usage as the reasons but now you've gone back on those, what's left?

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.

This will explain.

On another note, you really need to look for another host for your website. Nobody wants to dig around on a site with 30 second+ page load times just to find the documentation, assuming they can find it at all.