eidenk Posted September 11, 2007 Posted September 11, 2007 This is just a versioning conundrum caused by M$ habit of late of releasing parallel series of updates starting at different versions for different OSes. But it can be solved, in the case of PE executables like oleaut32.dll, by looking at the file compilation dates (aka PE Timestamps, which are MUCH more stable, becuse they're tucked away in the PE header, than common file dates, which reside in the directory entry an can change easily). To see the compilation dates in readable format one must use MiTeC EXE Explorer, or PEDUMP.EXE by Matt Pietrek, a somewhat more technical console app. For the latter, try <pedump filename.dll | find /i "timedatestamp"> and consider the first value listed (the others are usually zero, anyway, because it tries to get the PE Timestamps of the .dll dependencies and fails silently... yes, they are the result of a bug...). Of course, if one knows from which packages or updates those files came, and their relative release dates, it should not be necessary to go for the PE Timestamps, but that is not always the case. But I don't think the existence of PE Timestamps is very widely known, and this is a good exemple to show their utility. Too bad only PE executables (sometimes referred to as Win 32 executables), among all possible types of executables present in the Windows OSes carry their compilation date inside. Then again, they are becoming more and more the standard for .exe, .dll, .ocx and .tlb, and that is good news!In a nutshell, changing oleaut32.dll form v. 2.40.4522.0 to v. 2.40.4519.0, despite all the apearances, *is an upgrade*, not a downgrade! HTHThanks, I ignored that. Let us hope it is more reliable with MS files than with Exe Explorer itself, as I would not think it has been compiled the 19/06/1992.
dencorso Posted September 12, 2007 Posted September 12, 2007 Thanks, I ignored that. Let us hope it is more reliable with MS files than with Exe Explorer itself, as I would not think it has been compiled the 19/06/1992.Great catch, eidenk! The people at MiTeC, of course, may have done it as a deliberate prank...It hadn't occurred to me to use it to look for its own PE Timestamp. It can be spoofed quite easily. The only reason I think that it's usually reliable is the fact that it is a very little known detail of the PE standard, automatically set by the linker. One has to know it's there to spoof it. PEDUMP, for instance, really is from 29/08/2001, and I just found out a newer version of it (05/4/2004) in the downlodable companion file to this MSDN article, by Matt Pietrek: interestingly enough, when you run the 2001 version it says 1988 on the sign-on message, while the 2004 version says 2001. Matt Pietrek has updated that program many times, but did not update the text of the sign-on message consistenly every time... This new version still cannot find the dates of the dependencies but has improved, for, at least, it abstains from translating 00000000 as Wed Dec 31 22:00:00 1969...
MDGx Posted September 26, 2007 Author Posted September 26, 2007 UPDATED · 9-26-2007Please see the top of this topic for most recent updates:http://www.msfn.org/board/?showtopic=46581
soporific Posted September 27, 2007 Posted September 27, 2007 (edited) What a haul this month MDGx !!! Any further info on:CNTROL98:http://www.mdgx.com/web.htm#9SU* Unofficial Windows 98/98 SP1/98 SE Control Panel Applets Lockups CONTROL.EXE 4.10.1999 Fix [63 KB]:http://www.mdgx.com/files/CNTROL98.EXEcheers.EDIT:re: the MS Paint add-on and Graphic Filters Pack ... i'm including them both as an optional update in the next v of AP, and i may as well package them together as a stand-alone MSPAINT update ... wanna beat me to it ? edit: ie the fixed version of MSpaint.exe and also the Graphic Filters Pack. Edited September 29, 2007 by soporific
Drugwash Posted September 28, 2007 Posted September 28, 2007 RICHED9X [RTF]:http://www.mdgx.com/add.htm#RTFUpdated to USP10.DLL 1.422.3790.3959 from Win2003 SP2:* Unofficial Windows 98/98 SP1/98 SE/ME Rich Text (RTF) Edit Controls RICHED20.DLL 5.40.11.2220, RICHED32.DLL 5.0.1461.82 + USP10.DLL 1.422.3790.3959 Security Vulnerability Fix:http://www.microsoft.com/technet/security/...n/ms07-013.mspxDirect download [912 KB]:http://www.mdgx.com/files/RICHED9X.EXEI see the inf has the infamous ,,,4 parameter for the included files. Incidentally I have (better said, had) USP10.dll v1.0471.4030.0 installed prior to this upgrade and I had noticed no visible issues. After the upgrade I forcibly got the lower-versioned file.Question: is this version matching required? Otherwise, why is the ,,,4 parameter used for all files in the package?Also, as reported some time ago in some other thread around, this version of riched20.dll has issues with bad words underlining in Miranda IM's spellchecker (based on Hunspell), reason why I had been using riched20.dll v5.30.23.1221. Is there still no better version that'd be worth using instead of this one?Nevertheless, thank you very much for all your hard work!
erpdude8 Posted October 5, 2007 Posted October 5, 2007 (edited) KB891711:http://www.mdgx.com/web.htm#W98* Unofficial Windows 98/98 SP1 Animated Cursor (.ANI) + Icon Handling USER32.DLL + USER.EXE 4.10.2003 Security Vulnerability Fix:http://www.mdgx.com/files/q891711.phpDirect download [419 KB]:http://www.mdgx.com/files/KB891711.EXEThis Fix replaces ALL PREVIOUS Microsoft MS07-017 (Q925902):http://www.microsoft.com/technet/security/...n/ms07-017.mspxMS05-002 (Q891711):http://www.microsoft.com/technet/security/...n/ms05-002.mspx+ unofficial (U891711) Animated Cursor (.ANI) + Icon Handling Security Vulnerabilities Fixes, which are now OBSOLETE!Q891711 + U891711 MSFN forum:http://www.msfn.org/board/?showtopic=58780STRONGLY RECOMMENDED: KB891711 provides the BEST Fix!I may consider dropping the user.exe/user32.dll v4.10.2003 files from the next release of the unofficial Win98 FE SP since it can cause problems with Tihiy's RP pack. And I'll restore the kb891711.exe & q8917111.dll files as well.I see the inf has the infamous ,,,4 parameter for the included files. Incidentally I have (better said, had) USP10.dll v1.0471.4030.0 installed prior to this upgrade and I had noticed no visible issues. After the upgrade I forcibly got the lower-versioned file.Where the heck did you get v1.0471.4030.0 of the usp10.dll file, Drugwash? That's what I'm more worried about. Edited October 5, 2007 by erpdude8
erpdude8 Posted October 5, 2007 Posted October 5, 2007 (edited) Also, as reported some time ago in some other thread around, this version of riched20.dll has issues with bad words underlining in Miranda IM's spellchecker (based on Hunspell), reason why I had been using riched20.dll v5.30.23.1221. Is there still no better version that'd be worth using instead of this one?Version 5.40.11.2220 of riched20.dll is featured in the Office XP post-SP3 MS07-013 security update.Version 5.30.23.1221 of riched20.dll is prone to security flaws mentioned in security bulletin MS07-013. Replace it with version 5.30.23.1227 which I have for my Office 2000 suite.Newer Root Certificates update (revised August 23, 2007); file size 281kb:http://www.msfn.org/board/ipb_seo.php?url=...%2Frootsupd.exe Edited October 5, 2007 by erpdude8
Drugwash Posted October 6, 2007 Posted October 6, 2007 (edited) To be honest, I can't remember where I got that usp10.dll version from. I don't quite keep an evidence on sources; all I'm interested in is the final result.Here's the full info on it:C:\WINDOWS\SYSTEM\usp10.dllon Microsoft Windows 98 SE version 4.10File Version Information : Version language : English (United States)CompanyName : Microsoft CorporationFileDescription : Uniscribe Unicode script processorFileVersion : 1.0471.4030.0 (main.030626-1414)InternalName : UniscribeLegalCopyright : © Microsoft Corporation. All rights reserved.OriginalFilename : UniscribeProductName : Microsoft(R) Uniscribe Unicode script processorProductVersion : 1.0471.4030.0Last Modif. Date : 06/27/2003 08:18:32 Last Access Date : 10/06/2007 00:00:00 FileSize : 413184 bytes ( 403.500 KB, 0.394 MB ) FileVersionInfoSize : 940 bytes File type : Dynamic Link Library (0x2) Target OS : Win32 API (Windows NT) (0x40004) File/Product version : 1.471.4030.0 / 1.471.4030.0Language : English (United States) (0x409) Character Set : 1200 (ANSI - Unicode (BMP of ISO 10646)) (0x4B0) Build Information : Debug Version : no Patched Version : no Prerelease Version : no Private Version : no Special Build : noI'm positive I don't have riched20.dll 5.30.23.1227 around, otherwise I would've already had it installed. Frankly, I'd rather use one of the 5.50 versions - because of the link color fix - but those seem to have some issues of their own. This has been discussed at large some time ago. Edited October 6, 2007 by Drugwash
dencorso Posted October 6, 2007 Posted October 6, 2007 (edited) I see the inf has the infamous ,,,4 parameter for the included files. Incidentally I have (better said, had) USP10.dll v1.0471.4030.0 installed prior to this upgrade and I had noticed no visible issues. After the upgrade I forcibly got the lower-versioned file.Question: is this version matching required? Otherwise, why is the ,,,4 parameter used for all files in the package?Hi, Drugwash!Since everybody here clearly understands .INFs better than I do, I'll just take this opportunity to ask, before I die of unsated curiousity: what do the ,,4 and ,,,4 flags mean, please? Thanks in advance and best wishes! Edited October 6, 2007 by dencorso
Drugwash Posted October 6, 2007 Posted October 6, 2007 Ah, I'm not a specialist either - just catching some things on the fly. As far as I understand, that parameter is used to force installation even over an existing higher build number of a file.It should be used - at least theoretically - only when certain files strictly depend on other certain versions and mismatching would lead to unpredictable results.
dencorso Posted October 6, 2007 Posted October 6, 2007 (edited) [...]As far as I understand, that parameter is used to force installation even over an existing higher build number of a file.[...]Thanks, Drugwash. You rock!Added text 9th October 2007 - 04:25 AM:Thanks for the links in you post below this one, soporific! They sure help a lot. You do rock too! Edited October 9, 2007 by dencorso
soporific Posted October 8, 2007 Posted October 8, 2007 Since everybody here clearly understands .INFs better than I do, I'll just take this opportunity to ask, before I die of unsated curiousity: what do the ,,4 and ,,,4 flags mean, please? Thanks in advance and best wishes!here's a link that explains all:http://soporific.dsleague.com/downloads/copyfile.htmi got it from the INF guide that MDGx keeps a copy of at this location:http://www.mdgx.com/INF_web/INF_WEB.ZIP
Fredledingue Posted October 12, 2007 Posted October 12, 2007 K891711 (or Q891711) IS EXTREMELY DANGEROUS: DO NOT USE IT For the second time (same problem as with the previous version 2 months ago) my computer was unable to restart and I had to reinstall windows.It said "unable to load user.exe" then shut down in 1/10th of a second. Clack! (You know, the sound when the PC power is turned off). I didn't have the possibility to restart it! ===> Boot Floppy time!MDCx: Please remove it from your list!!
Drugwash Posted October 12, 2007 Posted October 12, 2007 Dunno what your problem is, but I just installed it (twice: installed, uninstalled while trying to fix some unrelated problem and reinstalled) recently and I had/have absolutely no such issues. Well, there may be problems with resources dropping quite fast, but that's something else and could be caused by any other factors as well, such as gdi.exe/gdi32.dll (updated to 4.90.3003).Please check any possible resident/BIOS anti-virus or other applications that may block operations on system files. Or maybe some strange boot-up configuraton...You may ask MDGx to create a debug version that'd create a log of the operations performed during install, so you could find where (and possibly why) it breaks.
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now