strel

XP SP3 doesn't has any .NET framework version installed. See Silent .NET Maker synthesized.

Yes, I was focusing only in 3.5 frameworks, I'll make files for 2.0 frameworks too, but I see yours is almost neat, that's going to save time. My test revealed that removing those empty tables cause installation to abort, it surprised me, don't know if I did something wrong. A lot of thx YumeYao.

I don't think so, moving and strifing with keyboard, and aiming with the mouse is possible, the real annoyance is deformed free view up and down this engine makes. Like with Duke Nukem.

I concur with iamtheky.

YumeYao. This one seems to work. [ OUTDATED FILE ] Prior to approve it, I'd like to have your opinion after checking the database as you've done this before and me not. Thx in advance.

Just my terrible headache this morning, I misunderstood him. And now I realize what are you referring to. Really have no idea on how font caching behaves about hidden file attribute on fonts, but I don't have any reason to think that problem is reproducing with font cache service. OK, so I misunderstood your method, but why doing that? it seems 2K3 installer is Version2 and XP is Version3. But may you concur with me that if resultant installers are not meant to be used in a windows setup it makes more sense to include it. Nice info, to remove them you simply remove Windows folder in 3.5 SP1 portion, is that right? It's done yet, 3.5 SP1 framework+hotfixes+langpack around 5 MB. I'm just deciding to include or not some extra modifications in the next version.EDIT: Never tried it.

I've substituted the .dll custom action RemoveFontCacheData in the InstallExecuteSequence with 2 .vbs custom actions that removes the font cache data file effectively. Why 2? I wanted to replicate original installer behaviour and another RemoveFontCacheData_commit custom action referring to the same .dll and entry point arises when the first is run from InstallExecuteSequence to be executed after InstallFinalize, thus trying to assure the operation (if there wouldn't be a bug). This issue is not related with the previous one. What code65536 says is that windows is not registering some legacy fonts at T-13 until (at least) user log on. What he points out (I think) is that if this behaviour is overcomed, if you open a terminal (or so) during windows setup wrong font will be displayed, but only during setup. I don't exactly know what fonts 3.0 is installing but don't seems they are going to be legacy, so I don't think windows setup is handling its hidden attribute in order to avoid them to be registered over windows setup. Answering the rest of your post, thx for clarifying your method. So you're building .NET installers that include KB971276 features, I suppose all features of KB971276 are applied to the installers with this method, thus if windows would need to install KB971276 later, all this wouldn't make sense. For the XPS printer you're combining XP+2K3 KB971276 hotfixes, I don't like this for SNMsynth because I think it's better to build different installers to different windows versions to adapt them to version specific requirements, since SNMSynth installers could include another hotfixes that could apply exclusively to a specific windows version. Moreover you say there could be problems installing over XP SP2, that would be a great weakness. I don't know if I've understood you correctly but If you are saying something like an option to choose whether applying KB971276 or not, or whether applying XP+2K3 versions of it combined or not, would be a solution; then I agree with you, but only if this method apply all features from KB971276 hotfix(es), avoding the need to install it later.For the rest of your modifications, as long as I think SNMsynth should be oriented to customization I think that giving the option to avoid to include VC runtimes in the resultant installer, allowing its install from another packs, is a good idea; as well as including options to allow .NET related windows hotfixes, like KB971314 and KB971276, to be included in the resultant installers, idea I deprecated until now because they don't have the form of .NET hotfixes and could easily be slipstreamed to a windows source, but I realize it makes a whole lot more sense if resultant installers are not meant to be used in a windows setup so a unique file with completion is a more interesting option. To avoid including WIC or MSXML, SNMsynth have options yet to do it. And of course documentation about what cases are this options useful to, needs to be included in the guide, now it's a grey area. Cheers.

By the way, as I don't know what happened with you, and I don't know if you read my PM, and just discard it, can you try changing at the beginning of script CALL :EMPTYVARS line with REM CALL :EMPTYVARS ?

I suppose you can't or don't want to boot from HD so that you boot an external media to run it. You may have the USB option. Not sure if it is possible through network but as long as you could boot a PXE image I imagine you'll may be able, as if you were booting from a media.

Are your fresh source reliable? Are you installing on a exotic partition scheme? Did your previous right trials remove BIOS info from text mode setup (options section)?

I still haven't checked final filesizes, but if you didn't get errors, I think it's correct. It is the new YumeYao's slimming method integrated for 3.5 SP1. Try installing and uninstalling of 3.5 SP1 and its langpack. Moreover for the next version, this slimming method is going to be applied to the 3.5 SP1 langpack too, making 3.5 SP1 resultant installer, even smaller. EDIT: I've checked it with the dutch installer. I was right. And if you don't touch COMPRESSION_RATIO to get max ratio (which should be doing everybody unless you have a pretty old machine with pretty low RAM), you'll get even smaller ones.

I suppose windows has behaved like if there was another WINDOWS installed on the partition deprecating the first folder. Have you tried simply repeating the nLite process?

About FSB I highly recommend you this CPU-world to stay in touch with processors. And Toms Hardware or Anand Tech for benchmarks. CPU Benchmarks seems to be a good reference too.

Still no luck. You didn't include file extensions, I hope they're right. No idea what's happennig with you. Can I have a screenshot? In my case the process run smothly except 1 bug I found applying KB963707 introduced in the yesterday release, and one minor issue removing unexistent files. But nothing about script requesting files actually present in the work folder. Bugs fixed now. Download the new version! EDIT: I forgot to remove 3 pause commands I use for testing, I've updaloaded it again. The first 9 who downloaded it, excuse me for the inconvenience

I still run regularly one of the Redneck Rampage saga, despite the bad 3D engine. And I'm still waiting for another game with leather style lyngerie violent aliens ready to punish your a** through the gardens of graceland.

Not getting that message. Please post your _SNMsynth settings and the file list in your work folder

New version in da hood! Managed to workaround the old 3.0 framework errors in the event viewer installing at T-13 (and later uninstalling), and managed to fix and to adapt YumeYao's method for slimming down 3.5 SP1 installers, among other things. Enjoy!

YumeYao, thx for sharing your method, I was aware of it but didn't put hands on it until now. Ultimately I realized too 3.5 was oversized but I hadn't a good solution. Your method rocks and I managed to fix it and to include it in the new Silent .NET Maker synthesized version. This never happened with SNMsynth installers, don't know if that happened in the previous versions of user_hidden installers, I don't think so, but obviously not on the last version. I suppose both are being made from admin install, I don't know why it would fail in his case. I was trying to make this value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{CE2CDD62-0124-36CA-84D3-9F4DCF5C5BD9}\UninstallString (the GUID refers to 3.5 SP1 framework) work by setting a fixed uninstall log filename for each framework version, but I was failing. From a failed uninstall process log I realized that, in the case of 3.5 SP1, Add/Remove Programs is not calling msiexec but %SYSTEMROOT%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5 SP1\setup.exe that is not copied with your method. That's why uninstall fails from Add/Remove Programs and why you said (I think) msiexec /x don't work for uninstall, but the later is not correct, if you open a command line and execute the UninstallString msiexec command, uninstall takes effect.SOLUTION: The following modifies your guide. - In point 4 forget about selecting remove on that feature and go to FeatureComponents table and look for all entries with Feature NetFX35_EXP_enu_x86_net_SETUP, each one points to a component. Don't do anything - In point 5 remove all components obtained in the previous point including ARP_REG_NETFX35_x86.3643236F_FC70_11D3_A536_0090278A1BB8 component (it's causing ARP to call %SYSTEMROOT%\.......\setup.exe) - Avoid point 6 - EDIT: AVOID POINTS 8, 9, 10, 11 AND 12. I was unsure at first but now not. Sequence in FileTable and Last Sequence values in MediaTable, only has to do with .cab files. No .cab file, no worry about sequence. Editing it is totally unneeded. - You should remove too in the Registry table, all values pointing to SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\[ProductName] - After you build your installer and install it you should change the following registry values (or maybe you can insert them in registry table, didn't try that): HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{CE2CDD62-0124-36CA-84D3-9F4DCF5C5BD9}\SystemComponent to 0 (this makes a 3.5 SP1 entry appear in ARP, but this one is not pointing to setup.exe) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\26DDC2EC4210AC63483DF9D4FCC5B59D\InstallProperties to 0, this one has no effect but to keep congruency. And then you are able to uninstal from ARP. In SNMsynth I have not included the rest of your modifications, I have yet to see if it worth it. And in the next days I'll try to apply it too 3.5 framework and all 3.5/3.5 SP1 langpacks. Thx a lot YumeYao.

It's explifiying your boot.ini has to be fixed. Yes.

New realeases are not announced.

If there's .inf files try using Roufneck's DrvComp. Then try using the output with nlite.

Always do it in one step with a fresh source.

Be careful too about trimming components too much, with nlite is very easy to overcome the limits of stability, and it's poor documented in order to avoid this kind of things happen.

Hi djanz. OK. I don't know if regkeys or .msi database items to fix with .mst files have changed a lot from x86 version, if not you're lucky, otherwise it comes the boring part. You'll need to extract the .vbs files to understand what the CustomActions of .mst files do. The logic of the conditions to execute custom actions in the InstallExecuteSequence is a bit tricky. Ask me your questions.

More complete answer in the next post.