d7II News: Critical Update to Custom Apps for Emsisoft a2cmd on Friday Includes Batch File Tips, Custom Apps Configuration Mini-Tutorial Here, and Yes, We Are d7IIx Alpha Testing on the d7x Code Platform!
In Today’s News:
Critical Update to Emsisoft a2cmd Help fix my customized a2cmd config! d7II Custom Apps: Configuration Options for Batch Files and Scripts Configuration Field Syntax Storage Locations (all additional files used with these settings) Today's Batch File d7II Custom App Config Explained: Emsisoft a2cmd (All) Batch File as a Custom App Command Line Parameters/Arguments Passed to the Batch File WHY do it like that? Moving On... What happened with a2cmd? Final Thoughts: (More of this!) d7IIx Alpha Testing (with the d7x Platform Code) FEED Me (d7II/d7x Specific RSS/Atom info...)
Critical Update to Emsisoft a2cmd
Last Friday evening, we released an updated d7II default custom apps profile (#58) for the default Emsisoft a2cmd custom app configurations, due to changes that company made to their portable app’s distribution, which caused failures with newer versions of their download/installer changes.
If using any default custom apps, this update requires NO prior knowledge from the technician in usage/configuration, nor any adjustment of your customized auto mode profiles or other d7II configuration options.
If using any non-default custom apps based on the affected ‘a2cmd’ configurations (e.g. “Save a Copy” button used to save modifications to a custom app’s config, and/or renamed to a new app, etc.) or for any other reason have a non-functional custom app using a2cmd.exe, then you should recreate your custom app based on what we have done for this update, if possible.
We believe the few reasons to alter the default configurations (beyond the persistent settings options) would mostly be alteration of the command line parameters/arguments passed to the custom app’s main executable, to the preference of the technician or tech shop. Should this be the case, and you see the size and complexity to this explanation, you may do well to spend just a minute or two on this quick fix for your own custom apps profiles using a2cmd.exe:
Help fix my customized a2cmd config!
Nothing beyond step 1 is necessary if you use our default apps configuration! You should only proceed with step 2 if you have a custom app that you copied/modified or created, which uses Emsisoft a2cmd, and is currently broken in any way (download failures, where automation is concerned, maybe you just can’t stop the user prompts for “installation” paths) then go to step 2!
1. Update to ensure Default Apps #58 (released late on 2017-02-03) If not updated, you should be notified at the lower status bar, and if not click d7II’s Main menu (top drop down) and then the “Check for Updates” menu item.
2. Find and select any of the Emsisoft a2cmd based custom apps in d7II Config on the Custom Apps tab. Note the search is ‘pattern’ style, so select the “Default Apps” radio button, then search for “a2” in the box above the list, and you should see all of them.
3. Ensure you have clicked the “New / Edit App” tab so you can see the “Save a Copy” button, and do that to create a copy of our updated configuration.
4. Update fields from your custom app to ours, taking care not to disturb (add/remove/modify) ANY settings on ANY tab before “Execution” and there starting only with the “App Command Line Parameters:” field.
5. If the command line parameters field from your existing custom app’s configuration ever differed at all from original, you’ll want to copy the changes you made to this new custom app based on our settings. I would strongly recommend pasting the entire configuration text field from both your original and the new custom apps into a text editor, or even just notepad.exe will do in a pinch 😉 The goal is to compare and ensure you have modified your parameters to utilize the different filenames (whitelist) and paths necessary in various parameters that you use. Paste the changes back in to the new custom app.
6. Final Step – decision time, either:
Keep old custom app for reference? Modify all of your Auto Mode profiles (or copy to new) in d7II config to implement the new custom app in place of the old.
Replace old custom app entirely? Find/select the custom apps from the “User Created Apps” radio button view, located above the left column in the Custom Apps tab; this ensures the appearance of the “Delete” and “Rename” buttons below the listbox where the app will be selected/highlighted.
- From d7II Config, delete the old custom app, after ensuring you have copied the name exactly!
- Rename the new custom app to the exact name of the old custom app.
… but don’t rush off too quick, there’s more to learn! This update prompted the necessity of a very different custom app configuration, and I thought it was a good opportunity to take a few extra minutes and explain more about not only working with batch files, but also on how they can work with d7II custom apps system to solve a lot of unique problems…
d7II Custom Apps: Configuration Options for Batch Files and Scripts
Some apps use batch files to accomplish extra tasks, and the setting for that is found in the configuration for the custom app under “Import Config Before Execution” which does some trickery many may not be aware of even with the mouse hover description.
Designed initially to copy configuration files (e.g. .INI/.CFG/.DAT/etc.) or anything with specific settings for the custom app into the app directory prior to running the app, and in this way customized settings for different apps can be carried along and used with the same configuration even in a d7II dir that doesn’t have any 3rd party apps downloaded yet, or re-downloads/re-installs the custom app.
Importing .REG files was also added to the functionality, as well as .BAT/.CMD and .VBS scripts which are copied to the app’s directory and run prior to running the app (but after any configured installer has been run for the app…)
Also note the “Save Config After Execution” checkbox setting will wait for the app to finish, at which point all files that were copied TO the app’s directory as part of the above functionality are then saved back to your d7II config directories, overwriting the old copy, which will be used for the next time the custom app is used on another PC (since you are most likely saving your config/profiles to either dCloud storage or your own local/cloud hosted FTP server, either can be configured as an automatic Start or End Session option if not already…)
The purpose for this is that updated settings in those configuration files, which you MAY have changed during a manual/non-auto mode run of the app, will be saved for the future and not lost, only to be used on this one machine…
Since it’s a dumb file copy, there isn’t much to say about the affect of this setting on .REG files (it doesn’t know what keys you configured or what to backup just by the import, so that isn’t done) and obviously the scripts aren’t usually dynamically changed, but if they were they would get updated/saved too, that’s just unlikely.
Configuration Field Syntax
- Syntax is filename.ext without any path info, since it will always look in set paths relative to the d7II.exe file for them.
- The setting support multiple files separated by a comma, and the syntax is: “file1.dat,file2.cmd,file3,vbs,file4.ini“
- Batch/scripts would run in the order of input in the config field, as in the above example the .CMD file runs prior to the .VBS
- All files (in the above bold example) including the .DAT and .INI, even though in a different order, should be copied to the directory before executing the batch/scripts… Please note that “should” means if it doesn’t work, it isn’t a bug so much as I need to remember the exact mechanics before I go blog posting, and that I will need to verify but if that isn’t the case, then the expected behavior should then be to put them first in the field just as you would respect order of the the batch/scripts…
Storage Locations (all additional files used with these settings)
[Your d7II directory\Config\CustomApps\3rd Party Configs] (Your created/modified custom apps.) While at least the last subdir would not exist if you didn’t make it, it can be created or you can copy the same dir from our default app storage discussed below and remove what you don’t want…
[Your d7II directory\Config\CustomApps_d7II\3rd Party Configs] (Our maintained default custom apps.)
Important! Everything from [CustomApps_d7II*] including subdirs is overwritten on a custom apps update (in fact I believe the dir is completely deleted) so any changes you make there WILL be gone, with only one exception: changes made from the “Persistent Settings” tab when configuring a custom app can persist, although only by using the “Save Custom Settings Only” button specific to that tab alone. Configuration is saved separately only for those settings with respect to that default custom app, and when saved along with your d7II configuration profile locally and/or to/from cloud services, they do persist after a default apps configuration update…
I would strongly recommend rather than manually copying any default custom app configuration file [\CustomApps_d7II*.*] to instead use the “Save a Copy” button in d7II Config, when you find and select the app from the list on the Custom Apps tab, and then choose the New/Edit tab.
Here’s why: Apps with the same name in the two different directories WILL confuse d7II auto mode profiles in a big way, so please don’t do that! This behavior is a side effect of the system used to intelligently find pieces of modified custom apps as necessary, as well as a limitation added from the configuration of other settings related to both the apps and d7II interface itself.
d7x Update Tidbit: We do plan to work on removing this same-name app limitation using possibilities available in the new d7x platform code to replace older functionality that produces these limitations. More below!
Please note that the “Save a Copy” button only saves the single Custom App configuration file to a new filename and perhaps there is another minor config modification, but it won’t create the [\CustomApps\3rd Party Configs] subdir for you, or copy any corresponding custom configuration or script from the [\CustomApps_d7II\3rd Party Configs] location.
Instead d7II.exe will intelligently determine which location has the config as necessary. So a config for your copy will still be pulled from our maintained default apps storage, UNLESS you manually copy that to the new location.
If the same file exists in both different 3rd Party Config directories, your custom one should take precedence currently, however (another let me verify this) but if not already, the behavior for this will likely be changed in the future to consider the last modified date of the file itself, and possibly other factors.
Today’s Batch File:
After updating to default apps 58 profile, check out the batch file! (Ahem, right click / edit if you’re not used to that, but a double click won’t hurt anything if you make the mistake…)
[Your d7II directory\Config\CustomApps_d7II\3rd Party Config\a2cmd.cmd]
With all that said, I’ll leave the batch file lesson itself in the file itself which contains a few good practices in the bits of code/syntax that should be commented well for the interested, including a section that retrieves d7II “Session” data from the registry (path info in this use case) that creates a whitelist for the Emsisoft a2cmd scanner to protect d7II and other custom applications from being targeted during the custom app’s run (a task actually being done for most any custom app providing the opportunity, and though some utilize per-path direct command line arguments, others allow a whitelist file to be generated, which is performed by this batch file.
Note the context of the batch file code, which needs to know where it is located in the file system, and as the author you need to know that d7II copies this to the final app path, which is found in the d7II Custom Apps config field “32/64bit App Path/Executable Name” and if not a complete path, then by default it is the root of [Your d7II directory\3rd Party Tools] directory for apps where this setting has no path but only a filename; likewise adding a partial path, e.g. [some subdir\file.ext] will prepend the 3rd party tools directory to this path (note there is no preceding backslash in the partial path.) For partial paths, unless it is a complete path (static paths are accepted, but Windows environment and other d7II specific variables can be used here as well and are recommended where possible, as in certain other configuration fields.)
d7II Custom App Config Explained: Emsisoft a2cmd (All)
The largest concept here that you wouldn’t normally see, is the idea that the batch file used with the custom app is used BOTH as the config setting/script to run BEFORE the app, AND as the custom app itself, causing it to be run twice as part of the app’s execution, and with both executing prior to the app itself.
Batch File as a Custom App
See the last paragraph of the last topic above for more on the d7II Config field “32/64bit App Path/Executable Name”
For this custom app, we’ve chosen to configure this field from the “Execution” tab to actually launch our batch file (as well as the Pre-Execution tab’s “Import Config…” field) instead of the custom app’s main .EXE file. Since our batch file exists in your d7II configuration, and NOT anywhere you want to just host it and download from your own FTP/web server, then it isn’t a complete custom app. As such certain things must be satisfied to make it all come together, and it helps to have insight on a few little intricacies in how the spider web of d7II custom apps handles processing the order of certain config settings, such as the actions taken to get the apps setup/started and cleaned up later.
For one, having the download URLs configured means that the app is always expected to be there (if not installed it will be) at least if internet access is to be had and/or the installer exists in your [\3rd Party Tools] dir… but there’s more to consider.
Since our batch file’s first run will be to run the app installers (after deciding on using the 32/64bit exe) there’s a problem – the batch file is copied to the app directory, which doesn’t exist until the installer is run. Since d7II can’t do that for running the installer and the batch file will, the problem now is that even though d7II is downloading the installer, it isn’t running it, and still it will expect the app to have been installed to the actual (final/installed) custom app’s main path\executable directory (the one linked/explained above.)
The issue here is ultimately pretty silly compared to the normally powerful no-nonsense do it or else functions in d7II… but specifically for the “Copy Config…” option, the functionality does not copy our batch file to the app directory (to execute it) when the app directory doesn’t exist first; it is in fact coded to skip creation on non-existence, unusual for d7/d7II, but it was for a reason! Even with failure checking, there are little to no blanket recovery options other than try the same thing a second time and expect the different result (determination or insanity?) So when different 3rd party apps fail differently from time to time, depending on the different ways they were coded in the different languages, with the different levels of whatever requirement is broken under various system conditions…
So it was reasoned this behavior would be more work on the tech using d7II when it came time to cleanup. For example if it created the directory anyway, copied the config (or script, not originally an option I might point out) and then moved on to the next app, well it just essentially did that for no reason — since we know the app was not working already when it failed to install, the dumb planting of the config that created new directories was inviting hassle for our techs when it came noticing the resulting omissions in cleanup through automatic d7II tasks, and a minor pain in the PSU for the obsessive cleanup qualities that we techs mostly seem to share…
Since the dir creation would’ve been pointless, the foresight at the time of original development didn’t include it ever being necessary to set a custom app up in this way (one of many lessons learned for the d7x platform code and the design of the new custom apps system!)
Now the installers will normally download to our [\3rd Party Tools] dir, and that’s where we want the batch file to be, but you want a partial path/subdir of 3rd Party Tools else other issues can occur; it’s also can’t be in the final app path of [%systemdrive%\Emsisoft …..], which doesn’t exist until the installer completes.
A [\3rd Party Tools\Emsisoft_a2cmd] subdir is created by the download syntax where the “Save As File” field will contain a filename with partial path (the subdir to create within 3rd Party Tools) which in this case was “Emsisoft_a2cmd\EmsisoftCommandlineScanner??.exe” Naturally keeping it different in the 32/64bit settings for filename, so they can co-exist, the same directory can be used, and the batch code simplified a little as well as the entire process.
After this directory is created by the download, the installer setting is skipped, and the copy config setting triggers the first run of the batch file, which is copied to the directory created by the downloading of the necessary installer, and that only works because again, the batch file is configured as the custom app’s main path\exe.
Command Line Parameters/Arguments Passed to the Batch File
The concept works with logic contained within the batch file to act differently depending on how it was started, and this serves to prevent potential issues caused by the same tasks being performed twice; in this case it is a simple determination on whether or not the batch file was launched with any command line arguments/parameters.
With NOTHING passed, it performs the config/batch (pre-app execution) functionality necessary.
With ANYTHING passed, it will act as the custom app itself as far as d7II is concerned, but in fact the batch file just runs the custom app using the parameters passed to it by d7II, which of course were all intended for the custom app anyway, NOT the batch file…
You may have previously seen the “Wait for App Termination & …” checkbox used with this app in the past, and since we’re running our own console window (for the batch file) which d7II must wait on, the batch file is configured to identify itself (for the tech using it) and also it launches a2cmd.exe with syntax designed to wait on the process.
The potential problem with this is that the console window waiting on the custom app could be unknowingly closed by another app or accidentally closed by the tech manually, for whatever reason, at which point d7II would stop waiting on the closed console window. The next d7II action is to continue with any configured post-processing for this app, or the execution of other custom apps in a running auto mode profile, which could interfere with this app’s operation. Especially since it’s now “flying solo” and no longer part of anything d7II is paying attention to, many of d7II internal functions will cause problems as well, both manual and automated.
To prevent the issue above an additional measure was added to keep automation smooth, and just below the “Wait…” checkbox you’ll see the text field to add additional process names that d7II can look for and wait on those processes to terminate as well, before moving on to anything that could interfere with this custom app… in this instance it will wait for the process named “a2cmd.exe” which is launched by the batch file, and of course that is the main executable for this custom app.
WHY do it like that?
Well a few reasons exist, but the convenience method here is that we don’t need multiple custom apps with chaining configured to do a few specific things, and these app profiles (if you use the defaults) we don’t want to replace the config with one using chained app configs, since you might need to re-think the setup – being a direct replacement design as we strive for with all default apps, no user (re)configuration of d7II should be required for the use or update of app itself nor the d7II auto mode profile order/arrangement.
Namely the issues here stem from being able to run the installer for a2cmd first within the custom app config, a 32/64bit issue. Again, since this is a direct default apps replacement that shouldn’t require any user configuration changes, so separating 32/64bit app configs wasn’t a consideration.
With 32/64bit installers, downloads were usually either spawned from the same exe or they are zipped separately, and as such, the somewhat limiting configuration for the installer field in a d7II custom app, which by default assumes only one exe name for any 32/64bit install.
Keep in mind while separate zips might throw this off, they are usually saved under the same name or extracted to different locations or similar and a batch file, like the one we’re talking about, that carry out the installer based 32/64bit decisions and operations.
It’s also important to note that even single file .EXE installers are either wrapped in or entirely consisting of just another form of compressed file like .ZIP that extracts itself, and sometimes you can save the file as .ZIP/.7z/.RAR/.LZH/.???/etc.
If you learn the actual format of the file (7zip file manager > file properties) and name it appropriately, you can save an .EXE download as a .7z or whatever the appropriate format is in it’s “Save File As” field in d7II config, where it will be treated just like any other .ZIP or compressed file supported by d7II…
Use this technique to solve problems with EXE installers that automate things you don’t want done (e.g. automate extraction to avoid user prompting, certain “installation” tasks, etc.)
More often than not this works without issue, but it was NOT the solution for this custom app update! See below!
(wow, yes I referenced the LHarc format above, did you spot it? Surprised me too, I guess my muscle memory hit a long term thought?)
Moving On… What happened with a2cmd?
This latest Emsisoft update did in fact move to an a2cmd installer (in EXE file format) but unlike the above mentions which is just education/side note material, this specific update uses Nullsoft installer as the extraction container (which to my knowledge doesn’t work as stated above, at least with d7II!)
What the Nullsoft installer will do, if configured to allow this at time of creation, is honor a silent extraction switch. The silent switch that pushes the app to the default directory as pre-configured by the creator (which is not uncommon among .EXE installer files, at least when the creator allows silent usage) but Nullsoft is a bit finicky, frustrating many with an requirement quite odd these days with similar tasks: it’s silent switch is “/S” (caps required) and not “/s” or “/Silent” or anything else you’ll find in dated or incorrect documentation and even some example scripts found here and there.
Final Thoughts: (More of this!)
d7II subscribers who haven’t checked out our dMZ section of the website, where you can get a lot of info like this on many topics as they pertain/coincide with more advanced d7II configuration and usage. (Note the dMZ/website has a login req which, for later recurring subscribers with no account changes, will likely equal your d7II/dCloud subscriber credentials; for any older subscribers would have dMZ/website credentials different credentials, most likely obtained at a later date.)
d7IIx Alpha Testing (with the d7x Platform Code)
The d7IIx binaries which will become the next d7II update are currently in a limited alpha testing, which is not freely open to all subscribers at this time. Big update/little news we realize, but you can learn more on the d7IIx Alpha page.
This is a great opportunity to point out the category feature to those who read the blog occasionally and/or use RSS/Atom feed readers, specifically to those not interested in all of our various blog content (e.g. techs and d7II subscribers who don’t follow our main blog due to the end-user CryptoPrevent stuff.)
Instead of the main blog, follow only one of our specific blog categories! Also by adding a “/feed/” to the end of any blog/category link makes it available for RSS/Atom/etc. feed viewers, e.g. (both styles demonstrated below for d7x categories!)
d7x Release Notes (Feed) Different than in the past, upon any new d7x public release, we plan to use the blog/RSS method for d7x release notes/revision histories, as opposed to a single static page… by using a feed from the beginning, we would like to eventually take advantage of some additional in-app features that are possible with the d7x platform…
That’s all for today!