YumeYao

I'm looking into the mysteries of NETWUFIXES.mst, NOFFADDONFIX.mst and REMFONTCACHEFIX.mst. Here are some suggestions/questions: I understand how REMFONTCACHEFIX.mst works, yet I haven't confirmed how Binary.FCSInstaller performs a RemoveFontCacheData action. I don't know if you're 100% sure but it makes sense. Anyway, if there is any space for unsure, here is a supposed improvment: AppSearch WINDOWS_IN_SETUP DetectWindowsInSetupProgress RegLocator DetectWindowsInSetupProgress 2 SYSTEM\Setup SystemSetupInProgress 2 InstallExecuteSquence RemoveFontCacheData NOT WINDOWS_IN_SETUP InstallExecuteSquence CA_remfontcachedata WINDOWS_IN_SETUP InstallExecuteSquence CA_remfontcachedata_commit WINDOWS_IN_SETUP for NOFFADDONFIX.mst since i don't use firefox but from what i read, it should work flawlessly. for NETWUFIXES.mst I understand KB829019 and KB928416 well. but for KB928416, my test shows even if's not executed, once .NET 3.0 language pack is installed then it won't show in WU/MU, and if language pack is not installed but this fix is applied, it won't show in WU/MU too. Is this by design? KB829019 is Portuguese only so i didn't test it. and for KB951847, i'm not sure what does it do. all i know is it prevents KB951847 from showing in WU but can explain why you're going to rename those msi files to specific file names(because i renamed them back and KB951847 is still not showing in WU)? any info/link you can provide will be helpful. TIA. and just out of curious, why don't you make NETWUFIXES.mst seperate ones and pre-applied them to the msi files? KB829019 for Portuguese .NET 2.0 lp, KB928416 for .NET 3.0 lp(for blocking lp?), KB951847fix1 for .NET 3.5 with KB958481&958483&958484, KB951847fix3 for .....(don't know, maybe all language packs?) and a typo in NETWUFIXES.mst: InstallExecuteSquence CA_KB951847FIX3b ( ProductLanguage=SystemLanguageID ) AND ( ProductVersion="3.2.30729" ) AND ( NOT REMOVE OR ( REMOVE AND ( ( LNG20="#2" AND KB958481 ) OR ( LNG35="#1" AND KB958484 ) ) ) )

good finding. CSetupMM_NetFx35_x86.3643236F_FC70_11D3_A536_0090278A1BB8, DesktopFolder, ProgramMenuFolder, StartMenuFolder and StartupFolder can be removed together with related entries in CustomAction and XXXXXSquence, ensuring a cleaner .msi file. ok, i can edit the post, lol.

after i removed this entry i don't need post-installation reg fix any more. maybe it must be removed together with INSTALLLEVEL together to take effect? 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. I believe you are familiar enough with .cmd so there is no need for me to explain further, all info is in the attachment. extractandmodify.cmd

I updated the tutorial with strel's help. Now it's bug-free.

a fast reply.... I don't know how do you plan to apply my method for language packs, but if you decide to build mst files for each language available, I suggest you stop doing that because I've found a better way to deploy them, including .NET 3.5 (not langpack). I've done enough tests that proves its functionality and I'm going to compose an updated tutorial, so you can do the job after my turorial is updated. EDIT: ok, a quick description is on the base of your method, modifying property table, removes "ARPSYSTEMCOMPONENT" and "INSTALLLEVEL". then you don't need to modify registry later.

waiting for good news from you, good luck! when i'm free enough, i'll help deal with KB971276 (to find a solution compatible for xp sp2 and 2000, if M$ allows XPS printer in .net 3.0 installed on them.) and then later look through your msi files to see if there is still space for improving.

sorry for not replying in time but my schedule is suddenly ful-filled and it will last several days. yesterday it was too late when i saw you post and first .mst file. yeah it obviously wouldn't work at one sight of transformed msi. this time i'm not sure whether it really work since i don't have much time to test it. but i removed more entries than you did. in brief: Binary: SxsUninstallCA CustomAction: SxsUninstallCA & SxsInstallCA InstallExecuteSquence: SxsUninstallCA & SxsInstallCA -------These 5 entries are used for installing VC runtime while Uninstall means uninstalling existing old VC runtime. others seems all ok but just curious: can't an mst file drop a table instead of empty it? I mean, MsiSFCBypass and SxsMsmGenComponents are empty. don't mind since it doesn't matter. and it seems you've forgot to remove VC8 in .NET 2.0 install package. and in .NET 2.0 there is still a junk besides VC8, that's OFFICE 11 debugger.(office 11 SP3 contains newer version of debugger than .NET 2.0) so attachment is what i did for .NET 2.0. it's based on the msi generated by your SNM. and i believe you can handle .NET 3.5 yourself now. remove_vc8_in_dotnet20.mst

1. yeah but they are all font related issues. there are still many unknown mysteries of windows installation even we think we have know enough. 2. 2K3-V2 means it's newer than 2k3(-V1), and XP-V3 means it's newer than XP-V2 and XP(-V1). they are seperate branches, so you can't say XP-V3 is newer than 2K3-V2. 3. KB971314 can be applied on a living system without .NET installed, although it's needed after .NET is installed. Additionally, it's not true that KB971314 isn't needed if .NET 3.0 is not installed. for example, KB948046, which address an printer issue, has already included an updated unidrv.dll, therefore it will also cause the issue descripted in KB971314 - PCL printer driver not signed. so KB971314 is better included in an updatedpack for integration onto windows install source. 4. to remove VC 8 and VC 9 runtimes, removing entries in msi is also needed. If you are not sure how to do that, feel free to ask. 5. ok, glad to hear it so i don't have to help my friends do a slimmed .NET 3.5 language pack for each language they use.

1. on the font. code65536 says it is because some hidden attributes are not set at T-13 so his utility fails, so maybe in some chance these attributes include font caching. now you have explained your method so i see it's totally ok. 2. on KB971276. i'm not combining that for 2k3 and xp but doing tricks on 2k3 hotfix to make it installable on xp - at least on xp sp3. I haven't play with xp sp2 for quite long, and i'll test it later on a VM. for KB971314, I never attend to include it in an .NET installer b/c it's totally an OS hotfix/update(therefore hfslip/nlite/RVM Integrator is a better solution.) for VC runtimes, yeah, you can consider it. The VC runtimes in .NET are not complete ones, so even .NET is installed the user still needs the full VC package. EDIT: from what i read from XPS Printer's install package, it's not installable on Windows 2000, is that correct? fow WIC, yes it's still gray area but i can confirm it's not installable on xp sp3. when you try to install .NET on-by-on without any passive or quiet parameter, you'll receive an error installing WIC on xp sp3, saying "the target service pack lever is higher" or something else. I've worked at ryanvm.net for 3 years so i'm sure with how an OS hotfix behaviors. 3. additionally, is there any chance to make .NET 3.5 language pack the same flavor? Although I know msi files for different language packs varies so there may be not a universal mst file.

I didn't do test on his latest works but when I used it long ago it was. ok, I later think it is an issue in user_hidden's work, his original installer doesn't have this one uninstallable even from "msiexec /x" when I tried to remove it manually. you see i'm always too lazy to download the original .NET installer. lol. thx for this and I'm glad you can apply it on your SNMs to share it with more people.

Many thanks first. yeah, i've catched the cause before and am just curious, did you totally remove this from InstallSequence? I don't know how it'll behavior but there is a post by code65536, says at T-13 there are still some jobs to be done for fonts. So do you think what original .NET 3.0 install does will or will not be done by windows's later jobs on fonts? you can take a look at what I posted along with the method. •KB955450 replaced with KB971276. KB955450 is XPS printer in .NET 3.0. I also did some trick to make it installable on both xp and 2k3. •WIC's update shell replaced for better compression. I copied spmsg.dll, spuninst.exe, spupdsvc.exe and update.exe, spcustom.dll updspapi.dll from KB971276, as 7z will combine same files. These two are helpful and harmless. I've tested it on XP SP3 and 2k3 SP2, it worked perfectly. and for KB971276, I suggest you to use that for 2k3, since KB955450 in .NET 3.0 is 2k3-branch(some files are with version 5.2.xxxx). and for the trick I use, you can follow these steps when you make changes to your script. extract KB971276 to somewhere, for example: %temp%\KB971276. you can use this commandline: WindowsServer2003-KB971276-v2-x86-ENU.exe /x:"%temp%\KB971276" /q copy SP2 branch to SP3(for xp sp3), that means, make a copy of "%temp%\kb971276\sp2qfe" in ""%temp%\kb971276\sp3qfe" copy KB971276-v3.CAT and update_SP3QFE.inf to %temp%\kb971276\update from WindowsServerXP-KB971276-v3-x86-ENU.exe, you can make these 2 files within your script(they are quite small). modify %temp%\kb971276\update\update.ver, just duplicate all existing entries and change sp2qfe to sp3qfe(for each line there are 2 "sp2qfe"s) modify %temp%\kb971276\update\updatebr.inf, add 3=SP3QFE in [DefaultBranchesServicePacks], SP3QFE="update\update_SP3QFE.inf" in [sourceInfsBranches], update\KB971276-v3.CAT in [setupFiles.Common], then add section [setupFiles.SP3QFE] with entry "update\update_SP3QFE.inf". modify %temp%\kb971276\update\branches.inf SP2QFE="%SP2QFE_NAME%",SP2QFE -> SP2QFE="%SP2QFE_NAME%",SP3BTA add SP3BTA="%SP3BTA_NAME%",SP3RTM in [FileBranchInfo] add SP3RTM="%SP3RTM_NAME%",SP3GDR in [FileBranchInfo] add SP3GDR="%SP3GDR_NAME%",SP3QFE in [FileBranchInfo] add SP3QFE="%SP3QFE_NAME%",SP3QFE in [FileBranchInfo] add SP3BTA_NAME = "SP3BETA" in [strings] add SP3RTM_NAME = "SP3RTM" in [strings] add SP3GDR_NAME = "SP3GDR" in [strings] add SP3QFE_NAME = "SP3QFE" in [strings] the attachment contains all modified files along with KB971276-v3.CAT and update_SP3QFE.inf. This method will not increase the size because 7z will archive same files only once. the weakness of this is XP SP2 users may not get this installed properly(I haven't done a test yet) the side-effect of this is both KB971276-v3.CAT & KB971276-v2.CAT will be installed on the user's system.(however it does not harm) There may be a solution but I don't have too much time now for working it out. FWIW the current solution will satisfy most occasions. EDIT: I mean the user can choose whether he want to replace KB955450 with KB971276, it's suggested for XP SP3 & 2k3 SP2 users, and for others, they can just choose not. update.zip

If you are interested in making the output smaller in size: http://www.msfn.org/board/tutorial-modify-...ll-t137477.html this method can be applied on language pack for .NET 3.5, also.

Let me explain the issue first: .NET 3.5 SP1 and its language pack are offline msi installers indeed. They are different than regular installers therefore once you use "msiexec.exe /a" to deploy it, the output dir is much bigger than before and both msi and cab files are still there. Even updated files are useless as the msi file is totally same as before so it only regard the cab file as a valid source. This fact is severe. 1. you can't get patches applied because updated files are ignored by the msi file.(you can try installing user_hidden's dotnet 3.5 and check file version of %SYSTEMROOT%\Microsoft.NET\Framework\v3.5\NetFX3.5InstallPath_GAC\System.Data.Services.Client.dll, it should have been 3.5.30729.196 if updated, but in reality it is 3.5.30729.1) 2. size is bumped. the original msi and cab is still there, and new files are in, so the final size increases. 3. If you just keep the original msi and cab, without attempting administrative install, you should have all patches applied later by starting msp files. this will still result a big 7zipped file. So finding a way to make it administrative-deployable is very helpful for reducing package size. Solution: **** This part needs some basic msi knowledges **** To work out a solution, we must first understand how is an offline msi installer different from a regular one. When I'm paying effort on removing the msi itself and source cab from the msi's file table, I find that no matter how "clean" I think I have done, the modified msi still doesn't work. So I realized the copying of the msi and the cab must play a very important role during the installation, there a thought of "offline installer" rose. Actually, I'm correct. As there is no document describing how to run the 2nd-step installation of an msi file, I decide to strip out the first step and then it works! Open vs_setup.msi(comes from .NET 3.5 SP1) with orca, move to "Feature" table, you'll see a feature named "NetFX35_EXP_enu_x86_net_SETUP" with a level flag of 2, whereas most others are with a level flag of 1. So yes, this the "first step" which I want to strip out! To totally remove it, "Feature" "FeatureComponent" "Component" "Files" "Registry" and some more related tables(such as msifilehash, not necessary for a working msi) should be modified. In next part I'll introduce with detailed steps for how to do it. Steps: Before we start, I recommend that you use InstEd to edit the msi file. It really has saved me a lot of time, so the steps below are all following InstEd. 1. make a copy of vs_setup.msi, for example here: vs_setup_org.msi. This copy is used for acquiring info for removed entries in progress. 2. open vs_setup.msi and vs_setup_org.msi in 2 windows of InstEd. Although InstEd allows you to open multiple msi files in one window, here we start 2 windows because once there is a dialog over it, you can't switch to a nother tab. 3. switch to vs_setup.msi, go to feature table, remove NetFX35_EXP_enu_x86_net_SETUP by selecting it and hitting delete key. InstEd pops a dialog prompting you for deleting related entries, click OK. 4. switch to vs_setup_org.msi, go to FeatureComponents table and look for all entries with Feature NetFX35_EXP_enu_x86_net_SETUP, each one points to a component. 5. switch to vs_setup.msi, go to component table, sorting entries by first column, then remove all components obtained in the previous point. Every time InstED pops a dialog, click OK directly. 6. go to FeatureExtensionData table, remove NetFX35_EXP_enu_x86_net_SETUP. (don't know if this step is necessary) 7. go to Property table, remove 2 entries: INSTALLLEVEL and ARPSYSTEMCOMPONENT. 8. save it, now you can deploy it! Credits: strel (one of Silent .NET Maker synthesized authors), who helped me realize how to make the installer uninstallable and shown in ARP. He also pointed that some steps are verbose and unnecessary, so I removed them. Known Issues: there is no issue currently. . Example (.NET 3.5 SP1): visit http://www.ryanvm.net/forum/viewtopic.php?t=7696 to get more info.

Hi, there. i find a bug in win32k.sys. you know M$ release hotfixes in two grades, one kind is GDR, another is QFE. with latest SP3QFE-win32k.sysES for windows XP, the message table resouces, however, has some entries added. it's al-okey in an english version of that, but in other languages, it's kinda corrupted. let me explain it: look, the new entries 243 and 244 has been added. however, for a non-english win32k.sys, the translation is directly copy-and-pasted without any confirmation. yeah you may got it. here is what's it like in a non-english win32k.sys so then things went messed up. i post this thread to let you know about the issue, and i hope someone can help me send a feedback or a bugreport to Microsoft, 'cauze i failed to find how(getting Microsoft Connect then confused about what next... oops) TIA.

Thanks for your hard work. It's so excellent and it's such helpful for an unattended windows installation.

thanks for you release, will do tests.

Thx all you here who are working hard on the project

so have anybody noticed this: http://www.microsoft.com/downloads/details...;displaylang=en