LoneCrusader

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]

Thanks I hope to be able to address the issues found by schwups soon. I have too many things going on at once! lol

Yes. All Windows 9x can run that fast with the right updates. 98SE and ME are OK, 98FE and 95 need patches. You should be able to find 98SE drivers for all devices on any Intel 8xx Chipset based board. I'm sure there may be exceptions out there, but I haven't encountered one yet.

+1 jaclaz said it best here:

I have no problem with the RTE editor being here, but I do consider the fact that the "plain text" (or BBCode as bphlpt referred to it) editor does not behave as it used to to be a "bug." Features that used to work are broken. Is it possible to have both editor types, or to enable the "controls" under the plain-text editor as it was before?

I'll type it out and bold where code is on the editor: B I U S X2 X2 Unordered Ordered Link Unlink Image Code Quote Twitter... (etc...) I believe he is referring to the lack of a "plain-text" style editor like we had before, not a "Code" box. Now you have something far more useful. Topic tags. The thing is that next to no one really used the topic descriptions. They were replaced with the far more useful tag system so that people can also find posts related to their interests. I've been using the tag system on my forums since it was introduced and it's really so much nicer than the descriptions. I honestly forgot all about the descriptions until it was mentioned here. Subjective. I disagree. The fact that topic descriptions were "rarely" used does not make a "tag system" "better." If you want it as an option, great, but we prefer the option of having the descriptions instead. More friendly? Once again subjective. A matter of opinion. I disagree. You can still insert them just fine. You can even type them out like so: (code)my code(/code), etc. and the editor will convert it on post. Remember, this is a much better editor, a WYSIWYG editior. Better? LMAO! Rubbish! Why would I want to type them out when before I could just click to add them? "WYSIWG" is useless if you actually want to break up a quote to address specific points, or to trim extraneous text to keep down unnecessary repetition. Please elaborate on how this "new" version is supposedly better, when it has removed a feature that worked in the older version?

So, in other words, this is something "broken" by the upgrade? All of those controls worked before, even though the editor worked in plain text mode. Essentially it won't allow us to insert those formatting controls (tags) unless the method of "viewing" them in finished form is turned on?

Quotes have now gone back to being a pre-formatted "block" that doesn't show the quote tags, etc as it was before. Try to turn of RTE (top left corner button in RTE) when you quote post.That fixed it. But it also comes with another problem... when this option is turned off, it disables all of the post controls, including Bold, Italic, Insert Link, emoticons.. the whole panel is grayed out.

Quotes have now gone back to being a pre-formatted "block" that doesn't show the quote tags, etc as it was before.

The "Reply to this topic" button has disappeared from the bottom of topics, but remains at the top. "Use Full Editor" option is also disappeared, along with all of the post controls (Font/Emoticons/Quote/Lists etc etc). The "More Reply Options" button doesn't take you to the Full Editor, or allow access to any of the missing items I listed. EDIT: "Use Full Editor" button does appear in Private Messenger, but it also is lacking the post controls above. EDIT#2: Emoticons are no longer animated? (had to enter the code manually due to problem above)

Have a look here. https://addons.mozilla.org/en-US/seamonkey/ You will probably have to look through the expandable "Older Versions" part of each Addon's page.

This seems to be quite a mystery. I set up an unmodified 98SE installation, and then installed ONLY the SYSDM.CPL HotFix. The CPU info on the System Properties tab does indeed disappear under these conditions. However, if one extracts the HotFix SYSDM.CPL to the \WIN98 folder before installation, therefore causing the HotFix version to be used during the original SETUP, then the CPU info is displayed properly. So, the 98SE HotFix files are NOT broken, but they must be used in the original SETUP to work properly. There must be some other "link" between SYSDM.CPL and the registry entries it uses to get the CPU information.

Fixed. My apologize. I guess i'm tired :-) Understandable!