See https://reactos.org/wiki/ReactOS_Foundation for more information.
the first part of CORE-18191
picked from 0.4.15-dev-4866-g 6881d8c624
Respect:
-Colins wish to leave out for now all the matches in kbdtool for legal uncertainty
-boot_images.cmake on master vs. boot/CMakeLists.txt in older branches
-treating cpu.inf special in this first commit for the sake of keeping sync to all other infs
-unlike master I decided to groom also cdmake, because I don't see any reason yet to dump that
in the older branches
-all releases down to releases/0.4.7 were released for the first time after the "ReactOS foundation"
dissolved already in 2015. So all are definitely fine to receive this commit.
-port back some EOL whitespace fixes as well in common.ver to sync the file to 100% to master head
This is a squashed backport of the following commits:
0.4.13-RC-53-g 4f628f6b16 (partial pick of shell32-changes for Miranda CORE-14439 & Winamp CORE-13584, explorer left out)
0.4.14-dev-369-g 141cf04239 (#2046) NTUSER
0.4.15-dev-1126-g 58b0558f94 (#3294) NTUSER
0.4.15-dev-2618-g 32b0cf6fc6 (#3697) NTUSER
0.4.15-dev-2621-g 59d4c11203 (#3700) NTUSER
0.4.15-dev-5242-g e6fb0e0c25 (#4800) Cleanup
brings us closer to releases/0.4.14
In the older branches it will fix the following bugs (or prevents introducing them):
CORE-13584 'Winamp 5.666 erroneously has a secret tab shown in taskbar'
CORE-14380 'Effective File Search 6.8.1 when you open up the app via desktop link there is no pane in taskbar'
CORE-14439 'Miranda IM 0.10.21 snap-to-monitor-border-feature brings ros to halt'
CORE-15655 'Click-N-Type Virtual Keyboard 3.03.0412 has no taskbar pane'
CORE-15669 'DVD Write Now 1.5.12 SP2 setup has no taskbar pane'
CORE-15716 'Photofiltr 7.2.1 has no taskbar pane'
CORE-15731 'Java JRE 6u45 setup, last page of setup has no taskbar pane'
CORE-16030 'Moo0 Audio Recorder - the taskbar icon does not appear'
(CORE-17330 Regression, many installers that should have only 1 taskbar pane, now have 2 of them erroneously)
First part with the typo in the assert was introduced by 5579428b4f
which was merged into ros by a merge-task during 0.4.8-dev'ing.
releases/0.4.7 didn't have that code yet.
fix picked from 0.4.15-dev-5035-g f308c6a2bc
----------
[NTFS] Do not print debug message for every function call by default
That 2nd part was picked from 0.4.13-dev-450-g 1552434940
----------
And for all the files that I had to touch for the 2nd part in the older branches,
I ported back also some EOL-whitespace-fixes within like they were done during 0.4.15-dev'ing.
fixes BSOD 0xc0000139 STATUS_ENTRYPOINT_NOT_FOUND upon boot when
replacing just the file advapi32.dll with 2k3SP2 version 5.2.3790.3959
We can not reach the desktop yet, but at least the GUI,
and we do no longer BSOD and can instead properly ACPI-shutdown at this point.
picked from 0.4.15-dev-71-g 0b530fe496
----------
also pick unrelated 0.4.14-dev-1260-g 6e79e60883 [RPCRT4] Fix 'Routeines' typos (#2481)
which contrary to its commits comment in master is very little only 'related' to CORE15682
but it imports c73352047d
and is a very safe fix, so I picked that as well.
is a small optimization picked from 0.4.14-dev-108-g 1bf982ff88
otm is checked for NULL already a few lines before in that function, and is not touched
anymore in between the two locations. Tiny bit shorter+smaller now,
and might satisfy also some static code-analysis.
The origin of checking it twice for NULL dates back into the pre-0.4.7-era of ros.
This avoids spamming "Syntax Errors" to the cmd-prompt when starting the VS2010 command prompt.
Or when typing something like "@Rem Hello" at the prompt.
Fix picked from 0.4.15-dev-202-g 9c11be5a3a
It fixes Heap Corruption when starting KernRate, which I could confirm also in
all the older ros branches by using:
gflags /p /enable Kernrate_i386_XP.exe /full
Kernrate_i386_XP.exe
The older builds did not expose the user-visible symptom of "the app crashing" yet
(due to different memory layout),
but the heap corruption was already happening in all of them.
This is a squashed backport of:
0.4.14-RC-92-g d3e301e28b (the actual fix)
0.4.14-RC-93-g 651a011548 (fix for compiling on GCC RosBE *Lin* 2.1.2 carrier-releaser)
0.4.14-release-24-g 57efac32b1 (just a whitespace addendum)
Otherwise fall back to the computed argv[0].
This is expected by some applications, for example Git.
Code is adapted from Wine.
Many thanks to Stanislav Motylkov for having investigated this bug!
fixes CORE-12931 and all its duplicates: CORE-13892 CORE-13898 CORE-14066
Fix picked from 0.4.10-dev-201-g f215f394d8
Logspam started during 0.4.9-dev'ing when zipfldr got committed,
logspam became much worse by 0.4.10-dev-599-g 932df378bf
But the actual bug of 'calling those functions when not needed' is much older than that.
Fix picked from 0.4.15-dev-3275-g cee171f5d2
Motivation is to fix the very frequent relocations
that we had since 0.4.9-dev'ing in the GCC build of the kind:
(../dll/ntdll/ldr/ldrutils.c:1311) LDR: LdrpMapDll Relocating Image Name comctl32.dll (7BEA0000-7C065000 -> 00410000)
(../dll/ntdll/ldr/ldrutils.c:1350) Overlapping DLL: C:\ReactOS\system32\rpcrt4.dll
(../dll/ntdll/ldr/ldrutils.c:1311) LDR: LdrpMapDll Relocating Image Name comdlg32.dll (7BAA0000-7BB87000 -> 005E0000)
(../dll/ntdll/ldr/ldrutils.c:1350) Overlapping DLL: C:\ReactOS\system32\shell32.dll
which really slowed down this release version significantly.
The update will also fix the following warnings at compile-time for GCC:
-- dxtn has no base address
-- zipfldr has no base address
-- verifier has no base address
-- custom has no base address
-- notifyhook has no base address
-- vfd has no base address
This updates the GCC baseaddress.cmake
to the state we do use in 0.4.10-release-145-gb5cfb62
leaving out the components that do not exist in releases/0.4.9 yet,
And additionally preserves the addresses for the 3 fusion dlls,
which our script currently cannot handle yet.
Therefore respecting the differences for:
set(baseaddress_localspl_apitest.dll 0x760a0000)
which has a different name in the old branches and:
set(baseaddress_fusion 0x721C0000) #added manually, last entry - 0x40000
set(baseaddress_fusion_1_1 0x72180000) #added manually, last entry - 0x40000
set(baseaddress_fusion_2_0 0x72140000) #added manually, last entry - 0x40000
This is a *partial* back-port of 0.4.10-dev-279-g 75dc031080
And a plain revert of the guilty SVN r73486 == git a35a785b11
It will fix the following regression symptoms:
- CORE-12614 empty "documents and settings" folder created when using non-english localization
- CORE-12613 we will save 1012KB of memory (commit charge in taskmgr), by shrinking the registry a bit
- CORE-18416 RaceCondition, sometimes the network icon in systray does not appear in late 0.4.9-dev and releases/0.4.9
For the record: I decided to pick only part of the fix from master and not all, because the proper fix
would rely on a lot of things to pick additionally from 0.4.10-dev' and even 0.4.11-dev'.
The consequences of only partially picking is that we cannot complete the setup of Office 2010 with its
copyprotection-driver anymore, which relies on being able to load its service with the proper account and user profile,
and not with the fallback we used in older reactos releases. If you need that feature, please use releases/0.4.11 or higher,
because even 0.4.10 is not handling this properly yet.
The conservative approach of 'not having the hack, and sticking to just one profile' is better for the older releases overall.
That problem in the shell was unhidden when we switched from our own to the MS-PL CDFS-driver
in 0.4.8-dev-164-g ec6b3ecbe4
because our own old CDFS driver erroneously never reported any CD file being read-only.
Fix picked from 0.4.15-dev-4348-g 513d0a6d2d
While backporting the fix, I decided to port back also some EOL-whitespace-stripping in that file.
This fixes log spam about NM_CUSTOMDRAW not being handled,
e.g. when interacting with the start-menu or filebrowsers menubar.
Less logging implies faster painting here with dbg-builds.
fix picked from commit 0.4.15-dev-3229-g 22e58e68aa
The bug was a regression of 0.4.9-dev-151-g 0aed0fd167 very likely,
The symptom with the logging can neither be observed in unpatched releases/0.4.8 nor in releases/0.4.7
which I could observe all the way from releases/0.4.7 up to releases/0.4.14
with MSVC 2010SP1 (16.0.40219.1) x86 target in dbg configuration
Creating library dll\win32\winhttp\winhttp.lib and object dll\win32\winhttp\winhttp.exp
LINK : warning LNK4199: /DELAYLOAD:ole32.dll ignored; no imports found from ole32.dll
Fix picked from 0.4.15-dev-4326-g 2f7dc168f2
And just for the record: Wine did the same with their:
f400f25c25
warnings can be observed with MSVC 2010SP1 (16.0.40219.1) x86 target in dbg configuration:
[7441/11751] Building C object sdk\tools\wpp\CMakeFiles\wpp.dir\ppl.yy.c.obj
[7442/11751] Building C object sdk\tools\wpp\CMakeFiles\wpp.dir\ppy.tab.c.obj
ppy.y(402) : warning C4146: unary minus operator applied to unsigned type, result still unsigned
ppy.y(402) : warning C4146: unary minus operator applied to unsigned type, result still unsigned
ppy.y(402) : warning C4146: unary minus operator applied to unsigned type, result still unsigned
partial pick from: 0.4.13-dev-132-g f47f45dbdd
Yes the /wd4244 wasn't really necessary for x86, but only for x64,
but taking it with me as well synced the file to 100%.
pick part of 0.4.10-dev-312-g a3ddb8a4c2 to harmonize the
inconsistency in the base-address-files regarding winspool.
Since an ancient winspool-name-change
the baseaddress*.cmake files do reference the winspool module in an inconsistent style:
- 'baseaddress_winspool' in baseaddress.cmake 'was already' / 'is still' ok without
the 'drv' in the older branches (unlike 0.4.10-dev-311)
- 'baseaddress_winspool.drv' in baseaddress_dwarf.cmake
- 'baseaddress_winspool.drv' in baseaddress_msvc.cmake
And therefore only GCC did properly set a base address, but MSVC failed at that.
No warnings afterwards anymore about 'winspool has no base address' during configure.
No false hopes though: The baseaddress-files do still remain a big mess afterwards,
especially in releases/0.4.9 for GCC dbg where we not only have the 'usual incomplete files'
but also still have and always had a lot of relocations between ros components at runtime
because some ros modules do overlap since some Wine-sync during 0.4.9-dev'ing, which
increased the binary sizes. But I just wanted to focus on the avoidable winspool-detail here for now.
Might deal with the other stuff later.
by always unconditionally enabling "String Pooling" /GF
Pros:
- consistency between the toolchains, as GCC always has this enabled
- shrinks the binary sizes for MSVC dbg builds
- smaller binaries will also make relocations less probable with MSVC dbg and a given set of (often outdated) precalculated base-addresses
- interestingly it also fixes/hides some linker warnings LNK4221
which can be observed with MSVC 2010SP1 (16.0.40219.1) x86 target in dbg configuration, here example from releases/0.4.7:
[819/11751] Linking C static library dll\opengl\mesa\main\mesa_main.lib
precomp.h.obj : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library
[830/11751] Linking C static library dll\opengl\mesa\math\mesa_math.lib
precomp.h.obj : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library
[858/11751] Linking C static library dll\opengl\mesa\swrast\mesa_swrast.lib
precomp.h.obj : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library
[879/11751] Linking C static library dll\opengl\mesa\tnl\mesa_tnl.lib
precomp.h.obj : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library
[897/11751] Linking C static library dll\opengl\mesa\vbo\mesa_vbo.lib
precomp.h.obj : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library
[1602/11751] Linking C static library sdk\lib\3rdparty\adns\adns.lib
internal.h.obj : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library
[4327/11751] Linking C static library sdk\lib\tdilib\tdilib.lib
precomp.h.obj : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library
[11714/11751] Linking C static library win32ss\user\winsrv\consrv.lib
consrv.h.obj : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library
[11726/11751] Linking C static library win32ss\user\winsrv\concfg\concfg.lib
precomp.h.obj : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library
It manages to make all the mentioned 9 LNK4221 disappear without introducing any other warnings into those modules, or into any other module.
Ftr I do not understand why String Pooling hides those LNK4221. But its effectiveness is evident.
But some other LNK4221 in other modules do still remain after it. Their count is not 0 afterwards, just significantly reduced.
Cons:
- String Pooling may slightly increase the build time, but the impact is negligible, even on my 12 year-old PC.
- String Pooling may make lousy code crash, that illegally wants to write into string constants, like we saw it for ROSTESTS298 for example.
But that is actually not a bad thing. That test was also broken beforehand and crashed even on real Windows.
We didn't find any similar problems within the 'productive code' yet.
fix is a partial pick of:
0.4.12-dev-354-g 5e673f3118
and its addendum
0.4.12-dev-655-g 237110604b [CMAKE] msvc.cmake: Remove 2 now redundant '/GF' (#1239)
can be observed with MSVC 2010SP1 (16.0.40219.1) x86 target in dbg configuration:
C:\047rls\reactos\modules\rosapps\applications\screensavers\cylfrac\cylfrac.c(109) : warning C4305: 'function' : truncation from 'double' to 'float'
C:\047rls\reactos\modules\rosapps\applications\screensavers\cylfrac\cylfrac.c(110) : warning C4305: 'function' : truncation from 'double' to 'float'
C:\047rls\reactos\modules\rosapps\applications\screensavers\cylfrac\cylfrac.c(137) : warning C4305: 'initializing' : truncation from 'double' to 'GLfloat'
partial pick of 0.4.15-dev-2951-g 5d8e834897
can be observed with MSVC 2010SP1 (16.0.40219.1) x86 target in dbg configuation:
[11438/11751] Building CXX object modules\rosapps\applications\net\roshttpd\CMakeFiles\roshttpd.dir\config.cpp.obj
C:\047rls\reactos\modules\rosapps\applications\net\roshttpd\include\httpd.h(70) : warning C4373: 'CHttpDaemon::OnAccept': virtual function overrides 'CServerSocket::OnAccept', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers
C:\047rls\reactos\modules\rosapps\applications\net\roshttpd\include\socket.h(132) : see declaration of 'CServerSocket::OnAccept'
[11441/11751] Building CXX object modules\rosapps\applications\net\roshttpd\CMakeFiles\roshttpd.dir\httpd.cpp.obj
C:\047rls\reactos\modules\rosapps\applications\net\roshttpd\include\httpd.h(70) : warning C4373: 'CHttpDaemon::OnAccept': virtual function overrides 'CServerSocket::OnAccept', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers
C:\047rls\reactos\modules\rosapps\applications\net\roshttpd\include\socket.h(132) : see declaration of 'CServerSocket::OnAccept'
[11442/11751] Building CXX object modules\rosapps\applications\net\roshttpd\CMakeFiles\roshttpd.dir\roshttpd.cpp.obj
C:\047rls\reactos\modules\rosapps\applications\net\roshttpd\include\httpd.h(70) : warning C4373: 'CHttpDaemon::OnAccept': virtual function overrides 'CServerSocket::OnAccept', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers
C:\047rls\reactos\modules\rosapps\applications\net\roshttpd\include\socket.h(132) : see declaration of 'CServerSocket::OnAccept'
partial pick of 0.4.15-dev-2951-g 5d8e834897
the warning can be observed with MSVC 2010SP1 (16.0.40219.1) x86 target in dbg configuation:
[11432/11751] Building CXX object modules\rosapps\applications\net\netreg\CMakeFiles\netreg.dir\netreg.cpp.obj
C:\047rls\reactos\modules\rosapps\applications\net\netreg\netreg.cpp(188) : warning C4065: switch statement contains 'default' but no 'case' labels
partial pick of 0.4.15-dev-2951-g 5d8e834897
can be observed with MSVC 2010SP1 (16.0.40219.1) x86 target in dbg configuation:
C:\047rls\reactos\drivers\bus\acpi\cmbatt\cmbatt.c(983) : warning C4146: unary minus operator applied to unsigned type, result still unsigned
partial pick of 0.4.13-dev-713-g 08c6d21e1f
Mutes too many to list them all here, but the motivation to pick that part was:
can be observed with MSVC 2010SP1 (16.0.40219.1) x86 target in dbg configuation:
C:\047rls\reactos\modules\rostests\winetests\rpcrt4\server.c(910) : warning C4305: 'function' : truncation from 'double' to 'float'
C:\047rls\reactos\modules\rostests\winetests\rpcrt4\server.c(910) : warning C4305: 'function' : truncation from 'double' to 'float'
Timo thought most likely that muting is okay here, to keep the diff to upstream low in the tests.
Partial pick from 0.4.14-dev-847-g 42d2d5ec9c
can be observed with MSVC 2010SP1 (16.0.40219.1) x86 target in dbg configuation:
c:\047rls\reactos\modules\rostests\apitests\ntdll\stackoverflow.c(57) : warning C4717: 'infinite_recursive' : recursive on all control paths, function will cause runtime stack overflow
Muting is okay here, because stack overflow is specifically what is aimed to be tested here.
Fix is a partial pick of 0.4.14-dev-847-g 42d2d5ec9c
No warnings left in module NTDLL_APITEST and no C4717 left in releases/0.4.7.
can be observed with MSVC 2010SP1 (16.0.40219.1) x86 target in dbg configuation:
C:\047rls\reactos\dll\win32\mswsock\mswhelper.c(264) : warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\047rls\reactos\dll\win32\mswsock\mswhelper.c(280) : warning C4146: unary minus operator applied to unsigned type, result still unsigned
C:\047rls\reactos\dll\win32\mswsock\mswhelper.c(326) : warning C4146: unary minus operator applied to unsigned type, result still unsigned
Fix is a partial pick of 0.4.10-dev-409-g 0f8439aa71
No warnings left in this module.
Fix the .code16 macro definition for MASM/ML.
Modify the .code16 macro so that the 16-bit code segment can get a
chance to be correctly merged with other (possibly 32-bit) code
segments, without keeping generating multiple .text segments with
different attributes and generating the corresponding LNK4078 warning.
This fixes the warning when compiling NTOSKRNL on MSVC2010SP1 x86 in dbg config:
"v86.S.obj : warning LNK4078: multiple '.text' sections found with different attributes (C0520040)".
And it even slightly shrinks the size of hal.dll, e.g. for releases/0.4.7 from 1.231.360 to 1.230.848bytes
fix picked from 0.4.12-dev-494-g 0ee02b2c4d
can be observed with MSVC 2010SP1 (16.0.40219.1)
This fixes 30 warnings of multiple kind, e.g.:
27 of the kind:
C:\047rls\reactos\dll\3rdparty\libtirpc\src\auth_sspi.c(107) : warning C4996: '_strdup': Deprecated POSIX name, Try _strdup instead!
and also:
C:\047rls\reactos\dll\3rdparty\libtirpc\src\svc_vc.c(315) : warning C4101: 'cleanfds' : unreferenced local variable
C:\047rls\reactos\dll\3rdparty\libtirpc\src\svc_vc.c(488) : warning C4101: 'pollfd' : unreferenced local variable
C:\047rls\reactos\dll\3rdparty\libtirpc\src\xdr_rec.c(424) : warning C4133: '=' : incompatible types - from 'char *' to 'int32_t *'
Muting makes sense for this *3rd party library*. Better than creating more diff within here by addressing them.
This leaves no warnings left within this lib.
Fix picked from:
0.4.12-dev-803-g 3d3377a5c0
The chance for us to get attacked is rather low, because
LIBTIRPC is used solely for the nfs service and
I pushed aggressively years ago to have that turned from
'Automatic' to 'Manual' already.
I doubt many used this service, that does not exist on real Windows at all.
Attacks may result in Denial-Of-Service.
For details check:
https://nvd.nist.gov/vuln/detail/CVE-2018-14622https://nvd.nist.gov/vuln/detail/CVE-2018-14621
Fixes picked from:
0.4.11-dev-93-g 000bbe074e CVE-2018-14622 CORE-15005
0.4.11-dev-887-g f5f3ff86ea CVE-2018-14621 CORE-15407
Continininininininininously improving ros by fixing glitches in msg408 and msg411. ;-)
fix is a partial (intentionally non-squashed) pick of 0.4.14-dev-1142-g 92aabb07fb (#2393)
(#2393) is fully covered now for the backport.
Chinese manually groomed similar to the
western '\n.'->'.\n' fixes (Chinese does not match our regular pattern matches).
fix is a partial (intentionally non-squashed) pick of 0.4.14-dev-1142-g 92aabb07fb (#2393)
Phew, these are the last ones for this branch!
Now reduced by the preceding commits to a manageable amount.
fix is a partial (intentionally non-squashed) pick of 0.4.14-dev-1142-g 92aabb07fb (#2393)
Yes, I do see the 'conti\n\n\n\n\n\n\nnue'-mess within dll/win32/rasdlg/lang/en-US.rc
Will be taken care of later.
fix is a partial (intentionally non-squashed) pick of 0.4.14-dev-1142-g 92aabb07fb (#2393)
Yes, I do see that we still have some '\n.' typos in some files, e.g.
base/applications/shutdown/it-IT.rc. I will take care of them later!
fix is a partial (intentionally non-squashed) pick of 0.4.14-dev-1142-g 92aabb07fb (#2393)
Yes, I double-checked the msi_en.rc, and we do only use the \t after the \n (without additional spaces).
It is a good harmonization therefore to reduce the indentation level here.
fix is a partial (intentionally non-squashed) pick of 0.4.14-dev-1037-g 554c41e4d7 (#2387)
I am aware that some of the touched lines do still contain other issues for the moment!
A *partial* backport of 0.4.14-dev-1506-g c82ba3485e , part of (#2603)
That menu item never had any effect up to now as it had no implementation in ros,
and it also does not exist on Windows at this location.
The desired effect can already be achieved by just hitting F5 or selecting "Refresh" from the same root-context menu.
I do port back only the removal of this commit for now, and not the added new functionality in the submenu "Arrange Icons By", to
allow translations for that to settle down a bit on master.
observed with MSVC2010SP1 16.0.40219.1 x86-target in dbg+rls-config several times:
sdk\lib\crt\string\wtoi64.c(28) : warning C4146: unary minus operator applied to unsigned type, result still unsigned
sdk\lib\crt\string\wtoi64.c(194) : warning C4146: unary minus operator applied to unsigned type, result still unsigned
the fix is a PARTIAL port of 0.4.15-dev-2951-g 5d8e834897
and while touching the file
fix another white-space-glitch.
in sum that brings us 100% in sync in this file to master 0.4.15-dev-3264-g570cedf.
The main motivation to port all that back is to get rid of Win32K-BSODs 0x50 like CORE-13907
that could be triggered by user-mode-applications.
Technical reason was CORE-14857 "RtlImageNtHeaderEx needs SEH" and issues with hooks+callbacks.
All other tickets mentioned in here were regressions that we experienced on the long
journey towards perfecting the fixes on master head, and those were not happening yet in the older builds,
so they are mentioned in here only to allow tracking where that code went into.
Thanks to Jim Tabor, Mark Jansen & Thomas Faber
By squashed backmerge of the following commits:
0.4.15-dev-3440-g a89844f740
0.4.15-dev-3430-g 9cff384c22
0.4.14-dev-1287-g 568b6d0558
0.4.14-dev-1255-g 177ae91bf6
0.4.14-dev-1241-g 915a5764a9
0.4.14-dev-1240-g d8add40e89
0.4.14-dev-1002-g feb7df42b4
JIRA-tickets: CORE-13907, CORE-16769, CORE-14857, CORE-17856, CORE-17857, partially CORE-13019.
We also had some more dupes of CORE-13907 in JIRA, but I linked all of them (transitively)
towards the initial report, and resolved them without setting a fixVer for them.
In more detail:
--------------
[USER32] Fix BSOD 0x50 in 'WineVDM + Castle Of Winds' CORE-17856 CORE-17857
CORE-17856 BSOD 0x50 when starting Castle of the Winds second time, with WineVDM
CORE-17857 BSOD 0x50 on shutdown after closing Castle of the Winds with WineVDM
0.4.15-dev-3430-g 9cff384c22
0.4.15-dev-3440-g a89844f740
--------------
[NTUSER] Fix Strings and Format to Hooks
Allocate heap instead of data segment to be used for callbacks on user side.
Move and correct initial hook call out setup. Use it in more than one hook call.
This fixes issues with strings out of alignment and use of kernel pointers.
See CORE-13907 (HXD-portable BSOD) and CORE-16769 (HXD-portable exception)
Small wow update.
cherry picked from commit 0.4.14-dev-1287-g 568b6d0558
--------------
[RTL] Introduce RtlpImageNtHeader,
which implements the required functionality.
ntdll and ntoskrnl now have a wrapper for this, with SEH.
This protects the function against malformed / bad images,
whilst still being able to use the code in freeldr et al.
Idea from Thomas.
CORE-14857
cherry picked from commit 0.4.14-dev-1255-g 177ae91bf6
--------------
[WIN32SS] Form Sanity to Hook Callbacks
Fix WH_CALLWNDPROC/RET data to user hook calls.
Helps with CORE-13907 "(HXD-portable BSOD)"
Fixes the logging of "(win32ss/user/ntuser/callback.c:748) err: Failure to make Callback! Status 0xc00000fd" within CORE-13019, but not the whole ticket.
cherry picked from commit 0.4.14-dev-1241-g 915a5764a9
--------------
[USER32] Fix null return.
See CORE-16769 "HxD 1.7.7.0 portable unhandled exception"
cherry picked from commit 0.4.14-dev-1240-g d8add40e89
--------------
[WIN32SS] Fix a typo in dbg print
cherry picked from commit 0.4.14-dev-1002-g feb7df42b4
Can be observed when building with MSVC2010SP1 x86-target in dbg config:
- "...\ebrowser.c(1188) : warning C4133: 'function' : incompatible types - from 'DWORD *' to 'EXPLORER_BROWSER_OPTIONS *'"
- "...\ebrowser.c(1198) : warning C4133: 'function' : incompatible types - from 'DWORD *' to 'EXPLORER_BROWSER_OPTIONS *'"
Cherry-pick 535f2f9e66
fix picked from:
0.4.10-dev-513-g 669d6b445b
I need this for the following commits to be able to fix more compiler warnings
without having to introduce additional diff for better code from newer branches, that
also uses this macro. The older the branch, the less of duplication we have for this
macro.
picked from 0.4.11-dev-258-g 82faa151e5
Observable in MSVC2010SP1 dbg config:
"...\vartype.c(3808) : warning C4028: formal parameter 2 different from declaration"
Minimal cherry-pick Alexandre Julliard
18f7ec3670
The fix was picked from 0.4.10-dev-512-g 2ad650469e
That can be observed in MSVC2010SP1 x86 dbg config:
- "...\htmlanchor.c(769) : warning C4028: formal parameter 2 different from declaration"
- "...\htmlarea.c(427) : warning C4028: formal parameter 2 different from declaration"
- "...\htmlform.c(757) : warning C4028: formal parameter 2 different from declaration"
- "...\htmlinput.c(1303) : warning C4028: formal parameter 2 different from declaration"
fixes picked from:
0.4.10-dev-620-g 990e7dfd1a (WineSync)
0.4.10-dev-603-g 2e7b73dc75 (htmlinput Temporary fix)
Observable in MSVC2010SP1 x86 dbg-config
"...\dialog.c(365) : error C4133: 'function' : incompatible types - from 'ENCODING *' to 'int *'"
CORE-7538
the fix is a squashed port of:
0.4.10-dev-286-g 6830ecb118 (#650)
0.4.10-dev-283-g 97df61edfa
0.4.10-dev-282-g 534a309edc (#648) got superseded by 2nd commit
