Thanks for the suppprt Sascha, I really appreciate it.
Hi Neil, I am the author of LAN Speed Test. Thank you for your comments and concerns. I totally get it - and wrestled with this myself as I decided to make the switch to Xojo. I have to say though, that the benefits far outweigh the drawbacks. Let me explain… Previous versions of LAN Speed Test were compiled with PowerBasic. It was a great tool in it’s day and very efficient. The owner passed away, and PB was no longer being updated. I knew that I had to move on. I researched a ton, tried different compilers, and decided that Xojo was going to be my compiler from now on. Yes, the app size was going to be larger, and I was now going to have to include Xojo’s .dll files, but felt that these drawbacks would be minor compared to the options that Xojo would give me moving forward. Now, LAN Speed Test includes a very helpful graph, an updated User Interface, HI-DPI compatible, Mac & Windows versions, and other features that I could not have done previously.
Getting back to the files, the plugins are only Xojo’s plugins. The majority of the 70 MB (60 MB) come from the XojoGUIFramework32.dll and XojoConsoleFramework32.dll files. Both are required as I use helper apps for the network tests and scans. The majority of the extra files that are there are Microsoft’s API support files that I decided to include (40 files) so that it works for those that have not done this Windows update, and 212 small .html help files. Previously I had the help built into LAN Speed Test, but it was difficult to keep up with different Help systems for the app (which now includes Mac), the website, and .pdf files. I decided to go with HelpnDoc as this was a great tool to create a help system that worked for all three options. I’m still wrestling with this though for the app, and hoping to come up with a better solution instead of all those .html files produced by HelpnDoc. If anybody has any ideas - i would love to hear them. I thought about making the help files available online only, but know that some of my customers have limited Internet access and do not want to inconvenience them.
Being able to just download the single file and run it for your network tests was simple and convenient. This is not totally gone with the latest versions. The portable version is also convenient. It is larger than it used to be, but almost as simple. Go into the unzipped folder you only see LAN_SpeedTestPortable.exe and an App folder. just run LAN_SpeedTestPortable.exe. The prefs file and all other files are stored inside the App folder which makes it easy to run on any computer from a memory stick or shared folder.
Again, thanks for your comments. I hope you try the newest version. Let me know what you think.
Thanks,
-Pete
Apple supply a limited number of help files. If you ask for other help files, Mac OS download them from Apples file servers (process have to be discovered)
I understand why you made the decision you did. The interface is great, but frankly all I need is the two numbers. I have (the old version) located in a shared folder and access it from there by all the computers on the network. The new version takes to long to run across the network. Also a side note your new version reports a slower speed than the old version.
I agree that for an ERP system the app size is not an issue. It’s small utility tools where it’s not ideal.
@Neil Burkholder
I can tell you are going against the popular belief (at least among Forum members). You can keep raising this issue with Xojo, but as I and few others have found there is very little traction for this request. I’m sure you will find other systems/groups where compiler optimizations are as important as aesthetics, and where the amount of perceived bloat is not popular, but this isn’t one of them. And to be fair having to deal with multiple platform compatibility requires some sacrifices; and with everything else that needs addressing by Xojo, compiler optimizations probably don’t even move the needle.
I, for one, find the bloat in app size very off-putting.
There are those of us who agree with him. It’s one of the reasons I still use RealStudio, for example.
It’s one of the reasons I use C#. I built an entire payroll app and it’s a single file executable of 872kb, most of which is graphics.
A computer program is like the contents of a house… it will expand to fill all available space 
At one time our computers were “single room flats”… today they are the “Empire State Building”
I know, I know…
I’m getting 400mbps internet at my business, but when I’m on the road I have as low as 2mbps. It’s not the hard drive that is the problem. Once 1gbps is the standard minimum speed for internet then this problem will go away. In the mean time if I’m downloading a 3D drawing app like SketchUp, I’m not surprised by a 150MB installer. On the other hand for a small utility tool like ScreenToGif, I like the fact that it is a 876KB single file executable. It’s important to me anyway.
Well there is definitely a lot that can be fixed in app size in the Xojo included engine. If you open up the DLL in Text editor then you will find there are long copyright texts there for this and that.
Why would you have copyright texts in the compiled DLL ? Noone will ever see them there anyhow ?
The fact that even things like this is not optimized out then you can only wonder what else is bloated in there.
And I agree with Tim all the way, it is very off putting.
you did 
Only because I was disturbed by the size few nights ago and went to check what was in it.
Right right, so some of us devs still notice this sort of thing. But the point is, surely, the vast majority of our users and clients just dont care at all.
And if you care this much, honestly, youre using the wrong tool. Its not that I think we should be wasteful or not do our best to be efficient - I think we should - but you cant use a very high level, multi-platform RAD tool like Xojo and expect tiny binaries.
But again, I think its a waste of time worrying about this any more. You might still care but the people that pay our bills just generally dont ignore if your desktop or mobile app is 10MB or 100MB.
[quote=404441:@Björn Eiríksson]Well there is definitely a lot that can be fixed in app size in the Xojo included engine. If you open up the DLL in Text editor then you will find there are long copyright texts there for this and that.
Why would you have copyright texts in the compiled DLL ? Noone will ever see them there anyhow ?[/quote]
Copyright law is bizarre sometimes, and it’s very possible this is a legal requirement.
Copyright text is probably not the biggest contributor to the XojoFramework.framework size anyhow.
My clients care. A lot.
Since about 2013 and the release of Xojo, I tend to agree, which is why I have moved my primary development to other toolsets. I just keep wishing for more from Xojo.
I know we are now way off topic, but I for one miss seeing the number of posts that we used to see from you.
There are things that we can do about it, in code. Now bear with me as I’m going to demonstrate a point, but it’s only one thing and therefore the numbers are not that significantly different.
In one of my kits, I changed the subclassed controls to use an interface, rather than addressing them directly. This means that the kit can now operate without any other dependencies than the added class interface.
In my example I only used one function from the Kit.
base application (no kit code) 13,684,612
Kit with dependencies 14,074,396 + 389,784
Kit using class interface 13,691,408 + 6,796
So by switching to a class interface, those controls that were not needed, were no longer directly referenced in code, and therefore no longer included in the application. So I saved a total of 382,988 bytes, which doesn’t sound like much, but if you have a monstrous application with lots of situations like this, they can all add up. You’ll get even more of a saving if these unnecessary objects use a plugin (Xojo or 3rd Party).
Don’t forget; we’re not talking about removing functionality from the application to save space, we’re simply making sure that what we don’t need is not actually included.
Addendum:
I then used App Wrapper to clean some stuff (like the 32-Bit framework, language packs and video player graphics that this application doesn’t need) and got the resulting application down to 7,602,910, that’s 54% of the “Kit with dependencies” size.