Here's what I've accomplished so far:
* Began to implement some ideas to for a structured method of passing data to RepairShopr, for more useful integrations in the future.
* Updated KillEmAll (internal to d7II, not the external version which will remain unchanged.) Re-wrote core functions for faster whitelist loading, array sorting, and comparisons, and _began_ a user interface refresh. It also now runs silently (with status displayed of course) in-between custom apps when enabled in Auto Mode on the Malware tab.
* Revised code in a number of core functions involving working with file system objects, especially with speed and accuracy in routines involving file existence checks and deletions, making the routines smarter and removing a lot of redundancy.
* Replaced some WMI code with faster API methods, namely in process detection related functions.
* Updated how 'frmBlocker' (displayed when using the Lock Screen function from the Main menu) displays statusbar updates, returning some control to an outside subroutine which should always filter out the Foolish IT/dMZ notifications from the text displayed.
* Statusbar update message updates now refresh the form being displayed (the user interface, be it the main window, a splash screen, whatever) and will break 'not responding' messages and restore responsiveness to the form, even if only temporarily.
* Re-wrote a lot of main and safe mode form code merging similar code into modules - giving a more consistent experience between the two modes.
* Re-wrote the technician email loading code for the various locations where sending an email is an option, also merging the code for a consistent experience.
* Fixed issues with d7II loading the main form and safe mode form simultaneously.
* Fixed multiple issues with 424 object errors in d7II Safe Mode during many operations.
* Made some code changes related to d7II installing itself as a system service for various reasons.
* Made some code changes related to certain d7II file deletion operations, removing some redundancy.
* Multiple improvements and fixes to basic Custom Apps code functionality, and preparation for some major functional additions.
* New methodology for retrieving log files from custom apps, essentially forming a queue which is re-checked at certain times, ensuring certain circumstances (like unexpected reboots) will not prevent d7II from retrieving the logs.
* Improvements in working with regsvr32.exe on 64bit systems.
* Fixed several issues with properly retrieving and registering a required .dll for TLS enabled email functionality.
* Fixed issues with loading/unloading custom configurable menus (e.g. Tools, Scripts, Search)
* Fixed issues with selected tab control going blank after resizing a form.
* Fixed a TON of minor annoyances.
* Began to remove many references to "d7II" in code and forms that will be visible during normal operation.
* Re-wrote a lot of code to merge more of the commonly used strings and data into public constants for multiple benefits.
* Re-wrote code detection of current application properties and environment, first speeding up the code, and second making it more precise in making decisions when re-launch conditions occur (should d7II.exe spawn multiple instances unexpectedly, especially if combined with unexpected program terminations, this will fix issues caused by a new, 'confused' copy of d7II.exe negatively affecting configuration and subsequent operation.)
This isn't by any means a complete list, but it is basically the starting path to accomplishing many of the bug fixes and feature requests already noted here and in other places. While it may not be obvious, some of these points are actually describing the fix for previously reported issues.
But that isn't all, I've got more in mind below, and I can't wait to get started on it -- but I need to address more existing issues with the current code (and issues found on the forums) before making some of these fairly major changes (which again, may not be as obvious, but the following points will also then address many issues here on the forums!)
Note these are NOT considered for a "v3.5" release - I'm probably going to push out what I've done so far as v3.5 mostly as-is after a few more finishing touches, and assuming testing goes well. But here's what is on the drawing board:
Major (noticeable!) features I am contemplating (not IF I will implement them, but rather HOW I will implement them) include:
* KillEmAll reporting and session start/end automation for that, (ultimately I would like to do start/end comparisons for optional use in reports.)
* Same as above for "StartupKill" functionality, which as natural as it seems I would like to integrate into KillEmAll, for both functionality and definitions list editing.
* password protected SFX creation!
* new ways of handling password protected archives throughout code, including some default logic to process when an archive is unexpectedly password protected.
* implement a global switch on/off style option either for overriding d7II's internet detection result and/OR to implement pre-configured default behavior rules regardless of that result.
* implement a system of updating certain d7II internal functionality via new configuration/definition style updates, eliminating the need for updating the main executable for certain functionality enhancements/adjustments.
* some LIMITED command line d7II.exe automation is planned, and I don't want to make any promises on what specifically so don't pressure me on that
* using new process identification techniques now being tested, this will enable the merging of dFunk, FileHandler, Browser, and other functionality back inside of the main d7II executable, enabling multiple launches of the same executable without operational conflicts occurring. This is mainly for the benefit of fixing a bug with commonly used code in one app one means fixing it in all of them, but also for bringing new features to other apps like dFunk's file inspection / malware hash scanning to KillEmAll! Even more benefits include smaller downloads overall and less reliance on managing multiple locations that functions are executed from.
I also have these ideas specifically for custom apps, which I'm working on a plan to implement:
* both expected and unexpected password protected archive love as mentioned above
* a network based 'home' path detection for d7II and 3rd party tools, including new default behavior options and specific custom apps options
* same as above, but on a personal server - either via FTP or even HTTP
* new custom apps options to add backup actions if things go wrong (e.g. like no or 'undetected' internet access mentioned above, download issues related to above, unzip issues, program not found where it was expected - so utilize pre-configured search parameters and find it - or other default logic, etc.)
* new custom apps ability to run unlimited scripts, both pre/post execution, also replacing the limited/shared pre/post config copy function.
* new custom apps ability to perform as many file copy/move operations pre/post execution as desired, replacing the limited pre/post config copy and post reports copy functions.
* new custom apps errorlevel checking and resultant action options (e.g. run a different custom app/email alert or logs/etc., like in dSupportSuite but with some new stuff, reboot, whatever) and...
* Eventually I want to implement some entirely new logic to make decisions based on app behavior (e.g. termination, previous app/internal function results, or even strings parsed from log files left behind.) The sky is really the limit here, and it's something that will be open to suggestion for some time to come -- what I'm really trying to do here is to implement a framework to make these things possible, not so much start implementing the things themselves right now...
* profile-wide configurable behavior settings and/or overrides for much of the above
* It is also worth noting that I intend to make custom apps code modular, to be included with other Foolish IT apps to standardize the new abilities (e.g. dSupportSuite.)
A lot of what has been done so far, and that will be done soon, is under the hood type stuff that will ultimately make the above possible. In other words, don't expect many of these very noticeable changes right away. At this point it is about testing stability and reliability with new code and methods in place. Probably the next area to focus on that hasn't yet been implemented, will be integrating new code to deal with zip/archives, affecting so many areas of both existing and planned functionality, then introducing some of that new functionality. After some polishing there, I expect to begin integrating some dFunk code back into the main d7II executable, to integrate/standardize some recent core code enhancements between the apps, and introduce new functionality to existing areas. Of course all throughout this process, I will do what I can to resolve any issues arising in other areas, but please keep in mind that a lot of issues can and will be resolved along the way as a direct result of an improvement outlined here.
I also want to extend a hearty "thank you!" to Brantley and Michael for helping make all of this happen, by not only giving me the time to work by contributing with business operations and support (both in email and on the forums,) but also by fielding great ideas, observations, and solutions from our awesome community of techs, and by contributing their own! I would also especially like to thank those of you here who have accepted and welcomed these 'new guys' (who aren't really new at all,) and for contributing to the best PC technician tool ever!