progress status

By +theblazingangel
in Software created by our members

 Share

Recommended Posts

Grand Master

+theblazingangel MVC

Posted
  • MVC
Posted (edited)

the old thread was getting a bit messy and it must have been difficult for people to locate progress details, so heres a nice new clean thread ;)

first of all, for the next three days the new releases are going to be my priority #2. i have my driving test on friday the 27th and i seriously need to get some practice in (not at all a bad driver, but need to practice), after friday autopatcher is back at priority #1. FAILED third time round i passed :D

here is a list of everything i need to do in order to complete the new releases, i'll cross things off the list as i go along

modules (done!)

  • DirectX addon: a) sort out detection, for some reason the installer doesn't always install the .cat files i was going to reply on. b) currently gandolas' releases are incompatible with mine. i want to help him get all of our releases correctly working together, unfortunately this DirectX module needs me to work out exactly how i will sort this out prior to finishing this module. it may be that i delay the DirectX addon until the next DirectX installer is released in june, however that means in june, if i determine that this installer does actually replace the basic DirectX installer in the windows 2000 release, then in june users will have at the very least a 34MB update release to download!!
    Just need to know what the_guy meant about KB904706 in post #3
  • sort through a small list of critical updates to see if any need re-inclusion. also decide whether to put ie6 updates back in the main release.
  • swap flash player installers with .exe versions flash and shockwave players updated to latest versions and now total ~4.5MB (previously ~10.5MB)

new install script {done!)

  • somehow simplify code that applies small updates to addon packs within update releases. way to complicated to be used as it is
  • awaiting feedback from gandolas as to whether i need to chuck in a privilege check for vista
  • sort out a prerequisite check to solve some common and basic user errors installing releases
  • implement caching feature to solve problem delivering updates to addon packs, when the addon packs are installed after the update.
  • clean up the config file a little

other (will all actually be done afterwards)

  • actually compile the releases ready to upload (takes maybe an hour)
  • prepare translation packs (won't take very long at all, could even wait till after the main releases are out)
  • update all documentation
  • update the download section of the website - needs redesigning to: 1) allow the user to choose between the five main releases and future office releases 2) provide all needed info to the user 3) make addon packs available to users. if any of the other team members want to attempt this for me, feel free just make sure to use the downloads_b default page and we'll port the finished product to the proper page when it's finalised.

i'm really sorry they're not done yet, i know people keep saying they're fine with it but i do feel bad for those that ordered CD/DVD's back in february. it's just taking a lot longer that i imagined.

Edited by theblazingangel
Link to comment
https://www.neowin.net/forum/topic/556096-progress-status/
Share on other sites
Rising Star

PsiMoon314

Posted
Posted

Hi theblazingangel,

Firstly thanks for the update on the progress on AP 5.6.

I am sure that everyone here will be pleased to see how far you have got and hopfully the remaining issues will be resolved soon.

With regards to the installation script issues then I would have thought that registry settings would have done the trick here?

For example you could have a of new keys as now under HKEY_LOCAL_SOFTWARE\Software\Autopatcher which has sub-keys and entries for dates ect for each build and release. Perhaps something similar to:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\AutoPatcher\XP 5.6]

[HKEY_LOCAL_MACHINE\SOFTWARE\AutoPatcher\XP 5.6\1033]
"BaseBuildDate"="BaseBuildDate"
"UpdateBuildDate"="UpdateBuildDate"
"InstalledDate"="InstalledDate"
"InstalledPath"="C:\\Program Files\\AutoPatcher XP English"

This uses the current AP registry entries but extends them to include the OS and Language (1033 is supposed to be the LCID for English - I can't remember what this is at the moment).

There could be seperate entries for each LCID to cope with diferent languages for each OS release (except perhaps for Vista).

Under each LCID is the Base Build Date (hard coded into the release for full installers), the Update Build Date (hard coded into the release for update installers), the Installed Date (when the user installed the currently installed build) and the Installed Path (where it's installed).

This would allow each OS/LCID release to be installed on a PC without conflicting with each other (as long as they are installed into different folders).

This information could also be written to an INI-type file in the InstalledPath folder to allow for comparisons, just in case the user manually overwrote the release (by accident or design).

You could then have the installer check for previous builds and when they were installed by comparisons of this information in the registry with information in the new full or update build.

You could even have funky checks for outdated installs buy checking the AP release the user is installing against the system date and time to ensure they are not using something really out of date (say installing the May 2007 release in November 2007).

Update installers could be included within this by using the BaseBuildDate and UpdateBuildDate information to ensure that full and update builds are installed in the correct order.

The information you store in the registry for each key could be the 16 digit number just to make comparisons easier. Something more human readable might be nice though ;)

Yes this does depend on the user not messing with their registry but most folks don't so something along these lines should work quite well.

Kind Regards

Simon

Community Regular

the_guy

Posted
Posted
modules

[*]DirectX addon: a) sort out detection, for some reason the installer doesn't always install the .cat files i was going to reply on. b) currently gandolas' releases are incompatible with mine. i want to help him get all of our releases correctly working together, unfortunately this DirectX module needs me to work out exactly how i will sort this out prior to finishing this module. it may be that i delay the DirectX addon until the next DirectX installer is released in june, however that means in june, if i determine that this installer does actually replace the basic DirectX installer in the windows 2000 release, then in june users will have at the very least a 34MB update release to download!!

Just a heads up: The April 2007 DirectX update does replace the original for 2000. It does not include KB904706.

the_guy

Mentor

gandolas

Posted
Posted
(...)
  • DirectX addon: a) sort out detection, for some reason the installer doesn't always install the .cat files i was going to reply on. b) currently gandolas' releases are incompatible with mine. i want to help him get all of our releases correctly working together, unfortunately this DirectX module needs me to work out exactly how i will sort this out prior to finishing this module. it may be that i delay the DirectX addon until the next DirectX installer is released in june, however that means in june, if i determine that this installer does actually replace the basic DirectX installer in the windows 2000 release, then in june users will have at the very least a 34MB update release to download!!

(...)

  • still awaiting feedback from gandolas as to whether i need to chuck in a privilege check for vista (easy, just one line of code, but need the feedback)

(...)

Yes, we have to make them AIO-ready...

Feedback sent! :D

Grand Master

+theblazingangel MVC

Posted
  • Author
  • MVC
Posted

@PsiMoon314, registry entries are no good, it would be a great solution if it were not for the fact autopatcher needs to be completely portable. people need to be able to just copy the contents of their install folder to external media as they have always done, i can't ask people to start backing up and merging registry keys in order to install releases on different systems. e.g. say someone buys a CD/DVD release, they then want to copy and paste that onto their system and install an update release ontop of it. in order to do so ben (aka steeltrepid - our sales person) would have to distribute updated copies of part of his registry with the disks and the user would have to merge it with their registry before they can install the update.

also, in order to maintain multiple copies of autopatcher in different folder on the same system the registry info would have to be split into sections, one section to hold info about the releases installed to each different folder ap is installed to on that system. this first of all means that if you change the dir ap is installed to you must also reflect that change in the registry which is a huge pain in the arse. but also, ben's registry export is extremely unlikely to work on the end users system without modification because the user could copy and paste the release from the disk to absolutely anywhere on there system.

also, i believe that some people may very well like to unpack the release in OS's other than windows and attempting to install registry info would definitely put an end to that (unless they use wine)

so after all that the registry solution is no good at all :(

Grand Master

+theblazingangel MVC

Posted
  • Author
  • MVC
Posted
Just a heads up: The April 2007 DirectX update does replace the original for 2000. It does not include KB904706.

the_guy

sorry, i'm a little confused, KB904706 applies to dx 9.0/9.0a/9.0b/9.0c, which suggests it is not included in the original anyway. if we replace the original dx 9.0c installer with the april2007 edition (the size difference apparently is due to non-nt cab file being removed), how does that affect KB904706 which will still be included in our releases?

Rising Star

PsiMoon314

Posted
Posted

Hi Blaze,

@PsiMoon314, registry entries are no good, it would be a great solution if it were not for the fact autopatcher needs to be completely portable. people need to be able to just copy the contents of their install folder to external media as they have always done,

Well then the two aspects of AP are in conflict to some extent. I use AP as a portable application (generally from CD) but I install it first to a Windows Based PC and then copy the files to a CD.

Perhaps the AP installer need to have two modes - one to create a portable version and one to install it to allow for updates?

i can't ask people to start backing up and merging registry keys in order to install releases on different systems.

Sure I can understand that, but how many users actually just "attack" the installer to unpack the files rather that using the installer for it's intended purpose, e.g. to install AP?

If they do, how do they use the update installers now unless they have a Windows Based PC with the previous months build installed for the update installer to work on!?

At some point a Windows PC has to be involved. How much of an inconvienience is it to expect AP to be installed at least once somewhere before it's used to update a PC? Anyone supporting a Windows based PC environment should really have access to one for that purpose.

e.g. say someone buys a CD/DVD release, they then want to copy and paste that onto their system and install an update release ontop of it. in order to do so ben (aka steeltrepid - our sales person) would have to distribute updated copies of part of his registry with the disks and the user would have to merge it with their registry before they can install the update.

I have never ordered a CD so I assumed that it contained a copy of the installer which folks install! :) I guess it could contain a portable version of AP but could a copy of the installer not also be included? If not how do folks update a CD version of AP now unless they install it somewhere first?

The update installers are not just big .ZIP files which unpack themselves as they also delete/update modules which involves programing somewhere. If they do unpack an update installer then they will only get new and updated modules not deletions or other changes.

In any event you really have two conflecting uses of the installer here which is adding complexity to what should be a relatively simple process, which should be "Install an application", "download an update", "run the update to install the update". I bet (say $50) if we did a head count then the vast majority of AP users do exactly that.

also, in order to maintain multiple copies of autopatcher in different folder on the same system the registry info would have to be split into sections, one section to hold info about the releases installed to each different folder ap is installed to on that system.

The scheme I suggested above allows for exactly what you are suggesting. One registry branch for each AP product installed on a given PC, including the OS, LCID and update / build status dates etc There should be no problem installing AP XP, AP 2K and AP Vista etc on the same PC, each to their own folder.

Each would be in their own seperate folder and each would have seperate registry entries. The code for this should be largely the same between AP OS versions. The folks doing the translations would have to work within what ever scheme is used but they do that now anyway.

this first of all means that if you change the dir ap is installed to you must also reflect that change in the registry which is a huge pain in the arse.

Why? Any decent Windows installer product should be able to cope with user input and install the application to what ever valid folder the user wishes to use and update the registry settings accordingly.

The default install folder would be say %ProgramFiles%\AutoPatcher\%OS%\%LCID%\ or what ever scheme you wish to invent. If the user then decides to move it somewhere else manually after it's installed then you should expect things to break! That is normal behavour for a Windows application.

The registry information could be exported to the "portable" version of AP as an INI / XML type file to be included with the portable AP files. It should be fairly strightforward to import this back again should the user wish to update a portable version and they don't have that version installer to hand.

but also, ben's registry export is extremely unlikely to work on the end users system without modification because the user could copy and paste the release from the disk to absolutely anywhere on there system.

Apologies, I am not familier with the registry export feature you mention. Is this part of AP 5.1 now or something new?

In any event if you wish to export some data (what ever that is) then you have two choices, use the stored information (Registry or INI / XML file contents) to determing where this should go or ask the user.

But again why would you manually move a windows application once it's installed? That is not something I would ever do because I know it would break the application.

also, i believe that some people may very well like to unpack the release in OS's other than windows and attempting to install registry info would definitely put an end to that (unless they use wine).

True however the option to create a portable version would solve that problem. In any event if they are not running the installer (because they don't have access to Windows) it can't create registry entries anyway.

For non-Windows users you might as well give them a big compressed blob of data to be written to a portable medium rather than an installer for all the use a Windows installer will be to them.

If the user is clever enough to be using Linux (or whatever non-Windows OS floats their boat) then they can probably be expected to sort this out for themselves.

At the end of the day it's not really too much to expect that a Windows application would be run in a Windows environment at some stage. If we were writing AP MacOS 10 then I would expect that access to a Mac might not be an unreaonable requirement! :)

so after all that the registry solution is no good at all

Well I would disagree. It works well enough for the vast majority of applications out there and I suspect to some extent you are making things more difficult than they need to be by expecting the AP installer to be all things to all people. That goal will be impossible as no application is 100% perfect. You can't please all of the folks all of the time and trying to cater to 100% of the folks will just add complexity for little extra gain.

Kind Regards

Simon

Grand Master

+theblazingangel MVC

Posted
  • Author
  • MVC
Posted
Well then the two aspects of AP are in conflict to some extent. I use AP as a portable application (generally from CD) but I install it first to a Windows Based PC and then copy the files to a CD.

Perhaps the AP installer need to have two modes - one to create a portable version and one to install it to allow for updates?

autopatcher needs to be run from a windows pc, but not necessarily installed to one. for example, i imagine it could be installed to a *nix server and made available accross the network to terminals running windows. someone may install to a *nix machine and move it to external media from there.

Sure I can understand that, but how many users actually just "attack" the installer to unpack the files rather that using the installer for it's intended purpose, e.g. to install AP?

If they do, how do they use the update installers now unless they have a Windows Based PC with the previous months build installed for the update installer to work on!?

At some point a Windows PC has to be involved. How much of an inconvienience is it to expect AP to be installed at least once somewhere before it's used to update a PC? Anyone supporting a Windows based PC environment should really have access to one for that purpose.

...

I have never ordered a CD so I assumed that it contained a copy of the installer which folks install! :) I guess it could contain a portable version of AP but could a copy of the installer not also be included? If not how do folks update a CD version of AP now unless they install it somewhere first?

The update installers are not just big .ZIP files which unpack themselves as they also delete/update modules which involves programing somewhere. If they do unpack an update installer then they will only get new and updated modules not deletions or other changes.

In any event you really have two conflecting uses of the installer here which is adding complexity to what should be a relatively simple process, which should be "Install an application", "download an update", "run the update to install the update". I bet (say $50) if we did a head count then the vast majority of AP users do exactly that.

actually i'm pretty sure ben installs the releases on his own system and then copies the files to the CD/DVD, the disks do not contain the original installers and it would take up a lot of extra space if we were to do so and it would be really unnecessary to do so.

The scheme I suggested above allows for exactly what you are suggesting. One registry branch for each AP product installed on a given PC, including the OS, LCID and update / build status dates etc There should be no problem installing AP XP, AP 2K and AP Vista etc on the same PC, each to their own folder.

Each would be in their own seperate folder and each would have seperate registry entries. The code for this should be largely the same between AP OS versions. The folks doing the translations would have to work within what ever scheme is used but they do that now anyway.

yeh, okay it allows for multiple installations of different OS's or languages, however that doesn't help if someone for some reason someone installs two copies of the same OS/language release into different folders which is entirely possible. i myself have a main copy in c:\program files, then i have at least two other copies in my autopatcher working directories while working on new releases.

Why? Any decent Windows installer product should be able to cope with user input and install the application to what ever valid folder the user wishes to use and update the registry settings accordingly.

The default install folder would be say %ProgramFiles%\AutoPatcher\%OS%\%LCID%\ or what ever scheme you wish to invent. If the user then decides to move it somewhere else manually after it's installed then you should expect things to break! That is normal behavour for a Windows application.

The registry information could be exported to the "portable" version of AP as an INI / XML type file to be included with the portable AP files. It should be fairly strightforward to import this back again should the user wish to update a portable version and they don't have that version installer to hand.

i'm not talking about changing the install dir when installing, i mean afterwards! i move folders about all the time while messing around with things.

Apologies, I am not familier with the registry export feature you mention. Is this part of AP 5.1 now or something new?

In any event if you wish to export some data (what ever that is) then you have two choices, use the stored information (Registry or INI / XML file contents) to determing where this should go or ask the user.

But again why would you manually move a windows application once it's installed? That is not something I would ever do because I know it would break the application.

no no, i mean the export feature built into regedit itself, basically copying a portion of the registry into a .reg file (i.e. a backup).

autopatcher actually runs much slower from CD/DVD's so it's easy to see why a user may copy and paste it off the disk onto their computer, the point is they could copy it anywhere and then due to that fact they would have to modify the .reg file ben made on his system to point to the location they copied it to. you may ask why we don;t then just ship the installers on CD/DVD, well i'm not sure everyone does copy it from the disk, and besides which what about the people who mke their own disks!!

True however the option to create a portable version would solve that problem. In any event if they are not running the installer (because they don't have access to Windows) it can't create registry entries anyway.

For non-Windows users you might as well give them a big compressed blob of data to be written to a portable medium rather than an installer for all the use a Windows installer will be to them.

If the user is clever enough to be using Linux (or whatever non-Windows OS floats their boat) then they can probably be expected to sort this out for themselves.

At the end of the day it's not really too much to expect that a Windows application would be run in a Windows environment at some stage. If we were writing AP MacOS 10 then I would expect that access to a Mac might not be an unreaonable requirement! :)

...

Well I would disagree. It works well enough for the vast majority of applications out there and I suspect to some extent you are making things more difficult than they need to be by expecting the AP installer to be all things to all people. That goal will be impossible as no application is 100% perfect. You can't please all of the folks all of the time and trying to cater to 100% of the folks will just add complexity for little extra gain.

Kind Regards

Simon

----------

sorry to be blunt but can we just forget the registry, sure it works for most other software, but most other software is not portable like autopatcher is. the registry just isn't going to work, please believe me.

further requirements to the solution:

- OS independent

- portable

it must not require anything outside of the directory ap is installed to, and therefore must also be file based!

summary of what i wrote above;

- people must be able to move the installation around to different folders without extra work (editing path info somewhere like the registry)

- people must be able to have multiple copies of ap (inc same OS/language) in separate folders

- people must be able to install onto *nix systems

- people must be able to move ap to and from external media without hassle

Rising Star

PsiMoon314

Posted
Posted

Hi Blaze,

Frankly how a Windows based application is going to be OS independent is a mystery to me. Using that "technology" you could get a Mac OS application to run on Windows.

A Windows application by defination requires a Windows OS to execute it and install it. A Windows based installation package requires Windows to operate in just to install the package in the first place. How can you install a Windows application under Linux or any other non-Windows OS?

If you are going to scrap a conventional Windows installer then I could perhaps understand how you are going to get this to work, in which ase just package the thing up as a .ZIP compatible archive and be done with it. Forget the Windows installer and update installers and just send out new .ZIP files each month with the lastest AP files within.

yeh, okay it allows for multiple installations of different OS's or languages, however that doesn't help if someone for some reason someone installs two copies of the same OS/language release into different folders which is entirely possible. i myself have a main copy in c:\program files, then i have at least two other copies in my autopatcher working directories while working on new releases.

When the second copy of the installer runs it would see that the same version (or a later version) is already installed and prompt you to that effect. If you install a second copy then the first one is essentially orphaned off and "forgotten". This would be the same if you installed two copies of most Windows packages, unless it is specifically written to take that into account.

Perhaps when you say install or installation perhaps you mean "copy". That is not strictly an installation but an instance.

You can have multiple instances of Autopatcher (e.g. complete sets of AP files in several different folders) but you can have only one installation unless the Windows installerand the application are written to take this into account.

Anyway I am beginning to regret saying anything so perhaps it's best to forget it.

Clearly you own ways of doing things and I can only wait to see what the results are.

Regards

Simon

Explorer

prandal

Posted
Posted (edited)

Sorry Simon,

I think you're barking up the wrong tree completely here.

The registry is one of Microsoft's dumber inventions anyway.

I have copies of Autopatcher both at home and at work.

I apply incremental updates at either location, then copy the files from work to home or vice-versa.

Registry keys are a completely bogus imaginary solution to the problem of ensuring that incrementals are applied to the correct preceding version.

A plain text file, containing a version string which is checked / updated by any incremental installer is by far the easiest way to ensure consistency.

Phil

Edited by prandal
Grand Master

+theblazingangel MVC

Posted
  • Author
  • MVC
Posted (edited)
Frankly how a Windows based application is going to be OS independent is a mystery to me. Using that "technology" you could get a Mac OS application to run on Windows.

A Windows application by defination requires a Windows OS to execute it and install it. A Windows based installation package requires Windows to operate in just to install the package in the first place. How can you install a Windows application under Linux or any other non-Windows OS?

If you are going to scrap a conventional Windows installer then I could perhaps understand how you are going to get this to work, in which ase just package the thing up as a .ZIP compatible archive and be done with it. Forget the Windows installer and update installers and just send out new .ZIP files each month with the lastest AP files within.

i'm not an experienced programmer, i have yet to even create a win32 gui app (spending too much time on autopatcher instead). i thought i read in the NSIS manual that installers would work on *nix as well as windows, however having another look it seems that it just applies to compiling releases not running them. however even so, that doesn't mean it's going to work.

When the second copy of the installer runs it would see that the same version (or a later version) is already installed and prompt you to that effect. If you install a second copy then the first one is essentially orphaned off and "forgotten". This would be the same if you installed two copies of most Windows packages, unless it is specifically written to take that into account.

Perhaps when you say install or installation perhaps you mean "copy". That is not strictly an installation but an instance.

You can have multiple instances of Autopatcher (e.g. complete sets of AP files in several different folders) but you can have only one installation unless the Windows installerand the application are written to take this into account.

ah but i don't want a new instance to bumb off a previous instance (yes, instance is perhaps a better word ;) ). take prandal's situation for example, or indeed lets look at my own development machine because i certain need it, i have several instances of the xp release for starters: one in 'C:\Program Files\' which i use for my system; one in 'E:\AutoPatcher\(05) Working 5.6\(02) Releases\(02) XP SP2 x86\(01) full\' for development; another in 'E:\AutoPatcher\(05) Working 5.6\(01) Translation packs\xp\' for translation pack creation; and two further instances on my external hard drive where i backup my laptops autopatcher development dir. all of which need to function as separate installations.

for all of my instances to function, in my registry i would have to have 'HKLM\Software\AutoPatcher\releaseinfo\xp\' and then have several sub keys, one for each instance, with a reference to the location of the instance along with date info. now, if i move any of the instances to a different directory path (i.e. with copy & paste or folder renaming) then i also have to update the referenced direcory in the registry. for people copying from a CD/DVD or other external media onto a computer so they can install an update release on top, they first of all have to run a .reg file to add registry entries, and then manually edit the registry to reference the directory in which the user copied the instance to.

Anyway I am beginning to regret saying anything so perhaps it's best to forget it.

Clearly you own ways of doing things and I can only wait to see what the results are.

Regards

Simon

i'm sorry if i offended you simon, that was certainly not my intention, i hope it doesn't put you off expressing further ideas. :)

----------

A plain text file, containing a version string which is checked / updated by any incremental installer is by far the easiest way to ensure consistency.

certainly the easiest, but what if you have two instances and copied and pasted on over the other? then either you need to reinstall, or somehow workout what releases you now have. * note that copying and pasting is not generally recommended *

it's certainly got potential since it's so portable, the only problem is that it can be so easy to screw it up and combining releases via copy and paste (if you really want to do that) would require that the user manually merges such files (and sucessfully - installer must be able to get the info)

Edited by theblazingangel
Rising Star

SteelTrepid

Posted
Posted

All CD orders are in fact the expanded/installed files from a "C:\Program Files\AutoPatcher\xxx" folder on my computer. When updates are released the installer is run twice, once for that versions individual folder and a second time for my "all" folder that I use for DVD's.

With 2K the size is 436MB, 2K3 size is 581, and XP 644MB. There really isn't room on any of those CD's for the installer program to be included. I think that Antonios and I talked about this in the past and decided on our current method. My "mind set" on the ordered CD's has always been that people wanted it on a CD they could take anywhere with them to run it on the fly. The service is provided to mostly help people that are stuck on dialup. I also think that most people do not like installing software onto their systems. Even with large hard drives today people are still concerned with "unneeded" stuff being on their hard drives.

Please note also when looking at the sizes I mention above, they include the latest SP for that OS version also.

I don't think my/our current method of ordered CD is wrong or bad?? I haven't received any complaints and have been doing this again for over 6 months. I am open to suggestions though.

Enthusiast

darthyoda6

Posted
Posted
All CD orders are in fact the expanded/installed files from a "C:\Program Files\AutoPatcher\xxx" folder on my computer. When updates are released the installer is run twice, once for that versions individual folder and a second time for my "all" folder that I use for DVD's.

Please note also when looking at the sizes I mention above, they include the latest SP for that OS version also.

I'm glad to see that includes the latest SP. That way I don't have to look for which cd has which sp.

Grand Master

+theblazingangel MVC

Posted
  • Author
  • MVC
Posted

yes, one update release can check for the hash of anything from the previous months release or itself, however it cannot guess what the hashes might be for future releases! e.g. lets say hypothetically the latest release someone has is may07, and for some reason they want to reinstall all update releases from march07 onwards without reinstalling the feb07 full/core release (i've done it myself). how could it possibly use the md5 of a future release when it has no idea what it might possibly be...

Rising Star

PsiMoon314

Posted
Posted (edited)

Hi Blaze,

yes, one update release can check for the hash of anything from the previous months release or itself, however it cannot guess what the hashes might be for future releases! e.g. lets say hypothetically the latest release someone has is may07, and for some reason they want to reinstall all update releases from march07 onwards without reinstalling the feb07 full/core release (i've done it myself). how could it possibly use the md5 of a future release when it has no idea what it might possibly be...

Difficult problems and as you have probably guessed it will be difficult to do.

One way that springs to mind would be to post the MD5 hashes online for download buy the user to be added to the previous release. This could be automated of course however then you have a whole set of other issues with online access etc so it's not ideal.

The only other way to do this would be to use some method to work out if a future release least a valid one issued by someone authorised to do so. This might involve public key crypto type peocess to sign the release to ensure that it's tamper resistant.

Within the release is information on the date it was released stored in some convienient form.

For example, if the March release see's a release signed with the correct signature and that release is dated say April then it can assume it's the April release. You can still use MD5 hashes to ensure that the March and April releases are valid internally and have not been tampered with individually.

As long as the information for signing the builds is kept secret then there should be no problems with forgeries.

If you are not that worried about forgeries then if the next release contains the previous months MD5 (which should be unique) then they can talk to each other to confirm the correct MD5 hash is given to the previous month by the next month. Signing is not used in this process.

This could be chained togeather to ensure that updates are installed in the correct order even if they are incorrectly named etc.

Kind Regards

Simon

Edited by PsiMoon314
Neowinian

CLHatch

Posted
Posted
yes, one update release can check for the hash of anything from the previous months release or itself, however it cannot guess what the hashes might be for future releases! e.g. lets say hypothetically the latest release someone has is may07, and for some reason they want to reinstall all update releases from march07 onwards without reinstalling the feb07 full/core release (i've done it myself). how could it possibly use the md5 of a future release when it has no idea what it might possibly be...

OK, I have a possible solution to this... Once the installer is built, calculate the MD5 hash yourself. Append to the installer the MD5 hash you calculated. Have the installer compare the actual MD5 hash of the installer NOT INCLUDING the MD5 info appended. If it doesn't match, it's not a good copy. It will also be able to tell if any future updates are good copies, because the MD5 hash info is in a known place in all updates.

Of course, the MD5 hash will not be the same as posted on the web site, because that one will have to be calculated on the entire file including the appended MD5 hash. It might actually be a good idea to have an option to display the MD5 hash of the entire file for us to check on the website for the truly paranoid, since that appended MD5 hash could be changed by someone who may have changed the files. If you think about it, this would make it very difficult to forge the hash, because you are dealing with two of them, the one of the website also based on the bytes of the appended hash.

Grand Master

+theblazingangel MVC

Posted
  • Author
  • MVC
Posted

@CLHatch, we're not talking about file integrity, we're trying to determine which release the user has installed. i.e. when installing update release C, the prerequisite is that update release B or greater must already exist.

that said, the idea of making the original md5 available from the download itself is a really good idea if its possible. some translators never post them and it would make it easier for the user to find :) it all depends on whether what i'm thinking is possible though!

This topic is now closed to further replies.
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.