5 ms·
fc.exe doesn't use any DLLs. It's a trivial console application, deployed as a single .exe that can be overwritten as long as it's not currently running.
by CamperBob 15y ago
fc.exe doesn't use any DLLs. It's a trivial console application, deployed as a single .exe that can be overwritten as long as it's not currently running.
- Locke1689 15y agoThe hotfix seems to modify ulib.dll.
- CamperBob 15y agoIf fc.exe depends on DLLs for its core functionality, then the whole scenario is even goofier.
- Locke1689 15y ago/usr/bin/diff depends on the following shared libraries for operation: linux-gate.so.1 => (0xb7f31000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7f18000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dc9000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7db0000) /lib/ld-linux.so.2 (0xb7f32000) Did you look any of this information up before making your statements? It looks like ulib.dll is a DLL for file utilities, which would perform an analogous purpose as librt and libc in any UNIX system.
- quadhome 15y agoBut, you don't need to reboot a Linux machine after updating a shared library.
- Locke1689 15y agoThis was from XP before they re-architected the DLL management. I'm not sure blaming Microsoft for a mistake made more than 9 years ago in OS design is relevant or helpful. -- Me, about 4 comments ago
- CamperBob 15y agoAnd this is relevant because....? You can rest assured that the actual bug was not in a CRT library DLL. They may have had a good reason for updating ulib.dll which wasn't mentioned in the KB article, but fixing an off-by-one bug in an app-specific memory-compare loop wasn't it.