Freezer, did you see the updated Open-Shell in repo? Not sure if you wanted to base it off those msi's
LOL, I hadn't seen the updates on that. I probably wasn't even looking for any. But then you know me... I rarely update an app unless I need to. I was staying focused on the Aero Glass one and Open-Shell was working well with no problems. So I imagine my Open-Shell apz is pretty outdated and behind. I'll update here shortly.
Yep, the Open-Shell you linked to isn't even in the Repo anymore. (It's in the archive if you need it) If you'e added themes to the Aero Glass one, be sure to verify that the Repo copy is the same as your local one. The Repo one is dated 10/25. Update the version number if appropriate.
The version of BigMuscle's AeroGlass (v1.4.6) that I'm using is for Win8.1 build 6.3.9600 (Final, I believe) -- also for Win10 up to build 10.0.10586. Later versions only work with later editions of Win10. So there's been no need to update that since I'm only focused on Win8.1. It does use Within Network's UxStyle bundle v.0.2.3.0 -- Sept. 23, 2013! That too only works for Win8 or Win8.1. I'm not even sure if there are any updates. The website is defunct (up for sale). So it appears that is the final version. I haven't checked yet, but I think the Open-Shell updates are probably the same way -- just trying to keep up with the Windows 10 retcons and don't much affect Win8.1 builds. I'd built into the SetupS file spec (and ssEditor) to allow for a Releaser-tag to be appended to the filename. So what I think I'll do -- since they are merely my adjustments or fixes to an unchanging version of the apps -- is to simply add my release version to the filename too. I've got ppGames with the same issue. Especially those "required runtimes" such as DOSBox or ScummVM, etc. I'll update or change their ppGame stuff -- cmd/reg files mainly -- but keep the current version of the "runtime". If it wasn't for their Time/Date stamp, I wouldn't know which version I was on.
Hmm... apparently if one would hypothetically update Win8.1 x64 in a sysprep VM, one would get Windows build number 6.3.9600.19478... Hmm
Some progress notes: - Updated Last8.1 x64 - Added additional telemetry related reg entries and block script (Blackbird, Abbodi).This is new, I recently tested it on a new 7 image also, which BP will try live. Should shield the OS further from MS telemetry and Win10 upgrade related junk. - Reworked Freezer's Aero.Glass.for.Windows.8.1+_v1.4.6_Win8_x64_ssApp (wallpaper collection edited/streamlined, matches Last8 walls now also; added a "Last7 World" theme that rotates those walls and is set as default theme; minor tweaks) - Reworked Freezer's Open-Shell_v4.4.142_ssApp a bit: some start menu changes (opening in Programs rather than highlight list, reorganized items a bit, minor tweaks). These 2 ssApps are included in the .iso. So Freezer can see if he likes or hates the changes - CPU idle tweak (mentioned in this thread) is probably best for Freezer to apply individually as it would be system specific. - Shadow rounding (mentioned in this thread) is set via Aero.Glass ssApp (if installed); I did not make it part of default Last8 tweaks in case one uses square themes only, in which case it will look funny. - Added time & date tweaks (mentioned in thread) - Went over all Glenn's additions for the 8 Tweaks ssApp, which as it turns out were either already in my previous Last8 image reg tweaks or else were Win10-only. The context menu path corrections are indeed needed when running the tweaks as a ssApp -- when running same tweaks in the Last8 image, entries differ slightly so thanks for figuring that out Glenn as I don't remember if I ever made a Last8 tweak ssApp and adjusted for the context menu entries. - So quite a few changes, and I think it covers most if not all we talked about in this thread.
Responded to PMs, once you decide if the menu icon is worth changing or not, it should be good to go, if you update the Last8 Tweaks ssApp I'll build on that one in the future instead of us running 3 different tweaks, I may even combine ALL the Last Tweaks into one and apply it depending on the OS it is ran on, all the tweaks that work on all OS will be separated from the Individual OS tweaks.
I'm not sure I understand. That reg only exposes the CPU option to disable/enable idle. It doesn't actually change the option. Without it one would not be able to stop their CPU from running full throttle all the time. Or to disable idle if they wanted.
Thanks. The theme for Last7 was mostly fiction. I meant to copy it directly from a copy of Last7 like I did with Last8's theme. I saw that Last8 theme simply used the Default theme but with new wallpapers. So I did the same thing to Last7... basically copy wallpapers I'd found somewhere; but not sure where. As I said, I meant to take a look at a Last7 copy. I also waffled on the idea to make the extra themes a separate ssApp and have the AeroGlass theme be the only one included in the AeroGlass ssApp. Maybe two separate theme packs. One for Windows 7 themes and the other for Windows 8. Like you said, unless you remember to change the Glass geometry radius to "Win8 style" (or back to "Win7 style") then the corners will look odd when you switch back and forth between a Win7 theme and a Win8 one. And, I haven't yet figured out a way to change that setting via the .theme-file. Have only been able to change it with a reg-file, which could just be an ssApp.reg file.
Drat, I must have misunderstood then. I did not add this reg tweak, although it would be easy to add. Just open the .iso and add it into \Last8.1-Ent-x64-2019.10.30\sources\$RegTweaks\Last8-regs.reg or do it post-install. I will add it locally though, for future iterations
For Open-Shell I should have tested it before I uploaded it. Time got a way from me and I never went back to test it. So I hope it worked well anyway. This one also favors a Window 7 look. So if you are using a Win8 theme, you'll have a taskbar and startbutton that look like Windows 7 rather than Windows 8.1
I see what you did then. The reason I kept the wallpapers in (although I edited them in my mod of your ssApp) was in case someone would install the ssApp on a vanilla Win8. But on the new Last8 image the same walls are included so it's a double-up (but won't change anything) and the walls will get overwritten. This is fine since Windows loads any currently applied wallpaper from a copy/different location, so it won't "lock" a current wallpaper from being overwritten -- except if it is the default img0.jpg which is protected by Windows but some Last releases even have a trick for that. But yes, the edited (default) theme file is basically just a text or ini file of sorts but even just a small edit to it like changing wallpaper paths, if you run a SFC /Scannow will get replaced as Windows will check the hashes. I never run scannow unless there is some huge issue, but if you do it will replace edited default Windows files, replace modded sound files, etc. -- although it won't delete 3d party themes or anything, just replaces default Win files that it determines are modified. So all I did to the .theme file is have it rotate the walls in the default Windows location, where I added the walls via the iso overlay of the Last8 image ($OEM$ folder: \sources\$OEM$\$$\Web\Wallpaper\Windows) and have it rotate these at intervals. Also I use NTLite to remove the default walls as I think these are also added in WinSxS so Windows can restore them if merely deleted in normal fashion (due to hard-linking).
Open-Shell seems to work well. As for Win7-looking skins in Win8, you're in good company because Microsoft still uses Win7 rounded corners in Win8 Setup and even the latest Win10 Setup -- not kidding. If you boot into the Win7 PE you will get square Win95 windows, but if you boot into Win10 PE you get Win7 theming with purple/blue Win8 background. It's just beautiful, isn't it? Microsoft also left a [DELETE THIS] folder in the LTSC boot.wim that is useless and when removed takes the boot.wim size down from 390mb to 327mb -- I am getting the feeling I am putting more work into their OS than they are! I removed it with NTLite.
Hehe, to be sure: I didn't mean about your Open-Shell theme, as you can set that per OS theme and of course would be proper if using Win7-like themes. But rather MS' boot/setup screens, which you can't change I wonder what would happen when installing the Aero.Glass ssApp over an already installed version -- would it just ignore the install/reinstall of it and move on, or would it cause problems... I'm thinking along the lines of making several, one for augmented Win8-type themes and including corresponding Win8-themed Open-Shell, and another that is Win7-oriented. If not problematic you could just install whichever ssApp you feel like when wanting to change to a 7 or 8 look and not have to uninstall an existing version, reboot, etc.
I've never notice any problems with it installing on existing. As long as it's the same version. Ditto with UxStyle. You can install it on top of itself all day long if you want. I've included the UxStyle installer in the AeroGlass ssApp and it too hasn't cause any issues there either. Which is why I waffled on making separate theme-packs. You can include UxStyle installer in the theme-pack and it'd be installed regardless. The Magic of SetupS.
Hey, I couldn't help but notice that you didn't include any of these to the end of the "Run_13_Post_Logon_Apps.cmd" or whatever: Code: rem ** Install ssApps ** FOR %%f IN (%~d0\ssAppsInstalls\*.apz) DO SetupS "%%f" rem ** Install Advanced Startmenu (LastOS sorted/organized) ** ssControlPanel -LastOS Both AeroGlass and Open-Shell are included in ssAppsInstalls. Just curious...
I wanted to keep options open for the general build, but I would like to try the start menu sorting again as I didn't have good and/or consistent results with that in the past. BTW are you talking about the new image? It didn't show you had visited that thread yet so I was wondering.
All those apps you have in ssAppsInstalls I would've installed anyway. Perhaps at the very least, Open-Shell followed by LastOS Startmenu sort? Something like this: Code: rem ** Install Open-Shell ** SetupS "%~d0\ssAppsInstalls\Open-Shell_v4.4.142_ssApp--Freezer-Trouba_2019.10" rem ** Install Advanced Startmenu (LastOS sorted/organized) ** ssControlPanel -LastOS Yes, but I grabbed it directly off the server.
I can't get this to work. Tried yours, tried various path edits, nada. The only thing that will run is the -LastOS start menu option, but it only reads "initializing" and then quits without making changes. This is on the Last10, not 8, but shouldn't make a difference. Perhaps you can test it on your end in VM. EDIT: did use open folder apps, not .apz wrappers. That might make a difference in how it's being called.
Sorry, I was going to warn you about that. The earlier script was scanning for .apz files. That last script just SetupS only the Open-Shell folder. Not sure why the startmenu sorting didn't take though. I'll play with it in a VM. But it won't be until later.
OK, sounds good. Do note that running msi's (Open-Shell) right after install often causes problems (delays, installs taking forever, etc.). I manually installed Open-Shell before reboot, as well as Java (msi based) and they took forever. Oddly, installing 7-zip with its tiny msi installers took the longest of them all. It's a known thing with msi's so this may put a damper on them being used right after install. Once you reboot once the msi's install quick. I remember talking with Glenn about this, too, he will be able to vouch for it. I did have a Classic Shell silent installer I used to include in PostLogon folder but it would be made with SetupS SFX but would install before SetupS itself and this worked well for a while but was a long time ago and surely on Win7.
Any delays with MSI installs is caused by the System Restore Backups and/or MS Updates consolidating all the versions of each .dll .exe prior to actually checking for updates, they can also be caused by Dot.NET building it's Cache (this can take up to 20 minutes on a magnetic HDD, also defragging and prefetch building. This is only some of the weird stuff that goes on until first reboot, I think MS calls a Process Idle at the very end of installation. A reboot calls off the idle tasks and your able to get on with the installation.
Okay, I think I have a handle on the problem. All the scripts being run in $Scripts is occurring during that first logon stage that Glenn mentions above. And I wasn't really paying attention to this in the "Run_13_PostLogon_Apps.cmd": Code: rem ** Make Post Logon Apps occur ** REG ADD HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce /V PostApps /D "%~d0\sources\$PostLogonApps\PostLogon_Apps.exe" /f Despite the name of this script, it doesn't actually install any of the apps in "$PostLogonApps". That occurs after the first reboot by another app called "PostLogon_Apps.exe" which does the actual installs of the exe's. But that won't happen until after the next reboot. And it only installs exe's. Which is probably why Trouba had to wrap apz's in exe's in order for them install. I guess the next question is if that first reboot occurs at all. Otherwise "PostLogon_Apps.exe" will never run unless the user manually reboots. Also I'm curious what calls on "$Script\FirstLogon.cmd" to begin with?
