awkduck

That's funny. This covers about 90% of my account creations, these days. Yeah, I'm sure you just spiced up some fond memories. Congrats, on crossing the Rust threshold. Good to see it being put to good work ;) I am capable of patching. Without an overall solution, I could manage where ever I invested the time. Time seems to be the killer, of many projects, lately. The list would be huge. But, were talking about play, not practical. RemoteAdmin (older Win9x ver), Telnet, BBS (likely COM to IP [Telnet] servers), HTTPDs/FTPs, KDX/Hotline, etc. Many things needing both the servant(s) and client(s). It is just a matter of whim, before you find something (old) you want to try. Peter Tattam's Trumpet Winsock v5, already supports IPv6. But, it was commercial and may have only supported an older version of Winsock. Version 3.0d only supported Winsock 1.1. Here is a link from archive.org, with no security exception required. I don't know if it can still be registered (an email is provided for registration questions). But, it also requires that the machine date be set back (pre-registration) otherwise the shareware time bomb prevents if from loading. It may not work on WinME at all. Yes. this is the crux of the situation. If one created a new Winsock, then maybe support for legacy applications might be included. Off the top of my head, this wrapper idea was the cheapest/dirtiest fix. Yes, you are right. It seems to be "IPv6 only" only in some locations (Tuvalu). There isn't much clear indication, if overall IPv6 adoption would end IPv4. It is almost meaningless, if you are using modern software. The transition would cause no real noticeable difference (with most users anyway). Some are of the opinion that IPv4 will be here to stay, anyway. But, I'm not convinced that this is the case. Their argument is that, we are (many of us )already behind shared or fake IPv4 addresses; and why would ISPs give up that level of network access (IPv6 potentially being more direct IP to IP). My theory, of the practical nature of the thing, is that overall IPv6 adoption would be a good time to implement new legislation(s) about using only secured devices over the Internet. Meaning, that if you are connected, the devices must indicate/authenticate the users "real/legal" identity. IPv6 is certainly capable supporting this, for even multiple devices out of a single household. So, it may be a near mute consideration. Near, because I still see the potential to run legacy devices over such a connection infrastructure. It would likely just depend if that sort of thing was allowed (probably country dependent legislation). I can see the potential argument that insecure devices can allow insecure activity (vulnerabilities). But this is just a theory and, if a viable reality, probably a ways out yet. Its more likely to be seen in China, without a doubt; however, Digital Identity is still voluntary there.

What are your thoughts on IPv6? Is it coming? Are we still years away? Is IPv4 safe, for a long time? I know that a Win9x IPv6 Winsock is possible, since Trumpet v5 exists. But that doesn't help legacy applications, that expect IPv4 addresses. Programs like DC++ (or the many hub applications) are not likely to be rewritten for Win9x, with support for IPv6. Maybe IRC is a better example. It would be completely up to volunteers, to port (if the code was available) IPv6 into older applications; or port newer applications back to Win9x (or create fresh). Instead of all that, could a wrapper exist? A kinda local database of real IPv6 to fake IPv4 addresses For example, a firewall can detect every application's attempt to communicate in/out. While IPv4 addresses may be in short supply, for the world, it is unlikely that you will ever connect to enough IPv6 addresses to exhaust local faux IPv4 addresses. So, a firewall like application could provide a kind of transparent translation/proxy, for IPv6 >< Ipv4. Even if you where using some bittorrent application, browsing whatever websites your legacy machine could still load, BBSing, and ton of other activities, you'd probably never exhaust fake IPv4 addresses. So "maybe" it would just be a matter of implementing an IPv6 Winsock, and an address interception application (translation might need to be optional, per application, since retro programmers may one day be implementing IPv6 retro software)? Does this make sense? Is it even something to be concerned about? Will ISPs continue to work with both IPv4 and IPv6, as they are now? I've heard StarLink is IPv6 only. Anyway, thanks for reading.

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