awkduck

@jumper Yes, that sounds right. Have you used a Dos Ethernet packet driver, before? I could expand on this a bit. When you install a packet driver, it creates a software interrupt vector. You specify that vector to the Dos application you'd like to use; either in a config file or as an command line argument. This all in real Dos. So with Win95, the Dos VM can reach that vector, having been setup at boot time (the packet driver installed at boot via Autoexec.bat). With Win98 (and above) this does not seem to be the case. I have tested it with different packet drivers and different machines (also Qemu). Another example would be trying to use Trumpet Winsock 3.0d with Win98 (or above). It seems Trumpet cannot access the Dos Ethernet packed driver, either. Trumpet Winsock 3.0d is not a Dos application. Trumpet is designed to provide a Winsock (16/32bit) to Windows, for Windows applications. I've noticed there is a Trumpet Winsock v5 (provides IPv6) that is specified for Windows 95/98/ME. It uses an Installed Windows Ethernet driver. So, this is a gentle suggestion that "maybe" Win98 (and newer) cannot use Dos packet drivers. However, this isn't truly confirmed; as Trumpet v5 came out later, and Windows Ethernet device drivers likely seemed like the "more" logical target (for a 3rd party Winsock). Note, in case it isn't already clear, I am successfully using packet driver dependent Dos applications, from Win95 DosPrompts(VMs). I can also use Pktmux, and share that packet driver with multiple dos applications simultaneously (VMs/DosBoxes/DosPrompts); as can also be done with Win3x(enhanced) and Desqview. Unless there is a option to allow the functionality, it seems Win98, and newer, are unable to do this. EDIT:I am aware of tools to emulate a packet driver, for Dosboxes/DosPrompts. So, if you have an installed Windows device driver (for your Ethernet device) you can run multiple Dos applications, with packed driver emulation over the stock Windows Winsock. I'm just more curious about the change between 95 and 98, concerning real dos packet drivers.

Hi @jumper, Software interrupt vector (example 0x60) established in "Real" dos, accessible to Windows Dos-Prompts/Dosbox (not DosBox emulator). As a basic example, you would install a network card packet driver, via AUTOEXEC.BAT (real dos). Then from inside windows, you would open a dos-prompt and use mTCP's SSH (or any packet driver dependent application) over the "real-dos" packed driver vector. I haven't had an issues doing this in Win3x(enhanced/standard) or Win95. In Win98/ME the dos application (like mTCP SSH or Telnet) seems to target the interrupt vector, but it does not actually function. For example, mTCP's DHCP will give a false MAC address (55:55:55:55:55:55) and acquire no IP. Before anyone asks, the driver for the Ethernet card (Win98/ME) is not installed, as is duplicated in Win95/Win3x. I don't even know if this is possible in Win98/ME. Something may have changed. But I never really looked into it, and thought perhaps it was just an option/preference/configuration I overlooked. I do tend to overlook things easily, from time to time. It wouldn't normally be testable, in ME, without some patching.

I've been meaning to look into this, probably going to this weekend. Maybe, it is just a matter of clicking a check-box preference, for the Dos-Prompt? Anyway, in Win3x and Win95, you can install a packet driver (at boot) and then target that drivers assigned interrupt, from a DosBox; for example, with the mTCP Dos applications. I never looked in to why, or if there was a configuration for it, but you don't seem to be able to do this "out of the box" with 98 and ME. Anyone know if it is just a simple setting, or rather something more intrinsic?

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.