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

[Kornman00]

So these plugins you speak of...you force them to not use CRT as well? What about the common runtime libraries used by other languages? There's a reason why they're called 'common' and are shared libraries.

Also, 32-bit processes generally have 2GB of addressable memory (user mode), with the game having been designed originally for a machine with only 64MB of RAM. Yet you're worried about 1MB? Have you even performed any useful profiling/measurements to prove all this effort is actually worth the time?

[RadWolfie]

So these plugins you speak of...you force them to not use CRT as well? What about the common runtime libraries used by other languages? There's a reason why they're called 'common' and are shared libraries.

No, they can still able to use the CRT. It's still being used by LoadLibrary function, I'm hoping I can actually replace it as well. Once it has, I'll make sure the CRT to be check and run support as well. I just need to verify the requirements for H-Ext to have ability load the plugins before it can actually be load as active plugin. However this isn't the main focus at the moment. As for 'common' and 'shared', there are two different version which is Multi-Threaded (/MT) and Multi-Threaded DLL (/MD). We are using the Multi-Threaded (/MT) which doesn't share the libraries of common runtime just like Halo does to another DLLs. If we do use Multi-Threaded DLL (/MD), then we get a lot of reports it couldn't startup due to msvcr__.dll missing. So this is not an optional for us and don't really needed the std library to go with it.

Also, 32-bit processes generally have 2GB of addressable memory (user mode), with the game having been designed originally for a machine with only 64MB of RAM. Yet you're worried about 1MB?

We aren't worry about the 1MB, however one of the hosting company does. Although, it will give more room for the user to add another plugin if they want to.

Have you even performed any useful profiling/measurements to prove all this effort is actually worth the time?

One of the old blog post long time ago from micorsoft's staff demostration the file reader by using with and without standard library to trim down the load, processing, and unload time. That is one of the proof and I have seens some improvement in our CiniFile in Add-on API 3.0 . The other proof was our contribute whose has been helping out along the way when I was having some issues and remove extra useless functions that aren't in used. The point was our contibrute made his own analysis with his third-party comparsion of with and without either of CRT (C runtime) and STD (Standard) Libraries. He showed me the improvements without them with less delay on startup.



From 3 years ago, I made my stand to say it's time to change the incompatiable third-parties on Halo to be compatible and be friendly to each other. The question is... are you?

E: Can't find the strike format on this editor. Using bold letters to correct my spelling.

[sehe]

LOL

If you let other plugins use CRT, then you could just compile your code whit /MD and SHARING libraries whit the plugins etc. Basically now if you have at least 1 plugin that uses CRT, then it will actually using MORE memory because you static linked everything into your app.

We aren't worry about the 1MB, however one of the hosting company does.

I'm pretty sure they were worried about your memory leaks and not of that +1 MB.

And CRT initialization takes about <10ms I guess and that includes the stuff you have to do anyways like initialing the global variables/classes etc..

[Kornman00]

What hosting company was this? I have never heard of any issues from the usual hosting providers used by CE players. If it's only one company, I question their ability to provide quality server hosting and thus someone's choice to use them (you get what you pay for).

I have to question the experience and abilities of someone with desires of replacing LoadLibrary. Also, there's a little thing called the VC++ redistributable. It's what you install with your release builds of your product. This is how you fix your "msvcr__.dll missing" problem. Treat the cause, not the symptoms.

What the hell is "contibrute"? I'd be more concerned about speed during runtime, not startup which is just a one-time thing. I would also rather develop with modern code and libraries, than reinvent the wheel.

Open Sauce's major releases are open source, and has a very specific development mentality (we deal with the entire engine, not just the game releases). We don't have to the time or patience to worry about how OS works with other people's shit. I'd rather we integrate the desired functionality into the codebase (making it open source too, unlike most of the other projects out there).

[sehe]

About replacing LoadLibrary: http://www.joachim-bauch.de/tutorial...l-from-memory/
It works fine, it's not as a big magic as it seems.
Not like LoadLibrary has anything to do with CRT btw.

[RadWolfie]

And CRT initialization takes about <10ms I guess and that includes the stuff you have to do anyways like initialing the global variables/classes etc..

I am not entirely sure, however it has to do with the functions next to the global variable preventing it to be complie. I had experenced with this issue and moved them into the dllMain as a global initializing for any of the variables to be initialize. The rest of the global variables are pretty much as it is as define in the value.


Sehe, it wasn't even about the memory leaks. Also claims your SAPP is using too much memory. So I wasn't the only one, just fyi. As for the post about the replacing the LoadLibrary, we have seen it before and have seen other replacment too. Although, still are taking precaution and is not a high priorty. Thanks for sharing.


Kornman00, which is reason why we are taking precaution steps with replacement on LoadLibrary. Using the modern code and libraries are what we asked for. However, it take more processing time with them. This new recode which basically remove every part of standard library and run better, even on the older computer as well.


I never asked you to take your time to worry about other people's "shit" and please do mind your manner. I am not against you or anyone else involving with third-party creations. Also what if some users don't even want any of the extra integration features that has nothing to do with game engine? And we will have a finished crash report that will determine the actual cause by a third-party or not. We also deal with game engine and the game releases. From what I remembered the Open Sauce's dedicated server executable is still using the patched from Termy's Patcher, that also need to be fix. What I heard form our users says SAPP isn't compatible with Open Sauce. Although, our project do able to run with Open Sauce just fine. We did perform some tests relative to player's coordination, vehicles and cloning objects. No conflict so far.

[sehe]

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.
In the other hand, I reduced CPU usage by 80% or more.

Anyways, no one ever complained about memory usage of SAPP to me, because proper hosting companies like GameServers.com not running PCs with 64MB RAM but at least 8GB.

I would not pay anyways for hosting company that whines about +1MB of ram when DDR3 RAMs are cheaper than ever, and you can buy 8GB for irrelevant amount of money for a company.

Also, you saying that your code is better than the std library which made by skilled coders who have at least a master degree and 20 year of coding experience? I doubt that.

Edit: Oh and looks like you ignored our comments about the shared libraries...

[RadWolfie]

Lol, didn't talk about a 1MB RAM limitation and Halo can't even run on 1MB RAM either too.

Didn't say our code is better than the std library, just doesn't need all of extra functions from a std library which we do reduce to only what is needed. Also we have done some profiling with std libraries at run time which took more processing than our code. Also we are not using the Intel's complier too, only Microsoft Visual Studio.

Hmm... Ah found what I left out, thanks for pointing out about the shared libraries.

CRT isn't shared across the msvcr__.dll, only the std library does. So basically the CRT are built-in, if you're saying I'm wrong about this. Please do and I will make little more research about it. Plus by using the /MD forcing us to include the msvcr__.dll file for every release builds is not even important for us to do. The only option for us to do is use the /MT instead. We used to provide an installer binaries with our older builds. However, we no longer doing that due to time consuming, constant updates, maintaining the website, etc. So we do not actually include the VC++ redistributable as there's no reason to constantly include it for every releases.

P.S. If any of you feel like I left out the response to your question/comment, then let me know and I will response it.

[sehe]

WTF? No one talked about 1MB limitation, don't even think there is such small RAM existed for PCs with x86 CPU.

If you use the /MT switch then compiler obviously cuts out the functions you never call (in release build), otherwise it would generate a 5MB+ dll, or if you use the /MD switch everything will be in the shared dll, and yours will be even smaller.

And no, CRT is shared too.
http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx

[Amit]

What the hell is "contibrute"?

He means contributor. There is an obvious language difference here. I'm surprised you didn't get it.