Offler

Windows 98 Driver bug solution - possible Add-on for Unofficial Servic

29 posts in this topic

the reason it is a monolithic driver file is to reduce pc bootup time.
Interesting point. Would it be possible to rebuild it with only the needed VXDs (and put the other VXDs that normally aren't in it) and decrease bootup time even further?

Yes, step-by-step instructions are in the link in my previous post:

http://www.helpwithwindows.com/techfiles/vmm32.html

Though I cannot say if it will "shave" anything off boot time.

jaclaz

0

Share this post


Link to post
Share on other sites
the reason it is a monolithic driver file is to reduce pc bootup time.
Interesting point. Would it be possible to rebuild it with only the needed VXDs (and put the other VXDs that normally aren't in it) and decrease bootup time even further?

If you want to decrease boottime you have to add vxd's that your sytem needs but are not in vmm32.vxd. Reading the artikel provided in this topic confirmed my feelings that the startpost is based on a misunderstanding of how vmm32.vxd works.

0

Share this post


Link to post
Share on other sites
the reason it is a monolithic driver file is to reduce pc bootup time.
Interesting point. Would it be possible to rebuild it with only the needed VXDs (and put the other VXDs that normally aren't in it) and decrease bootup time even further?

If you want to decrease boottime you have to add vxd's that your sytem needs but are not in vmm32.vxd. Reading the artikel provided in this topic confirmed my feelings that the startpost is based on a misunderstanding of how vmm32.vxd works.

In the past I have used Vxdlib, available from mdgx`s website which provides excellent compression of vmm32.vxd (please have a backup copy etc) quote

I have been able to achieve higher compression ratios than Microsoft's

DEVLIB tool by finding the best match in the history buffer rather than

just a good one"

also other vxd tools on there

eidenk I think you missunderstand me I mentioned wininit.ini as just one example of quite a few ways in which vmm32.vxd and for that matter system/vmm32 gets messed around with, i.e it is not a bug causing system crashes etc as the original poster on this issues states, errors with this file causing any instability in the os are not self inflicted. I appreciate you have installed a lot of software, but people out there do use vxds for other than they are intended.

Edited by oscardog
0

Share this post


Link to post
Share on other sites

Don't be so cryptic and give some typical examples as to how one can mess up vmm32 then.

0

Share this post


Link to post
Share on other sites

Maybe this is useful for tweaking/modifying VMM32.VXD:

http://www.tbcnet.com/~clive/vcomwinp.html#VXDLIB

VXDLIB.ZIP -- VxDLib is a utility that I have written that works with the new compressed W4 file format used by VMM32.VXD to archive multiple VxDs for Windows '95: you can dump out the contents of VMM32.VXD, decompress it, recompress it (more tightly than Microsoft), and extract individual VxD's from it. Multiple VxD's can be extracted using wildcards. VXDLIB.ZIP includes VXDLIB.EXE and VXDLIB.DOC.

jaclaz

0

Share this post


Link to post
Share on other sites
Interesting point. Would it be possible to rebuild it with only the needed VXDs (and put the other VXDs that normally aren't in it) and decrease bootup time even further?

It is indeed possible, but generally not worth doing unless, maybe, your system has undergone many changes since it was first build. Working instructions (by Pietrek or Russinovich or? some guru of the kind) are available on the web should you want to play, Google is your friend...

[Edited : The guru in question was Clive Turvey indeed, as referenced by Jacklaz while I was writing this...]

Basically, vmm.vxd is a composite of :

- "the" VMM.VXD itself,

- an "W4" archive of other VxDs, similar to a zip, built at system installation time from the individual VxDs.

Because the VxDs are compressed and also since it is only one file to open instead of several, the load time is indeed decreased. Notice that this was already done in Windows 3.11 for Workgroups, the Win386.exe was also an archive, albeit uncompressed (the "W3" type).

HTH

--

Ninho

Edited by Ninho
0

Share this post


Link to post
Share on other sites

I have made another reinstallation of win98se for testing purposes. Bios was set to manual mode - each irq has been set manually and it was forbidden to use PNP in many cases.

Then i listed device manager and only one device was using vmm32.vxd. In previous installation it was used by many devices (at least by three). Thats strange. When the PNP and IRQ selection was automatic many of drivers used it, but the system was unstable resulting in "Blue screen of death", and guess in which module happened this Exception Error. (yes, in vmm32.vxd)

but it is still hard to say if it causes trouble, maybe the same error could happen in other module (such as ntkern.vxd), but in fact i havent seen "BSOD" after i put these files in system folder.

(btw i realized one thing. ntkern.vxd has been installed in vmm32 directory, but it has not been installed in system directory. some other files has been installed in both directories during installation proces. i have no idea why...)

Edited by Offler
0

Share this post


Link to post
Share on other sites
If you open Device Manager, specific device and you read info about files which are body of driver sometimes you shall find entry like this one:

"C:\windows\system\vmm32.vxd (ntkern.vxd)"

This means that device is not using normal driver file but just generic"vmm32.vxd" slower driver. Some say that this setting causes system crashes and lock-ups and lowers system stability.

to fix this bug, following files have to be installed to both "x:\windows\system" and "x:\windows\system\vmm32" folders:

vcomm.vxd
vdmad.vxd
configmg.vxd
vdd.vxd
vmouse.vxd
ntkern.vxd
vflatd.vxd

Is this accurate? If you look at Microsoft hotfixes that has some of the files above, it only updates files in windows\system\vmm32 and not windows\system. This means users will have different file versions in different folders.

Edited by PROBLEMCHYLD
0

Share this post


Link to post
Share on other sites

If you open Device Manager, specific device and you read info about files which are body of driver sometimes you shall find entry like this one:

"C:\windows\system\vmm32.vxd (ntkern.vxd)"

This means that device is not using normal driver file but just generic"vmm32.vxd" slower driver. Some say that this setting causes system crashes and lock-ups and lowers system stability.

to fix this bug, following files have to be installed to both "x:\windows\system" and "x:\windows\system\vmm32" folders:

vcomm.vxd

vdmad.vxd

configmg.vxd

vdd.vxd

vmouse.vxd

ntkern.vxd

vflatd.vxd

Is this accurate? If you look at Microsoft hotfixes that has some of the files above, it only updates files in windows\system\vmm32 and not windows\system. This means users will have different file versions in different folders.

No. The statement is not accurate, and files only need to be updated in one folder. (and should only exist in one folder, not both).

0

Share this post


Link to post
Share on other sites

I would assume the vmm32 folder right?

0

Share this post


Link to post
Share on other sites

I would assume the vmm32 folder right?

Yes, for the files listed. It depends completely on the file. Some VXD's still go in \SYSTEM (including NDIS.VXD) or SYSTEM\IOSUBSYS (including CDFS.VXD) rather than SYSTEM\VMM32. The HotFixes should place them in the proper locations.

If in doubt, you can always examine COPY.INF inside your target 9x CAB files. Find the file in question and it will have an entry, for example:

CDFS.VXD=12

NDIS.VXD=11

UDF.VXD=22

The numbers after the file are "LDID's" - Logical Directory Identifaction Numbers (I think that's the right term).

These LDID's are explained in this section common to HotFixes:

[DestinationDirs]

; 10=Windows, 11=SYSTEM, 12=IOSUBSYS, 13=COMMAND, 14=Control Panel, 15=Printers, 16=Workgroup

; 17=INF, 18=Help, 19=Administration, 20=Fonts, 21=Viewers, 22=VMM32, 23=Color, 25=Shared

; 26=Winboot, 27=Machine, 28=Host Winboot, 30=Boot drv root, 31=Root of Boot drv Host

; 00=Null (new) LDID, 01=Source drv:\path, 02=Temp Setup, 03=Uninstall, 04=Backup

Some VXD's are compressed into VMM32.VXD when Windows 9x is installed. This does not mean that 9x is using a "generic driver" as described above. It simply means that all of those individual files such as NTKERN.VXD, UDF.VXD, VFAT.VXD, etc etc have all been combined into a single executable driver. Think of VMM32.VXD as a "ZIP archive" of VXD's. All of the original code exists, just no longer as individual files.

When applying HotFixes that place a newer version of a file such as NTKERN.VXD, the new file is added to the \VMM32 folder, where it will automatically override the older version that was packed into VMM32.VXD.

This is why it is preferable to slipstream files or add them to the \WIN9x SETUP folder prior to installation, so that the newer files will be picked up and be packed into VMM32.VXD during SETUP rather than the older versions. This saves space by eliminating the older unused code and preventing the need for a newer HotFix file to exist separately. It also can make the system perform faster if the VXD's are packed into VMM32.VXD rather than loaded individually (this was Microsoft's original intent).

Note that VMM.VXD is an exception to all the rules above. VMM.VXD does not exist as an independent file on a 9x system unless it has been added by a HotFix. VMM.VXD is already packed into VMM32.VXD inside the original CABs and the newer HotFix VMM.VXD's cannot be packed into VMM32.VXD. If VMM.VXD is present during the original VMM32.VXD compression, the compression will fail.

Edited by LoneCrusader
0

Share this post


Link to post
Share on other sites

Wasn't there a simple method to force a rebuild of VMM32.vxd?

0

Share this post


Link to post
Share on other sites

Wasn't there a simple method to force a rebuild of VMM32.vxd?

Not that I am aware of, but that doesn't mean that it doesn't exist.

VMM32.VXD usually contains many of the same VXD's, but it can still be unique to each machine. WININIT.INI is used to build it during SETUP, but this INI file is used for more things on the second round of SETUP, and only ONE backup version is maintained. Each time a new INI is generated, the oldest backup is lost. So theoretically you could lose the original INI that built VMM32 on the second boot to Desktop unless you physically make a backup copy of it and rename it to something that will not be overwritten.

0

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

  • Recently Browsing   0 members

    No registered users viewing this page.