All good, integrated with WinRE build, just waiting on the 12th (patch Tuesday is a day later in Aus ) I still need to make a few changes (wallpapers etc) I have removed the Slideshow from my tweaks as I like a static wallpaper.
Small correction: In the ppApp.app file, change Target=PartitionManager\PartMan.exe to Target=PartMan.exe for the Partition Manager shortcut
So Glenn, funny point: An old friend from SitP and probably AppzPoint even (Rose) emailed me that she couldn't restore a backup image she made with Active@ Boot Disk using an old A@ Boot Disk. So then she tried new ones from Boot Rack on here and it wouldn't work. She has an older PC but the CPU is 64-bit. It would halfway load with blue boxes here and there and then quit. Somehow the newer PEs aren't loading for her even though she has a 64-bit CPU. She also tried making an iso with the A@ iso builder but it also wouldn't load properly, same issue. I think the issue with her backup image not loading was using a much later version of A@ Disk Image (9.1.4) live in Windows, but using a very old version in the old PE. Anyway, having exhausted all options, I suggested I could upload just the Win7 x86 PE I am using for the final Last7 images, so she could burn it to disk. In the test in VM I did, I noticed it was complaining about lack of install.wim (due to ppApp gen script I think) -- but instead of changing everything I just went ahead and saved an empty text file as "install.wim" and that worked. So in case anyone's interested in an older Win7 x86 PE with updated tools, get it here. This will be the PE included with the final Last7 images. I'll make some with newer PEs in the future but this should work nicely for a certain era of hardware. EDIT: LOL, I forgot to mention it all worked perfectly for her now, she was able to restore from the backup image and the PE loaded well from CD.
Funny how it all came together like that - We know our stuff, not only knowing that x86 PE's are handy in some cases (no UEFI Enabled BIOS), but that using a later PE base wouldn't work on older CPU's/motherboards. I still want to make up a Boot DVD with Hirens, Parted Magic 2019.12.24, WinXP PE and some other Linux based tools, they come in very handy when HDD's start to fail as Win 7 + OS's detect hardware differently than XP. so will lock up the whole OS if a HDD is ticking/slow booting.
Hey Glenn, I made a x64 version of the ppAppsLive (actually has 32- and 64-bit apps), I'd like you to test it if possible. I included a Open-Shell ppAppLive but tried on the x86 PE but it won't load start menu folder icons for some reason. But then you may not want to use a start menu shell for the PE or have a scripted version -- but just a heads up that that one might be problematic. If you could try the AOMEI and MiniTool partition softs, I also updated TeraByte and made it x64, RegWorkshop etc. I'll post links here later.
Yep, I'll test them out, I did have a x64 version of Terabyte and I also include Image viewer now too, I was only using the x86 and only the imager before to save space. I'd rather more functionality now myself. I noticed in chat you said how different icons/resources and fonts slow down your PC workflow - I noticed the same things, I found if I apply even a different set of desktop icons it takes me time to register what Icon I want to click on, so I wont be modding resources in my next OS release, I may still make a themer or just add them in to ssWPI, but I don't install my OS's to look pretty, I install them to use and then browse pretty things on the internet instead I don't even bother modding the OEM info etc now as it doesn't really need my logo's and info spread all over it, I'd prefer people just have a clean OS that is fast, well tweaked, up to date and packed full of features and runtimes etc. So I am glad we're still on the same page with our modding, makes the end results easier to achieve. The only thing I can't agree with is the slideshow wallpaper - then again I never liked the animated/movie ones from Vista either - very distracting IMO.
The slideshow either in Win7 or 10 mods by me is fast to change, whereas the other is slow to change. I prefer the slow to change, I maybe should look into changing the fast changing ones. These are set in the .theme files, by the way. Each visual style (and accompanying .theme file) is set to use the Windows wallpaper folder, to which I write the wallpapers via ISOOverlay function. So each theme/vs picks up the walls from there, the VS folder don't have separate walls in them. I did this because I liked the same walls in some VS/themes, so as to not have to duplicate them and add to size of the iso, I centralized them. So you could just disable the wall rotate in the VS/.theme file you want as the main theme, or change them all. I noticed a few small errors in the ppAppsLive (shortcut related) so I'll up them in a bit.
Including so many ppApps into the LivePE slows down the booting by about 60 seconds on the VM, would be faster on USB3 Real Hardware or from DVD, but I am happier having more embedded apps and use a little more ram (especially for the apps I want access too from an installed LivePE (copied to HDD) that wouldn't be if no USB/DVD inserted. Aomei Partition Assistant x64 works fine. Partition Wizard 9.1 x64 works fine. Free Commander has been updated since the version you used, may be intentional. Open Shell works for me using the middle mouse button as StartIsBack is enabled for left click instead, may need to change it during the building of the LivePE/WinRE instead. QDir shows license Agreement All other apps work as expected
Thanks for testing Yes, I may not include all these in any future build, but I thought I'd convert to x64 what I had. Good to know the partition managers work and all. Q-Dir, it doesn't make sense as the config file included is supposed to take care of that -- but I had the same thing in the x86 PE with x86 version, go figure.
The old .ini version of the ppAppsLive seemed to load quicker for me. Or maybe I'm imagining that. But since switching to the ppApp.app format the app gen in the PE takes much longer it seems. Is there a way to speed it up? Is SetupS putting a deliberate delay in? Also, should I run ssWPI before making the iso, so the .ini files with app list get created (I think they get creatde in ppAppsLive folder too?) -- or does ssWPI only use these, and not SetupS for a (re)gen? Questions, in the night... EDIT: In the PE it's set to show the progress balloons above system tray, alternating between "LastOS" sorting balloon to the ppAppsLive app name balloon, back and forth. Maybe if that can be turned off it would gen faster? It should go fast, it's only about creating shortcuts and regs.
Yeah the SetupS settings in the LivePE's is in O:\Win10\Win10XPE\Custom\x64\AdditionalFiles\Windows\ssTek\ssConfig.ini Change to Mute=True TrayOnly=False SetupS is slower than the older ppAppsGen I made, but it's more complete and works with many more apps. You should run ssWPI and pick (Re)Scan for items, this will make the latest DB's without you having to delete them manually first. Do this just before making your ISO, it is the last step.
It might be installing them. A "ppAppsLive" folder can double as a "ppAppsInstall" one. Check to see if it's creating a "ppApps" folder with those apps on the C: drive (or wherever).
No ppAppsLive should be ignored by SetupS, I use them in X:\Program Files\ppAppsLive and they do not get installed either, I would have complained long ago about it if they did - I just built a LIvePE with the above changes, I'l see how it goes.
Sorry about the Audio, recording Video and only having the one core set for VM really slows it down too. Also a magnetic HDD for ISO, PENetwork trying to run at same time, perfect storm to show delays.
There's only a handful of folders that are regen-only and %ProgramFiles% is one of them. The %ppApps% folder is another one. What I was thinking was the potential that CopyFromLive got triggered if the ppAppLive app was located anywhere BUT %ppApps%. I hadn't thought of burying them in %ProgramFiles%; and wouldn't have believed that actually worked. That's pretty clever.
I agree the "LastOS" sorting can be excessively slow. Even on a brand new install. Sometimes incompletely as well. I'm surprised all yours regen'd properly. Getting the Startmenu sorting to work correctly has been one of my biggest hurtles with my own Last8.1-mod. What's even more puzzling is that ssWPI's AutoMenu has a much better track-record at the sorting than ssControlPanel itself does. Weird.
"hurtles" - that seems wrong, but in a way - right. My LivePE uses this as the integration, O:\Win10\Win10XPE\Custom\x64\AdditionalFiles\Program Files\ssTek\RunDelay.au3 :- (I have used the same method since Windows 7, maybe even Vista) RunWait (@ProgramFilesDir & "\SetupS.SendTo\SetupS.exe " & Chr($Test + $Tem) & ":\ppAppsLive" & " -Regen", @ProgramFilesDir & "\SetupS.SendTo") RunWait (@ProgramFilesDir & "\SetupS.SendTo\SetupS.exe " & @ProgramFilesDir & "\ppAppsLive" & " -Regen", @ProgramFilesDir & "\SetupS.SendTo")
So in my Win7 x86 PE, I have 2 instances of ssConfig.ini: one in \Windows root, one in Program Files\SetupS.SendTo. I changed both to: Mute=True TrayOnly=False And perform a regen with "SetupS Generator" (little inno exe you made at the time I think) and it still shows progress in the tray. So I don't know why changing those two instances of ssConfig.ini could have no effect. I did edit the ini's in the PE, I didn't build a new PE. But in previous tests I couldn't get it to change its behavior either. Weird. But yours takes a very long time to gen, mine is much faster even taking in to account you're using a HDD. EDIT: So I can't change the behavior of the tray balloons, but I did notice that when I take the Icon.7z file out of the LastOS start menu folder (Program Files\SetupS.SendTo\Menus\LastOSMenu) and did side-by-side test of how long the regens took, it added about 1/3 the time to the regen. Yes, without the .7z archive the start menu will produce no icons. So regular regen takes 45 seconds for me, without Icons.7z it takes 30 seconds. This is regen, not sure if that would be more time when first gen occurs after loading PE. But that is significant, being 1/3 the time. It feels like it's having to access the .7z *each time* it requires an icon. If we could write the icons (loose) to the Windows\ssTek folder, and have SetupS check whether the icons are present there rather than getting them out of the .7z file, maybe that would help?
X:\ Windows \ ssTek \ ssConfig.ini <- I edited this one (in the \ssTek\ folder) and the Tray was not shown (as seen in the video) True, SetupS should keep the icons extracted for the whole time it's active and only clean them up once at the end... that would speed things up if it is in fact extracting the 7z every time like we suspect.
I also suggested to Freezer to house the icons in a .dll file (like Windows does) but I'm not sure that would speed up the process (I think it should). I edited the ssConfig.ini file in the \ssTek folder to not show tray balloons and timed it, but it's the same so the tray notifications do not slow the regen down. Also, I'm gathering we have 3 instances of ssConfig.ini now and only the one in the ssTek folder gets utilized? Because it does nothing to add it to \Windows for me, or even edit the one in the SetupS Program Files folder. Perhaps the icons can be loose in the Progam Files Setups folder, as well as have a .7z file for backup, maybe that will make it go faster. Since the app files are just being read and shortcuts created (no copying of files except importing a few reg entries) it should really go faster, like much faster. I wonder what could hold it up. It must be doing things not needed for ppAppsLive shortcut generation. Another thing I tried was copying all the icons into the ssTek folder (via WinBuilder for building the PE, so they are actually inside the boot.wim already) but still SetupS will give preference to the Icons.7z file -- and when I remove the Icons.7z file, SetupS doesn't use the ones in the ssTek folder. The reason I put the icons loose in the ssTek\Icons folder is to fix some of the blank icons I end up with for start menu folders in the PE, which was due to the scripted apps making these folders, too, and this works. But as I said, having the icons there doesn't make a difference because when I delete Icons.7z; SetupS doesn't use the ssTek\Icons folder icons at all and I end up with a start menu with iconless folders. What?! So it's kind of confusing the way this works. Shouldn't SetupS give preference to the icons in the ssTek folder when present and only load the Icons.7z archive when absent? EDIT: By the way, honest question: Who uses the Kazz menu?
Of cause, it is. Let me see if I can shed some light on the issues. Yes, that's correct -- only the one in the "Windows\ssTek" folder gets utilized. The one in "Program Files\SetupS.SendTo" (or "ssWPI\Tools") is only in case the one in "Windows\ssTek" is missing (or deleted). The one in "\Windows" root, go ahead and delete. SetupS doesn't use that one anymore. FYI, you can also over-ride these options by using the CLI switches instead. For example, "-mute" could be used to silence everything including the system tray icon, balloon tips, and the splash-text. Yes, absolutely, that's the way it should work. The icons are already "loose" inside "Windows\ssTek\Icons"; and are in fact kept that way. Like the ssConfig.ini file, Icons.7z (and Definitions.ini) in the "Tools\Menu" subfolder are there in case the ones in "Windows\ssTek" don't exist. The LastOS Startmenu structure -- "Windows\ssTek\Icons" & "Windows\ssTek\Menu". It should only be constructed once... the first time an app gets installed or regen'd. (Or if SetupS is installed prior). It's why I was never concerned if the icons are stored loose or as an archive or .dll etc. -- even as a self-extracting archive is still supported. Since they'd only be extracted (or copied) that one time initially, might as well save space and use an archive. But you observed the system tray balloons "alternating between "LastOS" sorting balloon to the ppAppsLive app name balloon, back and forth". The first app, yes that's expected. But I'm pretty sure it should not be doing that for all the apps. I can't tell from Glenn's video if that is also the case. So it sounds to me like the question is really with "Windows\ssTek". Is SetupS not "seeing" it or what? Unfortunately, PE environments are very foreign to me.
So, the icons being present in the ssTek folder, it still utilizes the Icons.7z because when I remove the latter, the regen speeds up by 1/3. The back and forth action of the tray balloon notifications are occurring with each app install. However, the regen is actuated by an inno exe. When I open the script for one of them (not sure if that's representative of the exact .exe I have in there, but should be close) the code is: Code: #Region ;**** Directives created by AutoIt3Wrapper_GUI **** #AutoIt3Wrapper_icon=Icon.ico #AutoIt3Wrapper_UseX64=n #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI **** ; This program is free software: you can redistribute it and/or modify ; it under the terms of the GNU General Public License as published by ; the Free Software Foundation, either version 3 of the License, or ; (at your option) any later version. ; This program is distributed in the hope that it will be useful, ; but WITHOUT ANY WARRANTY; without even the implied warranty of ; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ; GNU General Public License for more details. ; You should have received a copy of the GNU General Public License ; along with this program. If not, see <http:;www.gnu.org/licenses/>. ; Modified by Ghost 4-21-2012 ; Copyright (c)2012 ssTEKies ; http:;www.ssTEK.com #include <String.au3> #include <GUIConstantsEx.au3> #include <StaticConstants.au3> #include <WindowsConstants.au3> #Region ### START Koda GUI section ### Form=C:\Users\Administrator\Desktop\Main.kxf #EndRegion ### END Koda GUI section ### Dim $Width Dim $Y $Width = 340 $Y = 280 ; wait for things to get done before continuing on ... If StringInStr($CmdLineRaw, "-wait", 0) >0 Then ProcessWait ("PENetwork.exe", 10) While ProcessExists ("PENetwork.exe" ) Wend ProcessWait ("explorer.exe", 120) EndIf ; fix the white out ( dead ) shortcuts/icon's issue in PE if usin a DVD For $i = 1 To 10 Local $var = RegEnumKey("HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\CD Burning\Drives", $i) If @error <> 0 Then ;MsgBox(4096, "error is: ", @error) ; if error Else ;MsgBox(4096, "Key is: ", $var) ; the key found RegWrite("HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\CD Burning\Drives\" & $var & "\Current Media", "Live FS", "REG_DWORD", "1") EndIf ExitLoop Next ; run the HDAudio detection tool, so this runs until the drivers are loaded ( the .exe in program files\realtek\audio\hda\RtHDVCpl.exe in PE :) Run (@WindowsDir & "\system32\RunHDAudio.exe",@WindowsDir) ;GUISetState(@SW_SHOW) ; just a simple box to let the user know its doin sumtin usefull, SetupS is the horse, that code is further down ;) .. SplashTextOn("Generate Shorcuts", " SetupS - Generating shortcuts, Please wait ....", $Width, 42, -1, $Y, 52, "Arial", 10) ;Run (@WindowsDir & "\system32\ppAppsGenPE.exe",@WindowsDir) _CreateFileAssociation("apz", "apz" & "SetupS", "SetupS.SendTo", @ProgramFilesDir & "\SetupS.SendTo\SetupS.exe") _CreateFileAssociation("app", "app" & "SetupS", "SetupS.SendTo", @ProgramFilesDir & "\SetupS.SendTo\SetupS.exe") ; create a shortcut on the start menu so if user neds to -Regen they can FileCreateShortcut(@WindowsDir & "\System32\RunDelay.exe",@ProgramsDir & "\SetupS Generator.lnk",@WindowsDir & "\System32","", "Run this to initalize ppAppsLive shorcuts again", "", "", "", @SW_SHOWNORMAL) ; run the ssWPIMon.exe, so when install starts it can copy over the .ini files to the new C:\ drive Run (@WindowsDir & "\system32\ssWPIMon.exe",@WindowsDir) ; variables to make the functions work, set 1 to true, and 1 to false, but its not used, so I left it as is .. update it more later Global $CountDown = 9 Global $ScanppAppsLive = True Global $ScanppApps = False $file = FileOpen("X:\Windows\ppAppDrive.ini", 2) ; Check if file opened for writing OK If $file = -1 Then Else FileWrite($file, "X:") FileClose($file) EndIf $Test = Asc("A") ; here is SetupS call to generate shortcuts and all that stuff ... For $Tem = 2 To 25 ;SetErrorMode(SEM_FAILCRITICALERRORS); DllCall("kernel32.dll", "dword", "SetErrorMode", "dword", 1) ; SEM_FAILCRITICALERRORS RegWrite ( "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows" ,"ErrorMode", "REG_DWORD", "2" ) If $ScanppAppsLive = True And FileExists(Chr($Test + $Tem) & ":\ppAppsLive") Then ;Turn Error Protection Back on DllCall("kernel32.dll", "dword", "SetErrorMode", "dword", 0) ; SEM_FAILCRITICALERRORS RegWrite ( "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows" ,"ErrorMode", "REG_DWORD", "0" ) RunWait (@ProgramFilesDir & "\SetupS.SendTo\SetupS.exe " & Chr($Test + $Tem) & ":\ppAppsLive" & " -Regen", @ProgramFilesDir & "\SetupS.SendTo") EndIf ;Turn Error Protection Back on DllCall("kernel32.dll", "dword", "SetErrorMode", "dword", 0) ; SEM_FAILCRITICALERRORS RegWrite ( "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows" ,"ErrorMode", "REG_DWORD", "0" ) Next ; another box to let user know SetupS shortcut gen is done ( yea hope the timming is right ), yep seems to be :) SplashTextOn("Generate Shorcuts", " SetupS - Shortcut Generation done!", $Width, 42, -1, $Y, 52, "Arial", 10) Sleep (4000) ; 4 seconds and it closes SplashOff () ; box disappears .. desktop ready to use .. Exit ; create file association for SetupS in PE, so things are a little smoother for the SetupS users in PE .. Func _CreateFileAssociation($Extension, $ClassName, $Description, $ExeProgram) Local $S, $E2, $S2 If StringLeft($Extension, 1) <> "." Then $Extension = "." & $Extension $S = RegRead("HKEY_CLASSES_ROOT", $Extension) If $S <> "" Then ;we have an association already If StringLen($S) > 6 Then ;min length If StringRight($S, 6) = "SetupS" Then Return 50 ;done already, quit (assume backup is OK too) EndIf EndIf ;Backup OLD value, its possible for another app to steal association ;in which case we just restore our association without doing a backup of the stolem ass. $E2 = "SetupS.Bak" $S2 = RegRead("HKEY_CLASSES_ROOT\" & $Extension, $E2) ;check its not already backed up If $S2 = "" Or $S2 = "Error; Bad Value Type" Then ;we haven't already have backed up this key in the past RegWrite("HCEY_CLASSES_ROOT\" & $Extension, $E2, "REG_SZ", $S) ;old value backed up EndIf EndIf ;procede if not already a SetupS association RegWrite("HKEY_CLASSES_ROOT\" & $Extension, "", "REG_SZ", $ClassName) ; create a value for this key that contains the classname RegWrite("HKEY_CLASSES_ROOT\" & $ClassName & "\Shell\Open\Command", "", "REG_SZ", $ExeProgram & " " & Chr(34) & "%1" & Chr(34)) ; set its value to the command line RegWrite("HKEY_CLASSES_ROOT\" & $ClassName & "\defaulticon", "", "REG_SZ", $ExeProgram & ",0") DllCall("shell32.dll", "int", "SHChangeNotify", "long", 0x8000000, "long", 0, "long", 0, "long", 0) EndFunc ;==>_CreateFileAssociation ;SetupS x:\ppAppsLive -Regen So is there anything in there that calls SetupS in the wrong manner?
Yes, that's the same conclusion I had. The Icons.7z is being reused for all the apps instead of just the first one. Somehow the "\Windows\ssTek" folder is being completely ignored. Does it even exist? Clearly, this was not the intended behavior-- for what are now obvious (observable) reasons. Could be. I'm unfamiliar with that particular code... from Ghost it looks like -- and from 2012 no less. Probably obsolete by now though. Regardless, I've never seen it before and if that's the culprit, maybe...? Is it calling an older version of SetupS? EDIT: It appears current. "ssTEKies" ... LMAO
