The build broke due to a typo introduced by
0.4.15-dev-275-g
612729b092
../dll/win32/syssetup/wizard.c: In function 'ProductPageDlgProc':
../dll/win32/syssetup/wizard.c:527:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-
after-statement]
cc1.exe: all warnings being treated as errors
fix cherry-picked from 0.4.15-dev-278-g
4cbb21761c
-------------------------
[0.4.14][SYSSETUP][BOOTDATA] Make Server default again and write Service Pack (#2749)
- Make "ReactOS Server" the default product option again instead of "ReactOS Workstation".
- Write "Service Pack" info onto registry.
- Add ProductOption option to bootcd unattend.inf.
- Delete IDC_PRODUCT_SUITE and IDC_PRODUCT_TYPE controls.
To fix regression with Visual Studio 2010 setup CORE-17028
I took 2 translation files in their most recent version from master 0.4.15-dev-275-g
612729b to prevent having to resolve any conflicts manually:
tr-TR.rc
uk-UA.rc
cherry picked from commit 0.4.15-dev-275-g
612729b092
do not allow traversal inside virtual folders when selecting a file
part of the fix for CORE-16908
"Unable to select a Zip file for sending with Common Open Dialog"
which was unhidden by 0.4.9-dev-632-g
da6a46c6ac
fix cherry-picked from commit 0.4.15-dev-254-g
332889b8d7
part of the fix for CORE-16908
"Unable to select a Zip file for sending with Common Open Dialog"
which was unhidden by 0.4.9-dev-632-g
da6a46c6ac
fix cherry-picked from commit 0.4.15-dev-252-g
f379a29606
part of the fix for CORE-16908
"Unable to select a Zip file for sending with Common Open Dialog"
which was unhidden by 0.4.9-dev-632-g
da6a46c6ac
fix cherry picked from commit 0.4.15-dev-251-g
b1003ae909
part of the fix for CORE-16908
"Unable to select a Zip file for sending with Common Open Dialog"
which was unhidden by 0.4.9-dev-632-g
da6a46c6ac
fix cherry-picked from commit 0.4.15-dev-250-g
ac215455bb
This version (after .rsrc) works different than the
proper version I used for 0.4.12 (after .reloc).
Inserting after .rsrc is actually not correct, but Thomas believes it can
be used as a temporary trick to avoid random memory corruption upon
relocations of the kernel, caused by ROSBE-154.
I follow his advice, although when judging from practical tests only:
as long as we limit this script to NTOSKRNL like I do for releases
there have no negative consequences been observed in real life yet
even with the proper version of 0.4.12.
Up to now those problems have only been observed when used for drivers
MODULE TYPE sdk/cmake/gcc.cmake as well, like
it was tried for a moment in master 0.4.13-dev-609-g
c4d8e2a6e9
Using for drivers immediately did lead to BSODs like CORE-16183 and therefore was
mitigated in master by total disabling of the scripts for both,
kernel and drivers in
0.4.13-dev-621-g
36e9a6f8dd
To allow installing DVDWritenow without BSOD,
we need the script at least for ntoskrnl!
I committed this patch (after .rsrc) already into 0.4.13RC and master
cherry picked from commit 0.4.15-dev-220-g
d28677795e
To fix 'MSTSC fails to connect with error "ERROR: Bad packet header"'
which regressed by 0.4.12-dev-752-g
6bc61f63f1
In 0.4.12 and 0.4.13 releases I totally reverted
Pierre Schweitzer's work instead.
Thanks to Doug Lyons, author of this new workaround,
we can keep Pierre's work.
We think MSAFD is a better place to workaround than
our MSTSC binary, because our MSTSC runs fine on
W2K3SP2.
fix cherry picked from commit 0.4.15-dev-211-g
666fe66fe9
JIRA-user "Illen" reported booting from his Z170 controller worked up to
0.4.12-dev-936-g89aaf0e
and would refuse booting - beginning with uniata commit
0.4.12-dev-937-g
b546130731
For sure this workaround is just a temporary and no proper solution,
but was confirmed to be working by "Illen".
We have no clear understanding of the real bug yet.
Can be replaced by something better at any time.
It was already committed into 0.4.12, 0.4.13, and master.
We never had an affected release therefore.
cherry picked from commit 0.4.15-dev-210-g
6c0ff7bd84
fixes regression CORE-16747 according to JIRA user 'Oleg Dubinskiy'.
The regression did not reproduce for me when I tested the unpatched
state locally though.
According to Oleg Dubinskiy the regression started to happen in
0.4.14-dev-599-g
2d4d3f5fce
fix cherry picked from commit 0.4.15-dev-204-g
97ccef7761
Remove WM_SYSKEYDOWN handling at component level, in consistency with other components (ListView,...)
Early embodiement of the fix proposed to WineHQ:
https://bugs.winehq.org/show_bug.cgi?id=49097 in order to remove functional limitation in ReactOS.
Fixes regressions CORE-17020 and CORE-12203 that were once introduced
by SVN r72320 == git 297e33f228
during COMCTL32 WineSync 1.9.16 CORE-11866
Fix cherry.picked from 0.4.15-dev-191-g
295ba62820
Wine's implementation relies on http.sys driver, which we don't have
anyway. Function declarations are taken from Wine 5.7
This fixes regression "failure of VS2010 setup" CORE-16963
which was introduced by 0.4.14-dev-198-g
ebcc4c6109
cherry picked from commit 0.4.15-dev-161-g
8bd9450da8
Luckily no release was ever affected by this therefore.
This prevents ReactOS asserting when 'My computer'
is opened, while it tries to send commands to floppy drive.
Many thanks to patches author Doug Lyons.
The regression was introduced by 0.4.13-dev-1081-g
eeff926ede
patch was committed to 0.4.13rls and 0.4.14rls as well.
Today it was committed to master as well, as
the initially planned investigation for the root cause
did still not happen and we can not afford the time
to retest and workaround this over and over again.
Thank god that Oleg Dubinskiy was still around to retest
this again and confirmed it can still happen, because
unlike initially, personally I was not able to reproduce it
today anymore!
Since every release was work-arounded, we did never
expose the bug in any final release.
cherry-picked from 0.4.15-dev-174-g
7c81fb8f56
CORE-16935
I merged that back, because at least the play-icon was a regression.
We did not always use an icon here, but instead earlier we just had some
font glyph displaying the play-symbol. It was once changed to icon to improve
display for some asian localization (japanese? iirc).
And the current bad display most likely was a consequence of that.
cherry picked from commit 0.4.15-dev-86-g
bdb4da009a
Although I do not intend to build the 0.4.14rls with the new
ROSBE2.2.0 RC yet, it may still be helpful in the future to have
the flexibility to build it not only with the old RosBE2.1.6.
I tested the build process successfully in XPSP3 with RosBE2.2.0
after applying this patch. Without it fails with PCH issue.
cherry picked from commit 0.4.15-dev-61-g
8639a131b0
- [MSVCRT] __DestructExceptionObject(): Remove '-version=0x600+'
- [APISETS] __DestructExceptionObject(): Forward it to msvcrt
CORE-15135
I cherry-picked this, because we did export a stub for that historically at least
"commented". :-)
Exporting it 0x600+ only is regression of
0.4.13-dev-1032-g
99fe069ce6
Sure unobservable, because was a change within a comment only.
cherry picked from commit 0.4.15-dev-87-g
a9161650ad
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 than option 1)
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.
Like done in last release.
my testcase: this allows opening an exe/dll with MsDepends (CORE-12052)
Unfortunately still necessary, luckily still effective
and also reliably hides a lot of other crashes due to uncaught exceptions
like done in all earlier releases since 0.4.3
cherry picked from commit bca25b10b4
Import Wine commits by Dmitry Timoshkov:
* 0cd8502b49 windowscodecs: Add support for 4bps RGBA format to TIFF decoder.
* 962bb99352 windowscodecs/tests: Add a separate test for 4bps BGRA TIFF format.
In return of GetGlyphOutline function call, gm.gmBlackBoxX and gm.gmBlackBoxY must be non-zero to avoid Division by Zero. At epilogue of ftGdiGetGlyphOutline, we adjust the values. CORE-15949
