[erpdude8]

You're still wrong soldier1st. Even if you use non-IE apps that does NOT mean
you're out of the woods with security problems. Even non-Microsoft software
can have potential security flaws. But at least they're harder to exploit than with IE.

Tarun, try using IEradicator to remove IE6. Get it here:
http://www.litepc.com/ieradicator.html
I use this tool to uninstall IE when IE's uninstaller doesn't work.

The IE uninstaller in WinME won't work if WinME's system file protection feature
is disabled. I found that out several months ago when I prevented 'Statemgr' from
running by disabling it from the MSConfig tool and restarting WinME, I couldn't
remove IE. When I re-enabled Statemgr and run the IE uninstall tool, it worked.

Forget about the Q249973 update, CLASYS. It's CRAP! Go to Axcel216's addons page:
http://www.mdgx.com/add.htm
And click on the links to download newer riched20.dll, riched32.dll & usp10.dll files.
They're better than the ones found in the Q249973 patches.

[CLASYS]

Tarun, on Nov 29 2004, 10:06 AM, said:

CLASYS, on Nov 29 2004, 07:37 AM, said:

After a reboot, I do notice that it DOES take a bit longer for the system to come up, which is what most of us would expect, since VMM32.VXD is being thwarted, etc.

However, I was able to set DMA on the controller and IT TOTALLY WORKS NOW!

Thus, it would appear that the compaction process that creates VMM32.VXD could be buggy; the fix in that case is to not use it!

Indeed it does sound like your VMM32.VXD had problems when it was built during install. You may want to try and reconstruct it.

This is a testbed system created thus:

• Format drive C:
  
• Install 98SE on C: drive selecting all options allowed except WebTV
  
• After last reboot, resolve Realtek 8139 NIC using latest (616) driver on D: drive
  
• Don't bother enabling DMA on Opti Hard Disk Controller because it will make system lockup predictably [Tested on a previous otherwise identical test installation on this machine]
  
• Add files indicated as being imbedded in VMM32.VXD into IOSUBSYS and SYSTEM directories. System Device Manager acknowledges them as now independent of VMM32.VXD
  
• Reboot; takes longer to come up; this was expected!
  
• Enable DMA in hard disk and CD-ROM
  
• After reboot, major speed improvement since DMA enabling makes it run faster as expected; no system lockup whatsoever. System behaves exactly like similar systems based on Intel chipsets. DMA can be enabled and disabled at will with predictable performance changes. Yet, if you do NOT remove the VMM32.VXD dependancy, you cannot ever enable DMA!

Clearly, there is no bug per se in the 98se built-in support code for the Opti chipset, or else it couldn't ever work. However, something gets "lost" in the process of creating VMM32.VXD by Windows itself when it self-creates that file, etc.

So, what would you have me reconstruct?

What are the files Gape is adding to \...\VMM32 to override VMM32.VXD? As I understand it, some are specifically because of hotfixes beyond 98SE release, but some are because he also noticed something "works differently".

[Note: "works differently" is official MicroSpeak for any change in how something works, no matter how big or small, important or not important. It is part of MS UML [User Manipulation Language] SP2 as used with Windows XP Service Pack 2 to deflect and minimize the impact SP2 has on many people's systems after installing SP2. UML cannot be uninstalled and all support contracts are automatically entered into and cannot be cancelled. ]

cjl

[Tarun]

CLASYS, on Nov 29 2004, 12:59 PM, said:

So, what would you have me reconstruct?

What are the files Gape is adding to \...\VMM32 to override VMM32.VXD?  As I understand it, some are specifically because of hotfixes beyond 98SE release, but some are because he also noticed something "works differently".

This has been discussed in this thread and many others. Remember, the Search feature is your friend.

Article on how to rebuild VMM32.VXD

A utility for those who do not wish to use VMM32.VXD titled WinPatcher. Basically scans the system and VMM folders and allows extraction of the files from the CAB files.

[CLASYS]

Tarun, on Nov 29 2004, 01:04 PM, said:

CLASYS, on Nov 29 2004, 12:59 PM, said:

So, what would you have me reconstruct?

What are the files Gape is adding to \...\VMM32 to override VMM32.VXD?  As I understand it, some are specifically because of hotfixes beyond 98SE release, but some are because he also noticed something "works differently".

This has been discussed in this thread and many others. Remember, the Search feature is your friend.

Article on how to rebuild VMM32.VXD

A utility for those who do not wish to use VMM32.VXD titled WinPatcher. Basically scans the system and VMM folders and allows extraction of the files from the CAB files.

Searching through the forum as you suggested, I realize there has been some furor over this subject. Since this is the time to "get it right" for the benefit of releasing the new SP, I just want it stated succinctly:

1) There are factions for and against the notion of even having VMM32.VXD and whether or not it either helps some things or hurts others. Within this discussion are claims of performance improvements/lack thereof and in particular case a report of a vanilla system build that probably creates the file initially corrupted, thus the "loose" files are better than the corrupted one, or at least this is the theory behind what I have observed.

2) There is the possibility that it gets created wrong when the system was first installed or somehow gets corrupted later.

3) There is an article from the people who insist that MS is correct and that there are no benefits whatsoever from displacing VMM32.VXD, for the purpose of rebuilding VMM32.VXD when it is discovered to be corrupted for whatever reason, etc.

4) There is posted a utility to carry out the method of eliminating the need for VMM32.VXD entirely.

5) There is posted a link to a VMM32.VXD known to be stable, but was created for Win ME; does this particular file apply to 98SE?

6) The SP will include several VXD files in part because it is necessary as the files are updated by the SP itself, and partly because Gape believes that there is a performance boost if certain others are additionally added in "loose" form despite not being updated. Are there any other files that would be considered as a portion of VMM32.VXD beyond this set?

7) Most importantly, what is the method the SP will use to best implement a stable result after applying it?

Part of what I read here is that unless you can prove that VMM32.VXD isn't corrupted, it's always safer to run with all of the "loose" files, albeit it boots slower. Conversely, rebuilding VMM32.VXD to a known non-corrupt state should be as good as having the loose files with the added benefit of shortening boot-up times. However, some report that VMM32.VXD eats some resources as compared to some form of perhaps selective override at least some "loose" files, etc.

Do I have it right or what? Someone please show me the errors of my ways, if any.

cjl

[Tarun]

CLASYS, on Nov 29 2004, 06:19 PM, said:

Searching through the forum as you suggested, I realize there has been some furor over this subject.  Since this is the time to "get it right" for the benefit of releasing the new SP, I just want it stated succinctly:

1)  There are factions for and against the notion of even having VMM32.VXD and whether or not it either helps some things or hurts others.  Within this discussion are claims of performance improvements/lack thereof and in particular case a report of a vanilla system build that probably creates the file initially corrupted, thus the "loose" files are better than the corrupted one, or at least this is the theory behind what I have observed.

2)  There is the possibility that it gets created wrong when the system was first installed or somehow gets corrupted later.

3)  There is an article from the people who insist that MS is correct and that there are no benefits whatsoever from displacing VMM32.VXD, for the purpose of rebuilding VMM32.VXD when it is discovered to be corrupted for whatever reason, etc.

4)  There is posted a utility to carry out the method of eliminating the need for VMM32.VXD entirely.

5)  There is posted a link to a VMM32.VXD known to be stable, but was created for Win ME; does this particular file apply to 98SE?

6)  The SP will include several VXD files in part because it is necessary as the files are updated by the SP itself, and partly because Gape believes that there is a performance boost if certain others are additionally added in "loose" form despite not being updated.  Are there any other files that would be considered as a portion of VMM32.VXD beyond this set?

7)  Most importantly, what is the method the SP will use to best implement a stable result after applying it?

Part of what I read here is that unless you can prove that VMM32.VXD isn't corrupted, it's always safer to run with all of the "loose" files, albeit it boots slower.  Conversely, rebuilding VMM32.VXD to a known non-corrupt state should be as good as having the loose files with the added benefit of shortening boot-up times.  However, some report that VMM32.VXD eats some resources as compared to some form of perhaps selective override at least some "loose" files, etc.

Do I have it right or what?  Someone please show me the errors of my ways, if any.

cjl

1.) I run Windows ME and have found my system to be much more stable and faster when using the VMM32.VXD

2.) That has indeed been confirmed as a bug on Windows 9x, it all depends on the hardware.

3.) I have checked with many PC techs and asked on several forums about the Infinisource website; it is correct and reliable.

4.) If you are referring to WinPatcher, that would indeed be a creation of mine to help automate the process if anyone chooses not to use VMM32.VXD (which I do not recommend unless you are experiencing problems)

5.) Another file that I constructed with the help of several PC techs, however I do not have a Windows 98 machine around and thus am unable to create one for 9x versions. The ME version provided will not work on Windows 9x machines as it asks for MS-DOS 8.0.

6 and 7 will be left for Gape since he's constructing the SP.

VMM32 is a good file to have in your system and running if it is constructed properly and without bugs (As some Windows OS' have issues with the creation of this file).

You can also check this link where I asked about this instance. DjLizard is a certified PC technician and he definitely knows his stuff.

[soldier1st]

tarun was talking about internet explorer not non microsoft software,stay on topic please

[Tarun]

erpdude8, on Nov 29 2004, 12:48 PM, said:

The IE uninstaller in WinME won't work if WinME's system file protection feature is disabled.  I found that out several months ago when I prevented 'Statemgr' from running by disabling it from the MSConfig tool and restarting WinME, I couldn't remove IE.  When I re-enabled Statemgr and run the IE uninstall tool, it worked.

Ah, then that would be why. I disabled and removed System Restore. ;)

[Gape]

CLASYS, on Nov 30 2004, 01:19 AM, said:

6)  The SP will include several VXD files in part because it is necessary as the files are updated by the SP itself, and partly because Gape believes that there is a performance boost if certain others are additionally added in "loose" form despite not being updated.  Are there any other files that would be considered as a portion of VMM32.VXD beyond this set?

7)  Most importantly, what is the method the SP will use to best implement a stable result after applying it?

Part of what I read here is that unless you can prove that VMM32.VXD isn't corrupted, it's always safer to run with all of the "loose" files, albeit it boots slower.  Conversely, rebuilding VMM32.VXD to a known non-corrupt state should be as good as having the loose files with the added benefit of shortening boot-up times.  However, some report that VMM32.VXD eats some resources as compared to some form of perhaps selective override at least some "loose" files, etc.

VMM32.VXD is a compressed file of a collection of VXD files. Its contents depend on system configuration.

Because it's a compressed file, any corruption affects most of VXD files in it. For example: Assume that you have a ZIP file which has 10 files in it. If this ZIP file corrupts, you cannot extract ANY of these 10 files with using normal ways.

On my tests, an uncompressed VMM32.VXD file (still ONE file like a TAR package) has a small performance improvement. But, the booting process is slower a bit, too.

In the 2.0, I only copies updated VXD files onto VMM32 directory. Perhaps, a reconstructed VMM32.VXD will be better, but it is not an easy process. Perhaps it will be on the future versions.

[soldier1st]

but will this vmm32 ask for msdos 8?cuzz i hope not

[CLASYS]

Gape, on Nov 30 2004, 02:30 AM, said:

VMM32.VXD is a compressed file of a collection of VXD files. Its contents depend on system configuration.

Because it's a compressed file, any corruption affects most of VXD files in it. For example: Assume that you have a ZIP file which has 10 files in it. If this ZIP file corrupts, you cannot extract ANY of these 10 files with using normal ways.

On my tests, an uncompressed VMM32.VXD file (still ONE file like a TAR package) has a small performance improvement. But, the booting process is slower a bit, too.

In the 2.0, I only copies updated VXD files onto VMM32 directory. Perhaps, a reconstructed VMM32.VXD will be better, but it is not an easy process. Perhaps it will be on the future versions.

I'm still slightly confused:

1) How did you test an uncompressed version if it's a compressed file? What process makes it an uncompressed variant? Or is this just the "natural" result of adding in the updated component .VXD files necessitated by the SP?

2) What performance improves? Is this possibly merely because there is redundant resources being used, i.e., for both the VMM32.VXD monolith being in memory as well as the authoritative drivers also being in memory [i.e., the ones you added because they are updated per the SP, etc.] "wasting" memory space?

3) Can I assume that if we carry out the infinisource-based method on the updated collection of files [after the SP] we can get both the performance and the resources back?

Part of why I ask is that my test example indicates at least the possibility that Tarun suggests, i.e., the installation failed to make a non-corrupted VMM32.VXD. Thus, to fix the problem, I have no choice but to rebuild the VMM32.VXD file anyway. Thus, it would be best to defer this to the point where all the driver considerations are stable to avoid having to do this multiple times, correct?

cjl

[Gape]

CLASYS, on Nov 30 2004, 09:01 PM, said:

I'm still slightly confused:

1)  How did you test an uncompressed version if it's a compressed file?  What process makes it an uncompressed variant?  Or is this just the "natural" result of adding in the updated component .VXD files necessitated by the SP?

2)  What performance improves?  Is this possibly merely because there is redundant resources being used, i.e., for both the VMM32.VXD monolith being in memory as well as the authoritative drivers also being in memory [i.e., the ones you added because they are updated per the SP, etc.] "wasting" memory space?

3) Can I assume that if we carry out the infinisource-based method on the updated collection of files [after the SP] we can get both the performance and the resources back?

Part of why I ask is that my test example indicates at least the possibility that Tarun suggests, i.e., the installation failed to make a non-corrupted VMM32.VXD.  Thus, to fix the problem, I have no choice but to rebuild the VMM32.VXD file anyway.  Thus, it would be best to defer this to the point where all the driver considerations are stable to avoid having to do this multiple times, correct?

cjl

You can uncompress VMM32.VXD with DEVLIB.EXE or VXDLIB.EXE. Both of them are available on Axcel216's site.

For example, a compressed VMM32.VXD is 800 KB, after uncompressing it, its size is more than 2 MB. It is still ONE file. I didn't extract any VXD file into VMM32 directory. I tested uncompressed VMM32.VXD with WinTune98 and PCPlayer 3D Benchmark on the April 2000. The results were:

Compressed VMM32.VXD: PC Player Direct3D Benchmark - 38.4
Uncompressed VMM32.VXD: PC Player Direct3D Benchmark - 42.8

You're right about the resource problem. Updated VMM32 files in the SP 2.0 is approximately 500 KB, it was 1 MB in the SP 1.x. The reason of difference is VMM.VXD file. I use RPLCLDR.EXE tool (it is also available on the above link) in the SP 2.0 for replacing VMM.VXD (one of the VMM32.VXD files).

If we reconstruct the VMM32.VXD with updated files, we can get resources back. But I think the performance doesn't change.

[Gape]

CLASYS, on Nov 29 2004, 02:37 PM, said:

hotfix xxxxxx installs 4.10.2223 of a file; hotfix yyyyyy installs 4.10.2224 of same file; hotfix zzzzzz installs 4.10.2226 of same file.  However, if xxxxxx is installed BEFORE yyyyyy or zzzzzz or the SP, then the file stays at 4.10.2223!  If the file is manually deleted, QFECHECK info for each hotfix correctly state what rev of the file they require.  Yet, if xxxxxx gets installed, then each QFECHECK section gladly accepts 4.10.2223 as the revision they "like".

If xxxxxx is never installed, all else works as intended.  Apparently, something within the installer for xxxxxx makes the installation of the file at 4.10.2223 too "permanent".

I don't understand the above problem. Is it a particular hotfix? Which one?

If a file's revision 2223, it contains only one fix. If it's 2224, it contains two fixes etc. Of course, 2224 revision has 2223's fix.

Adding QFECHECK information is a difficult process because of the SP's mechanism. I need a more powerful installer such as InnoSetup or NSIS for these complex processes. But they are some disadvantages, too. (For example, you can't see inside of a InnoSetup file with WinZip/WinRar).

[MasterT]

So Gape, are you going to release any working version this week?

[soldier1st]

cuzz i could test it n report any problems

[CLASYS]

Gape, on Dec 1 2004, 02:04 AM, said:

CLASYS, on Nov 29 2004, 02:37 PM, said:

hotfix xxxxxx installs 4.10.2223 of a file; hotfix yyyyyy installs 4.10.2224 of same file; hotfix zzzzzz installs 4.10.2226 of same file.  However, if xxxxxx is installed BEFORE yyyyyy or zzzzzz or the SP, then the file stays at 4.10.2223!  If the file is manually deleted, QFECHECK info for each hotfix correctly state what rev of the file they require.  Yet, if xxxxxx gets installed, then each QFECHECK section gladly accepts 4.10.2223 as the revision they "like".

If xxxxxx is never installed, all else works as intended.  Apparently, something within the installer for xxxxxx makes the installation of the file at 4.10.2223 too "permanent".

I didn't understand the above problem. Is it a particular hotfix? Which one?

If a file's revision 2223, it contains only one fix. If it's 2224, it contains two fixes etc. Of course, 2224 revision has 2223's fix.

Adding QFECHECK information is a difficult process because of the SP's mechanism. I need a more powerful installer such as InnoSetup or NSIS for these complex processes. But they are some disadvantages, too. (For example, you can't see inside of a InnoSetup file with WinZip/WinRar).

Sorry about the confusion, but I wasn't at my home machine when posting! [From memory, was making theoretical scenario, etc.]

Here's the EXACT info and the EXACT problem:

There are a series of updates that affect VIP.386 and bring it to various revisions:

• Q238329 - Fragmented IGMP Packet May Promote "Denial of Service" Attack
  [Brings VIP.386 to 4.10.2223; I have this update]
  
• Q238453 - Data in Route Pointer Field Can Bypass Source Routing Disable
  [Brings VIP.386 to 4.10.2224; I have this update]
  
• Q242962 - "BUG CHECK Error in VIP" Error Message When Obtaining a DHCP Lease
  [Brings VIP.386 to 4.10.2225; I do not have this update]
  
• Q259728 - MS00-029: Windows Hangs with Fragmented IP Datagrams
  [Brings VIP.386 to 4.10.2226; I have this update; SP 1.6.2 also does this]

In any "normal" situation, one would expect that installing any of the above in any order would always do the correct thing, i.e., if the file is at the correct revision or higher, update the QFECHECK info and otherwise do nothing. If the file is at a lower revision, then update it to the revision provided within the hotfix, etc.

Unfortunately, this is a "pathological" case in that should Q238329 ever be installed, all attempts to change VIP.386 from revision 4.10.2223 will fail short of manual removal of the file!

All of the following have been observed:

Attempts to install either Q238453 or Q259728 or SP 1.6.2 after Q238329 is already installed will fail to change the file from revision 4.10.2223!

One way to fix it is to manually delete the file then do any of the above actions and they will succeed [provisionally].

The weird thing is that the QFECHECK program only "complains" correctly when the file is removed, i.e., the QFECHECK section for example Q238453 would indicate that the file is missing and it expects 4.10.2224; same for Q259728 except wants 4.10.2226.

But when Q238329 is already installed, and then these other updates are applied, not only does the file stay at 4.10.2223, but the QFECHECK information shown on all of the updates shows the file is indeed at 4.10.2223 [which is the truth!], but weirdly enough there are no QFECHECK warnings of any kind!

If you delete the file, and then update [which then works!] all QFECHECK info is as expected. The maximal case would be:

1) Install Q238329

2) Delete VIP.386

3) Install Q238453

4) QFECHECK now correctly shows VIP.396 at 4.10.2224 in both UPD238329 and UPD238453 sections.

5) Install Q259728

6) QFECHECK now correcly shows VIP.386 at 4.10.2224 in UPD238329 and UPD238453 and UPD259728 sections.

Alternatively to 6) use SP 1.6.2 and you get to the same place; all installed QFECHECK sections correctly show that VIP.386 is at 4.10.2226 courtesy of SP 1.6.2, which of course is the expected value, etc.

But if you have Q238329 installed, and you do NOT delete VIP.386 at 4.10.2223, all subsequent steps will fail to upgrade the file seemingly with the "approval" of any installed QFECHECK info that should be complaining about inadequate version level, etc.

Thus, it would appear that in order for the SP to correctly install, something like the following has to be done:

Delete VIP.386 unless it is already at 4.10.2224 level or greater; then install 4.10.2226 [or greater should that ever exist; doubtful!]

There's got to be some explanation of how the installer within Q238329 causes the file to be overly "permanent" or something like that, etc.

Hope that explains it!

cjl (Long explanations 'r us)

PS: Since Gape [besides his millions of other talents!] is THE .inf guy, here is what's inside of the Q328329 update [besides all the usual files including 3304UPSE.cat] which is usually distributed as 3304upse.EXE.

Contents of 3304UPse.inf:

; 3304UPSE.INF
; This is the Setup information file to install the Windows 98 Second Edition IGMP Security Update.

[Version]
AdvancedINF = 2.5, %AdvPackWarn%
signature="$CHICAGO$"

[DefaultInstall]
CopyFiles=W98Upd.Copy.qfe,W98Upd.Copy.Sys,W98Upd.Copy.Hlp,W98Upd.Copy.inf,Win98.Copy.cab
AddReg=W98Upd.AddReg

[DestinationDirs]
; 10=Windows, 11=SYSTEM,17=INF, 18=Help,

W98Upd.Copy.Sys = 11
W98Upd.Copy.qfe = 10
W98Upd.Copy.Hlp = 18
W98Upd.Copy.inf = 17,QFE
Win98.Copy.cab = 10,Options\Cabs

[W98Upd.Copy.Sys]
vip.386,,,32

[W98Upd.Copy.qfe]
QFECheck.exe,,,32

[W98Upd.Copy.Hlp]
QFECheck.hlp,,,16

[W98Upd.Copy.inf]
3304UNSE.INF

[Win98.Copy.cab]
vip.386,,,32

[W98Upd.AddReg]
;msinfo32
HKLM,"Software\Microsoft\Active Setup\Installed Components\%GUID%",,,"%UpdName%"
HKLM,"Software\Microsoft\Active Setup\Installed Components\%GUID%","IsInstalled",0x10001,01,00,00,00
HKLM,"Software\Microsoft\Active Setup\Installed Components\%GUID%","Locale",,"%LANG%"
HKLM,"Software\Microsoft\Active Setup\Installed Components\%GUID%","Version",,"%VERSION%"

;qfecheck
HKLM,%UpdateKey%\%UpdateSubKey%\,,,"%UpdName%"
HKLM,%UpdateKey%\%UpdateSubKey%,%11%\vip.386,,"4.10.0.2223"

[Strings]
;Non-localizable
GUID = "{2a1700c0-5c86-11d3-a7ad-0000f804e326}"
LANG = "EN"
VERSION = "4.10.0.2222"
UpdID = "UPD3304"
UpdateKey = "Software\Microsoft\Windows\CurrentVersion\Setup\Updates"
UpdateSubKey = "W98.SE.IGMP.SECURITY.UPD"
UninstallKey = "SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall"

;Localizable strings
UpdName = "Windows 98 Second Edition IGMP Security Update"
AdvPackWarn = "You need a newer version of advpack.dll."

[SourceDisksNames]
55="IGMP Update","",0

[SourceDisksFiles]
QFECheck.exe = 55
QFECheck.hlp = 55
VIP.386 = 55
3304UNSE.INF = 55

That's it! I can provide any and all of the portions of the thing [or the entire original 3304UPse.exe] to anyone who wants it. Unfortunately, this is one update we wish NO ONE had!

[erpdude8]

Read MS article 206071 on how Win98 hotfixes work:
http://support.micro...b/206071/EN-US/

I get what your saying, CLASYS but you may as well delete the old registry qfecheck
entries after installing the most recent update. Remember that updates for
Windows 9x & ME systems ARE cumulative. Version 4.10.2226 of the vip.386
file contains its new fix plus the older ones from versions 4.10.2225, 4.10.2224
and 4.10.2223. When I install a newer vip.386 fix like the Q259728 update, I
run Regedit and delete the older qfecheck entries such as the Q242962, Q238453 &
Q238329 qfecheck entries from the
'HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\Updates'
branch. That way the Qfecheck program doesn't list the older vip.386 updates and
there is less confusion.

[erpdude8]

Gape, on Nov 26 2004, 04:44 AM, said:

This problem comes from IE 6. Because if you use IE 5.5 or older version, you don't have this problem.

Problem files are BROWSEUI.DLL and BROWSELC.DLL. The only fix I know is that you must replace these two files with IE 5.5 SP2 versions.

For more information, please look at this link.

A fix for this problem is not in the SP 2.0, because adding a IE 6.0 specific fix is difficult. I hope I can add it in the 2.1.

Follow up on the problem on deleting a large number of files and causing
Windows Explorer to hang. I've done some tests on this on two of my
computers at home. One using WinME & IE6 SP1 and the other using WinXP SP2.
I copied a lot of files totaling almost 600 Mb from a CD on both systems onto
a temp folder in Windows Explorer. I reboot and reload Windows Explorer.
Then I deleted the temp folder where I copied all those files. The problem happened
on my WinME computer but not on my WinXP machine. Guess the problem was
fixed in WinXP SP2. Note that at the www.frankprovo.com site he does NOT mention
Windows XP. Not sure if the problem happens with XP SP1 or the original release
of XP.

[Gape]

erpdude8, on Dec 1 2004, 07:19 PM, said:

Follow up on the problem on deleting a large number of files and causing
Windows Explorer to hang.  I've done some tests on this on two of my
computers at home.  One using WinME & IE6 SP1 and the other using WinXP SP2.
I copied a lot of files totaling almost 600 Mb from a CD on both systems onto
a temp folder in Windows Explorer.  I reboot and reload Windows Explorer.
Then I deleted the temp folder where I copied all those files.  The problem happened
on my WinME computer but not on my WinXP machine.  Guess the problem was
fixed in WinXP SP2.  Note that at the www.frankprovo.com site he does NOT mention
Windows XP.  Not sure if the problem happens with XP SP1 or the original release
of XP.

erpdude8,

Thanks for the feedback. But I'm afraid of that 2000, XP and XP SP1 don't have this problem. It occurs only if you use both Windows 98 and IE 6.0.

[CLASYS]

erpdude8, on Dec 1 2004, 12:04 PM, said:

Read MS article 206071 on how Win98 hotfixes work:
http://support.micro...b/206071/EN-US/

I get what your saying, CLASYS but you may as well delete the old registry qfecheck
entries after installing the most recent update.  Remember that updates for
Windows 9x & ME systems ARE cumulative.  Version 4.10.2226 of the vip.386
file contains its new fix plus the older ones from versions 4.10.2225, 4.10.2224
and 4.10.2223.  When I install a newer vip.386 fix like the Q259728 update, I
run Regedit and delete the older qfecheck entries such as the Q242962, Q238453 &
Q238329 qfecheck entries from the
'HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\Updates'
branch.  That way the Qfecheck program doesn't list the older vip.386 updates and
there is less confusion.

The need to avoid confusion is noted. But that's not the point of my post:

This is a documentation of an aberration. You CANNOT install the latest version! All attempts to get past the EARLIEST update fail to actually do ANY update. It's just that as an aside, QFECHECK also gets confused in that it's perfectly fine with the older file, as long as it exists, even though in the usual case, this would be red-flagged as an out-of-date file, etc. However, when the file is absent/hand-updated to newer, the seemingly brain-dead QFECHECK rejoins the living and correctly reports the newer-still file revision it would want to be present as actually absent, etc.

In the case of these simple overlapping hotfixes, clearly what should be installed is the one that agrees with the highest revision to be installed, and presumably that is done by the SP. That way, the SP is in agreement with the relevant QFECHECK info. [And if earlier updates are left in, they become redundant to the latest one because there is no field within QFECHECK to report the MINIMUM acceptable version, just the current level as long as it meets or exceeds said minimum, etc.]

Problems develop when there are updates that replace whole groups of files that are partially redundant to other updates, but not a complete superset/subset relationship. In this case, you HAVE to have both [sometimes there are more than two interdependencies!] updates in QFECHECK to account for all that has been installed.

In the interest of getting the latest SP release issues closed, that's why I pointed out "problem-case" updates such as Q238329 and Q249973, both of which apparently have installation problems. Q249973 doesn't change what the SP should do, but it should be noted that attempts to actually install it will fail if a SUBSET of its three files [I am guessing USP10.DLL is the culprit) are already at/past the level Q249973 is attempting to upgrade to. You wind up with no QFECHECK information nor any actual file update should any of the three still need to be updated. [I believe that Q249973 provides one or perhaps two of them still higher than say a vanilla install followed by IE60SP1; clearly the IE install gets at least one of them still higher, but since all three ought to get upgraded, Q249973 still has work to do; doing no file upgrade nor QFECHECK-related housekeeping is clearly NOT its intended function!] [Note: If you want QFECHECK information for Q249973, fully expecting all relevant further updated files reflected eventually at their ultimate respective revisions, you have to install Q249973 hotfix BEFORE you upgrade to any updates of IE60SP1 and/or the SP. Apparently, one or more of the 27 known [to me at least!] available updates to IE/OE provides one or more [but not all three!] of these files that hoses the Q249973 installer logic, so installing it "earlier" gets you there, etc. Alternatively, you can patch the registry faithfully to Q249973 to "synthesize" the update; this can be done at any time.]

[A side topic: Since QFECHECK doesn't support the notion of a "high-watermark" revision level, I would recommend some means of adding QFECHECK information that demands the known-highest level that SHOULD be present; this would then be a useful tool to locate accidental file corruption, etc. As currently implemented, any file "back-dated" to a revision merely adequate to a revision demanded by QFECHECK is NOT indicated as corrupted! Indeed, perhaps the SP itself needs a "master" QFECHECK entry!!!]

However, Q238329 represents a more insidious case: It literally prevents ALL methods from performing the file update, including the SP!

Perhaps what is needed is some way to eradicate what Q238329 does, presumably to the registry to make VIP.386 4.10.2223 so "permanent" in the first place. I merely pointed out that I discovered that if you manually delete VIP.386 [at 2223] after you have [unfortunately!] installed Q238329, then you can use any method you want to update the file [presumably to 2226 using the SP would be the goal, etc.].

cjl

[CLASYS]

Gape, on Dec 1 2004, 02:04 AM, said:

Adding QFECHECK information is a difficult process because of the SP's mechanism. I need a more powerful installer such as InnoSetup or NSIS for these complex processes. But they are some disadvantages, too. (For example, you can't see inside of a InnoSetup file with WinZip/WinRar).

Currently, we don't see what you are working with, just the "innards". I assume that for the W32 self-extracter package itself you are writing some kind of script file to for it to carry out a few list items [run batches, use .inf files, etc. I would presume], and it supports EULA's and options like /C, etc.

Can you give us an example of "what's under the hood" that particularizes the package as you are releasing it currently [say for 1.6.2 since 2.0 is not yet stable, etc.]?

For the future, what's wrong with just using self-extracting .ZIP archives? That way we can unzip and not execute [analogous to /C] or just let 'r rip, etc.?

cjl