Faster XPize install after CD integration?

[Delprat]

you should read carefully...

As long as I know windows the hotfixes replace the entire files.

"other programs" means not "windows hotfixes"

"other programs" means "all the wide variety of programs you can find anywhere"

don't be so stubborn... stupid me, you may have interest in MS ?

Yes I already know that XPize already updates the resources without knowing if the file is the same it is meant to be patched I just made my suggestion considering that such a practice won't change. However XPero could save correct CRCs of the resources and compare then when they're extracted (there aren't localized resources images as long as I know). So XPize can extract them, compare the extracted resource image files' crc with one stored internaly in the application and be sure the resource it's going to patch is correct. That is probably the best workaround because with CRCs check there won't be messes if the dll is different (another version).

1/ that's only a detail, but CRC/CRC32 is an unreliable algo ; and MD4/MD5 are known to create collisions also. For safety, another algo needs to be used (SHA for example was never broken AFAIK).

2/ all you say here is right... You presume "there aren't localized resources images". That's true. But adding an image as a resource in an executable is not enough to display this image. There is also (localized or not) "code" (mainly DIALOG(EX) or UIFILE resources) that have references to those images (by their ID).

One can easily change this reference, and XPize-like shell packs are blind to this (they update a resource ID that is no more used by the binary file).

This is not a "possible (theorical) bug case", since some shell packs does this sort of modifications. Another example : i were talking about sysdm.cpl 'coz there's here on msfn a thread on how to have a "vista-like" one : if you use it, xpize is no more able to reload sysdm.cpl, with or without your resources integrity checks (you will get the dialog layout of the "vistaized" one, with images from both xpize and vista-ized one, and it looks weird, defeating the "reloader" purpose)

++

[Francesco]

you should read carefully...

"other programs" means not "windows hotfixes"

"other programs" means "all the wide variety of programs you can find anywhere"

don't be so stubborn... stupid me, you may have interest in MS ?

But In my first post I was talking about system files. I don't care about extra applications at all: when you integrate XPize in the DVD it surely doesn't patch 3rd party applications.

1/ that's only a detail, but CRC/CRC32 is an unreliable algo ; and MD4/MD5 are known to create collisions also. For safety, another algo needs to be used (SHA for example was never broken AFAIK).

2/ all you say here is right... You presume "there aren't localized resources images". That's true. But adding an image as a resource in an executable is not enough to display this image. There is also (localized or not) "code" (mainly DIALOG(EX) or UIFILE resources) that have references to those images (by their ID).

One can easily change this reference, and XPize-like shell packs are blind to this (they update a resource ID that is no more used by the binary file).

This is not a "possible (theorical) bug case", since some shell packs does this sort of modifications. Another example : i were talking about sysdm.cpl 'coz there's here on msfn a thread on how to have a "vista-like" one : if you use it, xpize is no more able to reload sysdm.cpl, with or without your resources integrity checks (you will get the dialog layout of the "vistaized" one, with images from both xpize and vista-ized one, and it looks weird, defeating the "reloader" purpose)

The way XPize replace the resources is already flawed: I just made some easy suggestions about implementing my idea surely there are plenty others but since XPero is just using a nsis setup using reshacker.exe and FC.exe seemed the simplest idea to me.

At least extracting the resources and comparing them would make XPize safer (less system files replacements).

Edited September 22, 2006 by Francesco

[Delprat]

But In my first post I was talking about system files. I don't care about extra applications at all: when you integrate XPize in the DVD it surely doesn't patch 3rd party applications.

Noh, that's the opposite : 3rd-party apps can be used after.

You did said you were looking for an easy solution : writing a specific "reloader" procedure for "after setup in case xpize is already slipstreamed" is not an easy solution when a generic "reloader" procedure can be written. (that's already the way xpero did, even if he did not thought about this case)

Thus my first post in this thread : "log slipstreamed resources" and my second "add a hash to this log". This way of patching resources allow the exact same "reloader" code to be used, minimizing the amout of work needed both for writing and debugging.

The way XPize replace the resources is already flawed: I just made some easy suggestions about implementing my idea surely there are plenty others but since XPero is just using a nsis setup using reshacker.exe and FC.exe seemed the simplest idea to me.

But it's not the simplest nor the easiest : why extracting resources to compare them when it's possible to compare whole files in less time ? (when you slipstream Xpize, no files are partially patched : either they are, either they are not)

Obviously there are better ideas but I only expressed the one I thought that may have been the easiest to implement for XPero. And surely extracting the resources and comparing them would make XPize safer (less system files replacements) and less flawed because if a new dll comes out and the resource ids are not the same then it won't get messed up. Nothing more nothing less.

Having "less system files replacements" is not safer than anything. Sorry for being bold, but having safe files replacements is safe no matter how many replacement there are. Again, sorry for being bold, but extracting-then-compare resources increases the number of operations above the bare necessary which is increasing the risk of error...

About the resources IDs, they can be "same", "different" or "partially different". The first case is aready handled. For the second and the third, you're suggesting to ignore and continue, making the xpize reloader no more a reloader whereas it's possible to handle correctly these rare cases and reload the right resources.

++