by hand!
Motivation is to fix relocations during 2nd/3rd stage of the kind:
(C:\047rls\reactos\dll\ntdll\ldr\ldrutils.c:1311) LDR: LdrpMapDll Relocating Image Name C:\ReactOS\System32\spool\PRTPROCS\W32X86\winprint.dll (10000000-1000A000 -> 003D0000)
(C:\047rls\reactos\dll\ntdll\ldr\ldrutils.c:1350) Overlapping DLL: C:\ReactOS\system32\localmon.dll
(C:\047rls\reactos\dll\ntdll\ldr\ldrutils.c:1311) LDR: LdrpMapDll Relocating Image Name beepmidi.dll (7A140000-7A147000 -> 00BF0000)
(C:\047rls\reactos\dll\ntdll\ldr\ldrutils.c:1350) Overlapping DLL: C:\ReactOS\System32\browseui.dll
Motivation is to fix the following warnings at configure-time for *MSVC x86 dbg* :
-- shsvcs has no base address
-- libtirpc has no base address
-- acgenral has no base address
-- nfs41_np has no base address
-- shellbtrfs has no base address
-- ntdll_vista has no base address
-- redirtest1 has no base address
-- redirtest2 has no base address
-- localspl_apitest.dll has no base address
-- localmon has no base address
-- winprint has no base address
This fixes CORE-14831 for *MSVC dbg* for this release-branch at least.
Meaning: It hides the effect, without fixing the cause.
It is not a sustainable solution for master yet.
We'd need to improve the python script for that.
I tested afterwards the bootup of a build configured via:
-DENABLE_ROSTESTS=1 -DENABLE_ROSAPPS=1
and built with:
MSVC 2010SP1 (16.0.40219.1) x86 target in dbg configuration
and verified that we had no relocation happening until 3rd stage desktop VBox4.3.12.
MSVC 2010SP1 (16.0.40219.1) x86 target in *rls* configuration was not
tested yet, as that up to now did never reach the desktop yet for unrelated reasons.
I will not upload an iso to sourceforge after this commit,
because it will not have any impact for our primary GCC 4.7.2 toolchain.
This updates the GCC baseaddress_msvc.cmake
to the state we do use in releases/0.4.10 to date
leaving out the components that do not exist in releases/0.4.7 yet,
And additionally preserves the addresses for the 3 fusion dlls,
which our script currently cannot handle yet.
Therefore manually respecting the differences for:
set(baseaddress_localspl_apitest.dll
set(baseaddress_fusion
set(baseaddress_fusion_1_1
set(baseaddress_fusion_2_0
*partial* pick of 0.4.9-dev-719-g b3fb8555bf
I picked only the STATIC controls registration and implementation to
fix CORE-11195 'A drawing glitch in hundreds of NSIS installers'
----------
Above commit requires me also to port back the following 2 commits
0.4.15-dev-534-g 887764e607 (fix) Mouse Pointer CORE-17062 (#2829)
0.4.15-dev-2705-g a3cadf630a (nitpick)
to prevent a regression with the mouse pointers preview in the mouse applet CORE-17062.
----------
0.4.9-dev-32-g b02d78586c CORE-14346 'Auslogics Disk Defrag Free v8.0.4.0 installer fails to start'
----------
partially pick 0.4.8-dev-505-g 435b0b19d2 Install comctl32 v6 and its manifest in first stage
As this fixes a lot of log spam during 2nd stage of the kind:
(../sdk/lib/rtl/actctx.c:3072) Could not find dependent assembly Microsoft.Windows.Common-Controls (6.0.0.0)
err:(../dll/win32/comctl32/commctrl.c:206) CreateActCtxW failed! bV6=0
...
I took that part which copies the manifests during 1st stage already. That allows to strip some former rosdiffs from comctl32
that we introduced for showing the theme selection dialog. And harmonizes the manifests filenames to the newer branches.
I left out the part which triplicates comctl32.dll 1x system32 and 2x within WinSXS.
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:
[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)
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.
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.
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
- 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
