98 FE + 98 SE + ME updates + patches + (hot)fixes

[MDGx]

-DOSLFN and DOSLFNBK perform different functions... doslfnbk backs up & restores all the LFN's/8.3 filenames in a dir-tree (whether in windows or real-mode dos), doslfn just allows u to read/work with lfn's in real-mode dos, but doesn't perform any backup/restore filename functions...

-I've lightly perused your backup progs list, but it isn't mentioned if/which ones also preserve the lfn/8.3 filenames PROPERLY... (I've tested MANY free backup progs, including some on your list, and none of em passed the "~1, ~2" lfn/8.3 preservation test... same prob exists with zip utils:  ya have to first save the lfn's, then change all the filenames into 8.3 format only (using xxcopy /N, or pkzip /N, etc) for the compression, then restore the filenames after de-compression... -otherwise, the "~1" and "~2" 's will sometimes get switched (same bug happens when ya use Explorer to copy or move a bunch of files; the 8.3's are NOT preserved, and sometimes get swapped, leading to bad links, system errors/instability, etc)

(...the "save entire partition..." utils will probably work, preserving the names properly, of course, but saving an entire partition at a time is a bit extreme, for routine backup purposes...)

-thx for the help, but it looks like I've got the doslfnbk limitation sorted out, splitting off 2 or 3 sub-dirs (of too many files in each) during the restore function... when I get the time/motivation, I'll continue testing your backup-utils list, see if any of em do really preserve LFN/8.3's properly...

My bad, I must have misunderstood your question. ;(

DOSLFN only allows DOSLFNBK and other similar DOS tools to work properly [preserve LFNs] from native DOS mode.

I have never used DOSLFNBK.

DOSLFNBK [and other similar tools such as MS LFNBK] from what I read, only backs up LFN information from the HD, not the actual files/folders, that's why I don't care for it, and that's why I don't even mention it at my site.

But if u prefer a free alternative [which I don't care for either, for the same reason], please try [if u haven't already] LFNBK.EXE = MS Long File Names Backup tool for Win9x/ME, which is found on your Win98 SE setup CD in the \Tools\Reskit\Powertoy folder.

I don't like xxcopy because it is nag freeware, it pops up its annoying copyright screen every time it starts, after which I have to press additional keys to make it continue, thus making it useless for automated batch files.

Another LFN compliant tool is:

XCLONE.EXE v1.3 LFN disk, directory + file copy 16-bit DOS console tool [freeware]:

http://www.sac.sk/files.php?d=14&l=X

D/l XCLONE [20 KB]:

ftp://ftp.sac.sk/pub/sac/utildisk/xclone13.zip

which I use in 98SE2ME to backup the entire Win98 SE OS into C:\W98SEOLD from options 1 + 2, inside Windows.

XCLONE is extremely easy to use, requires only few command line parameters, and I like it mostly because it is very fast [if loading SMARTDRV in memory before using XCLONE].

Please note that XCLONE is LFN compliant only from within Windows, same as all other 16-bit DOS tools [except xxcopy I believe], because native/true MS-DOS mode [outside Windows] is not LFN compliant per se [as I'm sure you already know]. That's why I was recommending DOSLFN, a free GPL TSR [memory resident], which makes native MS-DOS mode LFN compliant, so you can copy/rename/delete/move/etc whatever files/folders around.

So if u load DOSLFN into memory [occupies ~ 12 KB], then u can use tools like XCLONE [and probably even DOSLFNBK + LFNBK (but I haven't tried them)] from native DOS, and they will preserve LFNs.

When I recommended those LFN compliant backup tools, I meant that these are native Windows tools, which perform full/incremental/partial backups of files/folders/drives/partitions.

And as we all know, all native Windows 32-bit [a.k.a. Win32 = includes all 9x + NTx MS OSes] tools [backup or not] preserve LFNs, a.k.a. are LFN compliant. This means that whenever you see a program that says it is 32-bit, it implies that it is always LFN compliant.

Also, most of the backup tools that make drive/partition backups, also make file/folder backups, and it's up to you how you configure the respective program to serve your particular needs.

Glad u found a fix to your problem.

Hope this helps.

[PsycoUnc]

I don't like xxcopy because it is nag freeware, it pops up its annoying copyright screen every time it starts, after which I have to press additional keys to make it continue, thus making it useless for automated batch files.

? -that only happens the very first time it's run, to install it, in my experience... after it's installed, it never happens again, no nag, no extra keystrokes, and it also has additional switches for more automation of any prompts/defaults, too...

XCLONE is extremely easy to use, requires only few command line parameters, and I like it mostly because it is very fast [if loading SMARTDRV in memory before using XCLONE].

(here comes more xxcopy praise : I've found xxcopy to be extremely simple (the /clone switch does pretty much everything ya need), and very fast (if HD is defragged, often get 20mb/sec true copy transfer rate, and that's with 5000-10000 files copied; not bad at all))

When I recommended those LFN compliant backup tools, I meant that these are native Windows tools, ... And as we all know, all native Windows 32-bit [a.k.a. Win32 = includes all 9x + NTx MS OSes]tools [backup or not] preserve LFNs, a.k.a. are LFN compliant. This means that whenever you see a program that says it is 32-bit, it implies that it is always LFN compliant.

I think we're confusing terminology here: LFN compliant means it preserves the "long" filename, but does it ALSO ALWAYS preserve the SHORT (8.3) filename which is associated with the LFN? Windows itself does not, when copying files/folders in explorer; -Are u familiar with that classic win98 flaw, I call it the tilde ("~") flaw? This is what I'm talking about, keeping the 8.3 name & the LFN properly associated (if ya copy 2 or more files that have similar short names, like MICROS~1.TXT, and MICROS~2.TXT, at the same time to another directory, it sometimes SWITCHES the short (8.3) filenames, depending on which file it happens to create first... -same thing happens when unzipping files, the short name's "~1,~2", etc, are completely arbitrary, NOT necessarily the same as when ya zipped it up, they (8.3's) are numbered by the new file creation order only... it's a famous flaw, the reason for which DOSLFNBK was created (and is probably much better explained at it's web site)

-and, with my testing, every zip/copy/backup prog (FREE, anyways), have failed to keep the proper association between 8.3 names & LFN's in some cases, making them useless for reliable backups (and believe me, I was SHOCKED when I discovered this, about 1 or 2 yrs ago... I couldn't believe it was so prevalent, so flawed, everywhere! )

>;]

Edited July 11, 2005 by PsycoUnc

[MDGx]

I don't like xxcopy because it is nag freeware, it pops up its annoying copyright screen every time it starts, after which I have to press additional keys to make it continue, thus making it useless for automated batch files.

? -that only happens the very first time it's run, to install it, in my experience... after it's installed, it never happens again, no nag, no extra keystrokes, and it also has additional switches for more automation of any prompts/defaults, too...

XCLONE is extremely easy to use, requires only few command line parameters, and I like it mostly because it is very fast [if loading SMARTDRV in memory before using XCLONE].

(here comes more xxcopy praise : I've found xxcopy to be extremely simple (the /clone switch does pretty much everything ya need), and very fast (if HD is defragged, often get 20mb/sec true copy transfer rate, and that's with 5000-10000 files copied; not bad at all))

When I recommended those LFN compliant backup tools, I meant that these are native Windows tools, ... And as we all know, all native Windows 32-bit [a.k.a. Win32 = includes all 9x + NTx MS OSes]tools [backup or not] preserve LFNs, a.k.a. are LFN compliant. This means that whenever you see a program that says it is 32-bit, it implies that it is always LFN compliant.

I think we're confusing terminology here: LFN compliant means it preserves the "long" filename, but does it ALSO ALWAYS preserve the SHORT (8.3) filename which is associated with the LFN? Windows itself does not, when copying files/folders in explorer; -Are u familiar with that classic win98 flaw, I call it the tilde ("~") flaw? This is what I'm talking about, keeping the 8.3 name & the LFN properly associated (if ya copy 2 or more files that have similar short names, like MICROS~1.TXT, and MICROS~2.TXT, at the same time to another directory, it sometimes SWITCHES the short (8.3) filenames, depending on which file it happens to create first... -same thing happens when unzipping files, the short name's "~1,~2", etc, are completely arbitrary, NOT necessarily the same as when ya zipped it up, they (8.3's) are numbered by the new file creation order only... it's a famous flaw, the reason for which DOSLFNBK was created (and is probably much better explained at it's web site)

-and, with my testing, every zip/copy/backup prog (FREE, anyways), have failed to keep the proper association between 8.3 names & LFN's in some cases, making them useless for reliable backups (and believe me, I was SHOCKED when I discovered this, about 1 or 2 yrs ago... I couldn't believe it was so prevalent, so flawed, everywhere! )

I'm not trying to convince you that xclone is better than xxcopy [obviously, your favorite], because it's not, I'm only trying to tell you that there are other tools to consider out there that have merit, depending on user's purpose.

More like this:

http://short.stop.home.att.net/freesoft/filutil1.htm#move

From my point of view [for example, building installer packages like 98SE2ME], I need a simple tool to do the job fast from batch files, the same time be of small file size *and* have a freely distributable license. Guess what, xclone has all that, xxcopy doesn't.

The only way to force xxcopy not to display its annoying copyright multiscreen slow-scrolling message is to delete INSTALL.BAT and add UIXXCOPY.BAT into the directory where the XXCOPY.EXE executable resides, which is exactly what it does when u 1st install it [note that XXCOPY16.EXE only works in native DOS mode (16-bit, no LFNs), and if u don't use native DOS mode, u can safely delete it]. But the moment u delete UIXXCOPY.BAT, it will display that message all over again.

And that is not acceptable, if looking at this from my point of view, of using such tool with installers like 98SE2ME, because I'm not going to add a useless batch file only to prevent xxcopy's messages.

Then if u compare their sizes:

- xxcopy.exe 2.85.9 [current ver] = 274432 Bytes

- xclone.exe 1.3 = 22916 Bytes

again, unacceptable.

And if u look at the distributable license, you'll see that xxcopy.exe cannot be bundled by itself [single file] with other distributable packages, but xclone can.

Again, unacceptable.

Talking about the speed at which such tools perform in native DOS mode:

they copy/move/etc files/folders as fast as your CPU, HD controller + HD are, no matter what else u do.

In Windows mode, that's an entirely different matter, because different disk/file/folder manipulation tools are not the same, some are built to take better advantage of certain Windows features.

And I presume, because xxcopy is a more sophisticated tool, it most certainly performs faster in this respect.

But in the native DOS world, all such tools are equal, and if u time the same cloning operation using both [let's say copy entire Win98SE OS to another drive/partition], you'll see that completion times will be almost identical, depending mostly on the cluster location on HD of respective files at the moment of initiating the copy operation.

Of course, you can use SMARTDRV to speed this all up, but u won't notice any difference between the two if u use the same SMARTDRV command line switches with both.

Another factor to consider is file copy verification, because if it is turned on, the whole operation slows down considerably.

About LFN standard compliance/preserving:

SFNs [short File Names] = MS-DOS 8.3 [file naming convention] are always associated with LFNs in MS Windows 32 and 64 bit [a.k.a. Win32 and Win64 = that include all 9x + NTx OSes] environments, otherwise the entire HD would not be readable.

And all tools that deal with LFN/SFN file operations must comply to preserve both.

That implies their indelible association, because a LFN file in MS Windows world cannot exist without its SFN counterpart.

It is not the tool's fault if LFns are lost, but u can blame the [early] Windows 9x/NT4 OSes, especially original Win95 for this, and poorly programmed setups [including Microsoft's own], INFs, REG files, tweakers etc... that do not account for this "filename truncating" feature.

More info:

http://www.mdgx.com/newtip9.htm#NUMTAIL

Please note that MS lists only 9x + NT4 OSes as affected by this "glitch", not 2000, XP or 2003.

Therefore the way Win9x generates 8.3 SFNs "aliases" from LFNs [not their association], is an entirely different matter.

That's why I have added a combination of VBScript + DOS batch code into E0!X.BAT in order to make sure this doesn't happen, no matter what 8.3 [short name] the "C:\Program Files" folder might have on any computer 98SE2ME would install files to.

To avoid this problem altogether, I've also replaced all "C:\PROGRA~1" instances in my registry with "C:\Program Files", and also fixed all other similar folder names.

And because of this WinOS limitation [sequentially generating 8.3 "aliases" upon file/folder creation], any copy/backup/restore tool based on standard filecopy command would behave the same way.

And you're right, DOSLFNBK is one of the few that preserves LFNs properly because it uses a completely different approach.

Hope this helps.

Edited July 12, 2005 by MDGx

[PsycoUnc]

"And all tools that deal with LFN/SFN file operations must comply to preserve both."

-not true, when copying/unzipping is involved; -they SHOULD comply, they SHOULD have the functions of DOSLFNBK built-in, but they don't... even the win98se os itself (using Explorer to copy or move files) messes-up the LFN/SFN associations, occasionally swapping the "~1, ~2"'s as I've explained/shown before... and that includes all the copy/unzip/backup utils (with the exception of whole-partition backup utils, of course, since they don't create individual files, they just directly copy back all the sectors)... even the built-in "MS BACKUP" tool has this flaw; I've tested it, just like all the copy/zip/backup progs... it made me pull my hair out by the roots, for a very frustrating 2-wk period last year, when I was desperately trying to find a truly reliable backup method/tool... if ya need examples, it's easy to reproduce the flaw, for whichever util ya wish, just ask me for the details...

...

-XCLONE vs. XXCOPY: --yes, for your 98se2me project, xclone is a better choice, I was just talking about a backup/zip situation, where ya want to make multiple copies of the os and compress them into a backup file (ya don't want to have just straight directory copies without zipping em up, too many files to reside on the HD for each backup, not to mention how do ya burn em to backup cd's unless ya zip em up first, cd's filesystems mess with the SFN's even worse... not to mention size... of course keeping a dedicated backup partition is ok, but eventually ya want to be safe and burn em to cd too)

-for 98se2me, where there's just one backup copy of windows directory, it's ok to leave it uncompressed, since it's just one copy, maybe 7000 files, but again if ya want to burn the backup to cd, how do ya do it w/out messin up the SFN's? (in most cases, win98se will function *mostly* ok with a few screwed-up SFN's, but not always: one example, and this is how I stumbled across this problem, is "Windows Media Player" and "Windows Update" folders in Program Files: when zipping/unzipping, the win98se OS frequently swapped their SFN's, and then the winmediaplayer didn't function rite (because some links in registry/etc still used the SFN, not the LFN, of the folder in prog.files...). -that's just one example of why DOSLFNBK is needed for backup purposes, to make sure the SFN's don't get accidentally swapped during restore/unzip, and the xxcopy "/N" feature (stripping LFN's) is needed (or PKZIP's "-n", same thing) before zipping up the system dirs, so that when ya unzip em in a future restore, the SFN's won't be messed up by the inherently-flawed LFN/SFN file creations...

-I suppose ya could keep that backup partition full of unzipped copies of system dirs (using xclone or xxcopy, whichever), and then just once in a while use those "whole-partition" backup progs to save/burn the whole partition to cd's, but I like to make individual backup copies of the 2 system dirs, each one zipped-up into one file, easily/quickly burned to cd, and just as easily/quickly restored, w/out dealing with entire partitions/backups...

-MDGx: how do you yourself make backups to cd? -do ya just do the "entire partition" thingy, or some other method?

Edited July 12, 2005 by PsycoUnc

[PsycoUnc]

! UH OH, MDGx !

-your XCLONE fails the "~1", "~2" LFN/SFN preservation test, too!

-any backup made with XCLONE will have the same potential SFN-swapping flaws!

(in most cases, it won't be noticeable, true, but NOT all cases... it is NOT completely reliable, then, and really should be replaced...)

>;]

(edit: -if u really don't want to use xxcopy, then perhaps a combination of doslfnbk & pkzip "-n -e0" (store, no compression)... both those tools will work in either Windows or real-mode dos, and the combination WILL preserve the SFN/LFN relationship perfectly...)

Edited July 14, 2005 by PsycoUnc

[MDGx]

"And all tools that deal with LFN/SFN file operations must comply to preserve both."

-not true, when copying/unzipping is involved; -they SHOULD comply, they SHOULD have the functions of DOSLFNBK built-in, but they don't...  even the win98se os itself (using Explorer to copy or move files) messes-up the LFN/SFN associations, occasionally swapping the "~1, ~2"'s as I've explained/shown before... and that includes all the copy/unzip/backup utils (with the exception of whole-partition backup utils, of course, since they don't create individual files, they just directly copy back all the sectors)... even the built-in "MS BACKUP" tool has this flaw; I've tested it, just like all the copy/zip/backup progs... it made me pull my hair out by the roots, for a very frustrating 2-wk period last year, when I was desperately trying to find a truly reliable backup method/tool... if ya need examples, it's easy to reproduce the flaw, for whichever util ya wish, just ask me for the details...

There are actually 2 different issues to consider here:

1. LFN + SFN naming convention for file + directory names built into every file + directory entry = those are strictly kept, they are "hardwired" into the file/dir entry header, cannot be changed unless file/dir is renamed or deleted [but if recently deleted, then u have the problem of wrongly assigned "aliases" - see 2. below].

2. SFN "alias" created by OS or file/dir manipulation tools to corespond to LFN of same file/dir = relative, not hardwired, changes every time, depending on what other SFNs already exist [and which cannot be overwritten, unless u use a dedicated LFN tool like DOSLFNBK or XXCOPY] in same directory [for file names] or on same disk/partition [for directory names].

LFN/SFN convention [1. above] must be kept at all times for HD integrity.

SFN alias is the problem you are reffering to: wrong ~1 or ~2 etc SFN names for LFN files/folders, no matter if OS settings [registry, INI, SYS, CFG, BAT etc files] are different, because there is no OS feedback check facility to preserve them properly.

And exactly as you said [i haven't done this kind of experimenting], doslfnbk + xxcopy are probably the only ones that properly backup/restore/copy aliases, by reading correct SFNs.

Om my PC I have eliminated all LFNs that could cause such problems, because I've noticed this issue early on, way back in the Win95 days.

So I renamed all LFN folders to SFNs [and of course, modifed all system/setup/boot/etc files, including the registry accordingly]:

- C:\Program Files to C:\PROGRAMS

- C:\Program Files\Windows Media Player to C:\PROGRAMS\WMP

- C:\Program Files\Internet Explorer to C:\PROGRAMS\MSIE

- C:\Program Files\Common Files to C:\PROGRAMS\COMMONS

- C:\Program Files\Common Files\Microsoft Shared to C:\PROGRAMS\COMMONS\MSSHARED

- %windir%\Downloaded Program Files to C:\PROGRAMS\DLPROGS

- %windir%\All Users to C:\PROGRAMS\ALLUSERS

... etc, u get the idea.

Also, deleted C:\Program Files\Accessories and few others that I don't care for anyway.

So in case I backup the entire OS, I have no folders with LFNs to worry about, only a few LFN files, and because those have unique names, the probability of assigning wrong SFN aliases is extremely small [never ran into problems so far].

I also recommend to everybody to save their entire registry as a REG file, replace all "C:\Progra~1" instances with the proper "C:\Program Files" string [and eventually all other similar LFN folders which are wrongly represented inside the registry as FNAME~1 or FNAME~2 etc], and then rebuild the registry from native DOS mode [example : regedit/c c:\reg\reg.reg].

It takes a lot of time to do all this, but it's a 1 time thing, and in the long run it saved me from all related troubles.

This is [as I was telling VWIMaster in this post: http://www.msfn.org/board/?showtopic=49538...ndpost&p=350569 ] 1 of the reasons I never reformat my HDs/reinstall my OSes every time I bump into a bug.

I find more interesting to solve a bug that locks me out of my OS in a more "constructive" way.

My thoughts on using xxcopy to replace xclone in 98SE2ME:

please see this thread:

http://www.msfn.org/board/?showtopic=46349...ndpost&p=352719

Hope this helps.

[PsycoUnc]

-wow, that IS a lot of work, getting rid of most/all LFN's, and updating registry links as well... wow

...I personally have the bad habit of cramming waaaay too much info into folder names, as to explain exactly what's in that folder, and even what's not! -I've often hit the "max path limit", even inside windows, that way! lol... shame...

--but, yup, your method does sound like the best, safest way to go, avoiding even the possibility of bad linking... personally, again, all those itty-bitty-teeny-tiny file/folder names would drive me nuts... >;]

(ps: I'm surprised this little side-topic hasn't attracted the usual "UPGRADE TO XP, YA DINOSAURS!" squawkers, yet... B) )

Edited July 14, 2005 by PsycoUnc

[MDGx]

(ps: I'm surprised this little side-topic hasn't attracted the usual "UPGRADE TO XP, YA DINOSAURS!" squawkers, yet...  B) )

I'm sure they'll show up soon...

But I'm not worried about them, I'm also using XP OEM since 1 month before the retail edition was out [september 25 2001], but I still prefer 98SE, cuz it's more fun to tweak. B)

[Petr]

- MS IE 6.0 SP1 Patch for Windows 98/98 SE/2000 SP3/2000 SP4/ME/XP SP1 [106 KB]:

http://download.microsoft.com/download/9/0...235-x86-ENU.exe

- MS IE 5.5 SP2 Patch for Windows ME [106 KB]:

http://download.microsoft.com/download/3/1...235-x86-ENU.exe

These two files are EXACTLY the same.

Exactly the same file is used for all IE versions with BROWSEUI.DLL versions 5.0.3502.1000 to 6.0.2899.0, i.e. for Internet Explorer 5.01 SP3 to 6.0 SP1.

No surprise - it adds only one key to the registry.

Petr

[MDGx]

Petr,

Actually all these 3 files are identical [i didn't list the 3rd here because doesn't apply to 98/ME]:

- MS IE 6.0 SP1 Patch for Windows 98/98 SE/2000 SP3/2000 SP4/ME/XP SP1 [106 KB]:

http://download.microsoft.com/download/9/0...235-x86-ENU.exe

- MS IE 5.5 SP2 Patch for Windows ME [106 KB]:

http://download.microsoft.com/download/3/1...235-x86-ENU.exe

- MS IE 5.01 SP3/5.01 SP4 Patch for Windows 2000 SP3/2000 SP4 [106 KB]:

http://download.microsoft.com/download/f/1...235-x86-ENU.exe

Edited July 21, 2005 by MDGx

[erpdude8]

- MS IE 5.01 SP3/5.01 SP4 Patch for Windows 2000 SP3/2000 SP4 [106 KB]:

http://download.microsoft.com/download/f/1...235-x86-ENU.exe

_____________________________________

<{POST_SNAPBACK}>

The IE 5.01/Win2000 KB903235 patch should be listed as MS IE 5.01 SP4/Windows 2000 SP4 patch, MDGx. Microsoft noted in MS security bulletin MS05-037 that Microsoft ended extended security support for IE 5.01 SP3/Win2000 SP3 on June 30, 2005 in the FAQ section. The IE 903235 patch and future IE patches will no longer be supported under Win2000 SP3/IE5.01 SP3 systems after 6/30/2005.

The patches only install from IE 5.01 SP4 (not SP3) to IE 6 SP1.

Edited July 15, 2005 by erpdude8

[Petr]

The patches only install from IE 5.01 SP4 (not SP3) to IE 6 SP1.

No, as I already mentioned, this patch test the IE version and will install for IE 5.01 SP3 too. This is Microsoft engineer's intention.

Petr

[erpdude8]

The patches only install from IE 5.01 SP4 (not SP3) to IE 6 SP1.

No, as I already mentioned, this patch test the IE version and will install for IE 5.01 SP3 too. This is Microsoft engineer's intention.

Petr

<{POST_SNAPBACK}>

my bad. I stand corrected. You & MDGx were right on. The 3 patches MDGx mentioned ARE exactly the same; thus it can work with IE 5.01 SP3. Though in the future new IE patches made after July 2005 will no longer install under IE 5.01 SP3 and WILL require SP4.

btw- MDGx, where did u modify the voltrack.vxd file to make it 4.10.2000? if you edited it in a hex editor it isnt enough. The voltrack.vxd file from your unofficial Win98 voltrack.vxd fix will be 4.10.2000 in Win9x/NT4 Explorer shell only BUT QFECheck will still report it as v4.10.0.1999!! And when I viewed the voltrack.vxd file in WinME's Explorer it says 4.10.0.1999 & when I clicked on the File Version Description item in the Version tab of the file's properties, it says 4.10.2000. You really need to use a Visual Basic Editor [VBE] or a special editor that can read and properly modify VXD files instead of using a hex editor.

and Petr, I have the Q192117 mstcp.dll Win98 patch.

[Petr]

btw- MDGx, where did u modify the voltrack.vxd file to make it 4.10.2000?  if you edited it in a hex editor it isnt enough.  The voltrack.vxd file from your unofficial Win98 voltrack.vxd fix will be 4.10.2000 in Win9x/NT4 Explorer shell only BUT QFECheck will still report it as v4.10.0.1999!!  And when I viewed the voltrack.vxd file in WinME's Explorer it says 4.10.0.1999 & when I clicked on the File Version Description item in the Version tab of the file's properties, it says 4.10.2000.  You really need to use a Visual Basic Editor [VBE] or a special editor that can read and properly modify VXD files instead of using a hex editor.

It is no problem to use hex editor, but the version number has to be edited twice - the first is binary and the second is in ASCII. Sometimes even Microsoft has different binary and ASCII version.

and Petr, I have the Q192117 mstcp.dll Win98 patch.

Thank you, I've got this hotfix already from Microsoft when I asked for Windows2000-KB886765-v2-x86-ENU.EXE hotfix and just to be sure, I have asked for all missing fixes too. No other fixes were available, I was told thath they are no more available.

Do you have any idea how to verify that the OLE automation files version "4526" from this KB886765 work well with Windows 98? At present, SESP (and FESP) contains files version "4522" from W2K SP4, so it sould be OK I think.

Petr

[MDGx]

btw- MDGx, where did u modify the voltrack.vxd file to make it 4.10.2000?  if you edited it in a hex editor it isnt enough.  The voltrack.vxd file from your unofficial Win98 voltrack.vxd fix will be 4.10.2000 in Win9x/NT4 Explorer shell only BUT QFECheck will still report it as v4.10.0.1999!!  And when I viewed the voltrack.vxd file in WinME's Explorer it says 4.10.0.1999 & when I clicked on the File Version Description item in the Version tab of the file's properties, it says 4.10.2000.  You really need to use a Visual Basic Editor [VBE] or a special editor that can read and properly modify VXD files instead of using a hex editor.

Per the advice from the person who created this voltrack.vxd patch, I have reverted back to voltrack.vxd build 4.10.1999, so users would not be mislead in thinking this newer [4.10.2000 unofficial] build includes also the [official] Japanese edition patch from Q234697:

Your modification is fine with me, but it is not a fully valid version 4.10.0.2000. I would not expect this to cause any serious problems. More of concern is what this version number implies: a higher number generally implies that the patches / hotfixes of a lower number are included. There is a KB article for it, but I do not recall its number. I would need the Q234697 hotfix to confirm, but I assume it is not included in the English version 4.10.0.1998 of VOLTRACK.VXD.

I indeed never used Windows 95, but there are other reasons for not patching VOLTRACK.VXD 4.0.0.950: at least one newer version is available as a hotfix, and patching more than one version is too time-consuming. Windows 95 is also more than dead now. My suggestion is: try the patched Windows 98 VOLTRACK.VXD. It reports itself as compatible with Win95, so it may work under Windows 95. VOLTRACK.VXD 4.90.0.3000 probably did not work for you because it reports itself as WinMe version and I most likely changed this to Win95 (sic!) when I used it as a QFE before creating (and now using) the version I sent you.

Hope this helps.