View source for Windows scripting, environment, explorer hooks, etc.

{{#addbodyclass:tag_tech}}
{{windows}}

{{stub}}

<!--
https://gist.github.com/pkfrom/f6eb82316b725a51f357
-->

==Environment variables==

<!--
Environment variables in the sense of "programs can open 
https://en.wikipedia.org/wiki/Environment_variable
-->

===Program stuff===
Program Files ({{inlinecode|%PROGRAMFILES%}}, and see also {{inlinecode|%PROGRAMFILES(X86)%}})
: considered read-only for regular users (it's a system account that does actual installation{{verify}})

<!--
{{inlinecode|PROGRAMW6432}}?
-->


ProgramData ({{inlinecode|%PROGRAMDATA%}}, apparently also {{inlinecode|%SystemDrive%\ProgramData}} and {{inlinecode|%ALLUSERSPROFILE%}})
: data that a program needs, yet which is ''not'' user-specific (it's not part of user profiles)
: might be writable to users in home installs 
: '''but''' AD-style workstation setups (where software install is managed for you) might choose to lock this down
:: that lockdown is often done in a way where only users that created a file can read back the same files, so even if you seem to be able to create files there, it won't let you do things like configurations shared between users
:: so '''programs shouldn't count on sharing data here'''
: some programs may use this for install-time configurations stuff and afterwards ''treat'' it as read-only - but others do not
: something you would consider 'supporting data' might frankly be here ''or'' in Program files (in fact, Program Files might have more refined ACLs more aware of installers)

===User profile stuff===

'''{{inlinecode|%USERPROFILE%}}'''


'''{{inlinecode|%HOMESHARE%}}''' {{comment|(and the related %HOMEDRIVE% and %HOMEPATH% (which should always be directly appended?))}}
: HOMESHARE is comparable to USERPROFILE
:: HOMESHARE is set later than USERPROFILE[https://stackoverflow.com/questions/606483/what-is-the-meaning-of-these-windows-environment-variables-homedrive-homepath] 
:: isn't necessarily the same as %USERPROFILE%
: This can get messy to understand. For example, in one AD-managed setup I used,
:: %HOMESHARE% points to a \\network path that contains all my files, and the contents of %USERPROFILE% are not synchronized 
:: %USERPROFILE% is a mostly-empty directory tree on the local disk   {{comment|(presumably because windows says this directory ''has to exist''?)}}
:: ...yet many (but not all) entires within that USERPROFILE are actually [[junctions]] to the path that HOMESHARE points to
::: in a way that is very hard to explain to non-nerds. For example, DIR is a Documents that is local, a My Documents that is is a junction - and that explorer also shows as Documents (without the My)
::: (note: you can see the presence of junctions e.g. using {{inlinecode|DIR /A}}, or ''mostly'' them with /AL)



'''AppData''' (under %USERPROFILE%\AppData)
: data required by applications, like configuration, caches, etc.
: there is little keeping you from putting those ''elsewhere'' under %USERPROFILE%, but it's generally here, and on network installs there are more notes -- see the notes below for the split into '''Local''', '''Roaming''', and '''LocalLow'''
: %APPDATA% seems to expand to %USERPROFILE%\AppData\Roaming  (has since Vista? Was it always to Roaming, though?)
: %LOCALAPPDATA% expands to %USERPROFILE%\AppData\Local (since when?)


'''AppData's Local, Roaming, and LocalLow'''
* '''Local''' is for things that ''should not'' roam with the user, even if it ''could''
: e.g. most program caches

* '''Roaming''' classically only did anything for people in [[Domain environments]]
: Since Windows 8, windows might synchronize between different MS logins {{verify}}

* '''LocalLow''' - The idea of "Low integrity environments" is to make it easier to have a location to ''distrust'' -- or rather, makes it easier to set up rules/filters for that set of software, letting you restrict them to all but a few directories. This is mainly aimed at browsers, because they are a common attack vector.
: in practive, LocalLow may point to the same folder as Local, or may not. 
: https://helgeklein.com/blog/internet-explorer-in-protected-mode-how-the-low-integrity-environment-gets-created/


Notes:
* I've seen programs choose to install completely to AppData (typically \Local), presumably to avoid requiring admin rights for an install
* Roaming and Local only serve different function if Roaming is actually synchronized (or remote-mounted?)
** if no syncing  (or remote-mounting?) is going on, Roaming is really just Local as well
** it's probably a good idea for programs to make the local/roaming distinction, just in case the system you run it on does


<!--
%LocalAppData% to Local

%ALLUSERSPROFILE% to ProgramData ?
-->

===Known Folders, Special Folders===

<!--
Known Folders

https://learn.microsoft.com/en-us/windows/win32/shell/knownfolderid

e.g. 

FOLDERID_Desktop defaults to %USERPROFILE%\Desktop 
FOLDERID_Documents defaults to %USERPROFILE%\Documents

but can be changed



These are looked up by fetching a specific fixed ID to SHGetKnownFolderPath (previously handled via SHGetFolderPath)

This is something programs (like Explorer) would have to do explicitly, 
which is why they are not always easily located,
even if standard open-file dialogues should include them{{verify}}.

https://learn.microsoft.com/en-us/windows/win32/shell/knownfolderid



Special folders

https://learn.microsoft.com/en-us/dotnet/api/system.environment.specialfolder?view=net-7.0#System_Environment_SpecialFolder_CommonDesktopDirectory

https://superuser.com/questions/984866/how-to-make-a-desktop-shortcut-available-for-all-users-in-windows-10



In windows:
* A folder is a location in the shell namespace
* A directory is a location in the file system - and one of the ''kinds'' of folders
* A virtual folder is another kind of folder, one that is not necessarily backed by a irectory
:: consider libraries, search folders.


Known folders are mapping between CSIDL enum values that correspond to the two .net special folder values you will see that they map to the same known folder guid

-->

===CSIDL===

<!--


A '''Constant Special Item ID List''' (CSIDL) is a Microsoft Windows concept that 
mean specific concepts (mainly to the Windows Shell?{{verify}}),
and can be looked up, ''mostly'' things within the user profile that are not necesarily always in the same place.

For example, 
* CSIDL_COMMON_DESKTOPDIRECTORY / FOLDERID_PublicDesktop is your desktop directory, 
* CSIDL_COMMON_DOCUMENTS / FOLDERID_PublicDocuments is <tt>All Users</tt>'s <tt>Documents</tt> directory,
* CSIDL_NETWORK / FOLDERID_NetworkFolder is a virtual folder that is the root of the 'Network Neighborhood' namespace hierarchy



Some of these are virtual folders, 




These seem to be constant GUIDs that, defined in [https://learn.microsoft.com/en-us/windows/win32/api/shlobj/ Shlobj.h]; see also [https://learn.microsoft.com/en-us/windows/win32/shell/csidl]


CSIDL (constant special item ID list) values provide a unique system-independent way to identify special folders used frequently by applications, but which may not have the same name or location on any given system. For example, the system folder may be "C:\Windows" on one system and "C:\Winnt" on another. These constants are defined in 




https://learn.microsoft.com/en-us/windows/win32/shell/csidl

-->

==Unsorted==
<!--

https://gist.github.com/pkfrom/f6eb82316b725a51f357
-->

==Scripting notes==

====cmd, bat====
<!--
.bat was introduced in the DOS era and was interpreted by COMMAND.COM, which came in non-NT-based windowses, so up to around ME.

.cmd was basically introduced to make it clear things are different in NT-derived windowses, and are interpreted by cmd.exe

The difference in syntax is minor, though.
-->


====Arguments, path transforms====

In a script,
 %0 is the executable
 %1 the first argument, %2 the second argument, etc.


There is some extra syntax. In the below, 
: d is drive
: p is the path     (without drive)
: n is the filename (without drive or path, or file extension)
: x 
: s changes the above to [[8.3]] style filenames
: ~ means remove quotes{{verify}}
 
Which can be combined, so e.g. if I create a script to demonstrate, its output might be:
 C:\foo>test.bat bar.txt
 ====0====
 %0      C:\foo\test.bat
 %~0     C:\foo\test.bat
 %~d0    C:
 %~p0    \foo\
 %~nx0   test.bat
 %~dp0   C:\foo\
 %~dpnx0 C:\foo\test.bat
 ====1====
 %1      bar.txt
 %~1     bar.txt
 %~d1    C:
 %~p1    \foo\
 %~nx1   bar.txt
 %~dp1   C:\foo\
 %~dpnx1 C:\foo\bar.txt



Notes:
* {{inlinecode|%~dp0}} can be useful to refer to other files in the same directory as the script you are running, with absolute pathsnames.

* {{inlinecode|%0}}, {{inlinecode|%1}} and so on are values as they are handed in, so might be relative '''or''' absolute paths (or UNCs). 
: Say, when dragging bar.txt onto foo.bat in windows, I got:
 %0      "C:\foo\test.bat"
 %~0     C:\foo\test.bat
 ...and...
 %1      C:\foo\bar.txt
 %~1     C:\foo\bar.txt

* works on UNCs {{comment|(though not all parts work ''quite'' the same)}},  then looking something like:
 %0      "\\DOM\Pers$\Homes\Me\test.bat"
 %~0     \\DOM\Pers$\Homes\Me\test.bat
 %~d0    \\
 %~p0    DOM\Pers$\Homes\Me\
 %~nx0   test.bat
 %~dp0   \\DOM\Pers$\Homes\Me\
 %~dpnx0 \\DOM\Pers$\Homes\Me\test.bat


<!--
The script itself would be something like:

@ECHO OFF
echo ====0====
echo|set /p="%%0    "
echo %0

echo|set /p="%%~d0    "
echo %~d0

echo|set /p="%%~p0    "
echo %~p0

echo|set /p="%%~nx0   "
echo %~nx0

echo|set /p="%%~n0    "
echo %~n0

echo|set /p="%%~dp0   "
echo %~dp0

echo|set /p="%%~dpnx0 "
echo %~dpnx0


echo ====1====
echo|set /p="%%1      "
echo %1

echo|set /p="%%~d1    "
echo %~d1

echo|set /p="%%~p1    "
echo %~p1

echo|set /p="%%~n1    "
echo %~n1

echo|set /p="%%~nx1   "
echo %~nx1

echo|set /p="%%~dp1   "
echo %~dp1

echo|set /p="%%~dpnx1 "
echo %~dpnx1


pause
-->

<!--

https://ss64.com/nt/syntax-args.html

-->

====Powershell====
<!--
Powershell was introduced later
.ps1
-->



==sysadmin/coder angle==

...focusing on things useful for sysadmins, 
makeshift installers batch-scripts, 
and such.



===cmd.exe===

Perhaps best known for getting a command line window from ''Start menu'' &rarr; ''Run...'' or Windows-R, then styping cmd.exe

Can also be useful for batch scripts. Then often used with /c, meaning 'close after the specified command is done'

===start, start.exe===

There is a <tt>START</tt> command (usable in cmd.exe windows, batch scripts, and such) that is a more flexible way of running things, can for example start without creating a window, start it minimized.

Note that the title argument is required, so if you don't care about a title, specify {{inlinecode|""}}


There are third-party tools that imitate the command, often to avoid having a visible cmd.exe window (e.g. installers, login scripts, CD/USB autorun)
* <tt>start.exe</tt> 
<!--* <tt>Launch.exe</tt> [http://www.google.com/search?q=site%3Asoniacoleman.com+launch probably here]-->


(Note: as with any common tool, there is malware that overwrites them)

===rundll32.exe===
{{stub}}
<!--
Specifically:
 RUNDLL32.EXE <dllname>,<entrypoint> <optional arguments>

There are a number of useful (and many more not-quite-that-useful) things that you can do this way.

For example:
 RUNDLL32.EXE SHELL32.DLL,Control_RunDLL desk.cpl,,0
...goes to the Display properties, second tab (Desktop).

There are webpages with endless lists of these, most of them fairly pointless.
You could try searching for some examples in the the registry.
-->

===regsvr32.exe===
{{stub}}

<!--
For example, you can unregister the DLLs that do [[Media thumbnails and previews in windows]].
-->

===See also===
<!--
Command lists:
* http://technet.microsoft.com/en-us/library/bb491071.aspx

* http://commandwindows.com/runline.htm
* http://commandwindows.com/command3.htm
-->