2015r2 application builds

You know, this isn’t much different from the Mac.
Some other company ripped off all my graphics for a competing mac app a few years back, simply because all you have to do is look in a resources folder.

Is putting the images into a resource folder really reducing the footprint?
Or have we ‘reduced the weight of the car’ by putting the fuel tank and the spare wheel into a trailer that we lug behind?

The resource change isn’t about disk size footprint reduction at all- please read my earlier explanations in the thread if you want to know why we needed to change it.

[quote=181127:@Joost Rongen]Of course this is the way to avoid files from being changed and check existence of the resources, but it seems that this approach change came as a surprise, at least to me.
When output (build) is not expected to be the same as it was in prior release, more attention should be given to it in the release notes.
@Travis Hill : yes I think finally it’s better not to compile unlimited resources into the EXE, even no language related data etc. , but for now it would be very nice to have compile option to stay compatible which the prior approach.[/quote]

I have the issue with some files I really do not want people to be able to peek at, noticeably custom fonts especially in Windows where people tend to pirate them so easily. The best I found was to store them Base64 encoded in a constant, unpack them for use in Temp or somewhere else unassuming when the app runs, then delete that just before closing.

[quote=181182:@Jeff Tullin]Some other company ripped off all my graphics for a competing mac app a few years back, simply because all you have to do is look in a resources folder.

Is putting the images into a resource folder really reducing the footprint? [/quote]

The Base64 encoded trick works wonder to prevent little prying eyes from looking into the bundle. It is not very good for executable size, but I rather have a few more bytes than shark bites.

Does anyone know what the failure mode is when an item in the Resources folder is missing? Doe the EXE die upon launch? Or only when the item is used at runtime?

As much as I like to fault Xojo Inc (-- kidding: you guys do great work) the problem here really is Microsoft’s : Like Apple did years ago with the “Bundle” format, MS needs to have some sort of logical grouping of an application’s “junk” that is not easily disrupted by the user clicking & dragging.

(For those who aren’t aware: on OS X, an “app” is just a special folder which contains sub-folders (etc.) that the Finder treats as a single object. Right-click and app and “Show contents” will reveal the magic).

I would argue that for most users, installers are totally acceptable and how they expect to deal with software on Windows. If all the user sees is the installer, it doesn’t matter how much ‘junk’ is in the executable’s folder.

[quote=181211:@Michael Diehr]As much as I like to fault Xojo Inc (-- kidding: you guys do great work) the problem here really is Microsoft’s : Like Apple did years ago with the “Bundle” format, MS needs to have some sort of logical grouping of an application’s “junk” that is not easily disrupted by the user clicking & dragging.

(For those who aren’t aware: on OS X, an “app” is just a special folder which contains sub-folders (etc.) that the Finder treats as a single object. Right-click and app and “Show contents” will reveal the magic).[/quote]

Microsoft does have a notion of Bundle https://msdn.microsoft.com/en-us/library/system.web.optimization.bundle(v=vs.110).aspx but it is used mainly for web apps. That said, the Mac OS bundle is little more than clever disguise for the application folder. And boy, does it contain junk :wink:

The notion of Resource folder arriving in Windows, identical to what is present is Mac, is probably a good thing, as it enables the same kind of practices of pointing a folderItem to these resources without having to recreate them. Moreover, it minimizes the need for extra cross platform gymnastics.

I use the base64 constant method to hide files within the code, as it was the case before, but there are other possibilities, like encrypting a virtual volume and placing it into Resources.

What I would love, now, is SpecialFolder.Resources .

Yes, but…

A problem with windows software is that if you download an EXE through IE the behavior is nice : you get progress bar, security scan, and auto-launch upon download completion.

If you download an EXE.ZIP then the behavior is fugly : the progress bar is inaccurate, the security scan can’t happen until the end of the download, and once the download completes “nothing happens”. (The savvy user will find the download, click Extract All, then find and double-click the EXE Icon. If they are not savvy, they will double-click the Zip file, then click the EXE and get the BevelButton crash described above).

For these reasons, there is a still a need for small-self-contained windows EXEs for software delivery.

Yes, InnoSetup (and others) can make this, but these sorts of third party software are not just “acceptable” they seem to be “necessary”.

I would say they are “expected”.

[quote=181214:@Michael Diehr]Yes, but…

A problem with windows software is that if you download an EXE through IE the behavior is nice : you get progress bar, security scan, and auto-launch upon download completion.

If you download an EXE.ZIP then the behavior is fugly : the progress bar is inaccurate, the security scan can’t happen until the end of the download, and once the download completes “nothing happens”. (The savvy user will find the download, click Extract All, then find and double-click the EXE Icon. If they are not savvy, they will double-click the Zip file, then click the EXE and get the BevelButton crash described above).

For these reasons, there is a still a need for small-self-contained windows EXEs for software delivery.

Yes, InnoSetup (and others) can make this, but these sorts of third party software are not just “acceptable” they seem to be “necessary”.[/quote]

Windows users simply expect an installer. I cannot really understand why you want to force a naked executable on them. All you will get from that is confused users and support requests.

Better build an installer, which is an EXE as well, and place it for download as such. You will get the nice IE behavior, and spare users haphazard manipulations like : enter their administrator password, confirm they actually want to run the program to satisfy SmartScreen. And since the program has not been installed properly, every time it is run, it will require SmartScreen vetting. IMHO, that could have been possible back in the eighties, but it is downright unacceptable in the 21 st Century.

Microsoft never intended the IE auto-launch to run unknown EXEs, and I bet SmartScreen is up in arms when you do that. Let alone antivirus programs. And for good reason. This an awful hack, if you tell me. Besides, users do expect to be able to remove a program in the Control Panel if they want. They should not be subjected to undocumented procedures such as locating an executable in the Downloads folder to delete. Worse yet, what happens if a user decides to clean up his downloads folder and erases his program ? On top of it, if he tries to use System Restore to recover the lost program, it will not work, as the EXE has not been installed properly.

Why don’t you simply follow Microsoft guidelines to insure the comfort of your users ?

As a Windows user I hate installers - rather just unzip and run. I admit that the semi-computer-literate majority would prefer an installer, and they are probably appropriate for commercially-sold software, but if you vaguely know your way around your machine they are often a pain. They are like the proverbial out of a shotgun - plonking crud in your registry, your system folder and who knows where else. Then the uninvited, unwanted “updaters” that insist on starting with your machine that clutter up your startup, waste resources, and go online just when you don’t need it. Many unethical companies also add in a surprise toolbar that does god know what. Even a program like Acrobat Reader, if you don’t watch it, plonks the horrid McAfee on your system. Uninstallers often don’t - leaving vestiges of said crud in your system. Bleh.

When I started, there was no Mac OS, no Windows, just an Apple II displaying # and saying syntax error all too often. So I am evidently extremely comfortable with the under the hood of most any desktop machine around. I, too, often prefer fussing around. But I am not your typical 2015 user.

As often in this forum, some people confuse their own preferences with what is ultimately their livelihood : satisfying users. Most of the time, I do not sell computer software to people like me (unless RubberViews becomes my core business, but somehow I doubt it). I sell to people who hardly know how to get on the Internet and have learned how to run an installer on Windows or drop an app in the Applications folder on the Mac.

As a professional who has enough sales to pay the rent and a few computers now and then, I do everything I can to minimize support requests. Not to mention nasty comments and ratings in online store, or disputes on Paypal. You would not believe the level of some users. I cannot recall how many times I had people trying to drop a font zip archive in the Fonts folder or Font Book, for instance. So anything I can do to avoid these unfortunate situations, not to mention angry people, I do. Customers today are not ready to cope with technicalities, like I was over 30 years. They know computers are supposed to be at their service, and not the other way around. They sleep with their smart phone and expect a computer to be just as cuddly.

Fine and well if you know how to race a car, but please, do not hand a Formula One monster to John Doe, who barely knows how to get to the market. He just hopes the next car will parallel park for him. Otherwise you will have a massacre on your conscience.

The part of this thread that I most agree with is the lack of attention brought to it in the list of changes in this release. We don’t normally scrutinize the changes for each release (guess that will have to change) and only noticed that the executable size was being reduced without fully understanding how this was being accomplished.

Without paying attention to this and modifying our Innosetup script to include the resources in the installed results in an application without splash screen and icons. Not a good thing! I would think that common sense would mean shouting it out loud so no one makes that mistake. As Michael Bujardet rightly points out, anything you can do to avoid support calls and make life easier for your users (in this case xojo users) is a good thing and should be encouraged.

Going back to the beginning of this conversation… would it be a good option to store all the graphics and language stuff in a SQLite database sitting next to the EXE ?
Does anybody have the experience with encrypted SQLite databases ?

Not on Windows. You can put it there but be sure to copy it to SpecialFolder.ApplicationData and access the copy. Otherwise only an administrative user will be able to run your program.

Data is just meant as resource data, not to be changed by anybody. Condition is that data stored here never changes, unless the next release.

Somewhat related: Is there a way to ‘share’ the dll folder with several EXE files? Currently we have about 50 .EXE files in our program (it is build in this segmented way partly it depends on the ‘plugins’ the user buys, partly of big memory leaks in the past RS versions, partly because of the size of the project +500.000 lines of code). Lukely, most of them are still in RealStudio but some are already converted to Xojo and each conversion blows up our program tremendously (currently almost 500MB, complete conversion would make it about 1.5GB). The point is, almost every .EXE has the same DLLs. Would be nice if we could only have them once.

If the applications are compiled with the same version of Xojo/RS you can use a Libs folder instead of “My Application Libs”. So each .exe will use the dlls in the Libs folder.

Didn’t know that :slight_smile: So technically it wouldn’t be a big problem for Xojo to point every exe to a relative path where the dlls are (with a setting in the IDE). Our current structure look like this:

SYSTEM\0001\0001.EXE
SYSTEM\0001\0001 Libs\x.dll
SYSTEM\0002\0002.EXE
SYSTEM\0002\0002 Libs\x.dll

SYSTEM\0050\0050.EXE
SYSTEM\0050\0050 Libs\x.dll

Theoretically, with such a parameter, it could become this, which would be a huge impovement for us:

SYSTEM\0001\0001.EXE -> points to …\Libs\
SYSTEM\0002\0002.EXE -> points to …\Libs\

SYSTEM\0050\0050.EXE -> points to …\Libs\
SYSTEM\Libs\x.dll

Understood but you can’t open a SQLite database read only which means that putting it next to the executable will cause Windows to have UAC alerts. You need to put the SQLite database somewhere where the application can open it without issue.