And also the In Source Binary files excluded from the source files in the main link (at the top) [These files are needed to compile the project but since they contained executable binary I had to post them separately here! (The directory structure is the same though so you can just drop them in )

Thanks Alice! Good to hear that it's working good! And yes I designed it to be easy!

I've had an issue with some games though where I've seen like double vision, but that might have gone away (It was kind of cool though and you could still work the menu! lol)... It could've been just an issue with an earlier version! (Hopefully! lol)

Anyways yes it could have a smaller file size, if I lose the borland C++ / now called Embarcadero RAD Studio XE3 C++ (lol long name)

Well I cut a lot of corners though by using it, so I guess that's what makes up for the increased file size! lol

I'm at least glad to hear that I compiled it all properly to run without needing those dreaded extra borland packages! _________________

EDIT: Okay I figured it out! (Borland packages and such) Unfortunately you can't get the whole package down smaller! You can reduce the size of the exe but I would have to either make an installer (to install rtl170.bpl and fmx170.bpl) which would require administrator privileges as you have to copy them to the WinDrive:\Windows\System directory Or have them in the same folder as the application itself (Not really that big of a deal, but it would actually be a bigger download if you don't already have those files, which I'm guessing most people dont!)Part of the reason why I made it write to the appdata folder (my documents folder could've been used as well but that's already crowded enough! lol) was to not require administrator privileges to deploy or inject the trainer (however if your game runs as admin you'll have to run the injector or your own injector application as admin)

That's with runtime packages checked and WITHOUT Dynamic RTL..(The difference between with runtime packages and dynamic RTL and with runtime packages and without dynamic RTL is insignificant so if I did it that way that's how I would do it)

If you also check dynamic RTL, two additional files are required either in the app's directory or the Windows\System dir! borlandmm.dll and cc32120mt.dll, that's an additional 1.11MB!

So just forgetting about using the dynamic run time library, rtl170.bpl is [3.57MB] and fmx170.bpl is [8.00MB] In ITSELF! So you can see somehow it's cramming all that in there with an application and wrapping it up in a 8.43MB package...

It does take each application itself (the Deployer, and the Injector) both down below 1.0MB though (very close to microsoft's size, like 500+KB's)

So what do you think? Should I make a 1 time installer application which would have a size of around 13MB's which you just run it once as administrator and it copies the rtl170.bpl and fmx170.bpl files to Windows\System directory, Then the total size of the deployer with everything included would probably be about around 2.0MB's or under... Or Just provide those two files and have you copy them their yourself (that's another option, but again requires the user to do something extra, takes away from ease of use...)

Or what I like better, just leaving it the way it is, and perhaps doing what I said before by making the injector program compiled with Microsoft's compiler!

That would at least bring it down under 10.0MB's

Or I could just keep it the way it is now haha! I really don't mind the increased file size I guess it's not that big of deal!

Anyway's I'm starting working on the next DirectX version to support, but I'm trying to decide how I should do it or how I could do it... Should each DX version have it's own DLL (don't worry they are pretty small LOL) or could I have one multipurpose DLL that would figure out which DX version the game is using and hook accordingly...

I'll have to play around and see what works for me!

Alice0725 wrote:

Did you remove the debug info. in that file? I think it should be less thant 8MB.

You mean did I compile as a release build rather than a debug build?

Yes I'm certain I have, and I double checked to just make extra sure!

All three projects are were built as release builds!

The thing is, I used two different compilers... Microsoft C++ 2012, and Borland C++

And there's different ways to compile your final executable (whether it be DLL or EXE)

On Microsoft compilers I noticed my executables would not run on a machine that didn't have either the Microsoft compiler used to compile the application, or the Microsoft redistributable package for that version. (Which contains the dynamic runtime library from my understanding)

By compiling with this setting set to Multi-Threaded /MT instead of the default (whenever you create a new project [I always have to remember to change this setting]) The compiled executable will successfully run and execute on any machine regardless if they have the redistributable package/ dynamic RTL... I don't like telling people they have to install something extra to get my stuff to work, so I just compile it this way so I know it will run, with the compromise of course that it makes the compiled executable slightly larger (at least with Microsoft)

As you can see below it, the latest DXTrainerKit DLL was compiled with Multi-Threaded DLL /MD (which makes it so you need that redistributable) It comes out to around [482 KB]

When compiled with the setting set to Multi-Threaded /MT (will run anywhere, on any machine practically) It comes out to about [583 KB] (Not bad Microsoft, it's actually not a whole lot bigger)

Note: The DLL in the current uploaded Deployer is 1.02MB, that's because I forgot to take out my RE6 .CT which was embedded inside of it! LOL So that's saving some space there! (That was when I was developing it and just testing it, now since it reads the configured .CT from disk it's not even used so no need to have it there taking up space!)

The real issue comes from the Borland C++, because it has so much built into it (which makes it really easy to work with GUI's and related, but it comes at a price) compiling similarly as Microsoft without using the dynamic runtime library, it makes the resulting binary exponentially larger! lol

I'm also using the FireMonkey component library rather than the traditional VCL (Visual Component Library) which is newer and makes the GUI look a little better / easier to customize, so that could have something to do with it too (but I even remember VCL apps as being large)

So to test this, I created and saved a brand new fresh project FireMonkey HD Windows Desktop app in XE3 without changing anything except setting it to a release build

When I compiled it with it's default settings it's only [339 KB]!

Here's the only issue though, when compiled like this it wont run anywhere, without having XE3 installed OR some other borland packages or something I'm unsure of! Perhaps if I knew what specific packages or whatever that I use only (as I obviously don't use the whole XE3, just some parts of it) then I could perhaps reduce the file size your about to see lol

So then I go into the project settings and change the C++ linker to NOT use the Dynamic RTL (This is like setting it to [Multi-Threaded]/MT instead of [Multi-Threaded DLL]/MD for the Microsoft Compilers)

However I discovered this isn't the only thing needed for Borland compilers! My apps still wouldn't run on my other machines without XE3! So by trial and error I figured out that by also setting it to compile with runtime packages unchecked, it WILL run on any machine!

Now remember this is an untouched project just saved after changing to release build! And now after changing those settings so it will run anywhere, it now compiles out to 8.43 MEGS!

LOL! So that's where basically MOST of ALL the size comes from, the Microsoft compiled DX DLL remember is only about 500+ KB's where as both of the Borland compiled EXE's start out at 8.43 MB's each!

So the total size of the whole packaged standalone deployer application bundled with everything inside it is at 18.0 Mega Bytes right now, after removing that RE6 .CT It will only be down to about 17.5+ MB's So not a whole lot smaller! But it's a start! lol

If I Re-code the Injector into a Microsoft compiled EXE using just pure win32 api, We can shave off an additional 8.43+ MB's! So then it will be down to around 9.0+MB's!

HOWEVER, if I actually figure out how to compile the Borland C++ EXE's by deploying ONLY the packages I actually use, I can perhaps reduce the size without needing to lose all the easy mode-ness of XE3! LOL

For example in order to make that injector application like I did so easily in XE3 the same way... I would need to have a PNG + JPG/JPEG + TGA + etc decompression libraries in order to decompress whatever image you give it in order to draw it on the GUI as a bitmap... (XE3 has all of that built in and does a good job of abstracting it where you don't even have to worry about any of it) I could however just forget about drawing the image / making it stretch to the window and it would be easy to covert to the Microsoft compiler with pure Win API

I'm going to look into this! Perhaps I should look into how others have been deploying their Borland C++ compiled applications! Maybe just maybe I can reduce the size while still NOT having any dependencies except what I actually use, and package and deploy with it! (So it could still be seamless execution without having to install anything extra or at least without seeing and waiting for an install progress bar )_________________

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum