LoneCrusader

KernelEx and WDMEX have completely different targets; KernelEx is for programs and WDMEX is for drivers, which are totally different beasts. I'm not certain it makes much sense to attempt to combine them (but I'm no programmer, so maybe I'm missing something). Now if you mean DLLHOOK, or the lesser-known "UNICOWS WRAPPERS" package, then it makes much more sense. I had hopes that with the "WRAPPERS" package that we might even be able to get roytam1's PaleMoon 26.5 build for Windows 2000 to run under 98, but I never seem to have time to work on making the attempt.

Why would you install Windows 98 to a FAT16 partition to begin with? (I assume this based on you saying you "converted" to FAT32...) You should start with FAT32 to begin with... You can enable 48-bit LBA from the beginning if you create your own install CD or copy the contents of the \WIN98 folder on the CD to a folder on your hard drive and run SETUP from there (i.e. C:\WIN98CD)...; simply extract ESDI_506.PDR from BHDD31.ZIP (or patch your own ESDI_506.PDR with rloew's patch) and drop a copy of it into the \WIN98 folder of your new CD or into the folder on your HDD where you copied the SETUP files. SETUP will then use this ESDI_506.PDR instead of the older unpatched copy inside the .CAB files. This would allow you to combine the first 5 steps... Install using the command "setup /p i" (note the spaces) from your 98 CD or from the folder on your HDD. This will force 98 to use the older APM standard rather than ACPI (ACPI causes many issues on newer systems not designed with Windows 9x in mind). Running automated setup from the CD just runs "setup" without the switches, and thus leaves ACPI enabled. Always install any official updates and packages and drivers BEFORE adding unofficial ones, especially KernelEx.. Usually I install DirectX right after SETUP has completed, and before I start installing drivers.

The Code 10 error in the Device Manager is common on WDM drivers that are missing a function.

2GB of RAM may be a problem here; try using rloew's RAM Limitation Patch instead. The various ram limiting "tweaks" never worked for me. I can't make out the picture very well; I assume it's just a black screen? IIRC this happens to my X600 laptop when I try to load the drivers under 95. Never found a solution for 95, but at least 98 worked in my case. What resolution was attempted/did you try to set for your desktop? It's possible the Mobility X700 or your laptop's LCD panel may not properly support some resolutions. Custom resolutions can be added to the INF file as well (adapt for your card's INF file/section and desired resolution obviously); it may be best to add one for the default resolution chosen by the drivers working under XP and reported in the DXDIAG you posted. Beyond this I'm not sure what to try next. SciTech Display Doctor might be of some use.. It worked on my X600 laptop under 95 but broke Plug & Play in the process. What do you possibly hope to achieve by loading an XP driver INF into the registry? First of all, as I've already pointed out, 2K/XP/Vista/etc display drivers DO NOT WORK under 9x. As far as I know, despite the fact that other devices can use WDM (.SYS) drivers, display drivers under 9x MUST be .VXD drivers. I can't remember the source of that, but I read it somewhere years ago, and I have yet to see any evidence to contradict it. Dependency Walker is for user-mode programs, not drivers, which are an entirely different beast. The proper way to check a 2K/XP WDM driver for 9x compatibility is to use WDMCHECK by Walter Oney or DISPPE32 by rloew on the file while running under 9x. Aside from all that; even IF it were possible to load a .SYS display driver under 9x, the NT-style INFs do not have the correct sections and registry entries to properly load such a device driver under 9x.

What's the Manufacturer/Model and specs of the laptop you're using? This will help us figure out if there may be other issues contributing to the problem. Most likely you will need to first install Windows 98SE with ACPI disabled (SETUP /P I) if you have not already done so. When I tried with ACPI enabled on my laptop I got an unrecoverable series of crashes. It's been several months, and I don't have the machine readily accessible at the moment, but from what I can remember you should only need to uncheck one option box to disable PCI steering. Other changes may produce different results and these may vary yet again according to the hardware in use. Your changes to C8_30314.INF should have been sufficient; you don't really need to change anything else but you will have to point the Update Driver wizard to the 9X_INF folder manually rather than depending on Catalyst Setup. I would just use one line and truncate the entry to just ""ATI MOBILITY RADEON X700 Series" = RV410_ENU, PCI\VEN_1002&DEV_5652" eliminating the REV, SUBSYS, and CC codes, as these get really super device-specific for no reason as they all point to the same section. Now, C9_30314.INF does NOT have all of the required sections to install a RV410_ENU device. This may be the reason for the crashes if you were using this INF at this point rather than your C8_30314.INF, which does have all of the required sections. Simply reverting to your C8_30314.INF may work; if not, or if you experience crashes/instability, start over using 98SE with ACPI disabled as above.

IMO, you've mixed too many parts together for starters. If you're using rloew's RAM patch you should not need HIMEMX, and unless you have some specific reason for using it, you most definitely don't need EMM386. Nor do you need to limit MaxPhysPage... (what is burnmem.sys? ) When using PATCHMEM, you can forget about all of the "tweaks and workarounds" used by those without it. re: Slow Boot due to unrecognized Machine Type... I've seen this problem once on an AMD machine. Newer systems don't handle Gate A20 in a 9x-friendly way. Setting /MACHINE:1 on HIMEM.SYS in CONFIG.SYS may solve the issue. I've not used rloew's AHCI driver yet, so I can't address that part specifically... If you have the option on that board to use Native SATA mode (may be labeled as "IDE") then it should work with his SATA patch, but I doubt that option is still present. Maybe someone who has used the AHCI driver can comment on this. Newer motherboard manufacturers no longer care about optimizing their BIOS code for x86 operating systems. They assume everyone will be using x64, so they don't bother to optimize the MMIO RAM allocation to make the most memory available to x86. I had an X99 system where only 1873MB of RAM was available to a 32-bit system when 4GB was installed; this later increased to 2910MB after a BIOS update but I never could manage to get their tech support to understand the problem. A good BIOS modder might be able to help with this, but they're hard to find in my experience. Newer video cards usually use a "memory banking" method to avoid tying up all of the 32-bit RAM.. since your 780GTX is XP compatible it should do this, but who knows what the onboard Intel HD Graphics will do. I've had 9x up and running on my X79 and X99 systems. I have an X299 system that has yet to see any experimentation with any OS... I detest onboard graphics to begin with, and the fact they're no longer supporting XP rules chipsets using them out completely. The "X" series boards and processors may cost more, but it at least rules out one set of legacy compatibility problems.

This problem (Mobility X600 in my case) drove me nuts for a long time on a laptop I was trying to get up and running with 9x. Despite scattered reports of people getting Mobility X600/X700 chips working under 9x, no matter how many times I tried or how many different Catalyst versions I tried, nothing ever changed. Forget Catalyst 4.11, use the last 9x compatible package. 2K/XP WDM (non-.VXD) Display drivers do not work under 9x, so they won't get you anywhere either. If you're having the same problem I did, then this should cure it. Disable PCI Steering on the PCI Bus under Device Manager. The reinstall the ATI Catalyst package if necessary. Manually choose an X700 device from the list, or add your specific VEN&DEV to the INF if you wish.

Try here.

I've had to use MTP a handful of times with a smartphone and XP and myself found it to be profoundly annoying.. so much simpler to have the media mounted as a drive rather than a device. Not to mention pure USB Mass Storage Mode allows for much greater backward compatibility with OS'es. Just my opinion though.

This particular subject is of interest to me as well... several times I've considered getting a smartphone and every time I always choose not to because of this or that reason. Apparently now I may be forced to because they claim my network is changing and my old flip phone will no longer work. This particular issue is one of my major peeves. I believe it is still possible to achieve "USB Mass Storage Mode," but from what I understand it requires using a rootkit on the phone/taking root control of the Android OS. I've tried to read up on that process, but what small amount of info there is is not conducive to those who are new to the subject. It doesn't help that now it seems those who want to use this mode are beginning to be "looked down on"; i.e. more people are wasting their time asking "why do you want to do this" rather than actually providing any useful information or solutions. Also, it appears one just has to blindly "trust" whatever tools are available for the rootkit operation.

I faced a similar odd issue with my XP x64 Media/"HTPC." You have to manually choose which output is used for sound, whether over HDMI or output to the Audio jacks. If you're using HDMI output, then the jacks do not produce output. It's been a while since I had the issue so I can't be more specific. Examine all of the settings for your Sound and Video hardware in the Control Panel, etc.

You're welcome. Google search for the exact filename in quotes. Ignore any "too easy"/questionable sites that come up early in the results. Go through the results looking for any full HTTP URL addresses to where the file once existed; try those live and in the Wayback Machine. If those don't work (i.e. the akamai.net link), the look for any FTP URL addresses. In this case the file name was inside a .TXT file that existed on an FTP server. I took a chance that that folder would contain the files listed in the .TXT, removed the .TXT file from the address, and checked the containing folder. As for Windows 10, that's out of my expertise. Theoretically drivers for earlier Windows 8/7/Vista might work, but it's a trial and error experiment.

Is this what you're looking for?

I noticed those as well... if I were going to guess I would say that those files are Rudy's notes on changes he was making for an updated version. The question is whether or not these changes were pushed into the "current" source code; whether or not these versions were ever actually built; whether or not they exist anywhere stand-alone, or whether they may only exist in use on his testing machine(s).

I've not seen any issues with it using Firefox 52.9.0esr under XP x64, so most people should be able to access it fine. I've not tried to access it on a 9x machine though. I think most of us 9x'ers have been forced to use XP, Linux, or some later Windows for online activity for some time anyway, but there are probably still a few holdouts. His debugger apparently was able to do kernel debugging on the target machine itself.. The only other debugger I know capable of this for 9x is SoftICE (although my knowledge of that entire subject is very limited). I know I kept trying to get him to try SoftICE when we were working on the HDA/USB3 projects so that we would be using a common tool but I don't think he ever tried.

Since you mentioned this; Around that same time (little earlier; May 22) Rudy told me something interesting in an email that I don't think was mentioned publicly or expanded on elsewhere. So we have yet another interesting bit of work from close to the same period. Hopefully this will turn up as well. I know he collected a lot of data. Most recently we were both working on backing up the content of Windows Update for XP as there was a rumor that it would shut down. Too many things for the older systems have been lost over the years, and he was well aware of it. I know he also had an archive of HP's entire printer drivers library before they disappeared all of the 9x files. Who would have ever thought a drivers CD would be valuable.. but now in many cases they are for us dinosaurs. Whatever makes setting up the page and getting everything uploaded easier for you works for us. We're just glad you're doing it. (Although it would be nice to not use anything that doesn't work properly with XP compatible browsers, lol.. )

I believe we can rest easy. Rudy's son does have plenty of experience of his own in programming and other matters even if they aren't directly related to our beloved older versions of Windows. It's just a major task to organize another person's work who doesn't work the same way you do or work in the same subjects you do.. which of any of us would know where to begin? I've been trying to decide how to handle some of the things I have that we worked on and I'm having trouble figuring that out myself. I'm confident everything will eventually be sorted out. I've been working on some webpages dedicated to Rudy's work, but it's slow going for this old dinosaur whose HTML knowledge is 20 years old and who writes all of his HTML by hand in Notepad. I would like to eventually have more than just file links and the text of README files.. I've been adding screenshots of Rudy's work in action as I have them but it would be a major time consuming task to stop and create such content for everything. Here's what I have up so far.. some of the pages are just placeholders, and most of the file links go to the archive.org collection for the moment although I do plan to host them myself eventually. I have also added a couple of small projects that we had worked on that were never released. I'm dreading the writeup on WDMEX when the time comes, lol.

So, I assume you're saying that MFC40.DLL does not exist in a clean installation of 95RTM or 95A (OSR1), and does exist in a clean installation of 95B/95C (OSR2.x)? If so, this sounds like a winner. Thanks for your help! I'll try to verify this myself as well, but my workspace and testing systems are a wreck right now. Even 95 VM's are not working on the machine I'm using now. Not to mention that I haven't worked on FIX95CPU or used it myself in over 6 years (I slipstreamed the fixes so I never have to use the manual version anymore), so it may take me a while to implement the change and push out an updated package. In the meantime, anyone who needs to use FIX95CPU on a KNOWN OSR1 installation can rename FILEXFER.EXE on their HDD to something else before FIX95CPU installs, or delete the line referencing it in FIX95CPU.BAT on the FIX95CPU floppy. NOTE the latter of those options will make the FIX95CPU floppy useless for OSR2 installs!

There does appear to be a problem when applying FIX95CPU to a full OSR1 installation from CD/scratch. RTM installations later manually updated to OSR1 should not be affected. FIX95CPU tests for the existence of FILEXFER.EXE to determine whether the version of 95 being patched is RTM or OSR2... FILEXFER.EXE does not exist in RTM, but does in OSR2. Apparently it exists in OSR1 as well. Looks like I will need to find another file to test for to make the determination. Anyone who may have further input on this please chime in. On the other hand, if you're not getting anywhere with 95 RTM or OSR2 either on this machine I'm not certain what other problems may be in play. OSR2 should definitely work, even if the others don't.

It's been a long time since I've used it, but I have an AGP Radeon 92xx card here that I previously used before I moved up to the 9800XT years ago. I know a working driver package for this card existed for 95*, but I don't remember any specifics of it. It should be possible to get this card up and running under 95* though. I doubt this card is the problem, *but once again my experience is based on OSR2. ON the other hand... after seeing you said "All-In-Wonder"; I do vaguely remember noting years ago that the system requirements on one of those older All-In-Wonder cards were different from the system requirements for the exact same normal Radeon 9xxx model. If you happen to have any other AGP or PCI video card, it may be worthwhile to do a test run with it instead of the All-In-Wonder. We can't say for sure this IS the problem yet, but if you have a way to test without it it could help rule it out. I understand completely.. my first machine had DOS and Win 3.1, but my next machine had 95 OSR2. I always preferred it.. hated 98FE with a passion. For a long time I refused to use 98SE because it changed IE from 4 that I was used to to 5 that had some minor difference that annoyed me (and now I can't even remember what exactly). I only moved to 98SE years ago when I hit this very CPU bug on my new P4 3.06GHz build. At the time I didn't know how to fix it, but at least I revenged myself on the problem years later. It may take me some time to dig further into this.. I've got some issues coming up this week that will prevent me from getting much done, but I've not given up. In the meantime, if you have the opportunity you can try some test runs with different conditions and see if anything changes. -Try a different video card if you have one (even one without 9x support). -Try disabling all onboard devices you can in the BIOS of the motherboard and reinstall. If it works, re-enable them one by one until you see the problem. -Try to get a BOOTLOG from the system.. this can be tricky as it's a hidden file and frequently gets overwritten. Bet way is to choose Logged boot from the menu, let the system crash, and then retrieve the file with another OS. This may give some idea of what exactly is crashing, although I'm not the best at deciphering them.

Looks like a nice board. I've never used ASUS myself, but it's very similar to many systems I've worked with so it should work for what you're wanting to do. For testing purposes and troubleshooting the current problem we should probably stick with the setup you've begun, and keep RAM at 512MB or below. However, I will point you to a few fixes that will make your life easier, especially since you're multibooting with XP. With the recent passing of my good friend and one of our most knowledgeable members here (rloew), his software is now available to the public. Make all 4GB of RAM, your SATA ports, hard drives larger than 137GB, and TRIM capability for FAT32 usable under 9x with the patches found here. I see you're already having some of the classic issues with large amounts of RAM (unable to open DOS boxes etc). This MAY be contributing to the problem as well (unless you're always at 512MB or below when experimenting). The patch I linked will eliminate that, and the need for system.ini modifications and other "tweaks." What video card are you using? This may be significant as well. I've seen 95 fail to boot on some newer systems with a particular video card but work on other systems with the same video card. In this case these machines were newer than the one you're using but it's still a possibility. The Incorrect MS-DOS version error may very well be significant.. I have always used OSR2 or later for anything myself. It's been a long time since I've even looked the package over (I slipstreamed the fixes, so I no longer have to use the diskette) but I remember specifically having to use SETVER in the script in order to have compatibility with the original version of 95. I reworked the last version of FIX95CPU to be compatible with the earlier releases of 95 (DOS 7/FAT16 as opposed to DOS 7.1/FAT32; originally my package only supported OSR2) but it really had very limited virtual machine testing done on those systems. Now that I think about it, OSR1 may not have been tested at all. The original release and all OSR 2.x were tested, but I didn't have a copy of OSR1 to test, and I assumed the DOS version would be the same. I'll see if I can find a copy of OSR1 to examine... I'm not certain how different it is from the original release. Depending on whether or not a new set of .CAB files was built, or whether another method is used to apply any updates it may be doing something unexpected. It's possible it may be overwriting some of the files applied by the patch (although I think this is unlikely); or OSR1 may introduce something else that causes a problem that did not exist under 95 RTM but was fixed in OSR2... there are several possibilities.

We need a little more information before anyone can help you. What are the full specs of the computer you're trying this on? Were any errors reported during the installation process? Are any errors reported when the machine reboots?

WinRAR 3.93 is the last version with official 98-ME support. It's been a long time since I visited this issue, but IIRC, the installers for 3.93 and down to somewhere in the 3.7x range (this seems to be very close to what the OP said about 3.80, so all 3.7x builds may work) crash when run under 95. The program itself MAY still work under 95 up to 3.93 IF the unpacking and installation process were done manually, but I never tested this.

I've been mostly offline for a couple of weeks and I return to find this. There aren't even words to describe the shock. I was just thinking that I haven't spoken with him in a couple of months and I should see how he's doing... and now I'll never be able to do that again. I was probably closer to him than anyone else here. I considered him one of my best friends. Unfortunately I never had the opportunity to meet him personally (although if I'd ever had occasion to go to New York we hoped to do so), but I've spoken with him on the phone and we have exchanged hundreds of emails over the years. He was always helpful and knowledgeable and never failed to help me with whatever issue I asked him about, from the small and insignificant to the overwhelming. I can't count the hours he probably spent helping me; fixing bugs, developing drivers, explaining arcane subjects so that I could understand them enough to help him... I always hoped that real life would eventually afford me the time to spend learning about programming and reverse engineering and that I would have his wisdom there to guide me along the way.. and now it's lost... Oh God this doesn't do things justice but I'm at a loss for any more words right now. Rudy, you will be missed.

It sounds as if the "product type" ("SKU" in the more recent Windows versions) of your copy of the upgrade does not match the product type of the key you have. Are you certain they were bundled together? I'm assuming you have a valid, legal Product Key for your Win98 upgrade in this situation. You can find the information you want here, but it is intended for research and informational purposes, not as a means to circumvent licensing requirements. Otherwise this discussion cannot continue; we cannot promote "bypassing" licensing requirements, even for such an old system. Just keep this in mind for any further discussion.