Page MenuHome

Windows: Separate out the ms CRT into a subfolder
Needs ReviewPublic

Authored by LazyDodo (LazyDodo) on Fri, Oct 25, 11:05 PM.

Details

Summary

By separating out the CRT into a private sxs assembly we
can clean up the massive amount of dll files in the blender
folder which people informally have complained about.

Diff Detail

Repository
rB Blender
Branch
tmp_crt_bundle2 (branched from master)
Build Status
Buildable 5462
Build 5462: arc lint + arc unit

Event Timeline

That's great.

build_files/cmake/platform/platform_win32_bundle_crt.cmake
7

Style:

# Install the CRT to the Blender.CRT sub folder.
8

Can we name this folder just crt instead of Blender.CRT?

We don't use uppercase for other folder names, and it's not clear to me why "Blender" needs to be in the name any more than other folders we have.

Same comment for naming of Blender.CRT.MANIFEST.

8

Code style: lower case install(.

10–13

Space after #

release/windows/icons/blender.exe.manifest
10–43

Is this compatibility thing related to this change?

My understanding is that what this will do is that in future Windows versions, it will run Blender with Windows 10 compatibility. Which seems like a good thing since we don't know what might change,

build_files/cmake/platform/platform_win32_bundle_crt.cmake
8

We could name it anything we'd like (afaik), but we'd have to be careful there. the way sxs works is that the global sxs cache will be searched first, if that comes up empty the app folder will be searched for private assemblies. Now if we choose a too generic name (like crt) and some other app installs a public assembly with that same name, the results may be 'undesirable'

Assembly naming tends to follow the <company>.<component> scheme

I Started with Blender.CRT (for the CRT) and Blender.Shared (for the ffmpeg/sdl/openal/python dlls) but the python naming change between debug/release threw a wrench in doing this quickly and I had to leave out Blender.Shared for a future diff.

release/windows/icons/blender.exe.manifest
10–43

No, This could be separated out (together with the changes to actually use the manifest we have on disk, which is currently not the case) if we do not declare any of these guids the app will run with the vista profile.

The changes by declaring these guids currently seem limited to VerifyVersionInfo (and friends like GetVersion) stops telling you we're running on vista and some RPC related changes where they fixed a deadlock that somehow apps were depending on, so they forced everybody opt in to the non deadlock behavior by declaring these guids :)

  • fix comment feedback.
LazyDodo (LazyDodo) planned changes to this revision.Sat, Oct 26, 11:54 PM

split in to 2 parts.

LazyDodo (LazyDodo) marked 3 inline comments as done.Sat, Oct 26, 11:55 PM
  • Separate out the Manifest changes into D6136

urgh, i don't know how to deal with patches depending on each other with arc it has combined both of them in this one, lets put this on hold until D6136 has landed.