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)
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
Just adds a missing module without touching the rest, because releases/0.4.7
is not plagued by any frequent relocations at runtime.
The minor update will just fix the following warning at compile-time for GCC:
-- notifyhook has no base address
The list of addresses we used in 0.4.7 is still hand-groomed, and was not
generated by the script yet.
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%.
warnings can be observed with MSVC 2010SP1 (16.0.40219.1) x86 target in dbg configuration:
[10138/11748] Linking C shared library dll\win32\setupapi\setupapi.dll
Creating library dll\win32\setupapi\setupapi.lib and object dll\win32\setupapi\setupapi.exp
LINK : warning LNK4199: /DELAYLOAD:winspool.dll ignored; no imports found from winspool.dll
[10209/11748] Linking CXX shared library dll\win32\shell32\shell32.dll
Creating library dll\win32\shell32\shell32.lib and object dll\win32\shell32\shell32.exp
LINK : warning LNK4199: /DELAYLOAD:winspool.dll ignored; no imports found from winspool.dll
fix picked from: 0.4.8-dev-594-g b20280a0f9
aka: [CMAKE] Allow overriding the .dll extension for delay imports in MSVC builds.
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.
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 configuation:
C:\047rls\reactos\dll\win32\netapi32\obsolete.c(241) : warning C4028: formal parameter 3 different from declaration
C:\047rls\reactos\dll\win32\netapi32\obsolete.c(301) : warning C4028: formal parameter 4 different from declaration
C:\047rls\reactos\dll\win32\netapi32\obsolete.c(335) : warning C4028: formal parameter 3 different from declaration
C:\047rls\reactos\dll\win32\netapi32\obsolete.c(405) : warning C4028: formal parameter 3 different from declaration
Fix picked from 0.4.9-dev-215-g e6d7480287
No warnings left in module module netapi32.
And no C4028 left in releases/0.4.7 and releases/0.4.8.
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)
and building in debug configuration for x86 target:
[9209/11324] Building RC object dll\win32\browseui\CMakeFiles\browseui.dir\browseui.rc.res
C:\047rls\reactos\sdk\include\psdk\windef.h(121) : warning RC4005: 'DECLSPEC_IMPORT' : redefinition
fix picked from 0.4.8-dev-988-g b9f88d594d
aka. "[PSDK][XDK] Remove DECLSPEC_* from windef.h, protect against redefinition in winnt.h"
which was the proper fix after the initial attempt of 0.4.8-dev-981-g e2c6c3cfc7
This was the last of the kind RC4005 for the releases/0.4.7 branch.
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
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
- Fixes MSVC errors: "...\dll\win32\dbghelp\minidump.c(857) : error C4028: formal parameter 5 different from declaration", for parameters 5, 6 and 7.
- Fix spec file too.
CORE-7538
I could reproduce those warnings on MSVC2010SP1 x86.
Ftr Wine 7.0 uses the same spec for that func atm, see
https://fossies.org/linux/wine/dlls/dbghelp/dbghelp.spec (18 Jan 2022, 8523 Bytes)
fix picked from 0.4.10-dev-275-g 3766d836c7
This is a big backport, that brings us closer to releases/0.4.14/0.4.14-release-10-g1b0b852
The main motivation is to fix the regression:
CORE-6412 'FoxitReader4 starts directly instead of launching setup wizard'
which regressed by SVN r56438 == git e5491506f1
By porting back the following commits:
0.4.15-dev-2883-g 33c7c91b36 CORE-17351 CORE-16898 (#3797) Improve performance of Start-Run Dialog Box Options
0.4.14-dev-1016-g 4e721f780e CORE-12266 (#1854) [SHELL32] This fixes the ERROR_DDE_FAIL in the 'www.google.de' testcase
0.4.13-dev-790-g 0f16d44b66 CORE-6412 + CORE-12927
but in return we have to fix all the callers of ShellExecuteW() that relied on this ancient hack-code, and we do this by picking
0.4.13-dev-930-g cb77f1701f CORE-16299 [SHELL32][STOBJECT] ShellExecuteW() params part2
0.4.13-dev-860-g 944aba1fcc CORE-16299 [SHELL32] ShellExecuteW() params part1 (#1833)
0.4.12-dev-94-g 932a812c66 CORE-15434 [SHELL32] shlexec.cpp UNICODE_NULL Add backslash if path was like C: (#1152)
0.4.12-dev-49-g fad9f6677a CORE-15434 [SHELL32] dialogs.cpp (#1117) Addendum
0.4.12-dev-48-g c64d31e9b8 CORE-15434 [BROWSEUI] Add backslash for directory (#1121) C: C:\
0.4.12-dev-36-g 472787ffea CORE-15431 (#1117) Crash on %SYSTEMROOT%
0.4.12-dev-19-g 06d717e3bc CORE-15431 (#1111) Enable Environment Variables
0.4.10-dev-446-g db13b422b3 (#737) shlexec.cpp to avoid regression CORE-14886 "regsvr32 can no longer register dlls"
0.4.10-dev-419-g bfcbda227f (#665) Multiple parameters dialogs.cpp, shlexec.cpp, sdk/include/reactis/undocshell.h
0.4.10-dev-335-g e018ccea4b CORE-14469 (#681) [SHELL32] lpDirectory must have priority in ShellExecuteEx
0.4.10-dev-238-g c84f398306 CORE-14583 (#593) base/shell/explorer/traywnd.cpp
0.4.10-dev-106-g 222534a5a2 IDS_FILE_NOT_FOUND from that unrelated commit was reused to display errors of the RunDlg
0.4.8-dev-253-g 53edadb8c0 CORE-12882, CORE-13847 (#159) [BROWSEUI] SHExplorerParseCmdLine: Improve relative path handling
and a few whitespace-fixes in undocshell.h to bring the file 100% in sync to current 0.4.8
Add missing structs and handler in BCryptOpenAlgorithmProvider().
Fixes CORE-16741 and similar problems.
The modern internet is not waiting for ReactOS, needed to keep the RAPPS URLs working.
fix picked from:
0.4.15-dev-3603-g e0a47b7b5f [BCRYPT] Add BCRYPT_ECDSA_P256_ALGORITHM
To make this work, we need to sync CRYPT32 to WineStaging-3.3, picked that from:
0.4.9-dev-214-g a8b9a43ae8 [PSDK] Fix the build for msvc 2010. wincrypt.h
0.4.9-dev-208-g dedd08c38d [PSDK] Fix wide string literals in bcrypt.h. Should fix VC2010 build
0.4.9-dev-207-g a6265fc4b0 [BCRYPT] Improve stubs for functions needed by crypt32 aka fix build
0.4.9-dev-194-g a6e1034289 [CRYPT32] Sync with Wine Staging 3.3
0.4.9-dev-193-g e129995058 [PSDK] Update bcrypt.h and wincrypt.h
The motivation to upgrade this host-tool is to fix a compile-time warning:
[4890/10620] Generating boot/bootdata/...oot/bootdata/system, boot/bootdata/BCD
Binary hive maker
->RegDeleteKeyW(0x0xcab210, '') is UNIMPLEMENTED!
[145/10684] Generating boot/bootdata/BCD
Binary hive maker
Creating binary hive: /home/jhenze/Release_WorkDir/Repo/output-MinGW-i386/reactos/boot/bootdata/BCD
Thw warning was most likely introduced when we started using mkhive in the hosttools, and is triggered
by livecd.inf having a [DelReg] section.
Warning fixed by implementing RegDeleteKeyW().
It can not delete full trees yet, but we also don't need that for our mkhive-usage yet.
While touching it, do also fix some other minor glitches and leaks.
This is a PARTIAL backport of the 15 commits from 0.4.11-dev, all to mkhive from 2018-10-09 to 2018-10-20 by hbelusca.
The main motivation to switch to that newer driver is, that our old one
simply can not read all isos. Especially complex ones made trouble and were
only shown as empty in explorer.
It is still possible to build and use the old driver when needed, only thing
that needs to be done for that is to revert 0.4.8-dev-164-g ec6b3ecbe4
Porting back the state up to 0.4.8-release-100-g8f947b5 implies:
Fixing the following JIRA-IDs (or avoid introducing them):
CORE-18029 "Mute noisy DPRINT 'SectionObject has ImageSection'"
CORE-17405 "Fix a macro-copy-paste and shrink the binary size"
CORE-15659 "Unable to build the gcc Release version in Windows using RosBE 2.1.6 (module cdfs fails)"
CORE-14315 "CDFS_NEW assertion during first stage setup due to new CcPerformReadAhead"
CORE-14128 "Avast! Free Antivirus 7.0 hangs the system when trying to detect a newly created virus"
CORE-14067 "CDFS_NEW assertions and exceptions"
CORE-14003 "Shutting down LiveCD asserts since introduction of MS PL CDFS_NEW"
CORE-13184 "Restore ability to install from disk-image"
by picking the following commits:
0.4.8-release-100-g 8f947b5322 [NTOSKRNL] Mute noisy DPRINT 'SectionObject has ImageSection' CORE-18029
0.4.8-release-80-g eb1ea19588 [CDFS_NEW] == 0.4.15-dev-1456-g 889eab7 CORE-17405
0.4.8-release-62-g 8c07aad4a8 [CDFS_NEW/XDK] == 0.4.11-dev-39-g a2f9762 + 0.4.11-dev-40-g 6d7ec8c CORE-14067
0.4.8-release-3-g 5d976d04e8 [CDFS_NEW] == 0.4.12-dev-431-g bccad87f3c + 0.4.12-dev-432-g 3463b2db9f CORE-15659
0.4.8-RC-3-g 51f9494d48 [CDFS_NEW] superseded later by the proper fix 0.4.8-release-62-g 8c07aad4a8 CORE-14067
0.4.8-dev-1069-g a5e89014dc [CDFS_NEW] CORE-14315
0.4.8-dev-475-g a59d4674de [NTOSKRNL] io/iomgr/device.c (forgotten assert) CORE-14128
0.4.8-dev-221-g 9d67a24799 [CDFS_NEW]
0.4.8-dev-220-g 67a7e45e35 [CDFS_NEW/DOC]
0.4.8-dev-219-g 6a3bbf24e0 [CDFS_NEW]
0.4.8-dev-218-g ec26cde4a1 [CDFS_NEW]
0.4.8-dev-217-g bc2378a356 [CDFS_NEW]
0.4.8-dev-216-g 5429771b99 [CDFS_NEW]
0.4.8-dev-215-g fd34548263 [CDFS_NEW] Sync with MS-PL driver
0.4.8-dev-164-g ec6b3ecbe4 [FILESYSTEMS] switch from CDFS to CDFS_NEW in CMakeLists.txt
0.4.8-dev-160-g 2b217e4ecf [NTOSKRNL] Mute spam CcSetReadAheadGranularity()
0.4.8-dev-159-g 64cb138a67 [NTOSKRNL] Mute spam CcPurgeCacheSection()
0.4.8-dev-150-g f723d230a0 [CDFS_NEW]
0.4.8-dev-133-g faee3753ea [CDFS_NEW] CORE-14003
0.4.8-dev-132-g 1d777ffab5 [NTOSKRNL] iofunc.c CORE-14003
0.4.8-dev-131-g c3d5a3f2bd [NTOSKRNL] iofunc.c CORE-14003
0.4.8-dev-130-g 3b64f7f8fb [NTOSKRNL] ob/obref.c & co CORE-14003
0.4.8-dev-129-g 7eefe70294 [NTOSKRNL] io/iomgr.c & co CORE-14003
0.4.8-dev-127-g 5f255827d3 [CDFS_NEW]
0.4.8-dev-126-g 1bef48796e [NTOSKRNL] just a comment, superseded later
0.4.8-dev-125-g cbf0430b56 [CDFS_NEW]
0.4.8-dev-123-g f88fe43abd [NTOSKRNL] io/iomgr/device.c (forbidden DPRINT)
0.4.8-dev-122-g 6c73385625 [CDFS_NEW] CORE-13184
0.4.8-dev-97-g 94298313c0 [CDFS_NEW]
0.4.8-dev-95-g e88eeb21af [CDFS_NEW/NTOSKRNL] CcWaitForCurrentLazyWriterActivity() stub return Success
0.4.8-dev-94-g 03d5be6437 [CDFS_NEW]
0.4.8-dev-93-g fa1c60db50 [CDFS_NEW]
0.4.8-dev-92-g 8b2fd60829 [CDFS_NEW]
0.4.8-dev-91-g e4da7ecc50 [CDFS_NEW]
0.4.8-dev-90-g 7b19676e2b [CDFS_NEW]
0.4.8-dev-89-g 3d4b8783fd [CDFS_NEW]
0.4.8-dev-88-g 818025ecc8 [CDFS_NEW]
0.4.8-dev-87-g 2639dd6736 [CDFS_NEW]
0.4.8-dev-86-g 755bdb5d0b [CDFS_NEW]
0.4.8-dev-85-g 3cbcb1bade [CDFS_NEW]
and mute spam in opcode INSTEAD of picking:
0.4.8-dev-165-g 2284a457a3 [NTOSKRNL] oplock.c Fixup
0.4.8-dev-163-g d3d5853956 [NTOSKRNL] oplock.c Implement oplock-support
0.4.12-dev-232-g f488102c86 [CDFS] was also left out for now
I am aware, that the backport introduces white-space-glitches within CDFS_NEW.
I decided to live with them in favor of better sync to master and newer releases.
Although the new layout that I committed in the previous commit
was favored by community ratings votes 8:0,
some devs still preferred the old layout with the bigger logo
because they liked the easteregg. So this commit restores
that.
But it syncs to that features latest&greatest implementation
we have in 0.4.15-dev-1685-gd0c237a instead of reverting the
previous commit to not unnecessarily have many bugs with it
that were still affecting the older releases beforehand.
Aside from the general tabs dialogs layout this commit does
also fix some minor issues in the translations for the oldest
branches in pl-PL, jp-JA, zh-CN and zh-TW.
And it fixes an x64 issue in general.c for 0.4.7 and 0.4.8.
picked in squashed form from
0.4.8-dev-650-g 81eb3bbceb
0.4.9-dev-622-g c704cf5f87
I also ported that into all other release-branches >= 0.4.8 before.
The same MSVC-rls-fixed implementation.
Addendum to 0.4.7-release-38-g ec85d9c62b
CORE-12752 was already fixed,
but using the "Motorbike"-game from CORE_16707, I could trigger a new
conflict between user32.dll and hid.dll.
Therefore move 3 potential colliders away.
The regression was unhidden by MSI-winesync 1.5.10 almost 7years ago:
8939969e21 == SVN r57070
Finally we can fix it by adding MS enumerator extension to Jscript.
Many thanks to the patches author
Andreas Maier <staubim@quantentunnel.de>
JIRA-nick: andy-123
fix picked from commit 0.4.12-RC-18-g 9ebb42a4c0
It went afterward into master in slightly modified form as 0.4.13-dev-890-g 83dcae1
But I decided to take the older state from 0.4.12RC, so that I do not have to risk
touching releases/0.4.12 again to sync to "latest&greatest".
Due to the changed PROPF_* defines in jscript.h, I felt most safe by porting back also:
0.4.10-dev-188-g c6f49f5
0.4.10-dev-152-g 3f071cc
0.4.9-dev-248-g 8dba275
0.4.9-dev-120-g 004d830fe9 [INCLUDE/WINE] Import heap.h from Wine Staging 3.3
0.4.8-dev-722-g 3381ee4
This squashed commit ports back almost all improvements
we did to explorer during 0.4.8-dev.
Main motivation is:
-fixing tons of bugs painting the systray icons, e.g. (but not exclusively) CORE-11378
-and to fix a regression about clock margins CORE-14272
-and the clocks vertical text placement
-Win+E behavior CORE-14199
Here is a list of the commits I ported back:
[PSDK] shellapi.h
0.4.8-dev-1053-g 8b78b0ff98
0.4.8-dev-982-g a64c33e787
0.4.8-dev-970-g 9d2139b7d8
[SHELL32]/[REACTOS]/[EXPLORER]
0.4.8-dev-984-g 131678a025
0.4.8-dev-971-g 5ecabcce59
[EXPLORER]
0.4.8-dev-1065-g f1535c2d6e tiny part of CORE-14306
0.4.8-dev-1064-g abdde0b764
0.4.8-dev-1054-g 3003471e64
0.4.8-dev-974-g 04498f3eb5
0.4.8-dev-944-g f5d679aeb9 fixes CORE-14272 Clock Margins
0.4.8-dev-936-g 556c485c8b
0.4.8-dev-935-g d11e7af5f2
0.4.8-dev-934-g c109dc9f24
0.4.8-dev-928-g 22d1e1017f
0.4.8-dev-925-g c54c5ebb5f
0.4.8-dev-924-g 488477d10d
0.4.8-dev-923-g 85d7dd4f83
0.4.8-dev-922-g 5a1984c998
0.4.8-dev-921-g 6c073e9539
0.4.8-dev-920-g 455bce68b5
0.4.8-dev-908-g 7f35908ad2
0.4.8-dev-860-g 3d75cc0814
0.4.8-dev-853-g 5ec441a867
0.4.8-dev-852-g bc43733e48
0.4.8-dev-851-g bbca71c4a5 [EXPLORER]&[ROSCTRLS]
0.4.8-dev-789-g cb8cc0d098
0.4.8-dev-788-g be2bf9b8c5
0.4.8-dev-787-g 851e0ca5a8
0.4.8-dev-786-g 2abd068398
0.4.8-dev-785-g 8c91a00fcf
0.4.8-dev-784-g 6c9629bb72
0.4.8-dev-783-g d66c6890f7
0.4.8-dev-691-g 2c8ed37605
0.4.8-dev-690-g 74e58d938e
0.4.8-dev-669-g 4b6d929be1 fixes CORE-14199
0.4.8-dev-46-g 2ed535da8a
0.4.8-dev-21-g 82b12ef4cf
0.4.8-dev-20-g 4238f22396
For now I intentionally did leave out
0.4.8-dev-684-g 71e66c69c1
to not make explorer import oleaut32 SysAllocString()/SysFreeString().
I also did not update the translations rc files.
CORE-12752 Symptom "multiple programs refuse to start because
base address conflict between MSVCP71.dll
& our user32.dll (that can't be relocated by design)."
E.g:
-Photoshop CS2
-Avira Antivir 6.35.00.243 when selecting "Start update" from systray icon
It regressed by SVN r68838 == git
a9a2119c0c
The new base-address is manually crafted to same address that I used
for 0.4.9-RC-23-g
519cdd3c52
already. It is most likely not as effective in preventing
other relocations as the proper fix that was
created by a full recalculation of all dlls base addresses later in
0.4.10-dev-338-g
80bac79070
But it worked properly for me to solve CORE-12752 and today
I do fear I would have higher chances to unhide other
memory corruption bugs if I would do the proper thing.
So unless this would prove to cause any other issue, I will
stick with this minimal invasive approach for the older releases.
In ConWrite(), emit an \r when a \n is encountered but not already preceded by \r.
And, don't emit \r\n when an \r alone is encountered.
This fixes the problem of extra newlines appearing when redirecting
"more" output to a file.
It regressed somewhere in between SVN [r68849-r73441], most likely with some
commit that touched 'conutils' or 'more'.
fix picked from commit 0.4.11-dev-1-g
b277cbdf22
Thomas Faber thinks that it's a bit more
safe to just move "after .rsrc" instead of the proper "after .reloc".
A temporary tribute until ROSBE-154 will be fixed properly.
For now we use this just for NTOSKRNL, but not for drivers yet, see
MODULE TYPE sdk/cmake/gcc.cmake
As using also for drivers would immediately lead to BSODs like CORE-16183.
To allow installing DVDWritenow without BSOD,
we need the script at least for ntoskrnl!
The regression was introduced by SVN r55835 == git
6ebf8c2537
This patch (after .rsrc) was already committed into 0.4.15-dev-220-g
d28677795e
Due to infrastructure changes on 2018-02-17 (after initial 0.4.7rls)
we totally broke the rapps compatibility of all releases before 0.4.8
leaving rapps useless in those.
Therefore I decided to port back what is necessary to make rapps work
again also in this ancient release.
fixes CORE-14351 adapts to infrastructure changes
fixes CORE-14350 RAPPS Certificate pinning
fixes download from FTP
and merges many other improvements from GSOC 2017 back in time
The cFileName member of WIN32_FIND_DATA is an array of MAX_PATH(260). Using strcpy/wcscpy with the target buffer being smaller is potentially bad. Corresponds to CID 1401198 and 1401195.
- SIZE_T -> ULONG in KsecGatherEntropyData
- Add missing ZwQueryInformationProcess() prototype for x64 build of btrfs
- Fix ml.exe path for VS 2017 Community Edition
- Add missing Handle32ToHandle to basetsd.h
