CORE-19496
All wallpapers that are not in bitmap format will not work on LiveCD. LiveCD has a read-only file system and to apply non bitmap files as wallpapers, we convert them to bitmap when selected as a temporary file. Therefore, only copy non-bitmap wallpapers to BootCD, not LiveCD. Also minor fix to README in the wallpapers folder.
This commit includes:
- Partial revert of dc1a4ae9ce [0.4.15][SYSSETUP][BOOT][WALLPAPERS] Set default theme to Mizu and add wallpapers
- 2e47094764 [SYSSETUP] Apply theming from unattend files very early on when booting the LiveCD or a new install (#7797)
ebdb7b3e4d A problem has been detected and ReactOS has been shut down to prevent damage to your time machine warp core.
- 4bc97ad145 [BOOTDATA] Arabic, Hong Kong, Singapore, come back! (#7795)
As decided by an official meeting vote on Mattermost, set the default theme and desktop wallpaper to Mizu.
In this commit, I also added the 16:9 variants of every wallpaper in our standard wallpaper pack that had a resolution of 1920x1080 or better. For most wallpapers, we don't need a 4:3 variant because we have a "Fill" placement option that will scale the wallpaper up to the desired height and cut off the edges. Unfortunately, the Mizu wallpaper is one that doesn't work well with this method. Wallpapers without text branding were preferred over text branded wallpapers. Also, add a fix for the Mizu start button so that it looks acceptable with large taskbar.
Limitations:
- Since we can only display bitmap (.bmp) images on the desktop, convert the 4:3 and 16:9 variants of the Mizu wallpaper to bitmap files.
- Since ReactOS will default to a 4:3 aspect ratio without changing the resolution, set the default wallpaper to the 4:3 variant.
- The theme is set on the welcome page of the setup wizard during second stage setup.
This backport fixes 'kmtest_.exe SeQueryInfoToken'
on all testers: VBox x86, KVM x86, WHS x86, Win2003_x64.
And according to Thomas description may also prevent a buffer overrun when executing that formerly broken test.
Afterwards all 76 tests of this suite do complete on all those builders.
Before the patch only 74 of those tests succeeded, 2 failed.
The fix is a squashed backport of the following 6 commits from Thomas Faber:
0.4.16-dev-11-g 44bdafa17e [KMTESTS:SE] Fix failing tests (#5308)
0.4.16-dev-10-g bf6af0f52e [NTOS:SE] Mark output parameters as such (#5308)
0.4.16-dev-9-g 156053cafd [NDK] Match AUX_ACCESS_DATA definition with publicly available version. - if you allocated only sizeof(AUX_ACCESS_DATA), the test would crash with a 4 byte buffer overflow. (#5308)
0.4.16-dev-8-g ff410211e9 [KMTESTS:SE] Don't modify internal data structure, this might cause buffer overrun (#5308)
0.4.16-dev-7-g 206df96bc4 [KMTESTS:SE] Correctly allocate PrivilegeSet buffers (#5308)
0.4.16-dev-6-g 64a6bd4c3e [KMTESTS:SE] Avoid use of uninitialized pool and hardcoded offsets (#5308)
WHS x86 before-and-after-state, the after-test had a few fixes from Timos unrelated PR7343 inside unfortunately:
https://reactos.org/testman/compare.php?ids=97640,97871
(This is added to prove the test being wrong)
I tested it also successfully on my local 2k3sp2 x86 with the releases/0.4.15 afterstate, built with RosBEWin2.2.2 GCC8.4.0dbg x86.
Win2003_x64 0.4.16-dev-11-g44bdafa at 2024-09-12 15:19 (after-state):
https://reactos.org/testman/compare.php?ids=97791
0.4.16-dev-5-g2913ef5 vs. 0.4.16-dev-11-g44bdafa vs. 0.4.16-dev-23-g53b304e:
VBox x86 https://reactos.org/testman/compare.php?ids=97795,97806,97877
0.4.16-dev-5-g2913ef5 vs. 0.4.16-dev-20-g144a8b5 vs. 0.4.16-dev-21-g2af6fd4:
KVM x86 https://reactos.org/testman/compare.php?ids=97793,97855,97856
Since we do touch the NTOS and NDK here the fix is not guaranteed to be side-effect-free,
but since we are so early in the RC-phase, I dared to pick it, especially since the alternative would have
been to disable the test altogether in the releases/0.4.15 which would have been a pity, if we can also have it all green everywhere.
I am really no fan of disabling tests, even when they are broken,
but in these cases they are really not worth of suffering the pain, and rerunning the bots all the time.
Those tests do have random failures and timeouts, and are accessing external web-resources
of the Wine test-infratructure, which are not always accessible.
I do disable them, because they very often make the testruns run extremely long.
"Inspired by" 0.4.15-dev-367-g d424a0e088 urlmon_winetest:url skipped due to frequent hang on Test KVM
This following links do reflect the BEFORE-STATE:
The "urlmon:protocol" test does even crash on the WHS x86 testbot, see:
https://reactos.org/testman/compare.php?ids=97640
0.4.14-release-123-gcc9c2ba:
VBox https://reactos.org/testman/compare.php?ids=97825 KVM https://reactos.org/testman/compare.php?ids=97826 (both timed out at urlmon:url)
0.4.15-2-g94cae27:
VBox https://reactos.org/testman/compare.php?ids=97837 KVM https://reactos.org/testman/compare.php?ids=97838
Yes, even older branches might also be affected, but I will only exclude them for now on releases/0.4.14 and releases/0.4.15
because only on those I do regularly run the testbots still.
For SOME reason comctl32 has been synched manually multiple times to different versions and different pots
This PR aims to fix that
With the exception of button.c which all in all is a massive fork over wines code entirely.
and datetime.c which is at wine 6.0
Comctl32 is now at wine-5.0
As part of fixing some bugs like CORE-13149, extend the tests to include more detailed examination of rendering functions. Extend the RedrawWindow test to include tests of all flags. As part of it, I am also testing the 2-point states of the render areas.
I moved the original test without changes into a separate function GetMessageRedrawWindowTest. For the flag tests I added FlagsRedrawWindowTest function. It sequentially tests the RedrawWindow with different flag combinations and compares the results with those discovered in Windows XP and Windows 11 (the values in both versions confirmed to be identical).
The API test turned out well in ReactOS, the only deviation was that in many cases (whenever the RDW_INVALIDATE flag is present) a WM_ERASEBKGND message is received after the window is rendered without the RDW_ERASE flag.
(this is what I'm focusing on now in https://github.com/turican0/reactos/tree/fix-RDW_ERASE-in-co_UserRedrawWindow, but before I merge it, I want to create more API tests)
These tests come with a VS solution, because that is the only way to test against a known good system, as the required runtime functions (like _ftol) are statically linked from the VS runtime library.
Checks CORE-19669, making sure that CS_HREDRAW and CS_VREDRAW
are respected when the client area changes due to the scrollbar
disappearing or re-appearing.
ROSTESTS-397
Co-authored-by: Stanislav Motylkov <x86corez@gmail.com>
Test 1 - test of creating/canceling 20 timers and comparing the raw number of returned messages - without parent window
Test 2 - test of creating/cancelling 20 timers and comparing the raw number of returned messages - with parent window
Test 3 - test creation/cancellation of 40000 timers - without parent window
Test 4 - test of creation/cancellation of 40000 timers - with parent window
Test 5 - test creation/cancellation of 2 timers and compare their index to see if they differ - without parent window
Covers the case in CORE-9141 (see #7087).
HAHA! Got you Stasm! :D
Just kidding!
In fact:
For the record the RES_LAST_INDEX was totally too small, someone forgot to increase it
for the last ~50 people that were added here.
I added 6 names today:
"Carl Bialorucki"
"Doug Lyons"
"Katayama Hirofumi MZ"
"Joachim Henze"
"Oleg Dubinskij"
"Whindmar Saksit"
For the record: I waited > 10 years to add myself to grab the cool number 66 all for myself!
This converts it from Windows-1252 to UTF-8.
Otherwise the changes to this file are not rendered correctly by GitHub.
As a core developer and repository maintainer, I have the right to change
file contents (including its encoding) without prior discussion, as long as
it corresponds with the repository's code of conduct.
I won't permit curtailment of my rights!
This is my answer and addendum to the commit b6bf110890,
which tries to disrespect me as a developer and maintainer.
The shell protocol path needs
special parsing. We didn't
implement it correctly.
JIRA issue: CORE-19693
- Add tests for
shell:windows\system32
and shell:windows\fonts.
If East Asian people were unable
to see the Latin characters, it
becomes a barrier to mutual
understanding.
FontLink will break that barrier.
JIRA issue: CORE-9616
JIRA issue: CORE-15480
- Modify font substitutes.
- Unify the lock variables.
- Add FONTLINK and
FONTLINK_CHAIN structures.
- Add FontLink_Create and
FontLink_Destroy functions.
- Add FontLink_Chain_Init,
FontLink_Chain_Free,
FontLink_Chain_LoadReg,
FontLink_Chain_Populate, and
FontLink_Chain_FindGlyph
functions.
- Implement FontLink.
- Add font file DroidSansFallback.ttf
for LiveCD.
* [UDFS] Clang: Fix a #pragma
'warning: unknown warning group '-Wstringop-overflow', ignored [-Wunknown-warning-option]'
Follow-up to 612b1f2e6 (0.4.15-dev-1129).
* [CREATESPEC] Clang: Fix a target_compile_options()
'warning: unknown warning option '-Wno-stringop-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]'
Addendum to 00ed72d7e (0.4.15-dev-1169).
* [MSVCRT_WINETEST] Clang*: Fix a target_compile_options()
'warning: unknown warning option '-Wno-stringop-truncation'; did you mean '-Wno-string-concatenation'? [-Wunknown-warning-option]'
Addendum to commits 00ed72d7e (0.4.15-dev-1169) then f155b9377 (0.4.15-dev-4612).
* [TELNET] Clang*: Fix a target_compile_options()
'warning: unknown warning option '-Wno-restrict' [-Wunknown-warning-option]'
Addendum to 447ef2aa4 (0.4.15-dev-4613).
We reduce our wallpapers in Release bundle.
Reduce the cost of downloading the release images.
See also: reactos/rapps-db#243
JIRA issue: CORE-19617
- Reduce some wallpapers (7 MB to 253 KB).
- Modify CMakeLists.txt to reduce wallpapers.
- Update ReadMe.txt.
- Add ReadMe.txt to reactos/Web/Wallpaper.
This export function is needed to implement
shell32!SHGetRealIDL function correctly.
JIRA issue: CORE-19278
- Implement IShellFolder_GetDisplayNameOf
function (This function is not inline function in
this case) with retry data.
- Add SFGDNO_RETRYALWAYS flag to
<shlwapi_undoc.h>.
- Add IShellFolderHelpers testcase.
This removes all fake apiset forwarders,
and handles apisets inside ntdll.
This is not 100% compatible with how windows does it, but it should be good enough for us.
