Last7 Collection

Ehm, I was just saying there is no relevant experience for me with those images because I don't have the hardware to test it

 

Ha, one thing to really remember when using the Simplix pack is that you have to install UxStyle *first*.

UxStyle is the only uxtheme patcher for Win7 that patches the theme dll's in memory only. Other patchers actually patch the .dll's on your drive, and since VirtualBox 4.3.12 (or something) having patched uxtheme files results in VMs not working. If you can use UxStyle, it only patches uxtheme in RAM; VirtualBox hardening then won't detect anything wrong and your VMs will work.

Or, if you use hard patchers you could either unpatch the uxtheme files every time (and reboot) before you use VirtualBox -- not really a solution -- or else boot into Safe Mode or something, which I may not even work and doesn't sound like a good idea to begin with.

Yes, that is the sad state of affairs. UxStyle got abandoned (it is on GitHub but last activity was 6 years ago) but it is only a superficial issue with the UxStyle installer that doesn't allow it to install since a cumulative update for Win7 that came out Fall 2019 or thereabout. I presume the UxStyle installer is looking for a certain signature or file version or state, and it not being able to find it after those later Win7 updates, just fails to run. The good thing (so far) is that you can install UxStyle on an original Win7 SP1, and if my past experience holds up, further updates won't disable it. I will test this but I'm pretty sure this will work. It remains the best way to patch uxtheme files and not having custom visual styles is just not an option. Another reason why sysprep is better than offline integration, because I don't think you could install UxStyle otherwise at all. The worst case scenario would be that it won't work and we'd have to use UltraUXThemePatcher or something, and have to deal with the VirtualBox issue. But we've already entered into FrankenWindows territory, no use turning back now

 

I came across a UxStyle Community Edition once; but it was not very helpful towards my goals.

 

If I'm not mistaken there used to be an older version of the Win7 UxStyle installer, which they offered along with the newer/current one. But it's not there now. It may have been a pre-SP1 version. What's so good about UxStyle is that it actually installs a service -- you can find it under Services and can disable it from there, too. So for sysprep purposes, even if you couldn't uninstall by regular means (you can, but theoretically), you could disable the service and still use UltraUX patcher instead or whatever. Meaning, it's not that weird to include it in the install.wim because of this. Well, I'm running the simplix pack after installing UxStyle in the VM, we'll see what happens EDIT: It works

 

I (think I) finalized Win7 x64 and x86 images last night. Since they're Pro, I used Daz Loader as silent installer at firstlogon phase. KMSpico is also in tools folder of the Settings app, including the silent installer that could be used instead with a small edit (or post-install, as Daz Loader can be uninstalled of course).

The install.wim's came out smaller with Simplix pack updating method, and my usual NTLite cleanup routine yielded even better results. It's kind of like being at install.wim sizes of 5 years ago, so I'm happy about that. It also allowed me to include the WIn7 x86 LivePE and 300mb of ppAppsLive on the x64 .iso without the iso being too big for a DVD burn (so remains an option to burn it to single layer). The x86 iso has LivePE and the ppAppsLive too of course, but in the case of x86 it would fit on DVD easier because the x86 install.wim is always smaller than x64 one. Cleaned x64 install.wim is 3.20gb whereas the x86 one is 2.17gb. And that is with VC and older runtimes included, DirectX9 updates, and .NET Framework 4.8 integrated and updated.

UxStyle as mentioned above remains working, but when using sysprep to update the images it must be installed before the Simplix pack gets applied. Also, I normally apply some reg tweaks in the VM and turn Defender off, but after experiencing issues with the Simplix pack & sysprep audit mode ending prematurely, I don't apply any tweaks before applying the Simplix pack, only after. I vaguely remember having tried the Simplix pack before, in sysprep, I just couldn't remember right away. At that stage of the pack, it did not do significantly better than my scripts routine or even WU. But the pack has improved A LOT (I think after the Win7 update model was revised) and is very good now, I highly recommend it. Smaller install.wim in this case also means less complexity and bloat in WinSxS, and possibly better future update application.

This part is still experimental but I'll test it out on real hardware soon: For some years I had no longer been using modded imageres.dll and spwizmig.dll files in the install.wim (I did use the ones in boot.wim). This means that you can have a custom background during install. For boot.wim, it means the Setup background can be customized. Once it reboots however, it switches to install.wim, so unless those .dll's are modded in the install.wim as well, you'll see the default Win7 logon screen during that phase of the install. The way I had been doing things the last few years is replacing the logon background during firstlogon, but then only after a reboot the custom logon screen would be in place. But now, hoping that VirtualBox hardening doesn't have a problem with those modded .dll's, I placed them in the install.wim so the entire install the custom background is showing (as it was on most LastOS 7 builds of the past). We know that the uxtheme dll's when modded and on the Host OS, cause VirtualBox VMs not to work. VB checks these and other files and if they're not signed it refuses to work. From what I read there is indication that VB does not check imageres.dll and spwizmig.dll, but it is possible that VB has implemented this with newer versions. So I'll have to do a real install and run some VMs to make sure. If they haven't added these to their hardening list by now, they won't anymore. So I'm hopeful this will work because it does make the install process a bit nicer.

Beyond that it's been a lot of small edits, making everything work.

 

I think it was since (or right after) v4.3.12 or so. But it doesn't matter for VMs, so you could have patched uxtheme files in the Guest OS/VM, and it will work just fine. But you can't have these files patched on your Host OS or the VMs fail. This is why I switched to UxStyle (which patches in RAM only) at that time.

 

I wouldn't mind in general, and it's probably fine with AMD drivers. But with Intel ones I had a problem with versions 8,9,10 of their chipset drivers, they had a "0" identifier in their drivers, making the system sometimes choose the wrong chipset drivers during install, causing BSOD. But I think with AMD it should be okay.

But what I was thinking was making another set of images based on that tool we talked about, that adds in USB3, chipset, nvme drivers and uses the CPU patch. Maybe even use a WIn8 or 10 boot.wim so it would have most drivers in there already, so they'd only have to be added to install.wim (and winre if you want to go that far). That later option would also allow using .esd format, making the images much smaller. But I haven't gotten around to that part yet.

Do you have a generalized AMD driver pack? It should be for both boot.wim and install.wim right?

 

Hey T, sorry to "double post" here and in the other convo, but have you tried the latest version of Blackbird https://www.getblackbird.net/download/ with any of your latest Win 7 builds? I know you had some issues before, but it has been updated as late as Nov 10, 2020, and I think there are installation switches available that can deal with the issues you had, if I remember correctly? Just curious, and since you have some time available while waiting for that Zero day patch.

FWIW, I agree with Ghost about adding in the drivers for the later AMD CPUs, and Intel if you can find a set that works, as long as it doesn't mess it up for older CPUs. Even if you use that tool, from what I understand you could still use Simplex to add the updates, if that is what you prefer, and only use the tool to add the other stuff. I guess you could have two different install disks, one for older CPUs and one for newer, but that's obviously not ideal.

 

So I'm thinking of making one set of iso's (x64 and x86) that has the Win7 x86 LivePE but without added drivers, and same for the install.wim. So this would install well on Win7-era hardware. I can't see a good reason NOT to have this basic setup.

Then I'm thinking of making another set of iso's that has the USB3, Chipset, NVMe drivers integrated in boot.wim and install.wim, and has the CPU patch that allows Win7 to install with newer CPUs. This would be a more experimental approach that would have a mixed success rate I would think, but may allow for install of Win7 on newer hardware. Whether this type of iso could have a LivePE and/or should use a Win7, 8, or 10-based boot.wim I'll have to see.

 

The simplix update pack, when using offline integration only, integrates a number of USB3 and Chipset drivers, which it does not do when installing it live (so when using sysprep to update images). However I found the driver pack he uses so I can integrate these drivers myself post-capture. I think I'll use NTLite to do the driver integrations.

One thing I did notice is that the NVMe-related MS updates you provided in your driver pack don't get installed by default by the simplix pack, yet when I installed KB2990941 (which did install), KB3087873 gives a "not applicable" message. This could mean the update is present in the rollups already installed, but that would be weird given it's a fix for a problem caused by KB2990941 which doesn't get installed by the simplix pack. But since the KB3087873 message didn't state "already installed" it is hard to figure out if the fix is applied or not. So I ended up installing those 2 KBs and another relevant one first, then applying the simplix pack after these, which works. At least then we're sure those KBs get applied.

For the CPU bypass, there is wufuc, WuaCpuFix (based on wufuc but without patching original OS files), and yet another method utilized by the MDL 7 tool. So I'm going to use one of these methods as I find out more about them. I'm looking into creating a collection of drivers for integration into boot.wim and install.wim (maybe even winre) and will look at the MDL tool, the W7UT (Windows 7 Updated Tool) and some other sources for these. The AIO tools like the MDL and W7UT ones tend to work in specific ways and apply certain things I don't want, so I'm having to pick their methods apart to see what will work. I don't want updates applied, or extra sidebar items installed, for example, so I will have to pick things apart to see what's relevant.

 

The attempts to integrate drivers into Win7 boot.wim and such is futile, as I had long ago concluded. This is due to various reasons, but one important one being that the driver names for various gen hardwares are not differentiated, meaning the system can boot the wrong drivers and fail (even in VM, let alone real install). There are a few USB3 drivers that could be intergated that are ported from Win8 and digitally signed (win-raid forums) and even if these could work the target systems for such an image would be systems without USB2 ports / post-Win7 era hardware which is a thinner slice of the pie and one that could be remedied on an individual basis by integrating required drivers yourself. So again I can't see more good coming out of altering the Win7 boot.wims and install.wims for any Win7 based image I would make. On top of this, efi-based systems of newer (than Win7-era) hardware will have issues with the x86 boot.wim (which is a LivePE) as these systems require a x64 boot.wim to install from. So it is what it is, general solutions don't exist for all these contingencies.

The hybrid approach (Win8/10 boot.wim with Win7 install.wim) is viable but complicated if one would also want the boot.wim to be a LivePE. The other problem is, I have no use for such images nor do I have a way to test it due to the generation of hardware I have. Again, we're talking about getting Win7 to work on individual newer systems but wanting a universal solution. In that regard I can't make images "blind." So if anyone with a newer system wants to install Win7, I'd recommend using the Windows 7 Image Updater or the MDL 7 tool as these are at least based on some feedback.

I'm actually kind of relieved to disentangle myself from these efforts (after entangling myself in them) as it would have meant a lot of time spent on very contingent outcome. So for newer systems, a hybrid approach could be something that could work depending on the system, and it could probably be made into a LastOS type automated install (sans LivePE, which I've done before but never uploaded). So that is possible but would just require people to build and test themselves. I'll make periodic Win7 images in the traditional way for Win7-era hardware. This is my closure post