Thank you Freezer. With SetupS not installed on the system, the SFX's with the new SetupS .exe's inside now work, so it seems that bug is fixed. I'll do a clean install though and will report anything I run across. I hope I don't 'ferret' anything anymore this time around, although I liked that I had been ferreting (you don't hear that every day)
Seems that bug affected not only SetupS, but Regenerator, ssEditor, and Super.LL.Clean. Unfortunately, ssTek needs way more testers than presently available
Well, you did great... too bad it was such a recent bug or I would have been able to tell you sooner in that particular application of the SetupS .exe's. BTW, putting the ssConfig.ini in the WIM Overlay did pre-set the SetupS settings successfully, so just finding that file in the Windows\LastOS folder will make SetupS adhere to those settings even if it has never been installed on a system before.
From Merriam-Webster... Definition of FERRET transitive verb 1a (2) : to force out of hiding : flush
Yes, I'm going to assume that the ferret's specialization to dig up and brings things to light made his name grow into a verb
My guess? ... The SetupS.Uninstaller -- which is now integrated into the SetupS SendTo Suite installer -- deletes the Startmenu structure and icons from %LastOSResources%, then runs SuperLLClean on the StartMenu. This "forces" the SetupS Installer to install the new Startmenu structure & icons. The idea behind this was to "refresh" the menu in favor of the new one if it had any changes, new or deleted entries, etc..
OK thanks Freezer, that may very well be. But all is working good now, did 3 real world OS installs in the mean time and working great every time. I guess when there were no real bugs, I had to make some up
errors and blue screen fixed ,i had Enable True Transparency in firstlogon folder and i have no clue why it started givin me these dumb errors like this , ive had this same app in there for over 4 months without any problems ,ive even installed on my main pc with no errors over 3 or 4 times ,but once i removed it , it stopped
So it was the Transparency app. Well a lot has changed with the preset methods, I also noticed some different behaviors with some things I tried. It is probably a timing or sequence related thing (it not taking well to messing with explorer.exe at that stage or something). So does Enable True Transparency work at all when you try to apply it later on? Remember it does need those modded system files injected during WIM Overlay.
Well the thing is ive been usin the same new preset for a long time and its always worked ,just the past 2 or 3 days is where it went to shit lol , its like it was talkin to me and said im not workin for u no more lol , im sure it will work later on durin install
Hehe, well who knows then. So you are using the latest FirstLogon methods and xcopy stuff right? So it basically be the same preset methods as RON has in the latest Builder/Preset package? Just asking because that is what I use now so just making sure we are on the same page.
No i dont have xcopy right now , but its close to the same , my preset is totally changed. Im goin to up it soon. But the thing is , its changed alot but is basicly does the same thing hard to really explain lol
lol, yes it sounds like it. But the good thing is, when you mod presets like that it will bring some problems to the fore that otherwise wouldn't be found out. Which is were your expertise comes in.
Atleast it was a easy fix though lol , but i will up my preset soon and if u want to test it in vm u can but. U will need to use all the folders in mine only because its remade. Alot different then urs or rons , but it does work , now , i moved ppappslive. To winbuilder theres a post from al.chol that made me try his method and it worked but i only use one live app but more can be added , i dont use setups send to in winbuilder either , i moved sswpi to root. Moved ssapps ppapps inside sswpi folder. Totally removed rootgui, moved all the files and folder to overlaywim , so yea its alot , but since i removed that buggie app it works. 100% for me , but ur welcome to give it a run , but btw its forx86 only
OK cool. Freezer, I have a question for you: when making ppApps that use the Patch archive to write certain files to certain directories, it occurred to me that this may only work when you actually (fresh) install the ppApp, not when you use Regenerator. Does SetupS support the inclusion of the Patch archive (in archived form) inside the ppApp.7z archive (as well as outside of it), so that when Regen runs it will be able to write the patch file to those directories? The question applies to the scenario where you have set the ppApps drive to a non-system drive. EDIT: I tried adding in a "Custom.7z" in the ppApp.7z archive, and hoped the %Extract% line under <Assembly> would call it when running "Regenerator for ppApps", but it would not work that way.
Weird. I only just today got an alert that there was any postings going on in this thread... This is a very tired and very old discussion (this problem with using "overlays" like that)... discussions which you've already acknowledged that it was acceptable -- especially with leaving "Safe Install" disabled by default. And "Safe Install" was designed to prevent such crap with %ProgramFiles%, %SystemRoot%, etc! So I don't know what else I can say or how else I can explain that I haven't already about this matter. EDIT: ... except have you ever even tried out that new "Nonething" flag? From the Change-Log:
"Patch.7z" is merely the patch folder compressed: "\SetupS\", "\ssApp\", "\ppApp\", or "\ppGame\". And as such then all that is intended for it is as an install-time only artifact. See, I had always found it a little annoying that ppApp/ppGame Installs used fantastic compression with 7z -- and ssApp installers typically already had pretty good compression with their packages -- yet then the ball was dropped a little bit with the "patch" folders. So what this means is that "-Regen" or Regenerator should never even "see" the patch folder because it is already "installed". In fact, the only operations that are relevant to Regenerator is the Post-Processing ones (you see them on the ssEditors "Post-Processing" tab) -- script, registry, fonts, dll regserver, file associations, etc. Basically, %Components% (such as %Extract%) in the <Assembly> section ("Assembly" tab on ssEditor) are ignored by Regenerator or -Regen with SetupS. They can only come into play when SetupS is in Install-mode. I'll refer you to this posting for more information: http://www.lastos.org/index.php?posts/4478. I never did get around to fleshing that explanation out better than in that posting (in the hopes that we could someday include it some documentation somewhere). Unfortunately, I can't give you a good reason, at the moment, why %Components% are excluded from Regen-mode. LOL But presently you would have to do that from <Script> instead. Useful fun fact: <Assembly> runs at the %SourcePath% whereas <Script> runs at the %AppPath%
That posting above got me to thinking about the differences between ppApps, ppAppsLive, and ppAppsInstalls. Especially when you consider %SourcePath% and %AppPath% and how they relate to and affect the two operating modes (Install-mode and Regen-mode). %SourcePath% is the folder that gets "Sendto" SetupS. %AppPath% is the folder the app is installed to and also listed in the .app-file under the <AppPath> section. When %SourcePath% is the same as %AppPath% then SetupS automatically assumes Regen-mod. If they're different then SetupS automatically assumes Install-mode. So let's look at the differences in a new light, shall we? ppApps. These are located at the %AppPath% (ie, they are already installed and ready to run). Here %SourcePath% is the %AppPath% (SetupS automatically assumes Regen-mode). Note that this is the exact same thing that happens with an ssApp when its %AppPath% gets "Sendto" SetupS ppAppsInstalls. These are located at the %SourcePath% (ie, they can only be installed and cannot be run because they are contained inside archives). Here %SourcePath% is NOT the %AppPath% (SetupS automatically assumes Install-mode). ppAppsLive. These are located at the %SourcePath% (ie, they can be installed) but they are also ready to run (because they are NOT contained inside archives). Thus, ppAppsLive can be both a ppApp and a ppAppInstall. Here %SourcePath% is NOT the %AppPath% (SetupS automatically assumes Install-mode) so the only way to force SetupS into Regen-mode is to specify it via the "-Regen" switch. So how does SetupS distinguish between them? ppAppsLive versus ppApp. Only a ppApp will be located at the <AppPath> as listed in the .app-file. ppAppsLive versus ppAppsInstall. Only a ppAppsInstall will have an install-archive using the new (and now enforced) filenaming "standard". The install-archive could be named as any one of the following: ppApp.7z|.rar|.zip|.cab (ie, "ppApp.7z", "ppApp.rar", etc.) %SourcePath%.7z|.rar|.zip|.cab (ie, "CCleaner_v3_x86_ppApp.7z", "CCleaner_v3_x86_ppApp.rar", etc.) %AppPath%.7z|.rar|.zip|.cab (ie, "CCleaner.7z", "CCleaner.rar", etc.)
freezer i tried the nothing flag on a ppapp AuslogicsRegistryCleaner yes it works but if someone wants a folder icon it also deletes that as well
