Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


Sign in to follow this  
Gape

To do list for 2.0 FINAL

Recommended Posts

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites

Read MS article 206071 on how Win98 hotfixes work:

http://support.microsoft.com/kb/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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Read MS article 206071 on how Win98 hotfixes work:

http://support.microsoft.com/kb/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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×