dencorso

The third "MSCF", seems to always be aligned at a paragraph (= has an initial offset xxx0) and should be found after the VS_VERSION_INFO structure (in UNICODE, not ASCII). Inside that structure is the "OriginalFilename" field, which must be "SFXCAB.EXE"... so, if the script searches for "SFXCAB.EXE" in UNICODE, and then searches for "MSCF" in ASCII, the right point is always reached, whatever the version. Then it's just a matter of copying everything from offset 0 up to, but not including, the offset of that "MSCF" string, and there you are.

Which version? v. 6.1.22.4 ---- x0->x93FF v. 6.3.15.0 ---- x0->x95FF

I confirm ricktendo64's repacked installer works like clockwork on XPSP3 Keep on the great work! BTW, for XPSP3, after updating the WUA to v 7.6.7600.256, all that remains to be done is updating muweb.dll to the same version by hand? Or are there other updates necessary to also bring MU up to speed?

One of the things that are not guaranteed, when one does plain copy, is whether the short filenames created on copy will be associated to the same long-filenames as they are in the original source. This problem is well discussed in one of the XXCOPY knowledge base documents I gave a link to in one of my previous posts to this thread. Then there's the question of how hidden and super-hidden files will be treated...

Here's the Nov 13, 2001 version of KB247024 for comparison. Whatever revisions were there dealt solely with the html code (i. e.: the presentation). The content, AFAICS, remained exactly the same.

With all due respect, and with thanks for the pointer to the interesting xclone13, whatever other options you may come up with, we still have just three cases, really (provided we limit ourselves to file-based cloning): XXCOPY: the most well-known, still developed, still supported, widely used and very thoroughly debugged, 3rd-party tool adequate for the job. XCOPY: the tool available with the OS, that is known to be able do the job (and reasonably well test-demonstrated to work as intended). OTHERS: everything that is not those two above, but that can probably do the job, although much less test-demonstrated to work as intended, if at all.

For each issue, the right tool. Here XXCOPY is the tool of choice (for file-based cloning). Of course it can be done with XCOPY, and possibly in many other more difficult ways. @jaclaz - Here's what the current point of this discussion reminds me of...

Yes, it does. It's documented in XXTB#03 (and XXTB#08). The full documentation is accessible from this index. XXCOPY /Clone works very well in creating a working copy of a Win 9x/ME partition. Of course, this is file-based cloning, not byte-imaging cloning, but it works really well. If one creates an active partition in a second HDD, and ensures that it can be booted to DOS, then cloning a 9x/ME to this partition with XXCOPY will result in a bootable setup. The partition on the second HDD has to be of the same size as that of the original partition, or bigger, in order for the cloning to be possible, of course.

Something like that will always work for Win 9x/ME, but not necessarily so for the NT-Family OSes. Since Win 9x/ME is the target here, it can be done even from a live system, using xxcopy (see XXTB#10 and XXTB#20). It should just work, provided the version of XXCOPY FREEWARE used is v.2.96.5 (xxfw2965.zip), which is the last version that works 100% OK in 9x/ME.

Take care: two identical MBRs in two different HDDs may render your setup unbootable or force you into MS-DOS compatibility mode, unless you change the so-called mystery bytes to make each of them different the other.

After installing on the IDE HDD, including the SATA drivers I pointed you to, if you simply clone the full disk onto the SATA HDD, then remove the IDE HDD, does it work?

There is official support for SATA on KT600, and the latest driver to work correctly on 9x/ME is the Via's SerialATA_V220E.zip (direct download). Now, you must be aware that KT600 does *NOT* support SATA II, and it is one of the chipsets that cannot successfully negotiate with SATA II for it to enter SATA I compatibility mode, and therefore it's one of the reasons for the SATA speed limiting jumper to exist... Any SATA II disk which cannot be jumpred down to SATA I speeds only cannot be used with the KT600.

+1! JFX, you sure do rock!

NoSaveSettings=0 is OK; NoSaveSettings=1 is a problem. Which value does NoSaveSettings have when it reappears?

If it began after some antivirus update, and you're positive there's no malware in your system, then try doing it as the TrustedInstaller (<link> and <link>), or, by the same methods, as Local System Account.

I have the original 1998 CD (MS Part No. 097-0001929; CDFS Volume Descriptor Info: Volume ID = WIN98RK ; Created in 04/29/1998 05:00 PM at GMT-7). In it, there are: WIN98RK.CHM: 311,429 bytes; Date/Time Modified = 04/30/1998 06:42 PM; MD5 = 0B09352FEDD03880F1FA12E80054EF8A; SHA1= D9A395FDD555F2D788A4E406C54192B7C0A39545. KILL.EXE: 118,524 bytes; Date/Time Modified = 02/26/1997 05:53 PM; MD5 = AFEA8821723BB98D71FB7CB4E6493AF6; SHA1= 813F554FCA4C4F010C98A1DF452102681F5FC645. TLIST.EXE: 114,240 bytes; Date/Time Modified = 02/26/1997 05:53 PM; MD5 = 899A994BC23753643937C344FF5FB9DF; SHA1= 5F713A1B800E3A7AD53B34A6833B4B771FD4FB10. USBVIEW.EXE: 69,120 bytes; Date/Time Modified = 03/11/1998 12:20 AM; MD5 = 10FD1035B333FE53068DC358181664B3; SHA1= 08E4C34BF8722DD41A33E9DD38E7EEE4915611C1. Now, since the last three are PE executables, I can say more about them: KILL.EXE: PE Timestamp = 3314B0EC -> Wed Feb 26 18:53:48 1997; File Version = <none>; stated PE Checksum = 00027E4C; calculated PE Checksum = 00027E4C. TLIST.EXE: PE Timestamp = 3314B0EC -> Wed Feb 26 18:53:48 1997; File Version = <none>; stated PE Checksum = 000294A8; calculated PE Checksum = 000294A8. USBVIEW.EXE: PE Timestamp = 35061116 -> Wed Mar 11 01:20:38 1998; File Version = 4.10.0.1710; stated PE Checksum = 00000000; calculated PE Checksum = 0001BFC6. Now, since KILL.EXE and TLIST.EXE are Checksummed PE Executables, I can demonstrate they aren't corrupt, by comparing the stated checksum (in the so-called "Optional Header", which is not optional) with a newly calculated checksum. But this is not always the case, as illustrated by USBVIEW.EXE, which has no stated checksum (or 00000000 as the stated checksum, to be punctilious). In any case, I've installed the WIN98RK in my system partition, just after finishing windows installation and update. My current installation was performed in 11/13/2001. Those four files I mentioned above are identical in the original CD and in my system partition, so I think it very probable that both WIN98RK.CHM and USBVIEW.EXE are not corrupt either.

I use both. However, kill.exe/tlist.exe are small command-line utilities, which can be used for fast kills and multiple kills. Process Explorer is an overkill, for those purposes. Ex.: open five instances of IE (not five tabs). Then issue the command "kill iexplore", from the DOS box. Process Explorer is sophisticated, but, AFAIK, cannot do that. Or can it?

How so? What do you mean by "but it doesn't have its original attributes"? BTW, kill.exe is more useful when one also has tlist.exe present, because tlist.exe lists process IDs in the right format for use with kill.exe. All existing versions of those programs, whatever their version, have matching versions, to show they work right together.

Well, that's to be expected if you're running with NoSaveSettings=1...

Kiss - God Gave Rock 'N' Roll to You II

@submix8c: Please do not get mad, it's not called for, AFAICS. I know Multibooter long enough to be sure he's not out there just to contradict or otherwise irritate you. We're all here just trying to learn something, and, at this point, our Win9x systems are all slightly different, to say the least, so divergent behaviours may happen anytime.

OK. Thanks for the detailed road-map. You rock!

When installing them, which should be the actual install order? !st FlashGet then FlashGot, or the reverse? TIA

Analyse the converted program, XYZ.exe, with PE Explorer. It's quite adept at finding out why an application is deemed "not a valid Win32 Application" by Win XP and while the full version is expensive, the free 30-day-trial version is enough for what you require and 30 days is plenty of time for it.

Some additional relevant info: The desktop layout(s) are kept in the Registry, under the key "[HKEY_CURRENT_USER\Software\JOConnell]" And, now, here are the promised screenshots: