awkduck

Very nice!

I did find that Startech sells a mpci-e to pci-e riser, with a nice case and power supply. They were over $150, and I'd still need to convert slots to legacy PCI. Not saying under $200 is bad, but I am cheap.

I've been tempted to move to Alaska, from time to time. I've always been worried about the circadian rhythm. Messed mine up once, long ago, while working the overnight shifts. But, if moving to Alaska, maybe moving out of the US is an option too. Sorry, off topic. Soldering it fine. I use many old things, and must repair/modify them. I am also a little cheap; so buying it when broken, and fixing it for my use, is handy. Often, I don't take the time to make things look as nice as they could/should (except for guitars). I wondered if there was an already existing solution.

I have plenty of Laptops and Thin-clients. Majority of the more powerful older systems (circa 2005-2012) have internal MPCI-E. So, it seems I can buy MPCI-E (male) to 2x legacy PCI (female); but it has no case and is powered by sata power (meant to be use in a desktop). Most external sata powers supplies are DC adapter/USB to Sata power cable. They typically provide 2A, which isn't enough (a fair PCI GPU will use 7A, for sure). I have a MICRO PC case, and could run it (MPCI-E to PCI) off the power in there, potentially mounting the 2 PCI slots inside it. Before playing with any of that, I thought I should ask if anyone has seen something that comes with it's own case/power? The bare adapter runs about $40 US. I wouldn't want to pay a whole lot more, than that. I've seen PCMCIA (male) to 2x and 4x PCI (female); but they are rare and costly. However, they came with nice cases and power supplies. My MICRO PC case has a fanless PSU, so it may be the best choice for me (noise is important here). But, if there ever was a place to ask advice, this is the place. Notice:This may not be a solution, for adding PCI cards to "late era" Win9x machines. For that, the PCMCIA route is likely more certain.

I do apologize, I'd love to follow the path jumper has started, and or research rebuilding/test alternative run-times/applications. I don't need Pidgen (prefer IRC/BBS[Mystic]/Hotline/KDX), but I enjoy working this kind of thing out. Access to my.... Retro machines? is limited, and free time is gobbled up. Supposedly, this winter will improve the situation (for awhile). @jumper has again stepped up as an upstanding member of the community. Several members here are quite inspirational to me; and I am glad they so willing help other.

Not sure if this will improve the situation or not (maybe you solved it already?), but you could try using other builds of GTK+2. Pidgin does offer a package without GTK. Even if the builds are newer, they may have been built with different build environments and configurations. But, it should be noted that running with a global set of GTK dlls can be irritating (if you need more than one set of Global GTK dll versions). OTOH, building Pidgen and GTK+2 with a different build environment and config could also solve the issue. I think Mingw32 has flags to set the max winver to support during compile (I believe there was two required). I'm guessing an old Mingw32 and Msys would work (still on sourceforge); probably shouldn't need Cgywin's userland). The source documentation may provide a hint. There are times when setting the max winver flags can bork the build, if the code explicitly asks for something. But, GTK is less likely to cause an issue there. And from the looks of this issue, Pidgen probably wouldn't either, or it could be an easy fix. Maybe of interest, this guy tested some different win32 GCC versions, and TDM-GCC may also be an option. You can find userland (msys) included versions of Mingw and TDM-GCC floating around on the net. Its harder to find, but there are fully bundled versions of Cgywin floating around, too (more useful for the usreland). Don't have my old GTK+2 builds around anymore. Kept GTK+1.3 only, it seems. But that doesn't mean someone else's builds couldn't improve the situation. Maybe here or here? You can also check on "mmnt dot ru slash int". Search gtk+ and then within results something like win32.

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.