dencorso

It used to say it didn't support win2k, when HashTab was in version 3.0.0... V. 2.1 was the last to officially support Win2k, and it's probably still findable around... here's some info on it: hashtab2_setup.exe 538,317 bytes MD5: 1bc01b816c015d194f0e39e370af1e1c

Yes. But I think it best to always report the preferred base. It's added to my to-do list. OK. Here's the new version of LOADDR... It'll detect when the file is a PE file and, if so, provide the preferred load address and the execution and relocation status of the file it's analysing. When the file is not a PE file, however, it'll behave just as the previous version did. AFAIK, only PE files have the preferred load address information. LOADDRII.7z

Elton John - Empty Garden (Hey Hey Johnny)

I join MagicAndre1981 in wishing you a happy birthday, cluberti! Auguri!

That's great news! And welcome to MSFN!

Well, they've released both wuweb.dll and muweb.dll v. 257, although the latter isn't quite in focus in this thread. But, with all due respect, that's rather old news already (I guess you skipped reading some posts above)...

Well, not anymore... While I left post #34 there, I moved #35-39 here, which is where they really belong, and now they've become posts #33-37 on this thread. i decided to leave post #34 there because it has a pointer to this thread, and it's quoted in toto in RLoew's reply to it, which is posts #33 on this thread, so nothing was lost.

Well... it's my understanding you'd like to be able to check the integrity of every file in a CD/DVD or a CD/DVD image. I have no solution for that, sorry! However, as your initial post mentions specifically DLLs, I do have a partial solution for that, that may be of interest. Let's see its limitations: Not all files are executables, and for non-executables this won't work. Not all executables are PE files (i.e.: files in the Portable Executable format), and for non-PE files this won't work. Not all PE files are checksummed (i.e.: there are PE files with the header checksum set to zero, when the true checksum is not zero), and for non-checksummed PE files this won't work. But it works for all checksummed PE files! Now, the bad news is Win 9x/ME does not care about the checksum, so non-checksummed PE files are more common for those OSes than for those of the NT-family. In any case I've done some quick statistics using my C:\WINDOWS\SYSTEM folder as a reasonable enough sample to see how useful my method might be, and here're the results: Of 2232 files, 1574 (70% of the total files) are PE files. Of these: 1111 (70% of all PE files) have matching checksums, 451 (29% of all PE files) have zero checksum on the header and 12 (1% of all PE files) have wrong checksums (those are sloppily patched files, which checksum was not corrected, in this case). So, all in all, I was able to confirm that 49% of the total files are not corrupt, and had to investigate just 12 files... Seems good enough for me! The method consists in calculating de novo the true checksum of a PE file and comparing it to the checksum present in the Optional Header: when both match, the file can be assumed to be non-corrupted. The exceptions to this rule are some files that chip with a wrong checksum in the header... I found out that QuickTime.cpl is an example of such a file (three different versions of it straight from the distribution package came with wrong checksum set in the header). I've thrown a little console app together, which I call VRFYPE (attached to this post), to perform the checksum test on any number of files. It accepts "*.*" as a filespec and proceeds to check each of the files, ignoring the non-PE files, and providing three possible veredicts on the PE files it finds: checksums match, or do not match or the header checksum is zero, returning all info for any given file in a single line, together with the filename, so as to be convenient for filtering with FIND or related DOS filters. Please do test VRFYPE, and let me know of any bugs you find. VRFYPE.7z

The ultimate uninstaller for .NET Framework is Aaron Stebner's .NET Framework Cleanup Tool. I suggest you use it as the standard uninstaller, or if you wish to learn more, then study it to incorporate its functions into your own uninstaller.

What you said is true only if you take a very narrow view of what Win XP is... otherwise, yes, there can be LDR files in XP all right: all it takes is to install updates to IE7 or IE8, by hand, using the /b:SP3QFE switch, once, and then, all subsequent updates to those files will always come from the LDR branch.

Read this, this and this.

Well, now I do, too, thanks to the newly rebuilt installer we've just concocted, after running it with the /wuforce option.. The changes you suggested to the WUAv256.cmd worked beautifully!

I still use COMCAT.DLL 5.0.2600.1, but downgraded OLEPRO32.DLL to 5.0.4530.0 after finding some issue with OLEPRO32.DLL 5.0.5014. And regarding OLEAUT32.DLL, I've stopped updating it at 2.40.4520.0. Never found a latter version that really worked OK.

Thanks submix8c, you rock! http://www.update.microsoft.com/microsoftupdate/v6/v5controls/en/x86/client/muweb_site.cab?1340383010227Just downloaded v257 of MUWEB.DLL, inside MUWEB_SITE.CAB, binarily identical to the one I got installed yesterday. Hey! You've just given me the solution! Just change "m" by "w", and there we are: http://www.update.microsoft.com/microsoftupdate/v6/v5controls/en/x86/client/wuweb_site.cab?1340383010227works, too! I've just got WUWEB.DLL through it, inside WUWEB_SITE.CAB!!! So, now we can revise the .cmd, and we're back to the *latest* WUA files once again!

I entered MU site and got immediately offered muweb.dll v. 7.6.7600.257, which I did accept. It didn't offer me the updated wuweb.dll, too, however, nor updated it silently. That may be because I run with Auto Updates disabled. Can one of you all find out its download link? I'd rather update it by hand, and, in any case, it'd be good to update submix8c batch to get wuweb.dll v. 7.6.7600.257, instead of v. 7.6.7600.256...

Certificates are irrelevant for XP. Downversion patching alone may not get more than a handful of drivers working, but that's a start. And a stubber filter driver like WDMSTUB.SYS might get a bunch more working. But it's not quite straightforward to do it, so some commited programmer(s) are needed, and the sooner the better.

More on Windows Stealth Updates here, here and here...

Use Palemoon. It's even stabler than Firefox, from which it's derived, and it has stable version numbering, instead of that version nonsense that got hold of Firefox.

Great work, submix8c! You do rock! PS: The correct link for 7za is the following, please do correct it in WUAv256.cmd http://sourceforge.net/projects/sevenzip/files/7-Zip/9.20/7za920.zip/download

My condolences. May both rest in peace. The ways of the Lord are unfathomable... My thoughts are with you.

So, I think should be translated as "The bug is not a problem if the extended kernel is used." Right?

Divide both HDDs in at least two partitions and use the first partition in each HDD for each OS. 12 GB should be plenty for 98SE. Install 98SE on the IDE, give it VIA Hyperion 4in1 v456 and VIA SATA v220e. Then install VIA USB2 V2.70p1-L-M, backup Usbhub20.sys v4.90.3000.11 (from VIA) and install NUSB36e, then boot to DOS and put Usbhub20.sys v4.90.3000.11 back, replacing the one installed by NUSB. After rebooting you should be all set. Now disconnect the IDE HDD and install Linux in the SATA HDD. Reconnect the IDE. By selecting the boot disk in BIOS, you should now be able to boot either OS an see/access all HDDs, except for the Linux boot partition (because it'll be formatted to Ext2 or whatever). There are programs that let you access Ext2 from 9x/ME, so Ext2 should be preferred. Moreover, Linux doesn't really need a second partition for the pagefile, it can use a common pagefile inside another partition, and that can be FAT-32. Once you know for sure you can boot OK from each HDD to the OS in it, set the IDE as default boot in BIOS, then edit the [Options] section in MSDOS.SYS to say this: [Options] BootDelay=0 BootMulti=0 BootGUI=0 BootWarn=0 LoadTop=1 DoubleBuffer=1 DblSpace=0 DrvSpace=0 AutoScan=2 Logo=1 DisableLog=0 WinVer=4.10.2222 Add a CONFIG.SYS like this (customize it, especially the [9X] section, to your liking): menuitem=9X, Win 98SE (98SE2ME). menuitem=GR, Grub4Dos Boot Loader. menudefault=GR,5 menucolor=7,0 [GR] install=grub.exe [9X] DEVICE=C:\WINDOWS\HIMEM.SYS /TESTMEM:ON /EISA /V DOS=HIGH SHELL=C:\WINDOWS\COMMAND.COM C:\WIN\ /E:2048 /L:256 /U:255 /P DEVICE=C:\WINDOWS\IFSHLP.SYS DEVICE=C:\WINDOWS\DBLBUFF.SYS DEVICE=C:\WINDOWS\COMMAND\DISPLAY.SYS CON=(EGA,,2) DEVICE=C:\WINDOWS\SETVER.EXE DEVICE=C:\WINDOWS\COMMAND\ANSI.SYS LASTDRIVE=Z BUFFERS=64,8 FILES=50 FCBS=40,8 STACKS=18,256 SET TEMP=C:\TEMP SET TMP=C:\TEMP SET TMPDIR=C:\TEMP SET PROMPT=$P$G SET WINPMT=$P$G SET PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\WINDOWS\SYSTEM; COUNTRY=055,850,C:\WIN\COMMAND\COUNTRY.SYS INSTALL=C:\WINDOWS\COMMAND\DOSKEY.COM Add an AUTOEXEC.BAT like this: @ECHO OFF WIN Add Grub4DOS to the root dir of the IDE HDD and add this MENU.LST (take care, the SATA HDD may be sd0, instead of hd1... if so, adjust): default 0 timeout 4 title LINUX map (hd0) (hd1) map (hd1) (hd0) map --hook rootnoverify (hd0,0) makeactive chainloader (hd0,0)+1 And now you should be able to multiboot from the keyboard, during startup, without needing to go into BIOS. HTH.

Ditto, from a double dinosaur (9x and XP diehard). As for the End of Life, no, I don't fear it at all: been there, done that and remain here to tell the story. When all official support ends, a bunch of committed diehards takes over. It happened before, and will happen again.

You should avoid uttering famous last words... Anyway, when it fails you do try Jack Ellis' version 3.03E of SHSUCDX first.

You may use MS FILEVER (extract it with 7-zip from inside the old mpedp.exe package) to confirm the SFXCAB.EXE version, and then use the offsets we have posted some posts above, then split it using PARTCOPY. complementarily, for versions in which the offset is not yet known, you can The 3rd occurrence, of course. XVI32 is a good way to find the offset, too, but less easy to automate, IMHO. P.S.: Here's a sample output from filever: N:\INSTALL\MS_UPDXP\WUA>filever *.* /a /b /d W32i APP ENU 6.2.29.0 shp e:\install\ms_updxp\20120611\windowsupdateagent30-x86_7_4_7600_226.exe W32i APP ENU 6.2.29.0 shp e:\install\ms_updxp\20120611\windowsupdateagent30-x86_7_6_7600_243.exe BTW, just tested it. For 7.6.7600.243 the command should be: partcopy Window~1.exe 0 8A00 SFXCAB.EXE provided that WindowsUpdateAgent30-x86.exe be in the same folder from which partcopy is run, and that there's just one file which long-name begins in "window" in the said folder, since partcopy requires the use of short-names. Of course, SFXCAB.EXE is aka MSCF.SFX.