Is the project still alive?

Announcements that may happen from time to time.
Post Reply
gada20
Posts: 1
Joined: Wed Aug 24, 2016 2:06 pm

Is the project still alive?

Post by gada20 » Thu Mar 11, 2021 10:17 am

Hi, everyone! Autopatcher is a brilliant project, but is he still alive?

User avatar
TheAPGuy
Site Admin
Site Admin
Posts: 977
Joined: Sun Oct 27, 2013 12:38 am
Location: California
Contact:

Re: Is the project still alive?

Post by TheAPGuy » Mon Aug 09, 2021 2:43 pm

It is kind of dead. I have "issues" that prevent me from concentrating on programming at all. The lack of help has burned me out on updating definition files as well. While it is not hard to do after you do it a few times, it is repetitive and a pain when Micro$shaft likes to update old files for no apparent reason.

User avatar
The Crow
Posts: 27
Joined: Wed Jan 25, 2017 12:12 am
Location: United Kingdom

Re: Is the project still alive?

Post by The Crow » Mon Sep 06, 2021 9:46 pm

I'm probably still down for keeping the project somewhat alive, but it will most likely be the fact that I'm only willing to support Windows 10 scripts moving forward

All the different versions of Windows 10 21h1, 20h2, 2004 etc all need scripts creating even as some of them have reached end of life status, I'm willing to support the end of life versions for people out there that cannot update to the latest versions for some reason.

I can create the scripts and give the end of life versions their own final autopatcher update script so to speak

Each version (21h1, 20h2 etc) need two scripts creating, one for x86 one for x64, so as you can see that is a shit ton to maintain monthly on it's own, it takes a considerable amount of time per script

Each vmware instance I have starts with a fresh install (reset from a snapshot), I then run Windows update, see what installs, after that I need to grab the kb numbers, then search download links for each from microsoft catalog, create the .apm and .script files, then there's the testing phase after resetting to the fresh install snapshot, use AutoPatcher to install the updates instead of Windows update to see if everything runs smoothly, if not make changes, reset the snapshot again and reinstall

I can easily spend a few hrs on and off, just doing one x86 script for one build number, multiply this for x64 scripts aswell for each build number of Windows 10

My decision to only support Windows 10 stems from the amount of work to maintain all the versions and creating / modifying / updating the scripts monthly, it leaves no time for me to update the others before Windows 10 scripts become outdated again, I can't physically keep every AutoPatcher script updated monthly running solo

@TheAPGuy with your current issues are you able to do any programming at all ? I need a way for log files to contain time stamps for each line / action, I also need an uninstall command for Windows 10 msu file uninstall options as the current method doesn't work with Windows 10

The reason for the timestamps is to save time clockwatching as updates install to kind of get an idea of how many seconds the update takes to install for the apm files where you enter an amount, I can just leave things installing with install time not set and pick the info to fill in the blanks after from the log files

With some timestamping system I can pick though the logs and see how many seconds elapsed between each update install, and example would be

06/09/21 22:57:13 Installing Windows Malicious Software Removal Tool - v5.92 (KB890830)
06/09/21 23:01:37 Installing Windows Malicious Software Removal Tool - v5.92 (KB890830) finished (time elapsed 4 minutes, and 24 seconds or could do 264 seconds etc)

I know AutoPatcher monitors for an update to finish before issuing the next, so it should be a case of adding timestamps for the log file directly after an update finished for the elapsed time with a bit of math to calculate the elapsed time, and just before the next update starts add the current timestamp before logging the next file installing line etc

If the timestamps was implemented it could be setup as an optional switch like autopatcher.exe /timestamp , so this kind of logging is only for me developing scripts or others developing scripts or can be used by anyone who wishes to

If the switch is also added and not set as default for everyone it keeps logs smaller for those that don't care for the feature

I come from a php background, I know Autopatcher is c+ coding and another language I can't think of top my head atm, but if I was to view AutoPatcher source files, is there a chance I can pick this up fairly quickly and possibly add and change things as needed ?

Windows 11 is around the corner, for the most part it looks like Windows 10 with just a gui update of the start menu, I'm assuming detecting the os and version / build number will work like Windows 10 detections, if not this may need adding moving forward to try keep the project alive

Without a coder keeping the AutoPatcher.exe file updated the project will eventually die anyway moving forward as I'll end up hitting roadblocks with no updates

It's been a month since you posted a reply to this thread, but I'm still about and willing to still try at least for the project, but if you wanna discuss the future of AutoPatcher with me, just send a private pm and I'll keep checking in for any updates / messages

Post Reply