by hand!
Motivation is to fix relocations during 2nd stage of the kind:
(C:\049rls\reactos\dll\ntdll\ldr\ldrutils.c:1311) LDR: LdrpMapDll Relocating Image Name C:\ReactOS\System32\browseui.dll (7A0B0000-7A17D000 -> 00C40000)
(C:\049rls\reactos\dll\ntdll\ldr\ldrutils.c:1350) Overlapping DLL: C:\ReactOS\System32\beepmidi.dll
(C:\049rls\reactos\dll\ntdll\ldr\ldrutils.c:1311) LDR: LdrpMapDll Relocating Image Name stdole32.tlb (10000000-10004000 -> 00D10000)
(C:\049rls\reactos\dll\ntdll\ldr\ldrutils.c:1350) Overlapping DLL: C:\ReactOS\System32\stdole2.tlb
Motivation is to fix the following warnings at configure-time for *MSVC x86 dbg* :
-- shsvcs has no base address
-- dxtn 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
-- zipfldr has no base address
-- ntdll_vista has no base address
-- verifier has no base address
-- redirtest1 has no base address
-- redirtest2 has no base address
-- localspl_apitest.dll has no base address
-- custom has no base address
-- vfd 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 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.9 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
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
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)
Addendum to 0.4.9-RC-23-g 519cdd3c52
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.
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
Giving this risky fix a chance.
It reliably prevents the conflict between MSVCP71.dll
& our user32.dll (that can't be relocated by design).
But we'll have to check very carefully that this
patch does not break anything else.
Instead of loading systemcompatible.manifest as the implicit activation context, load forwardcompatible.manifest
Add a new assembly containing all apisets called ReactOS.Apisets and make it a dependency to forwardcompatible.manifest
This is no official system DLL and WineD3D is its only user. But latest WineD3D prefers the libtxc_dxtn codebase instead of the alternative library we used.
This is also what Mesa uses and Fedora ships now that the patents have expired, so we should stick to the same.
I'm importing the libtxc_dxtn-1.0.1 codebase from https://people.freedesktop.org/~cbrill/libtxc_dxtn/
It compiles warning-free in our tree without modifying a single line!
I'm merging this Pull Request based on the positive response in CORE-12759.
I lack a proper test case myself, but my version at least shouldn't make things worse. In my opinion, the previous one was broken anyway due to using stdcall imports when WineD3D called cdecl ones.
This also removes the NSWPAT option from our buildsystem as dxtn was its latest user.
I use a (not yet used) dir-id value of "80" for this purpose (the value
"8" being already used for /bin/testdata/ and of course values from 9 up
to 50+ are also already used... >_>).
- 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
