ssTek

One of the abilities of SetupS -- the creating of shortcuts -- is somewhat complex and therefore can cause some confusion. For example, not many are aware that whole folders can be "sent to" SetupS. Such as "D:\ppApps" or "D:\Stuff.For.SetupS.To.Install".

With LivePE's we might even have a "ppAppsLive" folder. But if that folder gets "Sent To" SetupS might attempt to install them unto the LivePE disk, which would be undesirable -- if was even possible to do with these types of disk since they are typically read-only; or worse yet, install them to the system's actual ppApps folder. So in the following examples I'll present a couple of solutions to just such problems.

Note: Run these batch or cmd-script files from the SetupS.Sendto install folder or the Tools folder within ssWPI. Also, be sure to check the shortcut(s) properties to verify it is indeed creating shortcuts originating from those paths.

Example 1:
[tab=30]Simply use the -Regen switch. This switch allows the parent folder to be anything. It also prevents SetupS from installing apps and only "regenerates" them -- this is the so-called Regen-mode.

For example, the Live PE disk might have a folder called "\ppAppsLive" (and assuming the Live PE drive will be the System-Drive):

Code: Select all

@SetupS "%SystemDrive%\ppAppsLive" -Regen


If SetupS.Sendto happens to be on the same disk as the Live PE, you could also use "%~d0" for the following.
(But this only works from a .cmd/.bat file -- it won't work by itself from the command-line since %~d0 is a batch-file only variable.)

Code: Select all

@SetupS "%~d0\ppAppsLive" -Regen


Example 2:
[tab=30]Use SetupScp with the -ppAppsDrive=[x] switch to set the ppDrives. This assumes the Live PE drive is "writable" (such as a bootable usb flash-drive) and has a folder called "\ppApps" with suitable apps, of course.

Code: Select all

@SetupScp -ppAppsDrive=%SystemDrive% -ppGamesDrive=%SystemDrive% -ppDrivesRegen


Note that the -ppDrivesRegen switch will process any ppGames on the LivePE drive as well (if present). Alternatively, if you only wanted Regenerator to process just the ppApps, you could do the following:

Code: Select all

@echo off
SetupScp -ppAppsDrive=%SystemDrive%
Regenerator -ppApps


But what if the LivePE drive is not writable (such as a DVD-disk or a mounted virtual ISO)? Then you'll have to ensure these files are already located in the disk's "\Windows" folder -- for example, by inserting them in the ISO used to burn the LivePE disk. Also, be sure that the ISO has a "\ppApps" folder with the desired apps...

"ppAppDrive.ini":


Code: Select all

C:

"ppGameDrive.ini":


Code: Select all

C:

And then you'd simply use this command:

Code: Select all

@Regenerator -ppApps


This works because with NT6 (Vista/7), "C:" is always the System-drive. But this is not always the case with NT5 (XP, etc.). So I'll revise SetupS later to accept %variables% for the ppAppDrive/ppGameDrive ini-files so that this method will also work with XP-LivePE's:

"ppAppDrive.ini":


Code: Select all

%SystemDrive%

"ppGameDrive.ini":


Code: Select all

%SystemDrive%

And one more, greatly simplified example -- which is basically example 1 being applied to the situation with example 3 -- in that it doesn't matter whether or not the Live PE drive is writable nor that it's an XP-Live disk, etc.

"ppAppsGen.cmd":

Code: Select all

@echo off
SetupS "%~d0\ppApps" -Regen


'Nuff said.

So this will work in PE if the Live PE disk has a folder called "\ppAppsLive", and it won't matter whether or not the Live PE drive is writable nor that it's an XP-Live disk, etc.?

"ppAppsLiveGen.cmd":

Code: Select all

@echo off
SetupS "%~d0\ppAppsLive" -Regen


And I assume it would be called from FirstLogon, or where?

Cheers and Regards

Yes, and I think Ghost has already tested the method to be working. Yea!

We can even drop (or rename) "\ppAppsLive" in favor of "\ppApps" if we wanted.

Okay, so SetupS has (for quite some time actually) the following function -- which only gets called whenever the variable %CDROM% or %CDDrive% is used:

Code: Select all

Func GetOpticalDrive()
   If $Debug Then _ConsoleWriteDebug('@@ Debug(Trace) SetupS.Core.au3|GetOpticalDrive()' & @CRLF)
   Local $i, $Found, $Drive, $File
   ErrorProtection('off')
   ; Check System Varibles
   If $HomeDrv = '' Then $HomeDrv = 'C:'
   If $SystemDrive = '' Then $SystemDrive = 'C:'

   ; Get CD Drive (if any)
   If FileExists(@WindowsDir & '\SetupSCDDrive.ini') Then FileDelete(@WindowsDir & '\SetupSCDDrive.ini')
   If IsArray($CDDrivesList) Then
      If $CDDrivesList[0] > 0 Then
         For $Drive = 1 To $CDDrivesList[0]
             If FileExists($CDDrivesList[$Drive] & '\ssWPICD.ini') Then
               $CDDrive = $CDDrivesList[$Drive]
               ExitLoop
            EndIf
         Next
      EndIf
   EndIf
   If $CDDrive = '' Or Not FileExists($CDDrive) Then ;pick the first available one
      If IsArray($CDDrivesList) Then
         If $CDDrivesList[0] > 0 Then
            $CDDrive = $CDDrivesList[1]
         Else
            $CDDrive = $SystemDrive
         EndIf
      Else
         $CDDrive = $SystemDrive
      EndIf
   EndIf
   $CDDrive = NoBackslash($CDDrive)
   ErrorProtection('on')
EndFunc


Basically very similar to the line of code used inside scripts like FirstLogon.cmd that searched for a file called "ssWPICD.ini". Notably:

Code: Select all

For $Drive = 1 To $CDDrivesList[0]
   If FileExists($CDDrivesList[$Drive] & '\ssWPICD.ini') Then
      $CDDrive = $CDDrivesList[$Drive]
      ExitLoop
   EndIf
Next


I've changed it to instead check to see if SetupS is being called from one of the list of Optical-drives:

Code: Select all

For $Drive = 1 To $CDDrivesList[0]
   If $CDDrivesList[$Drive] = StringLeft(@ScriptDir, 2) Then ; Residing drive is on a CD-ROM
      $CDDrive = $CDDrivesList[$Drive]
      ExitLoop
   EndIf
Next


This is better. But it seems to me this function is very outdated even so. Yes, it detects mounted virtual drives as "CD-ROM's" but even the variable name is outdated because such drives have evolved past CD's into DVD's and now Blu-ray. Perhaps I'll add a new variable called "%OpticalDrive%".

In any case, I can see this variable as limiting. There's a variety of ways to boot into the OS now (USB, "Pixie", etc.). And just look at all the various ways to boot from USB: Flash-drive, HDD/SSD, even some type of Optical.

I know there's a long list of SetupS variables; and already I'm thinking of adding to it such variables as %OpticalDrive% and %ThisPath%/%ThisDrive%/%ThisFolder%. Here's what we have presently:

Code: Select all

%SourcePath%        Full path (drive + folder) to the .ini|.app|.ppg file.
%SourceDrive%       drive only of the .ini|.app|.ppg file.
%SourceFolder%      folder only path to the .ini|.app|.ppg file.
%ppApps%            Full path (drive + folder) to the system's 'x:\ppApps\' folder.
%ppAppsDrive%       drive only of the system's 'x:\ppApps\' folder.
%ppGames%           Full path (drive + folder) to the system's 'x:\ppGames\' folder.
%ppGamesDrive%      drive only of the system's 'x:\ppGames\' folder.
%Tools%             Full path (drive + folder) to SetupS's '\tools\' folder.
%ToolsDrive%        drive only of SetupS's '\tools\' folder.
%ToolsFolder%       folder only path to SetupS's '\tools\' folder.
%InstalledPath%     Same as %AppPath%.
%AppPath%           Full path (drive + folder) to the App's or Game's actual installed-to folder.
%AppDrive%          drive only of the App's or Game's actual installed-to folder.
%AppFolder%         folder only path to the App's or Game's actual installed-to folder.
%CDROM%             Same as %CDDRIVE%.
%CDDRIVE%           drive only of the system's optical drive (real or virtual).
%LastOSResources%   for "%WinDir%\LastOS" (ie, "C:\Windows\LastOS").


The main ones are %AppPath%, %SourcePath%, %ppApps%, %ppGames%, and %Tools%.

But let's take a closer look at the %Tools% (and notice it has related component called %ToolsDrive%). What does this mean actually? SetupS has a function that looks for the nearest available \tools\ folder. Actually, it uses a "tag-file" method because it's looking for a file called "Tools.ico".

So what does this have to do with all this, you wonder. I think what I'm driving at is if you wanted SetupS to break free from a batch-file/.cmd container -- and assuming SetupS is on the same drive as the folder we wanted regenerated -- we should be able to do the following instead (directly from the cmd-line):

Code: Select all

SetupS -Regen %ToolsDrive%\ppAppsLive

or

Code: Select all

SetupS -Regen %ToolsDrive%\ppApps

Ugh. I just found out SetupS doesn't convert incoming variables like that (or at least not as it is processing the input arguments).

Back to the drawing board. LOL

TheFreezerBox wrote:%LastOSResources% for "%WinDir%\LastOS" (ie, "C:\Windows\LastOS").

I assume that this will be changed to %ssTekResources% for "%WinDir%\ssTek" (ie, "C:\Windows\ssTek"), or at least have that added?

Have you ever done anything with PowerShell? I have not, but I understand it is freely available for use in everything from XP on and maybe even Win2K. Even http://ss64.com/index.html, one of my go to places for cmd help has a PowerShell section, along with VBScript and others. Anyway, one of the PowerShell commands, Get-WmiObject, can be used with Win32_SystemEnclosure class to get chassis type, see http://msdn.microsoft.com/en-us/library/windows/desktop/aa394474(v=vs.85).aspx. If you look at the comment at the very bottom of that page you'll see that apparently virtual systems (PE?) are identified as System Enclosure of type 0 (zero). I have seen that, for folks that know how to use it, PowerShell seems to be very powerful with many preferring it over cmd and vb scripting, for being able to do more, quicker, with less. So it might be one more tool we might want to learn how to use. (I might have to go find a "For Dummies" book. LOL) Might not really apply to us, but it was just a thought.

Cheers and Regards

bphlpt wrote:

TheFreezerBox wrote:%LastOSResources% for "%WinDir%\LastOS" (ie, "C:\Windows\LastOS").

I assume that this will be changed to %ssTekResources% for "%WinDir%\ssTek" (ie, "C:\Windows\ssTek"), or at least have that added?

Yeah, I copied and pasted that from an older file (before I added %ssTekResources%). We need to keep %LastOSResources% unfortunately for a little while longer in case any .app/.ppg files are still using it -- but we don't need to list it anymore; just recognize the conversion to "C:\Windows\ssTek".

bphlpt wrote:Have you ever done anything with PowerShell? I have not, but I understand it is freely available for use in everything from XP on and maybe even Win2K. Even http://ss64.com/index.html, one of my go to places for cmd help has a PowerShell section, along with VBScript and others. Anyway, one of the PowerShell commands, Get-WmiObject, can be used with Win32_SystemEnclosure class to get chassis type, see http://msdn.microsoft.com/en-us/library/windows/desktop/aa394474(v=vs.85).aspx. If you look at the comment at the very bottom of that page you'll see that apparently virtual systems (PE?) are identified as System Enclosure of type 0 (zero). I have seen that, for folks that know how to use it, PowerShell seems to be very powerful with many preferring it over cmd and vb scripting, for being able to do more, quicker, with less. So it might be one more tool we might want to learn how to use. (I might have to go find a "For Dummies" book. LOL) Might not really apply to us, but it was just a thought.

I too have heard about Powershell and its scripting abilities; but no, I've never played around with it yet. I don't even know if Trouba has ever made a SetupS app out of it.