Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


strel

Silent .NET Maker synthesized 20100118 - W2K/XP/2K3 x86

Recommended Posts

2 strel

No changes in the reg key, WU ask for langpack to Microsoft .NET Framework 2.0: x86 (KB829019)

Do you have a old _SNMsynth without reducing to send me?

0d

Edited by 0d14r3

Share this post


Link to post
Share on other sites

0d14r3

Bug fixed, check new version

Edited by strel

Share this post


Link to post
Share on other sites
for KB971276, I have modified it again. now it's totally ok in XP SP2/SP3 and 2003, expect for a tiny bug in XP. However this bug is fixed and the attachment shows all(extract KB971276, modify it, generate bug-fixer as a cmd file for later use).

put the attachment in .NET 3.0 working dir, which includes XPS printer.

This attachment will also replace windows hotfix update shell in WIC and XPS lng pack with that in XPS printer, that ensures a smaller 7z archive.

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.

There is another type of hotfixes, they may not require a reboot, but they have some post-install commands, therefore they may call spupdsvc.exe to perform these commands AT ONCE. WTF spupdsvc.exe doesn't know which delayed commands are scheduled by this installation and which are by others, so it executes every thing.

This is quite ok on a living system, but on a setup-in-progress system, it may be fatal. if you ever have a look at Windows Setup timeline(although it's quite out-dated it does something to this issue), you'll know that all steps are scheduled in order for a windows setup. One mistake may lead to the change of all the timeline after it. However, on a untouched system, this issue is so slight that can be ignored. But on a customized system, this issue may lead to quite a lot of customized actions fail. EDIT: and windows setup is so fragile that even a small fault may lead to global fail.

There once was a thread in RyanVM.net that discussed about all these, if I don't make it wrong, it was because a guy who made a T-13 switchless installer that executes some inf files to perform certain installation. Unluckily, his installer met some condition that make windows perform something similar to spupdsvc.exe, then it corrupted windows setup. (The situation was more complicated than what I described here.)

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.

Edited by strel

Share this post


Link to post
Share on other sites

New update released! :thumbup

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.

Edited by strel

Share this post


Link to post
Share on other sites

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.

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.

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

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

New update released! :thumbup

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

Edited by YumeYao

Share this post


Link to post
Share on other sites

When i run the installer at T-13, i have 6 log files left at the root of my system drive (see pic) is this normal ? i think previous versions didn't do that.

I have used 20090913_SNMsynth. installed all frameworks (except 1.1 ) and french langpacks in merged installer.

090924020147261268.png

Share this post


Link to post
Share on other sites

Its normal for last versions.

I have eight log files in my root, all dotNET mergeg in one installer.

0d

Share this post


Link to post
Share on other sites

replying from my mobile device.

this log issue is because environment variables are not assigned at T-13. strel specified log path to "%temp%\logname", resulting "\logname", which means logname in the current root.

I have locally fixed it by adding this line to install.cmd

if not defined temp set temp=%cd%

Share this post


Link to post
Share on other sites

I've got a solution, I have to test it. About the error with the log files there are environment variables at T13, but not %TEMP%:

Here is the result of the SET command, run at the T-13 minute point:
D:\$OEM$>SET
ALLUSERSPROFILE=C:\Documents and Settings\All Users
CommonProgramFiles=C:\Program Files\Common Files
COMPUTERNAME=NEWXP
ComSpec=C:\WINDOWS\system32\cmd.exe
Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.JS;.WS
ProgramFiles=C:\Program Files
PROMPT=$P$G
SystemDrive=C:
SystemRoot=C:\WINDOWS
Upgrade=False
USERPROFILE=C:\Documents and Settings\Default User
windir=C:\WINDOWS
__PROCESS_HISTORY=C:\WINDOWS\system32\setup.exe

Edited by strel

Share this post


Link to post
Share on other sites

Hello,

I made a .net package (German, version 20090922 and 20090913) with this configuration:

PROCESS_DNF1=
PROCESS_DNF2=
PROCESS_DNF35_DNF2=YES
PROCESS_DNF35_DNF3=YES
PROCESS_DNF35_DNF35=YES

PROCESS_DNF3_RGBRAST=YES
PROCESS_DNF3_WINIMAGING=YES
PROCESS_DNF3_MSXML6=YES
PROCESS_DNF3_XMLPSSC=YES

DNF_FF_ADDON=YES

PROCESS_LNG_DNF1=YES
PROCESS_LNG_DNF2=YES
PROCESS_LNG_DNF35_DNF2=YES
PROCESS_LNG_DNF35_DNF3=YES
PROCESS_LNG_DNF35_DNF35=YES

ADDON=
MERGE_FRAMEWORKS=YES
SILENT=
COMPRESSION_RATIO=
WINXP=YES

Unfortunatelly it installs only .net 2 and .net 3 but not .net 3.5

I'm using this files:

dotnetfx35.exe

dotnetfx35langpack_x86de.exe

msxml6-KB954459-deu-x86.exe

NDP20SP2-KB958481-x86.exe

NDP30SP2-KB958483-x86.exe

NDP35SP1-KB958484-x86.exe

NDP35SP1-KB963707-x86.exe

File size is 42.854 KB.

It worked with version 20090514. The file size was 50.859 KB

Any hints?

Regards

Stephan

Share this post


Link to post
Share on other sites

Can you check 3.5SP1 and its languages are not really installed after looking for them on HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} regkeys?, if they are not really installed, and if you have installed made the install out of a windows setup, is there any NETFX35install.log or NETFX35LNGinstall.log related to this installs (check date) in %TEMP% folder?

Edited by strel

Share this post


Link to post
Share on other sites

Hey Strel,

I updated the NL one, see here:

http://www.ryanvm.net/forum/viewtopic.php?t=7213

But unfortunatly, dotNET 2.0 crashes when windows xp is booting to desktop, just like the webclient service, because of this desktop hangs for like 10 minutes, and cant do anything. I disabled the causing service, but it still hangs, so I need to wait till it boots up.

Event log is full of errors, the exact errors are comming tomorrow (not written them down yet) , I will do some more tests also.

I installed from cmdlines. (using my extracted .exe from addon).

I might try installing it from runonceex.

I will rebuild installer tomorrow also.

Edited by Raoul90

Share this post


Link to post
Share on other sites

No changes were made to 2.0 installers in the last versions, so I don't find any justification for such a bunch of errors. Waiting to see more info.

Edited by strel

Share this post


Link to post
Share on other sites

Hello strel,

thank you for your answer.

The regkeys are not there. Also no files in C:\Windows\Microsoft.NET\Framework\ nor NETFXxxx.log.

Can you check 3.5SP1 and its languages are not really installed after looking for them on HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} regkeys?, if they are not really installed, and if you have installed made the install out of a windows setup, is there any NETFX35install.log or NETFX35LNGinstall.log related to this installs (check date) in %TEMP% folder?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...