First I'd say sorry I am again busy in real life. Er..... and I think I may have a cold(one f*cking guy of my roommates keeps motorfan running but it's already 3 days raining in a row.), so I decide to postpone my effort on this project to this weekend.
strel, on Sep 22 2009, 06:46 PM, said:
So here you are removing the inf files that define the update branch, and copying the .NET 3.0 update shell files (for maximum compatibility, I suppose) to W2K3KB971276 for making it able to install on XP SP2, but I suppose this is making it too OS version and SP# level independent (among XP/2K3 supported), what's great.
But I think there's an error in your draft, and correct if I'm wrong, you say update shell from .NET 3.0 framework should substitute the one in the .NET 3.0 langpack, right?, and I think this is redundant.
OK, I see the point, you're downgrading this files.
Yeah it's OS/SP# independent, so it's totally OK to be installed on XP/2K3.
For the statements in red, you get the wrong idea.
For the definition of these totally 6 files,
KB898461 describes it. Although they vary in version, and even files in same version may vary(due to different compile dates causing different build times in PE header), they are doing the same job. They are similar to 7zip sfx module, how they work all depend on the configuration files(just like 7zip sfx config.txt) and contents(just like 7zip sfx 7z archive). Only that maybe a higher version provides more features.
So, here, I want: use highest version of the copy of these 6 files for any installation in hotfix form. The reason is because 7z archive same files only once, hense making the output size smaller. And the hightest version must be downgrade-compatible(there are enough proofs for us update pack makers) so it doesn't curropt the original functions at all.
I'm acturally upgrading not downgrading
, version in .NET 3.0 is 6.
3.13.0, in 3.0 LP is 6.
2.29.0.
BTW, the shell for 3.0LP have renamed spmsg.dll to spmsg2.dll. Just FYI.
strel, on Sep 22 2009, 06:46 PM, said:
I'm working in the option to allow components running spupdsvc.exe to install at RunOnce. But I would like to understand the problem, at least to document it properly in the guide. I think you're saying that OS hotfixes running over GUI-Mode setup are scheduling its delayed actions to be executed by spupdsvc.exe at 1st logon RunOnce; but at this time spupdsvc.exe is making a mess with the all delayed actions it has to apply, that would lead to some customizations scheduled to be applied by the user at that time through spupdsvc.exe too on his unattended source fail, because they need to be applied in a specific order. Am I right? Thus, a user with this requirements would delay all OS hotfixes installing from GUI-Mode Setup to RunOnce, so that delayed actions for that hotfixes would schedule to be run by spupdsvc.exe on 2nd logon RunOnce. Have I understood it right?
If affirmative, let me say that in my opinion the user better should seek another method to apply his customizations.
Sorry you make it wrong again. (I think I have to improve my ablity of expression.
)
Continueing with the previous topic, I said that there are totally 6 "update shell files". Actually for most windows hotfixes/updates, there are only 5, spupdsvc.exe missing. spupdsvc.exe is not DELAYING jobs for next reboot at any time(this part can be simply done by registry), instead it always makes DELAYED jobs start right now. It's not odd that you can't reproduce it. For most delayed jobs, they are safe to be executed at once, that's the reason of spupdsvc.exe's existing. M$ uses this file to do certain post-hotfix-install routines including making delayed jobs execute.
For an untouched windows install source, there are some delayed jobs that can't be executed at once when the progress is T-13, but the problems they're causing are so slight that most people would ignore them.
An example is if you use nlite to crack syssetup.dll, nlite will make a delayed schedule at Pre-T-13(registry process stage) to restore syssetup.dll on next boot(move sysback.dll to syssteup.dll). Then a spupdsvc.exe executing at T-13 will break this.(it try to move sysback.dll to syssetup.dll but syssetup.dll is in use so sysback.dll is deleted and syssetup.dll is left as it was.)
Because as I said, most hotfixes doesn't contains spupdsvc.exe so it doesn't need the user to delay hotfixes to RunOnce and nlite can handle this correctly.
Off the topic, I suggest direct integration of hotfixes, or what's better, an
update pack(as the maker will consider everything through).
strel, on Sep 22 2009, 10:13 PM, said:
New update released!
It's NOT the release you're waiting for with the whole YumeYao's slimming method yet. This one will come soon.
In this one a couple of bugs are fixed:
1. The one causing 0d14r3 and brazilian users not to block KB829019 that was inserted in 20090912. Something copying .mst files to .msi folder and executing them from there not worked; plus doing all this as a workaround for
Karoly67 problems avoid removing of fixes applied on uninstall for this case, and only masks the real problem.
2. The one causing YumeYao and everyone, not to block KB829019 when removing only 2.0 SP2 langpack while keeping framework, and in general causing not removing the fixes applied correctly on uninstall. This bug was a typo inserted in inlay fixes removing scripts in NETWUFIXES.mst since 20090818.
YumeYao, finally your KB829019 prompt was caused by not having installed the langpack while the fix is still applied. I've reviewed you Block script proposals they wouldn't work, NETWUFIXES.mst does the work very well, but yes probably I'll split it.
thanks for this.
For my blocking scripts, yes they were not working correctly. Blockalllp.vbs is always working as expected, BlockKB951847.vbs was not working and I have fixed it(removed "(" and ")" for function WriteRegKeyIfNotExists in line 6,7,8). Blockall_Undo.vbs is still not working and I can't figure out where the error is.
Do you know any editor or tool that can assist a vbs editing?
EDIT: I've found a tool named PrimalScript, 45 days free-trial, it should be enough for me. thanks anyway.
EDIT2: Just see that you are woking on spupdsvc.exe fix. I have accompolished a modified version of your install.cmd, which including this fix. I'll put it here later in a word document(do you prefer .doc or .docx or .rtf?) with colored comments. Then all you need to do is convert them into your script(adding echo>>install.cmd and adding %, ^ and such special symbols.)
This post has been edited by YumeYao: 23 September 2009 - 10:11 AM
Frontpage
Forums
Tutorials
Members
Calendar
Subscription
Donate
Links
Contact 
Help
Back to top
