* Add ARM64 build configurations to projects
* StartMenu: add ARM64 support
* Add support for IAT hooking on ARM64
* Add ARM64 support to Classic IE
* Add ARM64 support to installer
NB: WiX 3.14.0.3910 or higher is required to create the MSI
* Revert whitespace change
* Separate x86/x64 and ARM64 installers
* Change suffix of ARM64 binaries
* Put also ARM64 MSI to final installer
* Fix sln
* Build some DLLs as ARM64X
These are meant to be loaded to both x64 and ARM64 processes.
We will compile them as ARM64X (when building for ARM64).
That way they will contain both x64 and ARM64 code paths.
https://learn.microsoft.com/en-us/windows/arm/arm64x-pe
* Make sure x64 installer cannot be installed on ARM64
In case if somebody manually tries to install x64 MSI on ARM64.
This is not supported/working scenario.
---------
Co-authored-by: ge0rdi <ge0rdi@users.noreply.github.com>
Windows started to add newer version of settings to settings description
file. These have the same description as older settings, but use
different parameters.
Unfortunately old settings are still present.
This causes our modern settings folder to contain duplicates.
And also we tend to use older setting definitions that no longer work
properly.
Thus we will de-duplicate parsed settings and try to keep newer ones
(that should work better).
New settings tend to have numeric suffix, so we will keep those with
biggest suffix.
Fixes#1031
Defender settings on Win11 use indirect strings in form:
`@{Microsoft.SecHealthUI_8wekyb3d8bbwe?ms-resource://Microsoft.SecHealthUI/Resources/DisplayName}`
`SHLoadIndirectString` is unable to load such indirect string, because it expects full
package name (instead of package family name).
In such case we will convert package family name to full name and try again.
Items can be pinned to directories that require administative privileges
(such as Open-Shell's default installation directory), so long as users
take ownership of the pinned folder. Also adds a command to Open-Shell's
context menu that opens the current pinned folder.
Adds general support for directory-based settings by creating a new
setting type called TYPE_DIRECTORY which uses a new bool added to
BrowseLinkHelper, called bFoldersOnly. START_MENU_PINNED_ROOT
has been removed, and all instances of both it and BrowseLinkHelper
have been adjusted accordingly. To create your own directory-based
settings, use CSetting::TYPE_DIRECTORY. Empty directory paths are
reset to their default value as they can cause unexpected behavior.
Based on `HostId`:
* {7E0522FC-1AC4-41CA-AFD0-3610417A9C41}
execute `shell:::{PageId}`
* {12B1697E-D3A0-4DBC-B568-CCF64A3F934D}
execute command in `DeepLink`
Adds virtual shell folder that contains items representing modern settings parsed from
`%windir%\ImmersiveControlPanel\Settings\AllSystemSettings_{253E530E-387D-4BC2-959D-E6F86122E5F2}.xml`.
It can be accessed via `shell:::{82E749ED-B971-4550-BAF7-06AA2BF7E836}` (in explorer).
Item in folder will open given setting page in `Settings` application.
Some projects do register COM server in Debug/Release sonfigurations.
We should do it with per-user redirection so that there is no need to
run elevated Visual Studio.
This has no effect on COM server registering in installed Opne-Shell.
It is related only to local development.
* Fix naming inconsistencies
'Menu' vs 'StartMenu'
* Installer: Remove Facebook link
* Installer: Remove PayPal donate remnants
* OpenShellReadme: Remove info about product version