Windows Side by Side is a complex beast and a source of much confusion in the administration of the Windows system. Today's post provides a basis in WinSxS and goes into considerable detail about how it works with Citrix App streaming.
History
DLL hell is the root of all evil and the Microsoft C runtime is the root of DLL Hell. If someone is short, it is "2" statements describing the underworld and I just started! For a detailed discussion of DLL hell, please read the earlier post, then head back
Okay. - Microsoft compiler Group implements many versions of VC5 and VC6 runtimes, which all have the same name. While these should be stored with individual application programs, it was not the standard procedure in that day, a time of really rare RAM. Standard procedure calls for applications to use the same runtime single DLL and install and replace * THE * C runtime with newer and better by their own installation.
Unfortunately, this upgrade could and did break existing applications, which depended on the behavior of the previous version of this version of the runtime. Maybe dependent defective execution behavior earlier but still dependent. Install an application, obtain a fixed execution, break free application report which has worked for years. The DLL Hell was born.
WinSxS
I really feel for the Windows kernel team. I guess it was something like that. The compiler team invented this bastion of DLL Hell, then the core team got asked to "repair". I read other posts on the Internet says that WinSxS first appearance on the stage with Windows Me. I really liked this version of Win 9x. important point is that this attempt to fix DLL Hell has been around a long time and was present in almost all versions of Windows NT from Windows 00 and higher.
More recently, I understand that Microsoft started to give up and return to WinSxS straight DLL loads. IMHO, a great idea.
What should we do
Consider two applications at once MSVCRTD.DLL install the Runtime C compiler for Visual C 6. THEORY each installation of the application program inspects the data from the version of the execution file because it is in the Windows System32 directory. If they are installing a "recent" one, they replace the existing MSVCRTD.DLL with the most recent. Recall that this crater often the first application.
"new" is defined based on the data file version of the runtime DLL. Here's an example:
> filever msvcrtd.dll
msvcrtd.dll: Microsoft (R) C Runtime Library, the 6.00.8168.0 version of
An important part is the "8168". In theory, this is the eight thousand 168th build the C runtime version 6.00. In fact, they probably started counting in 8000, but it did not matter. The key element is that the number is just "bigger". Bigger number is equal to "newer" version of the runtime.
With WinSxS when installers "replace" implementation, rather than replacing, what happens is that the subdirectory is created for the specific version of the runtime that the program install "installs". Now both "old" and msvcrtd.dll exist "new" versions of the execution-file and with a little help from the charger can be charged separately.
By running the application, when the application asks the runtime to be loaded, WinSxS used to tell the system to load a specific version of the runtime version 6
BTW - .. the problems of DLL hell are wider than the mere execution VC
How do you tell the system you need this help?
Manifest files
Manifest files are files on the disc, just simple text files that are found to have XML data in and exist on disk with .manifest extension. By convention a foo.exe named executable program file can have a cover that gives foo.exe.manifest charger instructions on which to load DLLs to this exe. Side note is that manifests can do much more.
coolest part of being .manifest files uploads text files is that it could be added to existing programs to make them work in a world in conflict, all without updating the application.
manifests can also be integrated into the EXE file itself, as a resource -. as an icon
modern versions of Visual Studio make this automatic - Product EXE file includes clear data entered into the EXE file to tell the charger, I have * CE * runtime version and gives me not imitators! With abundant RAM in modern worlds, this statement specific versions of C runtime has become the standard procedure and modern versions of Visual Studio include such data as a standard procedure in the production of applications. I'll add that it is often included, even if no help is really needed.
View function
Put your hat on Windows Loader. You load a memory .EXE and are ready to create a thread to run it. When did you observe manifest data. Because you are the one IMPLEMENTING WinSxS, it is your duty to go find the correct version of the runtime (really any DLL) and put it in memory to be part of the application.
You do that as the charger and when you actually get to find and load any DLLs, you finally release the application to run the state.
This all works swell. Until you add Application Virtualization.
Application Virtualization and WinSxS
In the application streaming, executable is run by ... the application virtualization system link. For Citrix App Streaming, the Streaming Client finally made a call to CreateProcess with the start this flag "hanging" specified. Here, the application is brought completely into memory, but it does not start again. The start is delayed until the application virtualization system has the ability to install "hooks" to hide the vision applications in the machine and put in place the glass insulating layers. Once these are in place, the application state is changed to runnable and ... it is out of the race for native execution speeds close.
If you Windows loader, the application that we asked you to start is something like
C :. Program Files Citrix RadeCache GUID_V Device C Program Files Bar foo.exe
Note that this is the long way; the system loader is not confused by isolation and no isolation yet. Only after the executable is "started" to the hooks in place to hide the vision of each. When the application asks: "Where did I come", the insulation system converts the very long name to the short version and the application continues pleased If the runtime application loads a DLL or accesses. a file from the virtual space, the insulation system converts to the long path and sends it on its way.
observe that without isolation in place, all fixups DLL needed to bring EXE into memory must be resolvable and resolvable without "cache fill". to do this, the isolation system inspects the PE header in the .EXE and the forces of the elements in the runtime cache that will soon needed by the Windows loader when the system is soon invited to run the application. ... This is standard procedure and is done for each application launch the application streaming.
the WinSxS activity is a hotspot
application of recent client said that with full cache, the application works. With empty cache, the application refuses to run. What happened? I have to deduce a little because I have not torn apart the application, but what I expect is obvious happened WinSxS data. Customer was able to wrest this part to identify a single DLL that was the culprit. In the footsteps of Filemon, see a reference to the DLL with "file not found" that the open file RC, the launch of the application unravels
Update: .. Hypothesis confirmed later
When running the application .exe.manifest, or equivalent resource board said the WinSxS charger to provide a specific version of the DLL, from a place outside the pre-populated files. Because this DLL part of the isolated application and the cache was empty, the DLL was not found and the shipper had no choice but to abandon.
Since the charger is not isolated, shippers attempt to load the DLL dependent WinSxS failed - and he missed load the application. Solution, place in single DLL RadeCache via pre-launch script and run the application, and works reliably.
Why is it not more widespread?
Because the main venue for WinSxS solves the problem invented MS C DLL hell. Here, application streaming "manages" and supports the execution of the application depends on WinSxS ensuring all SxS dependent DLLs are in place before the application is run.
We do this by installing locally installation, common runtime DLL depending on the installation of the streaming client. In a way, this is cheating, but the insulation itself is the system DLL anyway, it works to not spilled milk because we have to install runtimes anyway. Furthermore, the runtime installation is often a "nothing" because other components have already been installed, but we need to go through the motions
BTW -. It is for this reason that installs App streaming from an .EXE instead of an MSI. We install from an MSI, but first, the site EXE installer Visual Studio 05 and 08 runtimes on the machine where they will be seen by the system stream itself, and applications we run. This makes matters WinSxS largely disappear.
It becomes easier
For a time, we had to include more than one version of the runtime 05. Fortunately, Microsoft is now promoting the idea to have multiple versions of the C runtime installed on the same system is a bad idea. In this, they say that WinSxS is a bad idea - and - I agree. Much better to fix it by building your own version of the C runtime if you need, but if you can run with the runtime to use the most recent. With decades now, the implementation problems of versioning that were the root of DLL hell are largely ironed out.
The official story I get is that if a C runtime has a security problem, and if this vulnerability is fixed, then eliminating WinSxS really help move applications to a more secure version of the engine execution of the compiler. Do make the system more secure? It is debatable because you do not really know if the specific application calls the API was "fixed", but you can easily argue the opposite. The move to a safer implementation SHOULD make things safer and quite probably will not worsen. A "cost" to do so is a risk that the DLL hell resurrected.
In "Modern Times" today, the horrible history of the VC5 and VC6 runtimes are largely behind us. The compromise says that the runtime is quite stable and we now have problems with the solution (WinSxS) causing headaches when left alone, none would exist.
WinSxS is changing so it ignores requests to apply for a specific C runtime and instead of loading a newer version that is compatible with the old version. Winner. Things change.
I hereby compliments Microsoft teams who have inherited this complicated puzzle and did a pretty admirable job in retiring the old problems without inventing new too. While undoubtedly a safer get rid of old runtime compiler that have known issues System.
I also think receivable notes to the effect of "close, but it really works that way." I look forward to reading ...
Joe North
0 Komentar