LoneCrusader

I'm seeing a bug related to the Personal Messenger. When a new reply is added to a conversation with two other participants, and I click on the Messenger button at the top of the forum, instead of showing the name and picture of the last person to reply, it shows the name and picture of the person who started the PM, along with the time of the last message added, regardless of who added it. Rather confusing and I do not recall it behaving this way before...

Same here. Strange things seem to be happening.

No, LoneCrusader said: I knew that IE 5.5 SP2 was available from other sources, and I already have some of those archived, but thanks for the links anyway.

Nice find, thanks for the info. I wonder if IE 5.5 SP2 is still floating out there on some MS server... EDIT: IEAK6.EXE can also be found using the above links. Possibly other related files. What we really need is a complete list of the files that should be in a full IE 6 package, if such a thing exists.

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.

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.

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

Same. It was down here with a SQL Server error from at least 11PM last night to around 4AM US EST(EDT).

Hmmm... Looks like I've got my work cut out for me. And a crash course in subjects I've not delved into before. Thanks for the help... I'll get there eventually, but it's probably going to take a while before I can have enough time to devote to the project.

I knew I would still need the IMAP connection to Yahoo. What I didn't know is, do I have to actually set up a separate machine as a Web Server on my local network in order (for the sole purpose of) to run/access SquirrelMail and use it to connect to an "outside" network? Your reply indicates that I do. I was hoping that since I don't want to use it to access an "internal/local" network(mail server) that I might be able to somehow run it directly on/from the client machine for accessing the "external" Yahoo mail servers. Ugh that probably doesn't make sense either.. lol

To make a long story short, I am profoundly annoyed by Yahoo's recent decision to discontinue Yahoo! Mail Classic and force users to use their new garbage interface. I have been using Yahoo Mail for approximately 14 years and always found it superior to any of the other "free" services, but no longer. The only "alternatives" that users are given are 1) use IMAP to access mail with another program, and, 2) delete your account. Unfortunately I do need/want to keep my Yahoo address along with the years of correspondence, etc etc that I have stored there, or else I would do the latter. So, to the point: Is it possible to install and run a browser WebMail client such as Squirrel Mail on a single computer? And, if so, can I use it + IMAP to access Yahoo? I visited the Squirrel Mail site, but most of the documentation all pertains to using it on Web Servers, or within internal organization networks, so I don't know if it is possible to use it how I want to.

All true, I'm not "disagreeing" with you. I simply regard WinImage as the most "user friendly" tool for the job, and the best "GUI tool" for the job, especially if the operation is to be performed on an NT-based OS. If I were attempting this, I would only perform the operation on a 9x/DOS system to begin with.

The OP specifically stated he would be performing the operation on Win7... Hence the Write Protect advice. And the fact that the OP is here "asking the right questions" so to speak would imply that he has sense enough not to alter the Floppies with WinImage. (And I know Steven W has been around here a while.) I stand by my WinImage recommendation.

First, make sure every Floppy is Write Protected before you even insert it into a drive. Beware some "lesser quality" USB FDDs sometimes do not respect this setting. Then I would suggest WinImage for making RAW backups of the disks (and if it were me, I would actually use copies made from those backups to do the installs, rather than the originals). But my experience in this area is limited, so let's wait for more input from others.

All of the section names are the exact same as they were in the 98SE originals. My policy was to integrate the newer Intel data while making the absolute minimum changes to anything else. The problem is (was) the overall size. The "real" INF size limit for 98SE must lie somewhere in between 63KB and 64KB, rather than being 64KB "exactly." I removed some non-Intel entries to get the size down a few bytes; I plan to go back and reduce it in a different manner so that no content is lost. One way to eliminate a considerable amount of "unnecessary" size is to remove all instances of ".DeviceDesc" (without the quotes). In this way no information/identifiably is lost; but I will only make that change if it is necessary to preserve original content or add something that is absolutely necessary. I have adopted an "absolute minimum change" policy for most of my projects; this because it makes comparison/reversion to the originals easier and reduces the possibility of further problems down the line.

Thanks for the report! I will make a cleaner edit of the MACHINE2.INF file (and may try to figure out what the exact size limit is in bytes) soon; and I hope to find the time to make Windows ME specific INFs and add to the project at some point. Probably there is very little difference from the 98SE versions though. What is the manufacturer and model of the motherboards you used? Did you experience any problems with ACPI?

Hmm.. I'm glad that it does work that way, but this leads to unnecessary redundancy. The same Intel devices that are present in xRayer's ICH7CORE.INF are already handled in my MACHINE2.INF. (background info, slightly off-topic) In 98FE/98SE/ME the standard method of handling manufacturer-specific motherboard devices is to place their data in MACHINE2.INF, not MACHINE.INF. This is the "more complicated" difference between 98 and 95 that I mentioned in my first post; Windows 95 does not have a "MACHINE2.INF" by default, and all of the corresponding data is contained in MACHINE.INF instead. Needless to say, this, along with some special handling for ultra-legacy BIOSes makes the 95 MACHINE.INF much larger, and leaves much less room for additions. I have solved this in my slipstream by splitting the data into 2 INFs based on 98FE/98SE. (/background info, slightly off-topic) I had the opportunity last night to test my INFs on an ICH7 board (Intel DG41TY). Windows 98SE installed, but would not finish loading in Normal Mode. Most likely there is a serious conflict/incompatibility with the newer versions of ACPI on ICH7 and later systems. I was able to boot into Safe Mode, where I verified that all of the devices had installed properly, including the "PCI Bus" and related entries. I repeated the experiment using the "SETUP /P I" switches to prevent the loading of ACPI. Using this method I was able to boot 98SE in Normal Mode after installation, and the "PCI Bus" and related entries were properly installed. So, it looks like my INFs are now working properly after the size reduction to MACHINE2.INF, but the ACPI problem makes it difficult to run more definitive tests. When you have time schwups, could you please retest my new versions without xRayer's ICH7CORE.INF, and also see if using xRayer's INFs during installation (without mine) prevents the "PCI Bus" failure? (as you found his ICH7CORE.INF corresponds to MACHINE.INF, 945.INF should correspond to MACHINE2.INF)

Reproduced this error on a VM. I have removed some unnecessary entries for testing and it prevents the error on my VM. This is the first such problem I have seen with an INF size smaller than 64KB. The real "limit" must lie somewhere in between 63KB and 64KB. I compared my INFs to xRayer's again. The only major difference is that I moved all of the Intel data to MACHINE2.INF rather than MACHINE.INF; this because it is the method already used in 98SE. All of the ICH7 devices are pointed to the same "installation processes;" basically the exact same actions should be performed by both INF sets. As I mentioned above the "PCI Bus" driver installation failure happened to me as well, even without any updated INFs, and I had to manually install "PCI Bus" to cause the detection of the remaining missing devices. It may be impossible to avoid this during a "clean install," or, it may require special handling in the INF if we can figure out what to modify. When you say "manually" install xRayer's driver, what steps are you taking? If you manually place xRayer's drivers (without mine) in the \WIN98 folder before installation, are they detected and used during installation? If so, does the "PCI Bus" installation failure still occur?

Please post the manufacturer and model of the joystick, in the hope that an original manufacturer driver may have existed... First, be sure that you have all of the USB Supplement packages + later 95 USB HotFixes installed properly. (Describe what you have done, or if you haven't attempted this yet, post here first and I may be able to simplify the process for you.) After that, and after searching for a manufacturer's driver: You might try IntelliPoint 4.0, it is the last version to run under 95 and does allow the use of Wheel Mice, never tested with other devices... This apparenlty is not widely known, but contained in the Windows NT4 DDK is a "Beta/Experimental/Incomplete?? " USB HID stack for Windows 95. I don't know how complete it is, or if it could be made to work or not... I had planned to get around to this one day, but never really needed to; I don't use USB devices other than USB Storage.

Then don't use Windows 98 either, because it isn't free. And don't complain when you can't find the things you want or need, because everything in this world is not free, nor should it be. rloew deserves proper compensation for providing excellent products, and we should all be thankful that he is dedicated to extending the capabilities of the old systems that we all love, and that he is willing to spend his time working on Windows 9x, when there are many things more profitable that he could spend his time working on.

More than "trying," lol. It's already light years ahead of any other existing USB driver for 95, and only the one sporadic bug seems to remain.

No problem!

As far as we here know, there are no remaining "new" browsers that are supporting Windows 9x, paid or otherwise. If Firefox 2.0.0.20 or Opera (10.63 I believe?) doesn't do the job, your best bet may be in install KernelEx and try to run later non-9x versions of Firefox.

From the last upgrade.. requesting again EDIT: Nevermind, I found a link back to the board index at the bottom. I didn't realize it was a link at first.

Some, (not all) emoticons are no longer animated when added from the emoticons menu. The "Thumbup" one works, and is animated. However, the "Wacko" and "Blink" (and possibly others) emoticons, when added from the emoticons menu aren't animated: But when they are direct linked by IMG tags, they work: This doesn't work: :blink:This does:[img=http://www.msfn.org/board/public/style_emoticons/default/wacko.gif][img=http://www.msfn.org/board/public/style_emoticons/default/blink.gif]