[MSVCRT][CRT][UCRT] Disable intrinsic string functions on MSVC (#9157)
Commit hash: 300e1d525d
VS2022 version 17.2 and later (`_MSC_VER >= 1932`) added new intrinsic
functions (`strncmp`, `strncpy`, `wcsncmp`, and `wcsncpy`).
As we implement these ourselves, we have to avoid compiler error C2169.
This problem surfaced with a recent GitHub Actions update:
https://github.com/actions/runner-images/issues/14017
Use `#pragma function(...)` to disable new intrinsic functions.
[CRT][UCRT][MSVCRT] intrinsic functions: Follow-up of #9157 (#9226)
Commit hash: 0572d36024
JIRA issue: CORE-20617
@learn-more found #9157 breaks the build as follows:
> error C2220: the following warning is treated as an error
> warning C4163: 'strncmp': not available as an intrinsic function
> warning C4163: 'strncpy': not available as an intrinsic function
_MSC_VER=1932 was not the version that the intrinsic functions
(strncmp, strncpy, wcsncmp, wcsncpy) added.
Using Compiler Explorer could detect the correct version:
_MSC_VER=1950.
- Add winevdm_setup as an optional module that can be preloaded on install
- Prompt to install both gecko and winevdm if the installer is not on disk
- Change "DisableGeckoInst" to "DisableAddonsInst" because we are installing more than just Gecko now
- No longer use appwiz,,install_gecko hack from wine appwiz
- Delete installer after successfully installing winevdm and gecko locally
This is a cherry-pick of 6117b1bdef.
If no bitmap buffer size is provided (e.g. allocation path from EngCreateBitmap), do not validate that the size calculation is valid. Should fix some display drivers, like Radeon IGP 320M.
See CORE-13036, CORE-11676
This is a cherry-pick of 5e76d075f1.
Dragging the first-boot install/status window could make setup stall,
and the shell never started after that.
The problem is that the move/size modal loop can remove a posted `WM_QUIT`
while setup is tearing the thread down. That quit message then does not
reach the outer `GetMessage()` loop, so the setup thread keeps waiting
instead of exiting.
This fix keeps the `WM_QUIT` message alive by re-posting it and leaving
the move/size loop.
See also: https://devblogs.microsoft.com/oldnewthing/20050222-00/?p=36393
Boot to first-boot setup, drag the install/status window while it is finishing,
and check that setup continues and Explorer starts instead of hanging.
This is a cherry-pick of cf47094103.
Remove the excessive repainting of the non-client window area (title caption/buttons and borders) whenever other windows are being dragged over.
CORE-5877, CORE-16672
This is a cherry-pick of b38db9dd23.
AddControllers already disconnects the controller interrupt on its error paths but left InterruptObject pointing at the freed object.
Now that DriverEntry runs Cleanup on failure (and Unload() routes through it too), that stale pointer is handed to IoDisconnectInterrupt a second time, bugchecking with BAD_POOL_HEADER.
Clear InterruptObject right after disconnecting so Cleanup() skips it.
CORE-20669
This is a cherry-pick of 1b91127bbe.
This is needed for ISO filesystem driver to work correctly,
as it assumes 2048 bytes per sector for CD-ROM media.
Happens on 86Box with board `[i430FX] ASUS P/I-P55TP4XE`,
Bochs emulator with `01/17/97-i440FX-2A69HV3CC-00` BIOS,
and some other real machines.
CORE-20640
This is a cherry-pick of 2f514a5127.
The function didn't check if `COPY_FILE_FAIL_IF_EXISTS` bit flag is set
or not, always failing if _any_ flags were set and the destination file
already existed.
This behavior was probably implemented under assumption that
`COPY_FILE_FAIL_IF_EXISTS` is the only valid flag, but it's not the case.
There are other flags, so this was breaking applications when they intend
to overwrite a file with e.g. `COPY_FILE_ALLOW_DECRYPTED_DESTINATION`.
These functions were affected by the problem:
- CopyFileEx - exposed by Total Commander not being able to overwrite file
- PrivCopyFileEx
- MoveFileWithProgress
Also cover `ERROR_ALREADY_EXISTS` returned by CreateFileW to match Windows
behavior, making the API tests pass.
CORE-10271
This is a cherry-pick of 91146de1cd.
Import fix from Wine-11.6, commit 46e5cabca7
msi: Add ComboBox items, using value if text does not exist.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56296
PR #8971 will upgrade module to Wine-10.0,
so guard the change with `#ifdef __REACTOS__`. Fixes CORE-15709.
This is a cherry-pick of ea313e6129.
CORE-20422
Restore the ability to download ReactOS's Wine Gecko during the Second Stage Installer.
Reverts a part of commit https://github.com/reactos/reactos/commit/6b9122b.
It reverts all of the changes there to "win32/syssetup/install.c".
This is a cherry-pick of 17846e97d0.
* Fix typo in account locked message
* Fix typo in account locked message
* Fix typo in account locked message for Italian locale
* Fix typo in account locked message
* Fix typo in account locked message
* Fix typo in account locked message
This is a cherry-pick of c87e1b9c2d.
CORE-20657, CORE-13525
Fix an issue in `SetupGetBinaryField()` that made the GUI installer unable to read INF files properly.
For this reason, all the binary values in the registry on a fresh ReactOS installation were all set to `0x00`.
The reason was that the custom HEX parser in Wine's `SetupGetBinaryField()` is broken.
As a solution, we can replace it with a call to C's standard `wcstoul()` function.
(Note that Wine fixed this problem in wine-11, still with a hand-made hex-value parser...)
This is a cherry-pick of b4b8774bee.
CORE-20661, CORE-13525
The GUI-mode setup was asking the user for device configuration and installation
destination partition, even when upgrading or repairing an existing installation.
It doesn't make sense to ask: e.g. you shouldn't be able to upgrade an installation
in C: to D: partition; and the setup ignores what the user chooses: e.g. if your
installation is using a 1024x768 resolution, choosing another resolution during
the SETUP won't change the resolution.
Thus, the setup should skip these pages without asking anything from user.
This is also consistent with USETUP's behavior.
- Set `InstallPartition` and `InstallationDirectory` to selected repair/upgrade
target volume and directory.
- Jump to the Summary page from the Install type/upgrade pages.
- Return to the Install type/upgrade page when navigating backward from the Summary page.
- Return to the Installation type page when navigating backward from the Device page.
This is a cherry-pick of 2351d0ea8c.
Without a proper bootvid, users could see freeldr load on UEFI systems and then get confused why ReactOS doesn't appear to boot. Don't provide UEFI freeldr on releases until we have a proper bootvid. A similar hack was needed for 0.4.15 release.
By using the capabilities created in CORE-16631.
This will fix many crash-regressions in apps that have "Vista+ready"-manifests.
A good default setting for releases to protect "average Joe".
We think that's a tolerable balance.
E.g: This will fix CORE-16700 and CORE-16707 for releases.
The reason for those crashes is that we have far too many gaps in our apisets still.
Adventurous users have two options in releases if they want to expose more apisets
(and additional crashes when apisets are not implemented yet):
1.) change registry setting "HKLM\SOFTWARE\Policies\Microsoft\Windows\AppCompat" "DisableCompatGuidDetection" back to 0
to switch the global behavior to act like master-state (== opt-out)
or
2.) Select the "Windows 7" shim for example individually per app for more apiset exposure.
(more safe)
Contrary master will remain affected by such crashes and users will
have to manually apply shim "IgnoreManifestCompatVersion" on each affected app for opt-out,
as we intend to abuse master as a testing platform to spot gaps in apisets and problematic apps more quickly.
Thanks to Mark Jansen for having implemented that flexibility.
This is a cherry pick of 138d9ac
Checked against CORE-16410 (which is related to CORE-11915). Unfortunately still needed. This hack has been applied in all earlier releases since 0.4.3
This is a cherry-pick of bca25b1
BTRFS installs are still not stable. Disable BTRFS installs to make the installation experience less confusing for release.
This disables BTRFS installs for both text based setup and graphical setup.
- Rename wallpaper filenames so they make sense in the available wallpaper list
- Flatten folder structure
- Change the capitalization on file ReadMe.txt to README.txt
- Add a license column in README.txt to describe license of each wallpaper
Note: The licenses for Silhouette.png and Silhouette Dark.png could not be confirmed. Assumed CC-BY-4.0
- Removed CC-BY-4.0 LICENSE.txt from the wallpapers folder because that license doesn't apply to all the wallpapers in the folder.
- Remove suggestions.txt, most of the links are dead and hasn't been touched since 2005.
- Rename ReadMe.txt from Angelus folder to Angelus.txt (Should we just remove it?)
This is a cherry-pick of c32fa2c.
- The `HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\HideDesktopIcons`
entries were redundant between hivedef.inf and hivesft.inf.
In addition, adding them were useless, because the "Network Places"
(network location folder) icon they were specifying is already shown
by default (like the others) on the desktop.
This basically reverts commit 054c755d91 (r31545) -- originally added
for the next commit 562c812846 (r31547).
The "reason" given by this commit was also wrong: the registration
of the network folder is done instead in its `HKCR\CLSID\<the_clsid>`
registry key.
- Similarly, the `HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Bitbucket`
registry key doesn't need to be pre-created; the shell will create it
on-demand at runtime.
This reverts commit bab735cf05 (r35203).
This is a cherry-pick of e45a75888c.
In `SHELL32_IsShellFolderNamespaceItemHidden()`, use `SHRegGetBoolUSValue()`
to look at both `HKEY_CURRENT_USER` with fallback to `HKEY_LOCAL_MACHINE`,
when searching for the registry value that determines whether a shell-folder
namespace item is to be hidden or shown.
Behaviour confirmed on Windows 2003.
Addendum to commit 6ae11ba09d (PR #7189).
This is a cherry-pick of 9342ed43d9.
- Add SAL2 annotations
- Initialize Iosb, otherwise the function will return uninitialized data on failure
- Add NULL check for lpNumberOfBytesWritten/lpNumberOfBytesRead to match Windows 8+ behavior, which Wine code relies on.
See CORE-20559 and CORE-17376
This is a cherry-pick of 72bfa0c88b.
This fixes wscript.exe crashing on .wsf files because of delay-loaded shlwapi, the bug was introduced in 6762703 (PR #8419)
This is a cherry-pick of 879e1cff63.
Due to resource compiler (windres)'s
bug, WS_TABSTOP style wasn't added
to IDC_CONFIRM_INSTALL checkbox
(I've confirmed WS_TABSTOP lackness
on reactos.exe with Resource Hacker
and RisohEditor). This PR will improve
keyboard usability.
JIRA issue: N/A
- Add WS_TABSTOP style to
IDC_CONFIRM_INSTALL checkbox
in IDD_SUMMARYPAGE resource
dialog.
This is a cherry-pick of 99252d7f94.
The shortcut spawns CMD.EXE in the background and runs a specific
command-line that determines where the reactos.exe installer is:
cmd.exe /D /E:ON /C "start %SystemDrive%\%PROCESSOR_ARCHITECTURE:x86=I386%\reactos.exe"
An alternative could be:
cmd.exe /D /C "for /F %f in ('"if %PROCESSOR_ARCHITECTURE%==x86 (echo I386) else (echo %PROCESSOR_ARCHITECTURE%)"') do start %SystemDrive%\%f\reactos.exe"
(In this second case an exact value comparison is made, contrary
to the first case where all instances of "x86" would be replaced.)
The reason for using CMD.EXE, is that the `PROCESSOR_ARCHITECTURE`
environment variable contains the "almost" correct value for the
architecture directory name where reactos.exe can be found, except
for the x86 case where `PROCESSOR_ARCHITECTURE` is set to "x86"
(as on Windows) but the directory is named "I386" (as on Windows again).
This is a cherry-pick of 85f2a67a9e.
The environment variables used by some shell links for the Live-environment,
are passed as data by CMake on the MKSHELLLINK build tool command-line.
When building on Windows, they are transmitted to the tool via CMD.EXE,
and we have somehow to force CMD.EXE to keep these variables unexpanded.
Depending on the precise context where these variables are being used,
either use an "escaped" format with `^%`, as in: `^%SystemRoot^%` ,
or, surround the variable name with `^` instead: `%^SystemRoot^%` .
This second form appears to work when the variable is specified within
a quoted sub-string given to the CMD.EXE command-line.
Addendum to commit a46e1e96ec.
This is a cherry-pick of 8eea7255fd.
Only handle `DESTINATION`, and transfer all the other parameters verbatim to `add_link()`.
Addendum to commits 3a3b16af0d, 8cb3980766, and a46e1e96ec (PR #8936).
This is a cherry-pick of f9effd17bc.
Using `userenv!CreateEnvironmentBlock()` when starting the shell ensures
that, even if it's started as LocalSystem, its environment inherits the
"dynamical" environment variables created by SMSS at runtime (stored in
`HKLM\SYSTEM\CurrentControlSet\Session Manager\Environment`).
In ReactOS/Windows PE "MiniNT" mode, the Winlogon environment doesn't
contain these values, and doesn't start the Setup with this augmented
environment. (This is compatible with what Windows does, on WinPE or
during a clean installation.)
Winlogon creates an augmented environment only when a user logs in and
starts its shell (standard boot), which isn't the case in "MiniNT" mode.
It is thus the responsibility of the module that starts the shell instead
to do it: in ReactOS' case, userinit.exe in LiveCD mode.
As a result, we get access to the `COMPUTERNAME`, `NUMBER_OF_PROCESSORS`,
`OS`, and `PROCESSOR_*` environment variables, amongst others.
This is a cherry-pick of eec8c97708.
