Not me. I don't know anyone who uses it either. LastOS and default are the only two options I ever use. I don't know if it's worth leaving Kazz in case anyone wants an example of making another option besides LastOS or not, but that's the only reason I can think of to keep it. LOL I'm not very conversant in AutoIt, but if I read the above correctly, then that code is the same as this: Code: ; fix the white out ( dead ) shortcuts/icon's issue in PE if usin a DVD Local $var = RegEnumKey("HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\CD Burning\Drives", 1) If @error = 0 Then RegWrite("HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\CD Burning\Drives\" & $var & "\Current Media", "Live FS", "REG_DWORD", "1") EndIf Is that what is intended? To have $i only equal to 1 and ignore $i values of 2 - 10?
It may be too wild of a goose chase, Freezer, especially since I'm testing on Win7 x86 PE. If it produces similar or identical issues on the newer PEs, though, it may need some TLC. The only difference between ppApps regen and ppAppsLive regen should be that for the latter the app files remain on the boot drive and don't get installed, except for registry edits and shortcuts created. So it should happen pretty quickly. I did notice that I did not place all the start menu icons in the ssTek folder: I left out the Kazz icons. Should/can that matter? I can run a test including all icons in \ssTek\Icons. As far as the code goes, I was interested to see if SetupS was called correctly, and this line and perhaps one other even deals with that: Code: RunWait (@ProgramFilesDir & "\SetupS.SendTo\SetupS.exe " & Chr($Test + $Tem) & ":\ppAppsLive" & " -Regen", @ProgramFilesDir & "\SetupS.SendTo") EndIf I think the ppAppLive regen .exe I'm using is a later version that the one I gave the code for, but I can't find the .au3 file for it anymore so I'm assuming it's based on Ghost's code there. Anyway, if there is nothing obviously wrong with the way SetupS gets called by it then it must be slow for another reason. For this PE I can live with it, and I actually don't mind the tray balloons so that people will know it's still loading
No, it shouldn't make any difference. Kazz will be ignored regardless. (Menu-style is set to "LastOS") Since we've ruled out that being the problem, just leave them on then. I still wonder if Glenn's having the same problem... the constant reinstalling of the Startmenu. Are you both using the same PE? I can't tell.
"I actually don't mind the tray balloons so that people will know it's still loading" >>"Since we've ruled out that being the problem, just leave them on then."<< Given that it's loading slow, I don't mind having the tray notifications show If it wouldn't load slow, it would be better to not have the balloon notifications showing. I have concluded thus far that 1/3 of the regen time is the Icons.7z (at most, could be some time if icons were loose and picking up), other reasons escape me. But maybe the Icons loading slow is the only thing that can be improved. But for this PE, at least, I consider it a minor inconvenience. It is true the old. ini style (and older SetupS originally included with the PE/builder) did load faster.
I made ppAppsGen.exe, it was written for XP for Soporifc to use in his LivePE, it was never intended to work with SetupS it was only a regenerator, but as Freezer added more and more features, I wasn't willing to update it to support them, instead I switched to using SetupS and it works, just a tad slow, I'll attempt to speed things up in it soon, Freezer have you been working on a new build of SetupS at all that I should base new work on or is the final from late 2017 still good? I leave Kazz menu in place for the reason BP said, it lets you see how to make your own menu from scratch and it allows Freezer and I to test that feature actually works, else we'll start making code that doesn't allow changing menu systems, unknowingly. ppGen's were written in 2009 I also have some vb6 versions from long time ago.
Ok, I'll work on optimizing the ppAppsLive features in the version I have and forward you the code changes/additions.
I updated my LTSC 2019 install.wim 2020-02-12 and it's captured as a ESD at exactly 3GB, not sure if that can be improved upon, but I'll give it a run with the rest of the build and see if it all stuck, thanks Trouba for the base and the update/clean methods. Install size of new OS is, 9.1GB without swap or page files.
WOW Trouba found some old dirty code there LOL, bphlpt just quoted it. We where having issues in PE that the icons were just white-ish ( c0d3 ) and me and no function would happen, but after finding that the Disk burning thing was tied to the dvd in PE, well there is the end results, dirty fix. Apart from that, it fixed the issue of that time. I would assume that code isn't useful in win 10 PE.
It's from the old builder that made Win7 x86 PEs, Ghost However, the compiled .exe I have in the preset folder doesn't seem to match that script (but I don't have the .au3) so I must have been using your newer one. The blank icons in start menu (LastOS sorting) in my case were due to inclusion of scripted apps that would create the (same) start menu folders either before or after SetupS could, resulting in some of the main category start menu folders having no icons. It works, plus I don't intend to work on any Win7 x86 PEs anymore so I consider it finished
Current code changes for SetupS -Regen speed up: Code: line 1259 SetupS.au3 $CopyFromLive = True If $RegenOnly = True Then $CopyFromLive = False ;Glenn2020 Select ;The following keeps CopyFromLive TRUE if: Compiling on Windows 10 x64 made the error above, so I am installing LastXP v22 to compile SetupS properly... I just want to test if turning off $CopyFromLive is enough to stop it being slow during a -Regen call. SetupS Debug Logs, pre fixed code attached: -EDIT- Ok That compiles and works, got it down from 44 Seconds to 26 Seconds with the one line above. -EDIT 2- I am skipping a few more events if using -Regen as I never want it to move files around from ppApps/ppAppsLive during a regen as they should have icons made from the first install and patches applied etc... Code: Line 1259 SetupS.au3 $CopyFromLive = True If $RegenOnly = True Then $CopyFromLive = False ;Glenn2020 Select ;The following keeps CopyFromLive TRUE if: Line 387 SetupS.au3 If Not $ssInstall And Not $RegenOnly Then ssInstall() ; Includes any ppApp/ppGame 'installs' plus Aux files copied ;Glenn2020 ;------------------------- Post-processing ------------------------- If Not $ApplyPatch And Not $RegenOnly Then ApplyPatch() ; Patch archive/folder ;Glenn2020 If Not $ProcessShortcutS Then ProcessShortcutS() ; all shortcut/startmenu related tasks If Not $AppPathFolderIcon And Not $RegenOnly Then AppPathFolderIcon() ; Install-path (AppPath) Folder Icon ;Glenn2020 Line 456 SetupS.au3 If FileExists($TempDir & '\' & $scFolder) And Not $RegenOnly Then GetShortcutS($TempDir & '\' & $scFolder) ;Glenn2020 Line 465 SetupS.au3 If Not IsWriteProtected($App_InstallPath) And Not $RegenOnly Then ;Glenn2020 Line 440 SetupS.au3 ;---------- Fix Startup folder icon if missing or changed ------------- If $MenuStyle > 0 And Not $RegenOnly Then ;Glenn2020 Line 1893 SetupS.au3 If Not $RegenOnly Then RemoveSpecials($TempDir & '\' & $scFolder) ; (all) from specialized locations ;Glenn2020 Debug Console log has almost half the functions calls and is twice as fast now, the main speed increases was from the top edit tho, at least that needs to be included in Freezers update.
http://team.lastos.org/glenns/SetupS.Project_v20.02.13.0 Download here and I made a LivePE x64 package for easy testing (I still have to test that myself) will edit this post with results soon.
I found a way to get the folder icons to work in the LivePE's, I premake the Start Menu folders with desktop.ini files with the icon info in them, then I set the folders to "attrib /D +s" this makes the folders system folders and the desktop.ini is linked to %WinDir%\ssTek\Icons\LastOS_name.ico icons etc. worked perfect. You only need to do this for Users\Default\ menu items tho as the ProgramData\ (all users) icons show up fine, meaning any application you include extra will create the icons fine still. -EDIT- Man Microsoft have really broken the Lock Screen and Logon Screen Wallpapering features... it's beyond usable.
That's funny, I had to do a similar thing in my x86 Win7 PE; in my case I just created the start menu folders in the Users\Default folders with desktop.ini's and placed the icons in the \Windows\ssTek\Icons folder as you did but didn't set any attributes. This works too in my case but thanks for the pointers, I'll save this info.
I tried out your fixed SetupS version and made a x86 version for x86 PE and it works great. Much faster and the "LastOS Sorting" and "AppName" balloon notifications aren't alternating, just the appname balloons occur and much, much faster. Great! In fact it's so fast now that I have the PE Network initializing and app regen happening at the same time now, but it doesn't hurt anything. Kind of interesting you had to utilize Windows XP to get your latest Win10 image to work properly there
Well to tell the truth, I think I only needed to use XP because of the newer version of the tools (IcoFX, AutoIt, 7Zip) I had installed, still as XP is a supported OS for SetupS, I'd rather build it where it will be most compatible, I did have a weird issue when I used to share my Vista Edits of SetupS, but they worked when compiled in XP, but that was Vista
Somehow your changes seems to have put a halt to the incessant re-installing the LastOS Startmenu (and the constant extraction of Icons.7z). Sounds like CopyFromLive and the Startmenu cleaning functions (from ssControlPanel, I believe) are a little dicey for Live PE and perhaps new OS installs in general. One other possible issue might be if ppAppsLive is on a read-only media and SetupS attempts to write info back to the source .app-file while in Regen-mode. I don't remember off hand. I'll have to look into it. But I do know it writes to the destination .app-file in Install-mode. If it does so in Regen-mode, it would probably be better that it doesn't try to write back to the .app-file regardless -- a possible marginal speed increase there as well. I'll see about making these revisions first. Though the Patch folder/archive should have remained in the Source folder/archive from the beginning and never have been present in the Install-to folder anyway. But hey, it won't hurt to have that extra check.
Code: Line 440 SetupS.au3 ;---------- Fix Startup folder icon if missing or changed ------------- If $MenuStyle > 0 And Not $RegenOnly Then ;Glenn2020 That would be this test, it is the only one with the function call to re install the menu again and again. I would also like to make the MSI Shortcut checking only occur when it is needed, but that was in SetupS.Core and I only wanted to edit the one au3
Earlier I tested a Win7 x86 (Last7) and when I initiated LastOS Sorting (first time after fresh install) it got stuck and all the ppApp (it seems) start menu folders remained and ssControlPanel.exe and ssReGenerator.exe kept running (ssRegenerator in the tray as icon) but nothing was happening. I finally killed the .exe's in Task Manager and started ssControlPanel again and reverted to Standard sorting. This worked, so I then did LastOS sorting again and it worked -- it worked in the sense that the menu got sorted LastOS style. So I thought all was good but later I wanted to shut down the VM and I get this shutdown dialogue saying something isn't closing and if I want to force close it and then I got an au3 error (???); I open Task Manager and SetupS.exe was (still?) running in Task Manager. I want to say last time I tested x86 I had a similar problem. I don't know if this has anything to do with the changes you have been discussing but it's worth testing. I guess for all intent and purposes I got the LastOS menu installed but there was some weirdness going on.
It's very hard to determine the cause of a crash, I mean I am going to edit the AppPath=%SourcePath% ppAppsLive you made to use the proper %ppApps%\Folder.Name.Here\ instead as I know for a fact it can cause SetupS issues if you do unexpected things, if one of them got installed to \ppApps then it would be trouble IMO. Freezer can't batch process Shortcuts all at once, he has to test and build each one, that is the process that takes a while, but it also means sometimes things can cause it to wait.......FOREVER!!! - Maybe we need to add a timeout function that tells you where it's stuck (in SetupS) and then quits the current operation to continue to the next one, it may miss a shortcut or two, or not apply a patch etc, but it's better than a full on crash type experience. I personally only just discovered how good Freezers Debugging logs are, you enable them in SetupS Control Panel and it makes the logs in C:\Program FIles\SetupS.SendTo\ then you can jump to the end of one and see the last Function it called and even the steps it was up to before failing - where it's got stuck. so if you happen to figure out a way to make it fail on you on demand, then please test and report the logs in future so we have a chance to fix them as we go
I installed my PC with my Syspreped LTSC and it's crashing when I click Windows Update in Settings This will be fun to figure out -EDIT- Took me 4 minutes to figure out: UsoSvc Update Orcherstartor Service This was disabled, I am guessing by BB tweaks I included, I'l go fix it up and should be fine. PHEW!!! -EDIT- I can't find it... Maybe it's part of the Base Image I captured then, ah well I'll just use SetupComplete.cmd to turn it back on -EDIT- I had a closer look in the following file, it's bug ridden and I wont be using it after all: Win10-BB-Regs.reg Code: [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesWaaSMedicSvc] This is one of the many registry keys it has gotten wrong. Trouba you should stop using these broken sections from this reg file. how it's supposed to look: Code: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WaaSMedicSvc] -EDIT- Latest AIMP ssApp is broken - this is the 2nd time on fresh install it's done the following error: It still installs fine and works properly, but it shows errors, it isn't anything we did, maybe it's just a bug they have on fresh OS installs as the 2nd time you run it (even after uninstalling first), it doesn't show the error.
Glenn, I don't use any of the BB reg tweaks anymore. I also didn't include any in the Pro image from the other day. Freezer also had some networking related issues with them as well and from that moment on (some months ago) I've discarded them. I had considered leaving the MS server blocks in them because they say hosts addresses don't get blocked anymore when you add them in hosts files against MS telemetry, but to me it's just too untested and ill-begotten so I decided to discard them entirely. I would suggest just deleting the entire BB section like I did. Any additional telemetry fixes people can attempt via apps like W10Privacy ppApp or Debotnet or what have you. Weird about AIMP ssApp -- I exclusively use the ppApp version myself and had not encountered this issue yet. By the way, I came across this a few days ago and you might think it interesting. MS allows for disabling specific notifications for Action Center via registry tweak now (Win7 can't do this for example) which might come in handy (regs are on bottom of page): https://docs.microsoft.com/en-us/ar...abling-windows-10-action-center-notifications I couldn't figure out if you could add this LOCAL_MACHINE as well in case CURRENT_USER won't take for fresh installs/new user accounts so I added them to HKLM too just in case but anyway here's some I used so that Action Center won't give me the update error for the (disabled) OneDrive trying to update: Code: ;Disable Notifications in Action Center regarding Security & Maintenance, and Windows Update (in case you disable OneDrive from running upon install, it may give you a message saying Updates couldn't be completed, etc) [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Notifications\Settings\Windows.SystemToast.SecurityAndMaintenance] "LastNotificationAddedTime"=hex(b):af,4d,8d,cf,0c,e2,d5,01 "Enabled"=dword:00000000 [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Notifications\Settings\Windows.SystemToast.WindowsUpdate.Notification] "LastNotificationAddedTime"=hex(b):ee,fb,94,aa,0c,e2,d5,01 "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Notifications\Settings\Windows.SystemToast.SecurityAndMaintenance] "LastNotificationAddedTime"=hex(b):af,4d,8d,cf,0c,e2,d5,01 "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Notifications\Settings\Windows.SystemToast.WindowsUpdate.Notification] "LastNotificationAddedTime"=hex(b):ee,fb,94,aa,0c,e2,d5,01 "Enabled"=dword:00000000
I thought it was just me. But for me I've only been getting them with AIMP v3.60 -- I don't get them with v4.60. Also, I still get the errors even after uninstalling/reinstalling. And if you get those errors, it did not install properly. Those .dll's are the context-menu for playing music files/folders. The weird thing is they only happen with ssWPI (both v17 & v20); even "Install Instantly with SetupS". But everything's okay with the regular SetupS (double-click or Send-to) -- context-menus are present.
The problem would be with my StartWait.exe .au3 then, I offer a way to alternate how it launches SetupS, ppGames and this is what is breaking it then. ssWPI_Options.ini LauncherMethodInverted=No I would think that it being such a tiny bug, it's not going to come up much. I just double clicked the .apz and never worried about it.... I could use the ppApp version, but I wanted system wide hotkeys enabled, which I am not sure the ppApp has - it might? -EDIT- Latest VM test of WinRE and installed OS are good, I'll keep working on it for a few more days still.
