-WOO-HOO! fixed it! -if ya use "/h" (high-level disk access) during the doslfnbk BACKUP phase, the restore phase won't create filesystem errors! scandisk was clean!

I'll test it further, but for now I'm happy!...

>;]

(ps: this doesn't help for ALREADY-CREATED backups, tho... those are lost. )

***-doslfnbk "/h" note: *locksup* system BAD when too many files (couldn't do entire C: drive; had to do /windows & /progra~1 separately...)

-uh oh... "/h" saved 800 FEWER lfn's than without "/h", in same dir! (with /h: 8200 lfn's saved; w/out /h: 9000 lfn's saved!) -this CAN'T be good... (unless the bug in the non"/h" function also causes too many lfn's to be saved... ?)

siiiigh... the saga continues... testing testing & more testing to come.....

! CRAP! the "/h" DOES MISS FILES! -in my case, it missed about 800 files, which is roughly 1 out of every 10! ... so back to square one: NO DOSLFNBK RELIABILITY!

...
...-so, again, anybody know of a RELIABLE, FREE, replacement for DOSLFNBK?

(or of a FREE backup or zip util, which preserves the 8.3/LFN's in win98se?)

(actually, at this point, I'd be willing to PAY (a little) for something that works!)

(sry to continue off-topic here, I'll finish this quickly...)

-WORKAROUND for DOSLFNBK bug: (VERY time-consuming, yet effective)

1) backup whole dir (my case: \Program Files)
2) copy & restore backup to empty temp partition (ex: swapfile partition)
3) scandisk, fix crosslinks/etc...
4) -find the offending sub-dirs (\Plus! & \X-setu~1) by looking at SCANDISK.LOG, and create a new backup EXCLUDING those sub-dirs, then back them up separately.
5) test the new backup by restoring to temp, scandisk (should be no errors this time), and byte-by-byte comparison to orig.

-nasty, but it works... and is the only way to get uncorrupted backup...

(unless someone out there knows of FREE backup/zip tools which PRESERVE 8.3/LFN's in win98se? -or maybe not free, but CHEAP? (<$20?) )

>;]

-COOL! it worked! -we don't have to make separate backups, and all previous backups are still useable!

-during the RESTORE ("/r") function, just exclude ("/s") the problem dirs, then re-run doslfnbk /r with the sub-dirs specifically, one at a time, like thus:

doslfnbk . /r /s Plus! /s x-setu~1
doslfnbk Plus! /r
doslfnbk x-setu~1 /r

-it works, no scandisk errors! all files properly renamed, byte-by-byte comparison is good... only thing is, ya need to find out the problem dirs first... they each do contain a LOT of files, so that's probably it, gotta split the restore function to less than x names in a sub-dir-tree at a time... the documentation does mention something like that...

Decent selection of mostly free(ware) backup tools [see the 32-bit ones that keep LFNs in FAT32/NTFS/etx2 environments]:
http://www.mdgx.com/secrets.htm#FDPT

Bad memory? guide on how to check + DOS and Windows free(ware) tools:
http://www.mdgx.com/newtip8.htm#BADMEM

DOSLFN is issued now in 2 versions:

* DOSLFN.COM v0.32o Long File Names (LFNs) DOS mode TSR 16-bit for MS-DOS
5/6/7/8 and Windows 3.1x/9x/ME supports FAT32 and Joliet CD-ROMs, includes
LOWDMA and FastOpen cache, highly customizable:
http://www-user.tu-chemnitz.de/~heha/hs_freeware/freew.html
Direct download [291 KB, freeware, open source, German]:
http://www-user.tu-chemnitz.de/~heha/hs_freeware/doslfn.zip
More info:
http://www-user.tu-chemnitz.de/~heha/en/hs...re/what_lfn.htm
Improved DOSLFN v0.40a:
http://www.geocities.com/jadoxa/doslfn/
Direct download [290 KB, freeware, right-click to save!]:
http://www.geocities.com/jadoxa/doslfn/doslfn.zip
Uses 12 KB of upper DOS RAM if loaded with LOADHIGH in AUTOEXEC.BAT (upper
memory manager required in CONFIG.SYS).
Load LOWDMA.SYS after UMBPCI.SYS in CONFIG.SYS to fix ISA DMA errors in native
MS-DOS:
http://www.mdgx.com/umb.htm#TOO

I've also had a series of random [unexplained] HD errors recently: turned out to be a faulty 5V power cable, and it took me almost 2 weeks to figure it out.

-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...

>;]

Have you looked at XXCOPY?

It's easy to backup using the /CLONE switch...

XXCOPY <source> <destination> /CLONE


http://www.xxcopy.com/xxcopy10.htm

-yup, that's exactly what I use, xxcopy /clone AND "/N" -to strip off the LFN's before zipping up the dir (otherwise, the zip programs will often mess-up the 8.3 filenames when unzipping (swap the "~1", "~2", etc)), which is why I need to use doslfnbk to back up the LFN's/8.3 filenames first, before stripping using xxcopy's "/N"; then I zip it up, and after unzipping use doslfnbk /r to restore the LFN's to the stripped 8.3 filenames, properly...

[-after EXTENSIVE searching & testing of just about every FREE backup prog/util and zip util, this is the only method I've found that ALWAYS preserves the PROPER 8.3/LFN relationships (other than full-partition backups, of course... but that sux )... -if anybody else has found an other, FREE, prog/util/method, and has tested that LFN/8.3/"~" MS-win98se flaw PROPERLY with it, let me know, please... ]

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.

? -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...

(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))

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.

"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?

! 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...)

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.

-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... )

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.

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

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

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.

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

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.

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.
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

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:



Hope this helps.

-MDGx: re: your vb6sp6 update link page: typo in version # of MSVCP60.DLL:
6.00.9782.0 should be 6.00.8972.0 (as shown in both "version places" in the newest file in vb6sp6)...

-MDGx: re: vb6sp6:
Several of these new files don't already exist at all on my system, so does that mean we need to regsvr em? (just to be safe, I WAS gonna register em all, but it'd be nice to know if it's necessary or not, and if so, do ya need to include that step on your links page? I'll hold off 'til u say yea or nay...)

:edit: -? and a couple of these files have exactly the same version #'s in all places, yet different dates and slightly (1k) different sizes... ?

-thx again,
your humble and unworthy follower PsycoUnc >;]

To my (limited) knowledge, most of MS runtimes are self registering. They register themselves as soon as they are called upon by an app. For those who don't self register, you'll usually get a specific error message aying the app cannot find such or such file. So far I have noticed that problem with one single MS runtime file : MSSTDFM.DLL.

Here are a few handy context menu entries that I am using to register/unregister COM components :


An icon for Ax Files I have made. To be put in the System dir (or elsewhere but then the above registry file must be adapted to its location).

-MDGx: ...siiiigh... -after running your unofficial oleup and the vb6sp6 stuff, my scripting was screwed! -couldn't get any scripts to run from a file (pcpitstop autofixes, downloaded to HD), or on a website (winupdate, pcpitstop tests)... tried reinstalling wscript5.6, vbrun60sp5, xml, etc. and nothing worked (also tried reducing *all* security (enabling everything, everywhere), logging-off/on windows, etc)... also tried replacing the vb6sp6 files back to originals (which I backed up), unregistering/registering, etc... no luck...

-the thing that finally worked, was manually copying all vbrun60sp5 dll's to win\system folder, overwriting... now scripting works again... ???

? any ideas?

(I'll further test, if this disgusted feeling wears off, one step at a time, but I've already spent the last 3 hrs stuck on this...)

(ps: I manually registered the 6 vb6sp6 files which weren't already existing in \system... then unregistered & removed em during troubleshooting... no effect)

---EDIT! DOH! -I spoke too soon (below)! -it IS your OLEUP.EXE, screwin the scripts! Everything was fine, after doing the vb6sp6 files again, then I ran your OLEUP.EXE (since it installs newer builds than vb6sp6), and BOOM! there go the script errors again! -Probably had nothing to do with those 2 exe's (see below) inside vb6sp6, after all...
------------------------

[[[-re: above post: -never mind, I figured it out:

-while unzipping vb6sp6, I ran across 2 .exe's which looked promising: vcredist.exe and vbrun60.exe... I took a peek inside each, they weren't big, looked harmless, like just more auto-update stuff, similar files to what we were updating anyway, so I executed em... -looks like they weren't harmless after all....]]]

[ps: any news about 98se2xp?]

(-while we're already on a bug-hunt, the 98se2me winoldap-at-reboot bug came back, as soon as ya changed your code back, a little while ago, but ONLY if option #3 isn't already installed... )

PsycoUnc, I just got all of those files dld[dial-up] was gonnna install today, will save vb6 till last and watch this post. Thnx for headsup on possible prob.

-turns out the vb6sp6 files were no prob, it's the Unofficial OLEUP.EXE file which MDGx offers to use after vb6sp6...
-I tried the OLEUP.EXE on another install of w98se, without the vb6sp6 files, and the scripting (activeX, too) was shot, just the same... u can go ahead w/vb6sp6 files (16 of em, unzipped from all those cabs inside), but let me know if u have any probs w/his OLEUP.EXE update... (try going to winupdate, after his OLEUP.EXE update, see if it still works... or any site with activeX, like PcPitstop.com...)
>;]

(ps: ouch, dialup downloading that 60mb+ vb6sp6 file! And we only need 5mb (16 files) out of it... (1.5 mb zipped)... lol... -hey, if you'd like to save a lot of time, avoid all the unzipping and comparing version numbers, I can email ya the 1.5mb zipped 16 files... shouldn't be any license probs, it's freely available... PM me... )

Problems confirmed here with Oleaut update. Some of my BHOs (Net Transport and Flash Saving Plugin) weren't working anymore properly from IE. Downgrading Oleaut solved the problem.

Same here even lost my firewall,antivirus,windows update,shockwave and other programs.

-at least it's easy to fix: just unzip a vbrun60sp5.exe (from Micro$hit; google it) (7-zip will unzip it, and 7-zip is free), shutdown to ms-dos, and copy *.dll from it to \windows\system, overwriting all... (ya have to do it manually, for some reason it won't install right automatically)...
>;]
(edit: I suppose ya could also use vbrun60sp6.exe, newer, just saw it's available at M$, but I haven't tried it yet; I unzipped the sp6 version, and it fixed the prob...)

So what version is OK and what not? Windows 2000 SP4 version (4522 - included in SE SP 2.01) is OK and Windows 2000 post SP4 KB886765 hotfix (4526) not? Od do you use IE6SP1 version (4518)?

Is there any easy way how to reproduce the wrong behavior?

For example links to your plugins?

Petr

Hi Petr,

That's the plugins :

http://www.browsertools.net/Flash-Saving-Plugin/index.html

http://www.321download.com/LastFreeware/pa...Net%20Transport

I have an older version of the Flash plugin than the one on the above page.

My setup is WinME IE5.5 SP2 + latest security updates.

What version is OK ? I do not know as I have downgraded to 4275. For me 4275 is OK. I am not too sure about the highest version number of the Oleaut I had installed without having problems. I think it was 4522. I'll be upgrading to those again.

As well I had other problems with 4526, similar to those PsychoUnc has, with ActiveXs but I thought at first it was because I changed my default security settings in IE. Msdxm would not want to load to play video streams in IE for example.

And then I did downgrade the files from DOS and all problems were gone.

PS : Have you installed 4526 yourself ?

I think VB6SP5, VB5SP6, VC6SP5 and VC6SP6 all contain the same version of the oleaut runtimes : 2.40.4275


Because of the file version that is inferior to the ones already on the machine. The installer checks this and doesn't downgrade the files.

There are GUI tools that allow to downgrade locked files from Windows for those who don't like DOS or write by hand a wininit.ini file.

http://noeld.com/dl.asp?path=copylock.zip&
http://www.jkh.no/jkh/installfile/Installfile.zip

Hi Guys,

No need to panic...
I was testing [same as you were] the new OLE 2.40.4526 files, and found out that VBScript + DX Media 6.0 TransAnim functions stopped working in MS IE 6.0 SP1.
But on the other hand, all OLE core functions I've tested worked ok so far.
So I have updated OLEUP.EXE [446 KB]:
http://www.mdgx.com/files/OLEUP.EXE
Posted here:
http://www.msfn.org/board/?showtopic=46581
and here:
http://www.mdgx.com/add.htm#OLE
to include older OLEAUT32.DLL 2.40.4522 from Win2000 SP4, which fixed all problems.
_________________________________

PsycoUnc:
To test to see which DLL / OCX files in %windir%\system need to be registered with regsvr32.exe , u can create a DOS batch file and call it RS.BAT [example]:

and then run something like this [u need to type only the full name + extension of the file u want to regsvr]:

RS OLEAUT32.DLL

To manually test if a DLL or OCX accepts DLLRegisterServer or DLLInstall functions, just run [example using a DLL that does not contain these functions]:

%windir%\system\regsvr32 %windir%\system\asycfilt.dll

and then:

%windir%\system\regsvr32 /i %windir%\system\asycfilt.dll

As u can see, asycfilt.dll does not accept DLLRegisterServer nor DLLInstall functions, therefore does not need to be registered using regsvr32.

More info:
http://www.mdgx.com/newtip13.htm#REGAX

Hope this helps.

I just tried to use Net Transport from http://www.axitech.hu/nettransport/downloa...Setup_multi.exe with IE 6.0 SP1 and latest updates and SE SP 2.0.1 and I see no difference in behavior with 4522 and 4526 OLE automation files - if I click downloadable link, Net Transport pops up and starts downloading the file. Where should be the problem?

Flash saving I'm evaluating now - but I'm receiveing error message that FLASHBUTTON.DLL/210 line 7 generated library is not registered error. I have to check what dies it mean.

I did simple comparison of internal structure of 4522 and 4526 files - asycfilt.dll, olepro32.dll, stdole2.tlb seems to be almost exactly the same, oleaut32.dll has one small difference - one import was added:
Imp Addr Hint Import Name from ADVAPI32.dll - Not Bound
-------- ---- ---------------------------------------------------------------
00002004 12F RegOpenKeyExW

but this should be no problem.

It would be interesting to see if the same problems are on Windows 2000 too.

Petr

Hi MDGx, could you give me some steps how to verify this non-functionality on my system too?

Petr

BTW, MS in Q321915 recommends OLE version 4515 in some cases

http://download.microsoft.com/download/msn...us/mcrepair.exe


Petr

Same error as I had.



It was simply not poping up anymore to start the download. You have maybe installed a different version of Net Transport (I use 1.87 which is the last freeware version) or it might be due the fact that IE5.5 and 6 files are vastly different.

I have now installed the new downgraded upgrade and have no problems with any of the above. I just have to check that msdxm wants to display streaming video.


You've asked before me.

I have tried OLE 4526 on my test system (W98 FE + IE5.01SP3) and it stopped displaying the Flash content - there is probably really something rotten in this hotfix.
http://support.microsoft.com/?kbid=886765
It claims to repair a memory leak only but it seems there are much more changes.

Petr

I saved a couple of DirectX Transform demos on my HD, I can send them in email if u wish.
But MSDN has a nice one here:
http://msdn.microsoft.com/archive/en-us/sa...ransformwizard/
Another nice 1 here [not by MS]:
http://www.erwin-020.tripod.com/awal.html
Make sure u use MS IE 5.5 SP2 or 6.0 SP1 to view those web pages + demos.

Al 9x/ME OSes require DX Media 6 APIs already installed for this to work:
http://www.mdgx.com/dx.htm#DXM
Older versions of some of these files are installed by MS IE 5.5/5.5 SP1/5.5 SP2/6.0/6.0 SP1. Newest versions are installed only by DXM9X.EXE [9x/ME] + DXMNT.EXE [NT4/2000/XP/2003].
DXM9X contains files from WinME setup CD [also installed by 98SE2ME] + DXM 6 [not available anymore].
DXMNT contains newest files from XP SP2.
2003 SP1 also installs DXMNT files.

If using OLEAUT32.DLL 2.40.4526 [from 2000 SP4 UR1] these demos do not work.
But they work ok with OLEAUT32.DLL 2.40.4522 [from 2000 SP4] and other older versions I have tried.

Hope this helps.

Not so nice as the page apparently dropped a Trojan that has been intecepted by Antivir. After which IE crashed in kernel32.dll.

PS : I can't reproduce that.

Same here, haven't seen any errors with offline apps.
The only time I noticed errors was while running VBScripts + DX Transforms from within MS IE 6.0 SP1.
DX Transform code is accessed thru VBScript code implemented in a web page.

I have looked at OLEAUT32.DLL 2.40.4526 in Dependency Walker:
http://www.dependencywalker.com/
and didn't notice anything "special" compared to OLEAUT32.DLL 2.40.4522 .

Regarding the fact that this web page is on Tripod servers, it is well known they use JavaScript/VBScript, ActiveX, IFRAME tags and other BHO-inducing spyware targeted to MS IE users, to "push" their ads/etc.
I don't have that problem, because I'm using:
1. A huge HOSTS file which disables [among other 117,000 adware/spyware servers] Tripod servers.
U can get it here:
http://www.mdgx.com/modem.htm#HOS
2. Firefox 1.0.6:
http://www.mdgx.com/toy.htm#MOZ
which does not use ActiveX, BHOs or VBScript.

Hope this helps.