WinSxS, functional under 2k ?

[Guest Steph]

Using windows 2000 Pro SP4. After a reinstall and some cleaning, I

noticed I "caught" a winsxs folder, which some research shows to be for

use with Windows XP and later side-by-side DLL storage.

 

Was this function somehow retro-fit to Windows 2000 by a Windows update

(which I doubt... but safer to ask the experts) ?

 

Am I free to simply delete the contents of the winsxs folder ?

 

Regards

 

 

--

Steph (no working email)

[Guest John John (MVP)]

Re: WinSxS, functional under 2k ?

 

It was probably put there when you installed one of your applications.

The applications won't use the folder unless you upgrade the Windows

2000 installation to a version that supports SxS. The files in the SxS

folder are also present in the System32 folder, Windows 2000 does not

use the files in the SxS floder, it uses the files in the System32

folder. You can rename the folder or move it to a temporary location

and if you want and if you see no problems after a week or so you can

remove the folder.

 

 

On versions of Windows that do not support deployment of shared

side-by-side assemblies, such as Windows 98 and Windows 2000 Server, the

Visual C++ libraries are installed in the System32 folder and WinSxS

folder under the operating system root directory. This setup enables

running Visual C++ applications on these operating system versions

because they do not support manifest-based binding of applications to

dependent DLLs. On these operating systems, when an application is

loaded, the corresponding manifest file is ignored and the operating

systems searches for dependent DLLs using paths set in the current

running environment. However, on upgrading the operating system to a

version that support manifest-based binding, such as Windows XP, Windows

Server 2003, or Windows Vista, applications built with manifests start

using the DLLs installed in the WinSxS folder.

 

[end quote]

 

http://msdn.microsoft.com/en-us/library/ms235624(VS.80).aspx

 

 

John

 

Steph wrote:

> Using windows 2000 Pro SP4. After a reinstall and some cleaning, I

> noticed I "caught" a winsxs folder, which some research shows to be for

> use with Windows XP and later side-by-side DLL storage.

>

> Was this function somehow retro-fit to Windows 2000 by a Windows update

> (which I doubt... but safer to ask the experts) ?

>

> Am I free to simply delete the contents of the winsxs folder ?

>

> Regards

>

>

[Guest Steph]

Re: WinSxS, functional under 2k ?

 

"John John" (MVP) wrote :

> ... You can rename the folder

> or move it to a temporary location and if you want and if you see

> no problems after a week or so you can remove the folder.

 

 

OK, done, and will watch periodically for this folder to point its ugly

head again. Thanks !

 

 

--

Steph (no valid email)

[Guest Steph]

Re: WinSxS, functional under 2k ?

 

"John John" (MVP) wrote :

> ... You can rename the folder

> or move it to a temporary location and if you want and if you see

> no problems after a week or so you can remove the folder.

 

 

OK, done, and will watch periodically for this folder to point its ugly

head again. Thanks !

 

 

--

Steph (no valid email)

[Guest John John (MVP)]

Re: WinSxS, functional under 2k ?

 

Steph wrote:

> "John John" (MVP) wrote :

>

>

>>... You can rename the folder

>>or move it to a temporary location and if you want and if you see

>>no problems after a week or so you can remove the folder.

>

>

>

> OK, done, and will watch periodically for this folder to point its ugly

> head again. Thanks !

 

You're welcome.

 

John

[Guest someone watching]

Re: WinSxS, functional under 2k ?

 

Steph, I know in XP if MS .NET framework is installed and you change the

WinSxS name, delete it etc. any time .NET goes to start it will throw an

error message and fail to start. I do not have .NET installed in W2K so

don't know if the same holds true for that OS but would imaging so!

 

In other words, if you have programs dependant on .NET, changing the

WinSxS folder may cause it to fail.

___

"Steph" <steph@email.invalid> wrote in message

news:XnF9AA5D055BBFAAbzi7h1r@207.46.248.16...

> Using windows 2000 Pro SP4. After a reinstall and some cleaning, I

> noticed I "caught" a winsxs folder, which some research shows to be

> for

> use with Windows XP and later side-by-side DLL storage.

>

> Was this function somehow retro-fit to Windows 2000 by a Windows

> update

> (which I doubt... but safer to ask the experts) ?

>

> Am I free to simply delete the contents of the winsxs folder ?

>

> Regards

>

>

> --

> Steph (no working email)

[Guest John John (MVP)]

Re: WinSxS, functional under 2k ?

 

someone watching wrote:

> Steph, I know in XP if MS .NET framework is installed and you change the

> WinSxS name, delete it etc. any time .NET goes to start it will throw an

> error message and fail to start. I do not have .NET installed in W2K so

> don't know if the same holds true for that OS but would imaging so!

 

No, not at all. The new Side-by-Side Assemblies require XP or better to

work, Windows 2000 does not support this. Deployments on Windows 2000

only include this folder from upgrade purposes.

 

> In other words, if you have programs dependant on .NET, changing the

> WinSxS folder may cause it to fail.

 

Not at all. Windows 2000 does not load *any* files from the

Side-by-Side assembly cache, Windows 2000 does not recognize WinSxS.

Deployments on Windows 2000 require that the files be placed in the

%systemroot%\system32 folder or in the program's folder.

 

John

[Guest someone watching]

Re: WinSxS, functional under 2k ?

 

Hi John

 

Thanks for the useful information. Curious, what exactly is the purpose

of the WinSxS (side by side?) implementation for? Is it redundancy? I

noticed numerous DLL's in there are also in system32 (or elsewhere) but

are sometimes even different versions!

 

I found (in XP) .NET didn't work after deleting some DLL's in WinSxS

even though they were in system32. A registry check showed pointers for

those specific DLL's to WinSxS... (and these were common shared DLL's)

 

Well everything is restored once again but beets me why yet another

directory with seemingly duplicated files!

__

"John John (MVP)" <audetweld@nbnet.nb.ca> wrote in message

news:#mowc$QxIHA.3384@TK2MSFTNGP03.phx.gbl...

> someone watching wrote:

> > Steph, I know in XP if MS .NET framework is installed and you change

the

> > WinSxS name, delete it etc. any time .NET goes to start it will

throw an

> > error message and fail to start. I do not have .NET installed in W2K

so

> > don't know if the same holds true for that OS but would imaging so!

>

> No, not at all. The new Side-by-Side Assemblies require XP or better

to

> work, Windows 2000 does not support this. Deployments on Windows 2000

> only include this folder from upgrade purposes.

>

>

> > In other words, if you have programs dependant on .NET, changing the

> > WinSxS folder may cause it to fail.

>

> Not at all. Windows 2000 does not load *any* files from the

> Side-by-Side assembly cache, Windows 2000 does not recognize WinSxS.

> Deployments on Windows 2000 require that the files be placed in the

> %systemroot%\system32 folder or in the program's folder.

>

> John

[Guest John John (MVP)]

Re: WinSxS, functional under 2k ?

 

Do you recall the term "DLL Hell"? The new(er) Side-by-Side Assembly

technology was introduced with Windows XP to help reduce or eliminate

DLL Hell. In short, Side-by-Side Assemblies permit the use of different

versions of the same shared system DLLs.

 

If you recall earlier Windows versions, like Windows 95, when you

installed an application you were (usually) warned if the installer

tried to replace a DLL from the system folder with an older version and

you were asked if you wanted to accept the change. Those with enough

Windows experience knew of the consequences of replacing DLLs in the

system folder with older ones, those who didn't have enough experience

quickly learned of the consequences of replacing DLLs with older versions!

 

With private DLLs there are few or no problems with DLL versioning as

private DLLs are placed in the program's folder. If you have different

versions or releases of the same program simply installing the different

versioned programs in different folder eliminates private DLL version

conflicts. Until Windows XP it wasn't so easy to use different versions

of shared system DLLs, that is what the new Side-by-Side assemblies

attempts to resolve.

 

This business of applications replacing system DLLs wily-nilly and the

DLL Hell that ensued was somewhat fixed with the Windows File Protection

feature (WFP) introduced with Windows 2000 but the shared DLL versioning

problem was not really fixed or properly addressed. Considering WFP and

the fact that WinSxS is a protected folder I am somewhat surprised that

you could "delete" this folder or manually delete/replace files in the

folder, on Windows XP and later WFP does not easily permit this.

 

 

Wikipedia's concise explanation of SxS is one of the better one:

 

"A common issue in previous versions of Windows was that users

frequently suffered from DLL hell, where more than one version of the

same Dynamically Linked Library (DLL) was installed on the computer. As

software relies on DLLs, using the wrong version could result in

non-functional applications, or worse. Windows XP solved this problem by

introducing side-by-side assemblies. The technology keeps multiple

versions of a DLL in the WinSxS folder and runs them on demand to the

appropriate application keeping applications isolated from each other

and not using common dependencies."

 

http://en.wikipedia.org/wiki/Features_new_to_Windows_XP#Application_isolation_.26_side-by-side_assemblies

 

 

The rest of this post consists of excerpts and explanations from

Microsoft articles:

 

 

Side-by-Side Sharing

 

The workings of the new (XP) UI rely on a side-by-side sharing

requirements structure. As a solution for versioning problems and DLL

Hell, Microsoft strongly suggests that applications adopt a side-by-side

versioning strategy. As seen in the implementation of ComCtl version 6,

side-by-side components are the future of Windows development. This

section gives you an overview about what's new for side-by-side sharing

for Windows XP. For an in-depth look into this topic, see How To Build

and Service Isolated Applications and Side-by-Side Assemblies for

Windows XP. For background on side-by-side component sharing issues and

DLL redirection, see Implementing Side-by-Side Component Sharing in

Applications (Expanded).

 

With side-by-side components, multiple versions of a component are

installed simultaneously. An application is bound to the version of the

component with which it was designed and tested.

 

With Windows XP, there's an infrastructure to support assemblies and

isolated applications (both COM+ and Win32). A code change should not be

required to get at side-by-side assemblies from Win32 applications.

Applications can use the latest system assemblies without global impact.

 

In short, isolated applications are valuable because they are more

reliable. They are built and shipped with all needed components and are

not affected by changes that other applications make. Isolated

applications use a manifest, which is an XML file containing information

that self-describes an assembly or an application. All binding and

activation metadata, such as COM classes, interfaces, and type

libraries, is now stored in the manifest, rather than the registry.

There are two types of manifest files: applications manifests, which

describe isolated applications, and assembly manifests, which describe

individual assemblies.

 

An isolated application may use side-by-side assemblies. Assemblies are

the fundamental units of naming, binding, versioning, deployment, and

configuration. They come in two varieties, shared and private. A shared

assembly is available for use by multiple applications on the computer,

installed in the WinSxS folder in the Windows directory. A private

assembly is only visible to that application and is deployed within the

directory structure of the application.

 

There's another benefit for application developers in using side-by-side

sharing; your schedule can be much clearer. Your development schedules

are not affected by the release schedules of the components you use.

 

[end quote]

 

http://msdn.microsoft.com/en-us/library/ms997638.aspx

 

 

Windows 2000 doesn't understand diddly squat of these new Side-by-Side

Assemblies, here are more passages from Microsoft articles:

 

"If you install your application on a computer that is running Microsoft

Windows 2000 or earlier versions of Windows, do not ship the

side-by-side assembly in your application folder to those operating

systems. Instead, the side-by side assemblies should be used from the

system folder. If you install a shared component to the system folder as

part of your setup, make sure that you are not downgrading the version

if one is previously present."

 

http://msdn.microsoft.com/en-us/library/ms997620.aspx

 

and:

 

"On versions of Windows that do not support deployment of shared

side-by-side assemblies, such as Windows 98 and Windows 2000 Server, the

Visual C++ libraries are installed in the System32 folder and WinSxS

folder under the operating system root directory. This setup enables

running Visual C++ applications on these operating system versions

because they do not support manifest-based binding of applications to

dependent DLLs. On these operating systems, when an application is

loaded, the corresponding manifest file is ignored and the operating

systems searches for dependent DLLs using paths set in the current

running environment. However, on upgrading the operating system to a

version that support manifest-based binding, such as Windows XP, Windows

Server 2003, or Windows Vista, applications built with manifests start

using the DLLs installed in the WinSxS folder."

 

http://msdn.microsoft.com/en-us/library/ms235624(VS.80).aspx

 

John

 

someone watching wrote:

> Hi John

>

> Thanks for the useful information. Curious, what exactly is the purpose

> of the WinSxS (side by side?) implementation for? Is it redundancy? I

> noticed numerous DLL's in there are also in system32 (or elsewhere) but

> are sometimes even different versions!

>

> I found (in XP) .NET didn't work after deleting some DLL's in WinSxS

> even though they were in system32. A registry check showed pointers for

> those specific DLL's to WinSxS... (and these were common shared DLL's)

>

> Well everything is restored once again but beets me why yet another

> directory with seemingly duplicated files!

> __

> "John John (MVP)" <audetweld@nbnet.nb.ca> wrote in message

> news:#mowc$QxIHA.3384@TK2MSFTNGP03.phx.gbl...

>

>>someone watching wrote:

>>

>>>Steph, I know in XP if MS .NET framework is installed and you change

>

> the

>

>>>WinSxS name, delete it etc. any time .NET goes to start it will

>

> throw an

>

>>>error message and fail to start. I do not have .NET installed in W2K

>

> so

>

>>>don't know if the same holds true for that OS but would imaging so!

>>

>>No, not at all. The new Side-by-Side Assemblies require XP or better

>

> to

>

>>work, Windows 2000 does not support this. Deployments on Windows 2000

>>only include this folder from upgrade purposes.

>>

>>

>>

>>>In other words, if you have programs dependant on .NET, changing the

>>>WinSxS folder may cause it to fail.

>>

>>Not at all. Windows 2000 does not load *any* files from the

>>Side-by-Side assembly cache, Windows 2000 does not recognize WinSxS.

>>Deployments on Windows 2000 require that the files be placed in the

>>%systemroot%\system32 folder or in the program's folder.

>>

>>John

>

>

>

[Guest Steph]

Re: WinSxS, functional under 2k ?

 

"John John (MVP)" wrote :

 

....

> "On versions of Windows that do not support deployment of shared

> side-by-side assemblies, such as Windows 98 and Windows 2000

> Server, the Visual C++ libraries are installed in the System32

> folder and WinSxS folder under the operating system root

> directory. This setup enables running Visual C++ applications on

> these operating system versions because they do not support

> manifest-based binding of applications to dependent DLLs. On these

> operating systems, when an application is loaded, the

> corresponding manifest file is ignored and the operating systems

> searches for dependent DLLs using paths set in the current running

> environment. However, on upgrading the operating system to a

> version that support manifest-based binding, such as Windows XP,

> Windows Server 2003, or Windows Vista, applications built with

> manifests start using the DLLs installed in the WinSxS folder."

>

> http://msdn.microsoft.com/en-us/library/ms235624(VS.80).aspx

 

 

Good catch! And so, since I am sure I shall never want to "upgrade"

to Windows XP, I now know I can and should sweep those useless DLLs

from the WinSxS folder periodically (maybe, after checking that the

versions in System or the path are the same or newer.

 

Thanks to all responders !

 

--

Steph