Recommended Posts

Ok thought a bit more in depth about the checksum style idea.

You can give each release a binary number incrementing with each release.

IE First release 1, second 2, third 4 fourth 8 and so on. THen when an update is installed it adds its number to the existing one, this way always giving a unique number that can be calculated back to see which updates and versions are installed??

So when 3 is released, the checksum file must be equal to 3, if its 1 you prompt to download the 2nd release, if its higher you can tell them its already installed etc?

Made sense in my head, maybe you programming types can build on it and make it workable

Keep up the good work

Sorry to bring this up again, but sometimes i just have to talk.

rsrcomp, I understand you, believe me.

I know that Blaze didn't release it yet because he knows it's not ready, and can assure that he's doing his best.

It's hard for us to see some people that don't even try to understand us. Some people are very ungrateful. We are doing this (in our free time) to help other people, without being our obligation. It's not our fault that we don't have already XP SP3.

I am very great full for the project, and please sirs take all the time you need in order to make this the best possible product you can. No rush. Please try and ignore the critics because in life every project has critics, you have to learn not to let them under your skin and keep your cool.

Good day

I am very great full for the project, and please sirs take all the time you need in order to make this the best possible product you can. No rush. Please try and ignore the critics because in life every project has critics, you have to learn not to let them under your skin and keep your cool.

Good day

Well said

i thought you all might like a sneak peak at the new install script i've been working on :)

changes so far:

  • MAJ: enabled 'ifnewer' option which means when installing release it will only overwrite files if they are newer than the existing ones on the system. this will be useful when combining releases with different versions of the same module, you should end up with the latest copy.
  • MAJ: simplified the install instructions, parts that a user may need to customise (e.g. the 'delete redundant files' section used by update releases) have been moved to the beginning of the script
  • MAJ: added 'preferences' section
  • MAJ: script split up into three files to move code the user does not need worry about away from the user
  • MAJ: installation of new '.rti' files that come with AP 5.6 releases
  • MAJ: removed 'full/lite' option page for update releases (we've decided to go with core/update releases in future!)
  • MAJ: added command line switches to control the options on the finish page if you install the release in silent mode
  • MAJ: added command line switches page (accessible via /?) to list available switches
  • FIX: solved problem with installing to non-default directories, it used to stick a folder on the end of your custom path. very easy to solve btw, just took a single \ !!
  • prerequisite errors no longer quit the installation but abort it and allow you to choose another directory!
  • improved install instructions, you no longer get a warning when files or folders are missing when creating a full release like for an update release, instead you get an error and compilation is aborted!
  • added welcome page, it's nicer than starting with the eula and allows basic release information to be displayed to the user
  • using custom image for welcome/finish pages (thanks to raptor for creating it)
  • changed default font to give a cleaner interface, with the ability to change it back for translations if a language doesn't like the font.
  • using a better compression setting by default resulting in smaller releases (suggested by several people in the past)
  • you can now have multiple languages in the same script and specify a different eula for each one (suggested by gandolas)
  • now using colorful rtf file for eula (inspired by gandolas' latest releases which do this)
  • most packing files can now exist in a \packing sub directory to be tidier (suggested by gandolas)
  • removed creation of tweakundo start menu shortcut creation (redundant tool)
  • added ability for script to add 'file info' to the release created
  • improved vista support by adding a privilege check flag on the installer (thanks to gandolas for testing)
  • lots of cosmetic and functionality improvements

screenshot:

newapscriptpreview1qh9.th.png

Edited by theblazingangel
fixed typos and grammar

I'm new here - sorry if this is already posted or this is the wrong forum.

Just a suggestion: In the install script could we have a routine that checks existing installs and reports on base and updates already installed? Or maybe a warning if you install April update and February is not installed - something that checks whether your installing the right conconcurrent version of autopatcher.

Congrats on this amazing piece of software, love it - Thanks for all your hard work.

I am prepared to wait as long as it takes to make it properly, if it takes longer then expected so be it.

All of you who cant wait, can dowload patches from windows update and make modules with tool provided within AP package (tools section :) )

Use the following format for install instructions: filename.exe /quiet /overwriteoem /norestart

In that way u will get your own aprill /may full. Voila, now when thats solved , plz dont clog up this topic no more with that subject, instead open a new one called "Why I think AP is not good" or something like that (thats why Create Topic exists in first place :D )

P.S. Nice, i see you resetted the release progress bar

Its 6 AM here, and i just finished my MMAS project finally.... little tip : dont save .bat files in Unicode, they will give bizzare errors in cmd prompt and give you bad ideas about smashing your computer with keyboard :p

Edited by theblazingangel
fixed your command switches!

Just Info:

Before downloading and installing the new 5.6 Autopatcher (when it arrives) Make sure you un-install any old releases fully from either or both, add/remove programs and the actual old Autopatcher folder should be fully removed too. (By the way please make the program group = AUTOPATCHER not unofficial...)

Note: This will NOT remove any MS security updates/patches previously installed, just the old Autopatcher program.

Autopatcher 5.6 is new and full, and once installed and run, will check for security patches missing (plus a lot more) and allow you to update the patches that are missing. ie if your Xp is fully updated already, then there will not be any MS security updates to do; although there are still lots of other non critical updates that can be applied.

As stated, Autopatcher is designed to enable a user who has a newly installed Xp SP2 and wants to install all other updates offline (that is without visiting Windows Update) Or any other user who wants to update any missed patches since Xp SP2. And to do this a lot quicker.

Therefore, if you do not require any MS security updates (and other non criticals) and do not believe you will need to re-install Windows Xp SP2 at any stage. Then you do not need Autopatcher.

Note: I don't fall into this category, and therefore I WILL be downloading this large 300Meg release, when it arrives.

You know 07 is in two days !!

Kim

I'm new here - sorry if this is already posted or this is the wrong forum.

Just a suggestion: In the install script could we have a routine that checks existing installs and reports on base and updates already installed? Or maybe a warning if you install April update and February is not installed - something that checks whether your installing the right conconcurrent version of autopatcher.

Congrats on this amazing piece of software, love it - Thanks for all your hard work.

thats something i'm currently working on ;)

Will the new version have resize window functions, rather than dragging edges to maximise?

(b.t.w. thanks for all the hard work your team does, I am not an ungrateful **** like some are).

i did look into it but theres no easy option i can enable for that. i believe that i would have to take a copy of a resource file that comes with NSIS that describes page layout and stuff, and use a resource editor to hack the capability in, then distribute this copy with the script and tell the script to use it. it's not too difficult for me to do but is a hell of a lot just to enable the maximize button...

Will Autopatcher 5.6 fix the old bug which made it impossible to run AutoPatcher from a UNC path?

Mapping drives is so 20th Century ;-)

i really don't know, you'll have to ask raptor about that!

Will the new version have resize window functions, rather than dragging edges to maximise?

(b.t.w. thanks for all the hard work your team does, I am not an ungrateful **** like some are).

Yes, AutoPatcher 5.6 allows you to just hit the maximize button (check gandolas' site for screenshots...)

Just a quickie.

Will Autopatcher 5.6 fix the old bug which made it impossible to run AutoPatcher from a UNC path?

Mapping drives is so 20th Century ;-)

Phil

Mounting volumes to drive letters is also 20th century, but I have seen no Windows user complain about it.

Humor aside, I'll see if there's anything I can do to fix this behavior.

i did look into it but theres no easy option i can enable for that. i believe that i would have to take a copy of a resource file that comes with NSIS that describes page layout and stuff, and use a resource editor to hack the capability in, then distribute this copy with the script and tell the script to use it. it's not too difficult for me to do but is a hell of a lot just to enable the maximize button...
Yes, AutoPatcher 5.6 allows you to just hit the maximize button (check gandolas' site for screenshots...)

i think we need to clarify, @leesmithg, if you meant autopatcher.exe itself, read raptors reply, if you mean the install script then read mine :laugh:

A huge "Thank You" to the Autopatcher team. I discovered Autopatcher back in Jan. of this year and was just in awe of the time and effort and work put into this project to help other people for no monetary gain. You all are not only a group of highly intelligent people but you have restored my faith in the human race in general. There really are good people still around. :yes:

I am patently waiting with the rest of the community, who are smart enough to have some idea what an enormous task you all have put on yourselves, for the new release. There are some very nice people on this forum. All my hopes!

greyeagle

i thought you all might like a sneak peak at the new install script i've been working on :)

Blaze... you're the man. Looks great... tastes great and less filling. I think you are right on with the updating strategy... not sure you'll ever be able to prevent people from breaking AP due to ID10T errors, but you just give it your best well thought out shot and let 'er rip. Simple is usually better and more elegant, if it were my baby, I'd just scrap the whole update module and go with full releases every month which the re-design should allow very easily. I know it's a bandwidth issue for the cavemen on dial up... but hey, you can't please everyone all the time. All I know is that good things come to those that wait and the more hurried you go the more behind you fall. We know you are doing your best and doing it RIGHT.

Sorry about the driving test dude, but just tell 'em... Hey... if you don't like the way I drive... stay off the damn sidewalk.

Sincerely

A very appreciative and patient fan of Blaze and the AP Team

Today's good luck numbers are: 09 F9 11 02 9D.... LOL :whistle:

Nice to see some people who are patient.

Just consider the following:

AutoPatcher 5.6, though still a 5.x, is a complete re-write of AutoPatcher. It's not based on 5.1.

Lyndon's releases, although still carry the same name, are again a complete re-write (as far as modules go) in order to make use of the new features and deliver a more accurate, almost flawless patching experience.

Lyndon's installation script, as far as I can tell, has changed so much it could be considered an almost-re-write.

Let's recap. Rewritten AutoPatcher engine, rewritten modules, rewritten installation script.

A thought on the checksum idea:

Generate an encrypted date file using some standardized syntax for every month for the next several years. (I'd say 10 to be safe, but you could go less if you don't expect anyone to still be using these OSs in 2017) [NOTE: You'll need to be sure to stick to this syntax with every release at least until the end of the x years.] The date file would be placed in the directory to which everything is extracted/installed

Calculate checksums for each month's date file and store this info within the executable actually doing the patch/update installs. Since an MD5 checksum is just a string of 32 characters for comparison, adding 120ish strings and a simple MD5 calculating algorithm shouldn't bloat the end-product more than a few KB.

The executable calculates the hashing of the date file on the local machine and compares this result with its hard-coded list of the releases using this verification method.

At this point, it's really a matter of how you want to react to finding a newer or outdated source already in existence.

It may not be the most elegant solution, but maintains OS and registry independence.

Just my $.02

Anyone have any thoughts/criticisms of my suggestion from last week?

@TheGratefulNed, well...

1) an 'encrypted date file' has the same caveats as the ini/inf idea in the first post, it would get overwritten when combining releases. also the encryption isn't really necessary and adds a further complication - need for an encryption algorithm.

2) however, using some number, perhaps in the filename of the rti files, or even if you like, the md5 of the number, is an extremely simple solution and something i overlooked. the only problem that could occur is that someone forgets to increase the number.

right now i'm working on implementing the 'last modified date' solution, but i will certainly consider #2 as a great alternative ;)

Hi,

Just a quickie.

Will Autopatcher 5.6 fix the old bug which made it impossible to run AutoPatcher from a UNC path?

Mapping drives is so 20th Century ;-)

Phil

You can run AP 5.1 from a UNC path by running AP from the following .CMD file:

@echo off
setlocal enableextensions
pushd %~dp0
AutoPatcher.exe /noeula
popd

This file needs to be in your AP folder, at the same level as the AutoPatcher.exe file.

You may see a message in the .CMD window about not being able to use UNC paths in this context however you can and it does work.

If you wish to suppress that message then you can add the following entry to the target systems registry as follows:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Command Processor]
"DisableUNCCheck"=dword:00000001

AP XP 5.1 seems to work well when installing from a UNC path using the above method.

Upgrading to a Gigabit Ethernet Network (actually not that expensive now) also helps with performance.

Kind Regards

Simon

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.