Just putting together the MRP 146 archive , filing in the change log that has got quite a bit larger than the original bug fix one Will be released within the next hour.
After a long wait... MRP v146.0 has been uploaded, 2nd post's download link, password and hashes have been uploaded. Spoiler: MRP v146 Summary This was to be just a simple bug fix release but as time went on other items in the todo list was added in as mentioned below. Please note that on Windows 11 22000 and later the title bar colors may not get set correctly and may require a 2nd reboot. Most times the active color is set but the non-active color is not. Also some theme elements on Win 11 may not work as expected due to changes in later cumulative updates. + Using the 'The Slim win 11 Start Menu' option will now show just two Apps 'Settings' and 'File Explorer'. Both are useful items and other code been added to prevent m$ adding more after a few reboots. The user can add their own Apps/Programs links if required later as the change in code does not affect that side. + Updated the Dark Theme parts to hopefully set the colors correctly for latest insider builds etc. + Added new General option: AHCI power management - This only enables the hidden item within the Power Options section and is set to the OS's default, it is then up to the user to adjust as required. This could cause serious issues and non booting OS, so please make sure you have a working backup, if you want to use the 'feature'. + Added Win10/11 option: 'Create Restore Point' - This when used will add a desktop context menu item of same name, which should be OS translated, it is a on-demand item that when used will manually create a system restore point so that you can use it to restore the system if/when something goes wrong. This uses PowerShell and you will see a couple of windows appear before the progress one appears. + Added new win 11 {2262x+} option: 'Desktop Stickies', this is a currently hidden OS feature that may not be added by M$ when the latest OS is released. You will need to be connected to the internet as it appears to connect and download parts for it to work, or you will just see a blank window with a X to close. + Various code changes to log entries and functions, tidied some code sections as well.
Hiiii, its me again, first of all so so sorry that i wasn't active for some time. I started working again on this project and i even optimized the pictures more and reduced the size by really huge amount you guys can see for your self. I believe we can reduce the project size to1/3 of its current size without compromising the quality. i am attaching the samples for the ZT and i will optimze all of the oems so we can make this project 1/3 of its current size and compressed size i am talking about. When uncompressed its already much compact like literally. Compressed File Size Difference Uncompressed Size Difference
Majority of the MRP archive size is the oem branding parts, i try to keep the script coding to a minimum but as i am not that good with graphics i tend to leave the images alone if i can and just make sure they keep within 250kb for wallpaper size and a max resolution of 1920x1200 most are 1920x1080 where possible as any larger can cause some issues on some brands such as HP that seem to not like a default wallpaper greater than 1920x1200 I mentioned 250kb and not 256kb as that is the size on disk and not the image, generally a 256kb image equals to about 280/300kb when on disk and can cause win 7 to ignore the image, found that out when a few people mentioned certain brands not show wallpaper/background images after installation.
Could it be possible that MRP modifies the uxtheme.dll file? I got a bit nostalgic and wanted to try out the XP Luna theme on my Windows 7 installation. I created an updated ISO with the MDL SiMPLiX Tool and also used MRP for its amazing customization options. As recommended by the readme file I deleted the OEMs zip as I was not interested in the OEM themes. My Scripts folder only includes DeCompile.exe, MRPConfig.ini (love the customization options!), OOBE.cmd and WinTel.cmd. It has worked wonderfuly and I never had any problems with my setup untill I decided to try out the custom XP Theme. From what I've seen the recommeded way to install unsigned themes is to either use UX Style or Universal Theme Patcher. The first one (UX Style) shows me a warning that the .dlls have been tampered with and the recommended solution is to run sfc /scannow which in my case finishes with no errors. I decided to try out the second tool (Universal Theme Patcher) and thats where I realised something is a bit off. Looking at the readme file it says that unmodified .dlls files hash should end wtih 1 and modified ones with a 9. Upon running Universal Theme Patcher it shows the current .dll files and their state and indeed the hash for uxtheme.dll ends with 9 which is why I believe the UX Style tool didn't like it and refused to run. I was able to get the Luna theme running with the second program but I wonder what could've caused the uxstyle.dll to be marked as modified. The problem also persists on my other machine running Windows 7 installed from the same ISO. I believe I might have misunderstood the instructions for MRP and not used it properly without the OEM stuff and that might be the cause for this problem. I made my ISO a few months ago (in April) if that matters.
MRP has been designed so that if the OEM's.7z file is missing then it will just run all the other parts such as SLIC activation etc , plus any options, (if used). As for the modification of the uxtheme files, i had tried a few times to see if i could integrate the changed theme .dll files but i always ended up with either a BSOD or a endless boot loop, therefore i gave up on that idea as it is a very sensitive area in the OS not sure why m$ blocked/made it so awkward for the use of 3rd party stuff for the eye candy. I may try other methods but the use of SFC would always restore the original 'clean' files.
This is exactly why I wanted to get the UX Style tool working as it doesn't modify the .dll files but instead registers a 'magic' service that allows you to apply unsigned themes. A small correction from my previous post - the marked as modified file is themeui.dll. I did a clean install in a VM but still got the same issue. Tried without MRP (deleting the $OEM$ folder from the ISO) but the problem still persits. I thought I might have misconfigured MRP but the issue is clearly somewhere else.
You are using mrp ok , it just the project creates the theme 'on the fly' using the standard oem specification m$ set up for oem makers to use for the brand theme. Will see what i can do about somehow integrating a ux replacement , if i manage to get it to work without problems then i will add it as a option so the user can decide to be untouched standard or allow the 3rd party themes. Cant promise anything for a while as it a time consuming addon and time is my nemesis at present.
This month I have resumed work on the Win7 disks (see #8312 and following). I have found a workaround I'm satisfied with. So, the normal way, WinTel.cmd is never processed in Windows 7, and I don't know why. All windows are dismissed before the desktop shows (if I'm lucky I can see the cleanup messages, though). The only thing that works for me in Windows 7 is calling WinTel.cmd from OOBE.cmd, and I believe it was called that way, long ago. The file is processed and "route print" does show the proper routes set. So, if you are creating 7 media, and WinTel.cmd is not processed, call it from OOBE.cmd. That wraps it up, nicely. Consider that case closed.
One important thing to note with Wintel.cmd same with UserTweaks.cmd or other scripts is when they are called via OOBE.cmd is that any registry entries for HKCU will NOT be processed because at that early stage of the setup process, which is in operation at that time, the user name and therefore the user hive section of the registry does not exist. Any reg entries for HKCR, HKLM will be processed as those hives exist. If Wintel and UserTweaks scripts are not being called, if present with the standard MRP use, then there may be a script that cleans or deletes the Scripts folder before MRP has time to call WinTel and/or UserTweak scripts, such as SetUpCompete.cmd or FirstLogon.cmd - loader entries with RD 'Scripts' is one such item because Setupcomplete is called at same time as the addon manager part of MRP. This can be confirmed in the project log as the last parts will be missing entries because the MRP files will be deleted before completion. @Carlos Detweiller you are correct in that Wintel used to be called via oobe.cmd but i changed it to allow for HKCU entries as some users mentioned that some personal tweaks did not work, which turned out to be some HKCU entries they added.
If you go back to the posts, I did post logs, and the logs indicated that WinTel.cmd had been successfully processed, yet, somehow, it wasn't. "route print" always came up empty after Setup completed. No idea how to diagnose that. As I have it now, at least the routes are in place. Partially processed is better than not at all? Just for testing, I inserted a faux WinTel.cmd that only sets two test registry entries. If these are indeed set, I will split the whole shebang and call only the routes part from OOBE.cmd, the rest will process normally. All in all, routes in WinTel.cmd will need a major overhaul anyway, as there are only IPv4 routes set. MS now uses IPv6 servers extensively, however.
Nope, not even the two-line test WinTel.cmd works. I would like to try moving WinTel.cmd processing to the Cleanup phase, as I have seen that one running. But it would possibly require modifying MRP code to insert the hook. Off to bed.