dll hell problem

[Guest]

When I installed the Easy CD Creator, some dlls in \windows\system32\ were overwritten by older version dlls.

It seems that Windows File Protection is not working,
and sfc.dll, sfc_os.dll are different from those of XP Pro.

When I checked setupapi.log in \windows\ this happend.
--------------------------------------------------------------------
#-336 Copying file "E:\WINDOWS\Temp\WMFA\msvcrt.dll" to "E:\WINDOWS\System32\msvcrt.dll" via temporary file "E:\WINDOWS\System32\SET68.tmp".

#W025 A newer file "E:\WINDOWS\System32\msvcrt.dll" was overwritten by an older (signed) file. Version of source file: 6.0.8337.0. Version of target file: 7.0.2600.1106. The SP_COPY_FORCE_NEWER flag was ignored. The existing target file was signed.

#E246 A connection could not be established with the Windows File Protection server.

#W190 File "E:\WINDOWS\System32\SET68.tmp" marked to be moved to "E:\WINDOWS\System32\msvcrt.dll" on next reboot.

 

[KM]

jman,

IIRC, WFP feature was removed from XPe.

KM

When I installed the Easy CD Creator, some dlls in \windows\system32\ were

overwritten by older version dlls.

It seems that Windows File Protection is not working,
and sfc.dll, sfc_os.dll are different from those of XP Pro.

When I checked setupapi.log in \windows\ this happend.

"E:\WINDOWS\System32\msvcrt.dll" via temporary file
"E:\WINDOWS\System32\SET68.tmp".

#W025 A newer file "E:\WINDOWS\System32\msvcrt.dll" was overwritten by an

older (signed) file. Version of source file: 6.0.8337.0. Version of target
file: 7.0.2600.1106. The SP_COPY_FORCE_NEWER flag was ignored. The existing
target file was signed.

#E246 A connection could not be established with the Windows File Protection server.

#W190 File "E:\WINDOWS\System32\SET68.tmp" marked to be moved to

"E:\WINDOWS\System32\msvcrt.dll" on next reboot.

 

[Guest]

Do you have any idea of preventing 'dll hell' problem in XPe?
Doesn't Windows Installer compare versions of source and target?

I know one solution. Backup target dlls and copy them after installation.
But the users of my products are not professional computer engineer,
so this solution is difficult for them.

My product has a CD-RW and it needs DirectCD support.
My users may install various CD Burning programs which they buy.

So this 'dll hell' problem is critical problem to my product.
I need alternatives of Windows File Protection feature.

 

[KM]

jman,

This may be a tough one if you are not a programmer.

Basically, you want to be able to install any (CD Burning) software on your
runtime and keep the runtime with the original dll's.
If we don't think about the installing software problems (they may not work
without the old Dll versions).
You don't really know what system Dlls may be overwritten by the
installations (I agree - 'Dll hell').
So you need a backup for all the Dlls that may get overwritten and the
backup has to be accessible all the time within the runtime (local copy, or
a CD that is always in, or etc.).
For the backup content you can:
- Evaluate all [most of] the existing CD Burning software to analyze
what Dll's may be overwritten and put all these Dll's in the backup
directory(ies).
- Just have a copy of your runtime entire system directory(ies) as the
backup.

Then you can creata a simple agent app (a service, an agent app, etc.) that
monitors if any system Dll gets changed and reverts it back to the original
state (file).
To not load runtime much and not hit the system performance, the app can
leverage some good Win32 technologies:
- By a timer you can enumarate system directory contents
(FindFirstFile/FindNextFile/etc. API) to see if any Dll got changed,
- Instead of using a timer for monitoring the file changes, you can use
filter notifications
(FindFirstChangeNotification/FindNextChangeNotification/etc. API) to catch
when a file datetime stamp and/or file size is changed.
- Cache Dll versioning (version info, datetimestamp, size, etc.) in a
database (registry, plain text file, etc.) to not be doing a binary
comparison each time a system file change notification comes in.

You can think of many more optimizations for the feature implementation (you
can name the feature as a simple WFP implementation).

Regards,
KM