Faster XPize install after CD integration?

[Francesco]

I saw that when I integrate XPize on system files of my Windows CD and after I install it again in GuiRunOnce XPize reintegrates all the files even the one that have been already integrated.

Couldn't XPize extract the resources from those files, compare them and skip the already patched files making the install faster (obviously those files should be still monitored by the reloader)?

[XPero]

Why are you installing it twice and using different methods? I dont see it as a good practice, but I would like to know your reasons

[Francesco]

Why are you installing it twice and using different methods? I dont see it as a good practice, but I would like to know your reasons

I integrate and install after for the same reason that people integrate hotfixes on the cd: because if for some strange reasons some files on the PC gets damaged the patched ones are copied from the cd with the right resources.

The second install is to install the other stuff (some files updated by post-install hotfixes and third party apps) however it takes a lot longer. If XPize could check if a file has already been patched or not it could install a lot faster.

[XPero]

I dont see how it can be done. Anyway, this is not an intersting feature for the average user IMO, sorry

[Francesco]

I dont see how it can be done.

It could be done by extracting the resources from the system files and comparing them with the ones that should have been patched.

Anyway, this is not an intersting feature for the average user IMO, sorry

I thought that most people here did integrate on the CD and then installed XPize when windows installs to complete the patching.

[Delprat]

I dont see how it can be done. Anyway, this is not an intersting feature for the average user IMO, sorry

Un, dos, tres :

Log slipstreamed resources, slipstream the log, read back this log after windows setup.

++

[Francesco]

I dont see how it can be done. Anyway, this is not an intersting feature for the average user IMO, sorry

Un, dos, tres :

Log slipstreamed resources, slipstream the log, read back this log after windows setup.

++

That isn't a good idea because there are some MCE hotfixes that should be applied after windows installation.

XPize should be run after the hotfixes and as you can imagine at that point the log won't be accurate anymore.

The best idea is to extract the resources and compare them or let XPize change the file version structure adding it's own signature (so it doesn't need to extract all the resources but just the signature to find out if the file is patched or not.

[-I-]

1 easy option... is a commandlike option like...

xpize /fix filename.dl

[Francesco]

1 easy option... is a commandlike option like...

xpize /fix filename.dl

I think that a better idea would be to skip all the files that XPize usually integrates in the cd. It won't be the same thing (because it will require XPize to be installed before the hotfixes) but at least it it will make things faster.

[Delprat]

Log slipstreamed resources, slipstream the log, read back this log after windows setup.

That isn't a good idea because there are some MCE hotfixes that should be applied after windows installation.

It is a good idea(*1), and this error can be avoided with one of these three little tricks :

- hotfixes can not be applied before T-13 (svcpack.inf), and the order things happen from this file is easy to control

- md5 hashes or sha-1 hashes or whatever algo you want hashes embedded in the log

- files' versions embedded in the log

Like you said in the other thread, adding "tags" inside the files(*2), or extracting-then-compare resources will also work, but checking each binary is slower than reading a single log.

(*2): this should be considered as a bad technique, since the updated resources themselves can act like "tags"

(*1): i have a working batch that does it flawlessly, sorry for this egocentrism

++

[Francesco]

Like you said in the other thread, adding "tags" inside the files(*2), or extracting-then-compare resources will also work, but checking each binary is slower than reading a single log.

It is slower but it's more accurate. If it's just a version string then the check will be pretty fast: XPize doesn't patch a big number of files.

(*2): this should be considered as a bad technique, since the updated resources themselves can act like "tags"

But it's the most accurate way to do that job because XPize can know if each file has been patched.

(*1): i have a working batch that does it flawlessly, sorry for this egocentrism

That does what? altering the version strings of the files?

[Delprat]

It is slower but it's more accurate. If it's just a version string then the check will be pretty fast: XPize doesn't patch a big number of files.

But it's the most accurate way to do that job because XPize can know if each file has been patched.

stop brainstorming and implement your idea in a real program of your choice (or find someone to do it).

you should be aware that i've already wrote a bug report for it

That does what? altering the version strings of the files?

it was referring to "Log slipstreamed resources, slipstream the log, read back this log after windows setup."

It does some other thing too, like actually slipstreaming the resources or extracting them back (it's in fact @T-13 before any hotfix can be applied, not after setup).

i'm still debugging the "backup before hack" and "reloader" parts.

++

[Francesco]

stop brainstorming and implement your idea in a real program of your choice (or find someone to do it).

Where's the problem XPize can just extract the resources with reshacker and it can use FC.exe windows utility to compare them. There's no need of a magician to do such a simple task.

you should be aware that i've already wrote a bug report for it

But this is not a bug it's a feature suggestion

it was referring to "Log slipstreamed resources, slipstream the log, read back this log after windows setup."

It does some other thing too, like actually slipstreaming the resources or extracting them back (it's in fact @T-13 before any hotfix can be applied, not after setup).

i'm still debugging the "backup before hack" and "reloader" parts.

++

Ehm what application are you talking about? XPize? Isn't that programmed only by XPero?

[Delprat]

Where's the problem XPize can just extract the resources with reshacker and it can use FC.exe windows utility to compare them. There's no need of a magician to do such a simple task.

You don't need to explain me again, i understood the first time, and you still don't.

This "feature" suggestion will lead to a bug.

-> adding a tag doesn't mean other programs are able to see it, thus they can update resources leaving the tag intact, letting "xpize_modded_with_your_idea" think its xpized when it is not (same issue if using the fileversion)

-> comparing the resources themselves can be done only by predefined IDs, since xpize updates only the graphics and not the dialogs codes (for example), one can modify a dialog to make it use another resource ID, letting xpize updates a blind resource. This issue is present in the actual xpize, and in some other shell packs, your idea will just slow things without solving that (thus my "will also work"). (if you don't understand this point, just look around for sysdm.cpl customisations, for run box customisations and for logonui.exe customisation -- but all dialog boxes are concerned)

Ehm what application are you talking about? XPize? Isn't that programmed only by XPero?

i'm talking about a script i'm writing, it's not xpize-related, but resources-customizing-related. i just want more flexibility than what xpize do. (and use other resources than just graphics)

++

Edited September 22, 2006 by Delprat

[Francesco]

-> adding a tag doesn't mean other programs are able to see it, thus they can update resources leaving the tag intact, letting "xpize_modded_with_your_idea" think its xpized when it is not (same issue if using the fileversion)

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

-> comparing the resources themselves can be done only by predefined IDs, since xpize updates only the graphics and not the dialogs codes (for example), one can modify a dialog to make it use another resource ID, letting xpize updates a blind resource. This issue is present in the actual xpize, and in some other shell packs, your idea will just slow things without solving that (thus my "will also work"). (if you don't understand this point, just look around for sysdm.cpl customisations, for run box customisations and for logonui.exe customisation -- but all dialog boxes are concerned)

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).