awkduck

Hi @ruthan, The conflicts can be a real PITA, especially if it involves important "integrated" devices. Like you said, you can't simply just move it to a different slot. Shared IRQs, and other resources, can really be a problem. I've had issues with Video cards, using system memory, causing strange resource mishaps (no official or unofficial driver). But, sometimes it seem like Windows may be assigning the wrong driver, for a specific configuration. I have a laptop that will not detect most of the devices, until I replace the standard "PnP Bios" driver with the standard "PCI Bus" driver. I'm sure you can do registry alterations for different drivers. It seems many chipset installations are doing just that; especially on late 90's and early 2K machines. That might be the best bet. Even Linux drivers have configuration arguments, that can be set before or after boot (many Linux users never realized those exist). I'm into "Pro Audio" (not that I am "myself" a Pro). Shared IRQs can be a problem, depending on how demanding the situation is on performance. Even if I disable one of the two devices (bios) of a shared IRQ, it sometimes isn't enough. In that situation, if you are determined, there is usually still some potential hack. Keep in mind, this issue happens with both Linux (any *nix/bsd) and Windows. However, the difference there (Linux/BSD) is that you can sometimes recompile out the issue. Example: Linux (recompile) and Dos (esoteric arts) But, sometimes the conflict doesn't really cause any problems, at a practical level; it's just annoying to know that its there. And then, there is always the drivers themselves. Like audio drivers with no Dsound support (emulation only). Or drivers that were meant for a generic configuration, but your system is configured a little differently. So, its the right driver; but it isn't going to work right on your system. This particular issue can sometimes be fixed, by specifying hardware values in the registry. I suppose I'm being more conversational, then helpful. If anything, I guess I'm just saying "I'm there with ya, bud". If you are really interested, there are some resource on the 9x registry out there (archive.org). Watch out for the novice documents, advertising "advanced" internal wizardry (not that good). If you run into the need to hexedit,debug,etc, don't be too afraid to try it; unless the potential risk of hardware failure is absolutely out of the question. But the more you "poke/peek" at the esoteric arts, the more familiar it becomes. You may feel like it is useless, but it does slowly start to sink in. I've "cough" repaired a handful of abandoned applications, that I can no-longer get support for (personal use). Wish I had more useful data, to had off.

You could probably go somewhat modern, if you can handle no acceleration (might not be supported). On a fast machine it might not matter, you just need the initial Windows setup and boot to finish. But to be frank, I never really used anything past XP. I keep a handful of custom Linux Pen drives around; that's how I always have an older version handy. v4.X (VirtualBox) might no be the last version to support older chipsets, its just one I know does. If you are going to newer machines, that probably isn't needed anyway. Yes, QEMU can be a pain. I keep the last version of 10 around, only for times when I'm on an older machine (no CPU Virtualization support [have to use Kqemu]). Version 11 supports Kqemu, but the partial migration to KVM slows Kqemu down. The last version of QemuManager works supports Kqemu (for windows); but I'm not sure if it works on anything past XP (I would guess it would run on win7/8). For Win9x, the are probably some Dos tools that would do the trick. But, it sounds like you have a good collection of options. Expanding the virtual partition, to the full size of your real drive, does need some good tools. I just cheat, with Win9x, and mount the virtual machine image and target drive from a LiveOS (of some kind). Once the target drive is partitioned/formatted how I want, then I can just copy the files over (preserving type, etc). On Linux (I know, Command Line stuff) I'd convert the VirtualBox image to an *.img file (raw) and mount it with a command like: mount -o loop,offset=32256 -t vfat temp-image.img /mnt But something similar could probably mount the image, without converting it to the *.img format. I just never looked into it. I use fdisk (Linux) to get the value for "offset". I type: fdisk temp-image.img (as root or with sudo); then I multiply the sectors size by the sector/tracks amount ("p" + "enter" lists the partition information, "q" + "enter" exits fdisk). In my case 512 x 63. "-t vfat" just means that its a fat partition. On Linux (for me anyway) it seems like the file-manager MC (Midnight Commander) preserves the file types, on copy (again as root or using sudo). Actually, I believe that is right. You could do it "before" shutting down Windows, on the VM. The setting are already active on the booted VM; so you will be able to shutdown normally, after deleting the key(s). Yes, in Dos mode "I believe" you still use regedit.exe. It just works differently, in Dos. I'm sure "regedit /? or -h" should give some hints. Basically you need to provide the key location to delete or location and key to add. But, I've lost the exact syntax, to time. Note: For Win9x, I just use the SYS command (maybe from a MsDos USB drive) moving or renaming msdos.sys first, then replacing it proper afterwards ). But my WinNT skills don't exist "at that level". I wouldn't know what was required to make a "lazy" copied WinNT's partition bootable. Jaclaz, and many other would. You probably already know all of this, already. Looking forward to hearing that your machine is 100% configured, how you like it. That's always a good feeling, except for that the fun is over and then its time to tweak with something else. :)

Just putting this out there, maybe it will help someone. I've also had a machine, that only had serial and USB ports. It isn't a "pure" install, but you can use a another machine or VM, with a similar hardware configuration. For me, I used an older version of VirtualBox (v4 series) since in still included a older Intel motherboard type. If your target media can be removed you can partition/format/etc from another machine, or potentially the VM itself (using target drive as the VMs ). Or, you could boot DOS from USB and format/SYS.COM the target partition. Then with DOS, or any other bootable USB OS, you can copy the contents of the foreign install (without overwriting the contents of the partitions root (or else you need to SYS.COM again [save your msdos.sys]) while preserving the files/folders types). Once booted, on the target machine, you can use the serial mouse to accept installation of the USB keyboard etc. Probably not an option for every machine out there; but it worked great for me. You could also remove the hardware profile of the VM/Temp Machine, via REGEDIT. Then on reboot, have an cleanly built device installation.

I'm not into games anymore. But way back when the original Halo was released, it was said to work on Win9x and WinXP; but not W2K. Was that eventually solved, or does it still persist? If anyone remembers that, what was the issue? I never really looked into it. Or was it some myth, propagated as truth?

I've read the warning about updates, when using multiple cores with W2K. There is a registry fix floating around, that addresses issues with multiple cores on W2K. Does the registry fix resolve the update issue? Or are they unrelated?

@Joaquim You can use it "outside" of Windows. If you boot Win9x "NOGUI" to Dos only, you can then use Sbemu. If you boot "fully" to Windows Sbemu will not work. Sbemu does "not" provide audio for Windows. It can provide audio for Dos "before" Windows loads. So, you "can" use Sbemu on a machine that has Win9x installed on it (ME needs boot to Dos patch). Sbemu is "compatible" with Win9x "Dos". BUT, you will need to "configure" Dos to use Sbemu. You might need to read though https://www.vogons.org/viewtopic.php?t=93006

Dear God, let it be just this :)

What is the audio chipset? How new/old is the driver that you used? The driver's inf file usually has a date in it, near the top (inf file comments). While you are checking out the inf file, just check that it is indeed a CHICACO style inf. I'm guessing that device manager actually says the driver is working correctly? You could also check the driver file properties (while you are in device manager) to see if some of the files listed exist inside your driver's installer folder. Just check the folder corresponding to Win98 (could also be a folder named win95, win9x, vxd ,or wdm). Some of the files listed may be Windows system files, so not all files may exist in the driver's installer folder. If you had to hunt the driver down, off the net, then it might just not be the perfect fit for your machine. Especially, if it is newer. I've had problems, like the one you are having, when the driver was made for a different version of Windows (some actually worked). If the driver is old, like say before WinXP even was on the market, then its probably something else (registry issue?). If the driver didn't come with the device, it could still be an issue with your machine not matching some special configuration. I've seen, for example, an Emachine audio device not work because it was fabricated just a little off from standard. Drivers matching the hardware vendor ID just wouldn't work. It had to be the Emachine version of the driver. Even a matching driver, from a different Emachine, would not work. I haven't seen it often, but when I have, the driver almost always needs to come from the restore CD/partition. I've seen some old Compaq machines like that too.

It has been a little bit, since I played with 95. Sometimes, the chipset data is important, but not always. At what point do you get hung up, if you don't use the chipset inf at all? Is there a device you cannot install a driver for, because it is not listed (without the chipset)? I think I had best luck with rlusb; but like I said. its been a little bit.

It has been awhile, since I have worked with KQemu. I believe that the Win9x kernels lack something that KQemu needs to access user space, for processing. Not to mention that the .inf installation file isn't written in "CHICAGO" format (service installation). I'm pretty sure I ran into this same thing, when looking to see if I could get ArOS (Amiga clone Co-Kernel) or CoLinux (Co-Kernel) to run on Win9x. All three required Win2k+ (KQemu maybe WinNT4+). But I did find that it might be possible to get it somewhat working. It has been awhile, but I think the easiest solution wasn't as clean, compared to the NT kernel method. A little less sand-boxed (one reason no one bothered), because Win9x is a single user system. Also, around that time, KVM became king; no one cared about KQemu anymore (except users with older CPUs).

You could still try SweetLow's Dos Drive Removal tool. Since it still froze, it is more likely something specific to that pendrive. Some have a fake CD image, with software for the pendrive (I haven't seen any like that, for years). That could also cause an issue.

Did you unplug the pendrive, and then reinsert it, before you typed win? If you did not do this, then you have not completed the test. When you boot to MsDos, the issue is still present. When you unplug the pendrive, you disable the issue. Then you can plug it back in, and type win. It should not freeze. Please verify that this is what you have done. If you have not, please test it and report back. Sound in Dos? That is something totally different. For game sound, in MsDos, you will need SBEMU or VSBHDA. But they only work in Dos, not Windows. BIOS drivers are what MsDos uses to access your USB pendrive. You don't/can't install them. They are part of your BIOS, and MsDos uses BIOS drivers. When you boot MsDos, it uses these drivers to access the Disks and Harddrives. When you boot Windows 98SE, it uses MsDos to boot, before going into Windows. So the BIOS drivers are being used by MsDos, to access your Pendrive as a system disk (not all systems do this). What I am asking you to do, is disable the BIOS drivers "before" loading Windows. You can do that by just unplugging then re-plugging in the pendrive, before typing win. No matter what, you boot from MsDos. That is how Win9x works. But in MSDOS.SYS, BootGUI=1 mode, Windows is loaded right after MsDos boots. So you can not disable the BIOS pendrive driver, by unplugging it (you have no time, because Windows loads immediately after MsDos). Do you understand? BIOS is part of your Laptop's firmware. This is why some newer machines, that have no BIOS/or lack a full BIOS, cannot boot MsDos/Dos (only in a virtual machine). MsDos uses your Laptop's built in BIOS, to access the hardware.

USB Freezing - For me, I'd still like to know if boot-up freezes, when you (1) boot to dos first [pendrive plugged in], (2) unplug then re-plugin the pendrive, (3) and finally boot windows with the "win" command. If it does not freeze, then it helps "more certainly" point to the issue I have been describing. I also believe, SweetLow is waiting for an answer dealing with Dos. If you don't know how to get MsDos only boot, there is a file C:\MSDOS.SYS. You can edit it, and under [Options] change BootGUI=1 to BootGUI=0. If it isn't there, then add it. This will boot you to Dos only. You simply type "win" (without quotes) to start Windows. You can then change it back to BootGUI=1, to re-enable loading Windows on Boot. I don't know the full story, on the different version of the USB driver. They may all have the forced hand-off. But if not, it might be good to know which one you installed. Maybe even verify that you are actually "now" using the new USB driver (device manager). If you just right click and install from an inf file, the old driver is still probably being used (just an example scenario). I know less about the Dos Drive Removal tool, by SweetLow. But, if indeed a duplication is causing your freezing, then you may need to install that also. Since SweetLow is already in this thread, you are lucky. SD/MMC - I really doubt that your driver is installed. Almost all of these SD/MMC drivers, for machine 2005 and newer, use NT services. I don't think this will work in Win9x. I don't even think the registry entries are compatible (for services). I've altered the registry keys to be Win9x compliant, but the Winnt system files are not present or the Win9x system files are not compatible (with the driver files). So, I have never gotten them working. Maybe someone else has? These driver are most certainly meant for a newer version of Windows, and might not (most likely will not) retro fit. The driver looks like it is installed because it's device name, associated to your hardware ID from the inf file, is displayed under "Device Manager". But the driver is not actually functioning. So you have the right driver for the hardware, but the wrong driver for this version of Windows. Sometimes you can get lucky; I haven't seen much luck with SD/MMC drivers. Keep in mind "Device Manager" will say this device is functioning, but it isn't doing anything. Sometimes you can even examine the installed files, listed for the device in "Device Manager", and nothing will be listed. Often times, when installing Win2k+ drivers on Win9x, the driver files do not even copy to the system. And yet, "Device manager" will say the device is functioning properly. This is because there is no fault being issued to "Device Manager" as these drivers are not configured for Win9x. Heck, even the right drivers used with the right hardware, and version of Windows, don't always work. And they still report they are working properly. Also keep in mind, unless your SD/MMC slot is just a SD-to-USB convertor, USB drivers do not pertain to SD/MMC devices. So SweetLow's USB driver's will not initializes the SD/MMC drive slot. This SD/MMC issue can be frustrating. But often on these near post Win9x era machines, the Cardbus slots work with Win9x (not always). If that is the case, you can get a PCMCIA SD/MMC Card. The generic driver (for PCMCIA SDcard Adapter) that comes with Win98FE worked for me. But there is no guarantee. I've used (so far) up to a 64Gb SDcard. FYI, on Win98FE I have the same Boot issue, with inserted pendrives. I am also using SweetLow's USB driver, but the NOWMI version that comes with it. I still have the boot freeze issue, but have been doing the work-around I mentioned earlier (only when I need USB audio). If I don't need USB audio, I've been using Grub2 to kick the BIOS drivers. I have yet to use SweetLow's Dos Drive Letter Removal tool. So, if I get a chance, I'll see if I can correct it on my machine, and then pass along the knowledge. If you beat me to it, I won't complain :)

Joaquim, if you are still interested in help, we may need more information than this. Like, -what is this "card"? (the usb drive?) -have you installed the USB driver? You said nothing happened when you plugged in the card; but we are talking about freezing, at boot when USB drive is still inserted. Was that meant for a different topic?

It is probably something to do with your browser. The link worked for me, but I got a warning about the link not being "https", while using Firefox. An older Seamonkey browser downloads it right away. So, the link is alive.

You are right. Both need to be addressed/understood.

So, unless I am wrong about the cause, this is what Joaquim should try. It would be a nice clean fix.

You should try the painful workaround, I mentioned earlier. If it works, it identifies the issue more clearly. Disable booting to Windows, from MSDOS.SYS. Reboot the machine, with the pendrive in. Once you are at the Dos Prompt, unplug and then re-plug in the USB drive. Then type win, and see if you boot normally. If you do not freeze, as before, then it can be "loosely" called a USB hand-off issue. Although, similar behavior (between two or more different machines) doesn't mean it is the exact same issue; it has to do with the BIOS USB drivers being released. Being unplugged, in MSDos, releases the drivers. Then windows can boot normally. I want to clarify, I am saying BIOS drivers; but this is really misleading. I just haven't taken the time to give a full on description. It has more to do with BIOS/firmware design. Some may consider this issue a bug; since other systems boot just fine, with a USB drive inserted. But often the machines with this issue were never meant to be used with Win9x. So you really can't call it a bug, but rather lack of backwards compatibility. It isn't always 'entirely' a hand-off issue. BIOS may have assigned the wrong geometry or drive type, to the device. BIOS my have detected a USB thumb drive, as a USB supper floppy or zip drive. With the different variables in BIOS design, there are different behaviors and fixes. There is probably a Dos tool, to 'potentially' configure the state of your USB device (and other settings). I just haven't looked. A person could boot to Dos, then autoexec,bat could run the tool, and then load Windows. But, I've gone on awhile about this, risking the part of a fool. Should wait and see if this is actually the problem or not. I wouldn't mind being "thumbs down" wrong about this. Especially, with my own machines. Even more especially, if it meant I could fix it differently.

I know you can "sometimes" fix this by using the Grub2 bootloader. You initialize Grubs USB drivers, before boot; rather than boot with bios drivers, still enabled. But I've had this actually cause the issue, you are trying to fix, on machines that booted fine (with USB drives still inserted). On one machines it fixed the issue, but prevented USB audio devices from functioning correctly. This same trick has fixed, and caused, USB drives being detected incorrectly (type[thumb drive seen as a super floppy or zip drive]/geometry). There is a painful workaround. Set your machine to boot directly to MsDos. Then remove the pendrive, and type "win". This is only useful if you keep forgetting to remove the drive before you boot/reboot. It might help to echo a reminder in autoexec.bat, about removing the drive. Grub2 can be a real trip to wrap your head around. It may not be your best option; especially with the risk of failure. But It has worked, from time to time. An even more tedious possibility, is modifying MSR registers to alter the state of the USB devices. You could end up with the same set of problems I've mentioned with Grub2. But it would give you a more direct control over it. But finding the data sheets, for you machine, might be hard. And your data sheet may offer no options for adjusting the USB device state.

The picture does not show everything, you have installed in network components. But if the TCP/IP protocol is not installed, you won't be able to browse the Internet. Once/if installed, you may have to configure a Static or Dynamic (DHCP) I.P. (and potentially the subnet) address. If I remember correct, you can do that by selecting properties on the TCP/IP protocol. In properties you can select and or set the IP address and acquisition mode. If you are using a static IP address, you will need to manually enter in a DNS, other wise text URLs will not return an numerical address for connection. You may need to reboot. There is a way to acquire the address without reboot, but I don't know if those command line tools are installed by default; nor can I remember which one to use. I seem to remember Win95 having something other than the well know "IPCONFIG". But after rebooting, you can check the same properties, for a assigned dynamic address. There is no need to check for a static, since you assign it yourself. You can test for connectivity by using the command line tool "PING" (if installed). Commonly you ping your router and or modem; then aim for the internet, like pinging google. If you get a message like "host not reached" (or something similar) then you probably need to check you configuration. Otherwise, you should receive millisecond measurements of your ping's return. If anyone one remembers more about installing the command line network tools, please chime in. I remember my Win98se systems seemed to always install them. But my Win98FE, Win95A, and B didn't do so. I had to manually install them. And the different available command line tools (network) are getting fuzzy, in my memory. Mostly, the earlier network tools. It might also be wise to find an older free copy of TCP Optimizer (compatible with Win9x), unless you know where and how to configure those things yourself. At the very least, search for an online guide for tuning the your system for modern internet speeds. Otherwise, even small downloads can seem painfully slow.

Good luck. Hope everything works out.

I believe that is correct. It is my understanding that this patch could potentially make things worse, or "at best" not really make a difference. But I can't claim, with 100% certainty, that it won't help; instead with just an awful lot of certainty.

From private messages, I was able to tell Joaquim is referring to rloew's "Win9x 512Mb Nvidia patch". I believe there may be another patch, someone could be referring to. One specific to updating video device bios/firmware so that cards not compatible with the Win9x drivers (at all/hardware too new) could possibly work. This patch (rloew's) is extremely unlikely to help with the "black out" issues. It is a 2 path option patch. (1) driver patch - patches the driver limiting it to the use of 256Mb of video ram; thus preventing issues when the driver attempts to use beyond the 265Mb reported by the hardware. (2) hardware patch - updates the video device bios/firmware to report to the driver the full 512Mb of video ram, to the driver; thus preventing the driver's attempt at writing to the later 256Mb of ram, that isn't correctly allocated. !!!!Note: I may be getting the technical explanations of this patch incorrect, but I only gave the patch manual a brief skim. I think my description is near enough to express why this patch shouldn't change the "black out" issue. By all means, improve my description; I welcome the corrections. I would highly discourage updating the bios, unless you were sure it solved whatever issue was believed to be solved by doing so. As for patching the driver, sure. I doubt it will help. But in the spirit of desperation, I understand. These are the directions, as provided in the patch manual.

Joaquim, I don't think "anyone" has gotten regular drivers for HDA to work on Win9x(95,98,ME). The only driver with support, that I know of, is Walters Driver. You could use a USB audio adapter. Windows has built in drivers for that.

Which devices have the conflicts? Did disabling acceleration stop the black outs? There is a possibility an updated DirectX could help. I've had no experience with the specific drivers you are using. So, I can't speak to the probability of this being the issue. Unless you prefer not updating it, you could try and let us know the results. You audio device seems to be a Realtek HD Audio. It can be a bit of a struggle getting those to work. Deomsh does some work with Walter's HDA audio driver. There are several threads here, where you can examine the process of getting it to work. It may work right away. Did you search for more information on the video patching? There are some discussions here, about it.