awkduck

Hi @ABCDEFG, Just checking to see that I've got you right. You're saying, we could used an extra core, for the software GPU. You are also clarifying, that this is different from truly taking advantage of a multiprocessor/multicore system; which we cannot do. This I 100% agree with. Thanks for pointing that out, so we don't get lots of hopeful multicore win9x questions. I dream of taking a couple year holiday, and doing something fun with these, and other, ideas. I've been wondering if I could host a VST server (something similar to MuLab Plugin [used to be called Mux], or VSTHost) on the available cores (one host each). Each host being available to any Midi capable (potentially audio route-able) DAW. It would have to be a "from scratch" project. Hard to get motivated for something like that, with only "occasional" weekends available. Going into it, there are ALOT of problems with such a goal. Might get reduced to one core being a SoundFont/GigaSample server (headless); something like LinuxSampler. But, in the end, I'd be one of the few, or the only person, to ever use it. PipeDreams. But, SoftGPU sparks a little fame under my chair. @FantasyAcquiesce, I did compile some MMX/SSE1,2 software rendering Mesa binaries (I think you are encouraged to use the included non sse3+/Avx binary, for older machines [i915]). The included binary, without AVX, doesn't include SSE. On an Pentium M 1.2ghz, Unreal Gold "with Wine3D" was almost acceptable @ 640x480 & 800x600 both 32bit. The binaries I built only seemed marginally better; however, they scored noticeably better with the included OpenGL benchmarks (the Unreal game engine probably taps out any boost the SSE (and assembly optimized) builds ?may? potentially provide). So yeah! On a faster CPU, there may be a bit of hope for some older machines (the included Mesa [softpipe] probably being sufficient). I'm not sure they were worth my time. But if any one wants to test these older Mesa builds, I could upload them somewhere. I've also noticed slightly faster load times, with older versions of Wine3d. But, nothing huge.

The MESA LLVM uses it, or its just a soft dependency? I am glad the 2D VESA doesn't need it. That would be scary. EDIT: I guess I'll find out soon enough. I'll test it out on the next machine I setup. Its a pretty interesting project. I've wondered if the source for rloew's Win9x multi-core API came came out, if projects like this could use it (or it's ideas). I can't count the times I've though something like this should be possible. Its kinda great that someone has taken the time to keep polishing it into a reality.

Its not a problem, just a curiosity, but I noticed the dependency on the Winsock 2 Dll. Does it actually use Winsock, or is that just a default dependency from the building tool chain's configuration?

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.