awkduck

Is that MSFN post about Win95? Anyway, you can swap out the dlls by booting to DOS. C:> ren \windows\system\shell32.dll \windows\system\shell32.lld C:> ren \windows\system\shell32.new \windows\system\shell32.dll That's if at the C: root. Just rename and copy the new one(s) over before you re-start in DOS. Then you can test and look for problems. If it doesn't work, start in DOS and revert. I'm running with version 4.0.0.1112. The last version of IE, to work with Win95, probably has the "official" latest shell32.dll for Win95. I'm not sure if there is a newer one. I've 7zip and Cab extracted IE before, and found the stuff I've needed. After extracting the main packaged installer, I needed the Cab extract found in the contents. Their are folders designated for the different versions of Windows. So the one with shell32.dll and labelled with a 95 is the one you want. There are probably easier ways to get it. And, the one in the latest IE (for 95) might not be the newest usable.

In that case, it might be a little bit before I can test it (the patch) In all seriousness, it might not be that bad. Depends on the source. IPv6 was implemented in v2.8.6; maybe for the Win port too. Side Note: I've noticed that some Ws2 applications will work, with the older versions of Trumpet, if the Ws2_32.dll is present. But not many.

Nice work I've got a hand full of WinSock 1.1 compatible apps. All of the old Xchat clients, before it went demo/paid/shareware, should work. But that would only test the IPv4 connectivity. Whats an IPv6 application, for Win9x? Xchat 1.8.8, Last one. Also have a Win95B VM (no WinSock Update), I could probably test it on. Yeah, it would be real hard to use only WinSock 1.1 applications. By 2001 almost everything was WinSock 2. But, it is interesting to see how he implemented it. Hx Dos extender has a WinSock implementation (Incomplete, I think?). It rides off of a packet driver and provides networking for Windows applications, in "real" dos. I suppose ReactOS has a WinSock, too. Both offer a peek into making a WinSock. But that is a time eating project (a little bit, anyway). It seems like it might be an inevitable need, I just don't know how soon. Although, I'm sure we'll figure it out, if the time ever arrives

I imagine it is the same WinSock revision as his earlier Trumpet versions. Think back to Win3.1(1). Before Microsoft released Wolverine (TCPIP, for Win3x) and Trumpet was the first to market. I'm pretty sure his WinSocks are only v1.1 (Win95A/Win3x). I've read that he aided the Mircosoft employee that wrote Wolverine (tips over email?); Wolverine also being WinSock API v1.1. Back then there was actually a program for swapping out your WinSock. I think that is the same-ish logic Trumpet uses, as during the install it searches for other WinSocks and renames them. Supposedly, there were a handful of WinSocks. I think AOL had one. If Trumpet v5 does as older versions, the stock WinSock should still be there, just renamed. I think the only way around the TimeBomb, is to keep the clock behind. I have no clue about run-as-date type programs, as I've never found them useful. If a person had a key, and unlocked the program, supposedly it would be fine to run it ahead again. But, who knows if getting a legal key is possible anymore? I'm also not sure if it works with ME.

Check out here. While it is still up, anyway :)

Well, this would be a solution for many retro systems. A person could probably make a small Linux router for the task. Maybe a RPI-zero or something. For virtual machines, one might also be able to modify Qemu, or intercept it's traffic. Something on a bare metal install, without a router, might still be nice. @FranceBB, thanks for commenting. Glad people are thinking about it.

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?