XP look
5 отговора
154 прегледа
Re: XP look
Nqma nishto sramno
I na men mi e interesno kakvi sa mu rabotite. Moite programi sa s buttoni "a la 98". Kakvo trqbva da chakam Delphi 7 za da imam XP look taka li?
by Wise Guy
[email protected]
I na men mi e interesno kakvi sa mu rabotite. Moite programi sa s buttoni "a la 98". Kakvo trqbva da chakam Delphi 7 za da imam XP look taka li?
by Wise Guy
[email protected]
Re: XP look - porednata sturotia na MS
ami ne e mnogo slozno - eto ti izwadka ot statia - mislia 4e ste se oprawish bez pervod ;-)))
---------------------------------------------------------
Microsoft is not exactly slow at bringing out new technologies, and when it does,
they’re often accompanied by quite a fanfare. It’s rather surprising, then, that
Fusion is something that has quietly tiptoed in through the back door. If you scan
the latest MSDN documentation (the latest I have is April 2001), you’ll see only the
merest offhand hint at Fusion in one or two places.
Basically, Fusion is a logical extension of something that Microsoft has been
working on for a while. It started with the introduction of the side-by-side DLL
technology in Windows 98, second edition. This allows an application to use a specific,
possibly private version of a DLL rather than relying upon the shared ‘system’
DLL being the correct version. Microsoft further enhanced this idea with the introduction
of Windows 2000 and SFP or System File Protection. SFP uses a background
thread to periodically check that none of the system DLLs and other vital OS components
have been removed or replaced with some non-standard version. If this
does happen, the SFP thread automatically retrieves a pukka copy of the damaged
file from a private cache and repairs the damage immediately.
You see, folks, the essential thrust of Fusion is to remove the dreaded ‘DLL Hell’
syndrome. Side-by-side versioning is intended to allow third-party applications to
use the DLLs they want to use, whereas SFP is intended to prevent those same
third-party applications from forcing their choice of DLL onto everyone else! Two
sides of the same coin, with the intent being that all applications should be able to
live peacefully with one another!
In XP, this concept is taken even further with the introduction of an application
manifest. (Note: if you’re familiar with .Net technology, you’ll know that a .Net
executable contains a Manifest section as part of the metadata that’s linked into
the file). Essentially, a manifest contains a lot of assorted data relating to an application,
including a description of dependent items required by the application.
Listing 1 shows an example manifest (taken from the Microsoft documentation)
which illustrates how to set up a dependency on the version 6.0 COMCTL32 library.
When the application is loaded, the operating system scans the manifest and
automatically loads version 6.0 of the common controls library which (incidentally)
isnowreferred to internally as the ‘User Experience Controls Library’. Coo!
As you’ll see, the manifest is authored in XML. You can choose either to place
this information into a specially-named file which sits alongside your executable
or you can do things more neatly by compiling the XML data into a resource that’s
contained inside your EXE file. To cater for the latter case, Microsoft has defined
a new resource type, RT_MANIFEST.
You’re probably sat there wondering what’s with this publicKeyToken stuff in
the above manifest? Well, I’m not totally sure of the full picture myself, but if you
consult Figure 3, you’ll see the rather counter-intuitive location of the version 6.0
COMCTL32 library on my XP setup. The new ‘WinSxS’ subdirectory is apparently
used to hold all the side-by-side (Fusion-related) components distributed by
Microsoft, and currently includes entries for Common Controls, GDI+ and the new
Visual C++ runtime libraries. You’ll see that the full pathname is largely made up
by concatenating various entries from the above XML manifest. Although it’s over
a year old at time of writing, you can find an excellent description of the rationale
behind Fusion on Paul Thurrott’s SuperSite for Windows at [линк].
com/showcase/whistler_fusion.asp.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="CompanyName.ProductName.YourApp"
type="win32"
/>
<description>Your application description here.</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>
---
Е т'ва е живот!
---------------------------------------------------------
Microsoft is not exactly slow at bringing out new technologies, and when it does,
they’re often accompanied by quite a fanfare. It’s rather surprising, then, that
Fusion is something that has quietly tiptoed in through the back door. If you scan
the latest MSDN documentation (the latest I have is April 2001), you’ll see only the
merest offhand hint at Fusion in one or two places.
Basically, Fusion is a logical extension of something that Microsoft has been
working on for a while. It started with the introduction of the side-by-side DLL
technology in Windows 98, second edition. This allows an application to use a specific,
possibly private version of a DLL rather than relying upon the shared ‘system’
DLL being the correct version. Microsoft further enhanced this idea with the introduction
of Windows 2000 and SFP or System File Protection. SFP uses a background
thread to periodically check that none of the system DLLs and other vital OS components
have been removed or replaced with some non-standard version. If this
does happen, the SFP thread automatically retrieves a pukka copy of the damaged
file from a private cache and repairs the damage immediately.
You see, folks, the essential thrust of Fusion is to remove the dreaded ‘DLL Hell’
syndrome. Side-by-side versioning is intended to allow third-party applications to
use the DLLs they want to use, whereas SFP is intended to prevent those same
third-party applications from forcing their choice of DLL onto everyone else! Two
sides of the same coin, with the intent being that all applications should be able to
live peacefully with one another!
In XP, this concept is taken even further with the introduction of an application
manifest. (Note: if you’re familiar with .Net technology, you’ll know that a .Net
executable contains a Manifest section as part of the metadata that’s linked into
the file). Essentially, a manifest contains a lot of assorted data relating to an application,
including a description of dependent items required by the application.
Listing 1 shows an example manifest (taken from the Microsoft documentation)
which illustrates how to set up a dependency on the version 6.0 COMCTL32 library.
When the application is loaded, the operating system scans the manifest and
automatically loads version 6.0 of the common controls library which (incidentally)
isnowreferred to internally as the ‘User Experience Controls Library’. Coo!
As you’ll see, the manifest is authored in XML. You can choose either to place
this information into a specially-named file which sits alongside your executable
or you can do things more neatly by compiling the XML data into a resource that’s
contained inside your EXE file. To cater for the latter case, Microsoft has defined
a new resource type, RT_MANIFEST.
You’re probably sat there wondering what’s with this publicKeyToken stuff in
the above manifest? Well, I’m not totally sure of the full picture myself, but if you
consult Figure 3, you’ll see the rather counter-intuitive location of the version 6.0
COMCTL32 library on my XP setup. The new ‘WinSxS’ subdirectory is apparently
used to hold all the side-by-side (Fusion-related) components distributed by
Microsoft, and currently includes entries for Common Controls, GDI+ and the new
Visual C++ runtime libraries. You’ll see that the full pathname is largely made up
by concatenating various entries from the above XML manifest. Although it’s over
a year old at time of writing, you can find an excellent description of the rationale
behind Fusion on Paul Thurrott’s SuperSite for Windows at [линк].
com/showcase/whistler_fusion.asp.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="CompanyName.ProductName.YourApp"
type="win32"
/>
<description>Your application description here.</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>
---
Е т'ва е живот!
