During the development of the new version of BootZilla, this page will be updated with progress updates, questions to the community, and beta releases. Feedback is appreciated, so this release can be the best one yet.

First and foremost, the new design dictates a fully customizable scripting structure, which enumerates little scripts and processes the download, update, and decompression of tools into their appropriate places. This approach makes patching a breeze, and simplifies the ability to make BootZilla truly modular. An image of the current directory tree follows -

The first part of development involves creating a proof of concept. Due to the way that the new BZBuilder script operates, support for building the toolkit on Windows NT5 (XP/2003/2000) might not happen. Most users are on NT6 (Vista/7/8/8.1/Server 2008/2008r2/2012/2012r2), which makes some of this easier for the development and proof of concept stage. The BZBuilder will be utilizing the command-line utility “ForFiles.exe”, included in all versions of NT6. In order to support NT5 OSes, we will need to add an extra step to the build process which will grab the appropriate version of “ForFiles.exe” for NT5, and then process the rest of the script. For now, and during the proof of concept stage, this bit will be left out, unless someone expresses a need for NT5 support.

So far, the BZBuilder.txt is just a file filled with ideas for how the system will work, including bootcd functionality specifics, directory tree ideas, dependency lists, and various other notes about what the toolkit needs to be.

Work on the toolkit in its new form will progress rapidly. The hard deadline I’ve set is December 1st, 2014. No later than December 1st will be the release of this new version, to allow it to fit in with the Fall/Winter 2014. As such, the first version will likely be more of a proof of concept release than subsequent releases. Bugs may exist, logging might not be up-to-par, but at the least, the build script will be utilizing the new structure defined in my development documentation.

There will be a set of developer documentation in place for people who want to extend the toolkit. Ideally, BootZilla could be utilized as a software update framework for corporate and enterprise use. The main goal for the first release, however, is to get it up and off the ground.

—-

Cmdlets: What are they?

When I decided on dumping the v6 code for something better, I had been toying with some better Windows Batch scripting ideas, including switching over to powershell entirely. As of now, I have a limited understanding of PS scripting, and do not feel safe in developing a project on it yet. The other thing is, many people don’t like PS, or have any real working knowledge of how to use it. More and more of the Microsoft-speaking-world are pushing it, especially if you manage Exchange or other Microsoft-centric applications. My only real-world experience with it was setting up Office 365’s exchange service for a business I work at. Powershell is supposed to be easier to debug, but in my opinion, is more of a beast when it comes to error messages, than it is easier to make sense of. I started out on the DOS command line, writing better autoexec.bat files for my PC, so I feel a deep connection to command scripts than I do powershell scripts. Another idea years ago was to re-write BZ in bash scripts, which was partially done, for server-side software updating, but never released to the public, since my bash-fu is terrible. Plus, I no longer run any *nix-based OSes as my primary OS.

Back to the topic at hand…

Windows Batch Scripts come in either *.bat or *.cmd file extensions. *.bat is a leftover backward compatibility extension from the DOS days. *.cmd literally means “CoMmanD script”. A CMDLet is literally a command script applet. Each cmdlet is a small script consisting of instructions that will process a tool’s download, decompression, and configuration within the BootZilla toolkit. What this means is that we can actually bundle configuration files in with the cmdlet, and have them be placed alongside the decompressed tool (for things like ccleaner, you can include the ccleaner.ini profile, and winapp2.ini files) - your customizations to these tools’ profiles will be retained between builds of BZ. Some tools also generate dat files for preferences, which will also be looked for within the cmdlets directory. From here on out, all included apps will have their own “appname_version.cmd” file, where version typically will be either x86 or x64. In this way, an X86-only or X64-only toolkit can easily be built from the same build script, with minimal interaction from the user. This also means that you can setup different categories to be processed. By default, ‘all’ will be passed to the build program, but should you want only a specific set of tools, or a specific architecture, you can define it as the first argument on the commandline. For instance, “BZBuilder.cmd x86″ will only pull x86 tools in. If you were to only need utilities, then “BZBuilder utils” would give you only the utilities directory of tools.

The other great thing about this, is that you can move and take away any tools you don’t want, simply by removing the cmdlet you don’t want. You can also add your own cmdlet into whichever directory is applicable to your tool.

With this serious design change, moving up to PowerShell should also be a lot easier in the long run. Not relying on 3rd-party tools is something that has been well sought after since a malformed wget executable issue several versions ago.

 

This blog will be updated from time to time with information pertaining to the new development of BootZilla.