Sockets aren't functional because of a reference to ws2_32.dll
vlOd2 opened this issue · comments
The sockets API internally uses winsockets and it's referencing ws2_32.dll (which doesn't exist on Windows 95)
I would try to patch this myself, but I have no idea how to edit the winsockets DLL directly without breaking the signatures or whatever
Dont you just love signatures. :) Thanks Signed Code!
/endjoke
Hey, thanks for testing! It seems like the solution here might be to find a way to get ws2_32.dll working on 95 - perhaps it'll work already if we point it to my DLL wrappers? I'll look into it at some point
I think the best bet would be probably to try and get .NET to use winsock.dll instead of ws2_32.dll, or make a stub that calls winsock
I tried to edit System.dll to reference WINSOCK.DLL instead, but as the APIs are way too mismatched (+ a bunch of other stuff), it didn't work :P
Dont you just love signatures. :) Thanks Signed Code! /endjoke
Ignore the project name, I just wanted to quickly test sockets lol. I knew they would probably have issues, as they are very hit-or-miss in early Windows
Hey, thanks for testing! It seems like the solution here might be to find a way to get
ws2_32.dllworking on 95 - perhaps it'll work already if we point it to my DLL wrappers? I'll look into it at some point
Would porting the entire dll work? or just bashing our hands against our keyboards until microsoft does somthing for once the best bet. (they never do)
Best case, we just point the imports to my wrapper DLLs (might have to add a few more system calls, we'll see) and it works. Worst case, maybe we can port over the DLL code from Wine?
So we are StealBORROWING Code from wine then. :)
For real though, it'd probably be the easiest thing to just point it to the wrappers, and fill in any missing calls, or see if the wine dlls even work for starters. I Cant test it right now since i dont have a vm setup.
Best case, we just point the imports to my wrapper DLLs (might have to add a few more system calls, we'll see) and it works. Worst case, maybe we can port over the DLL code from Wine?
Windows 7 Extended Kernel developer here:
A few things:
- OllyDbg works on Win95 and should likely serve you a lot better than the archaic version of WinDbg
- There is actually a standalone version of Orca.MSI available, though it was released by a third party. No need for the Windows SDK
- Rather than using dumpbin, it is ideal to use Dependency Walker, which will show you specifically which functions are missing and which ones you have. This way, you don't have to comb through a bunch of things that already exist.
- The wrappers you made could be turned into an actual "extended kernel" similarly to KernelEx. Rename the original dll's to something else (I like to replace the last character with an _), put your wrapper at the original path and then forward all original API functions to the original that you renamed. Though, wrapping it this way can cause some instabilities, so it is best to just patch the functions into the original binary with a hex editor, fix the broken instructions in IDA, and then update the export table to add the functions (I usually move the export table to the end to make it easier)
Feel free to shoot me a message if you'd like to learn more about this. =)
as the APIs are way too mismatched (+ a bunch of other stuff), it didn't work :P
You would have to patch the version requested when wsastartup is called.
All the Berkeley sockets stuff should be the same in both (bind, connect, read, write, close, shutdown etc.). The Windows specific WSA functions might not be available in the old dll.
You would have to patch the version requested when wsastartup is called.
All the Berkeley sockets stuff should be the same in both (bind, connect, read, write, close, shutdown etc.). The Windows specific WSA functions might not be available in the old dll.
I'm not too familiar with Winsock, but couldn't you just:
int WSAStartup(WORD wVersionRequired, LPWSADATA lpWSAData) {
wVersionRequired = 0; // whatever
WSAStartup_orig(wVersionRequired, lpWSAData); // original function
}
This way the data in the output pointer still gets modified by the original function after the version is changed, so all should be good.
but couldn't you just
Yes, set the version to 1.1 (MAKEWORD(1,1)) when calling the original dll.
However, MSDN says there is a thing called "Windows Socket 2 Update" for 95 and that might install the new dll? It also claims 95 OSR2 supports 2.2 out of the box.
https://web.archive.org/web/20040320073520/http://download.microsoft.com/download/0/e/0/0e05231b-6bd1-4def-a216-c656fbd22b4e/W95ws2setup.exe (https://web.archive.org/web/20000229194643/http://www.microsoft.com/windows95/downloads/contents/wuadmintools/s_wunetworkingtools/w95sockets2/releasenotes/releasenotes.asp claims you might need https://web.archive.org/web/20000511213719/http://download.microsoft.com/msdownload/dcom/95/x86/en/dcom95.exe first)
Confirmed that W95ws2setup is working on my VM. Didn't install dcom95 and it still works.
(bear in mind this a simple test to connect to a socket)
EDIT: Tested with a local network socket as well on port 8080 to test that (just in case anything weird happens) and that works too.
@dotexe1337 Thanks for the info! I'll be sure to look into OllyDbg
The wrappers you made could be turned into an actual "extended kernel" similarly to KernelEx. Rename the original dll's to something else (I like to replace the last character with an _), put your wrapper at the original path and then forward all original API functions to the original that you renamed.
I did think about doing this, but at that point, I didn't want to commit to handling more than one app and just wanted to focus on .NET. That being said, I'm not necessarily opposed to spinning this work off into continuation/alternative to KernelEx (seems like the one for 98/ME hasn't been maintained for some time).
Confirmed that W95ws2setup is working on my VM. Didn't install dcom95 and it still works.
(bear in mind this a simple test to connect to a socket)
EDIT: Tested with a local network socket as well on port 8080 to test that (just in case anything weird happens) and that works too.
I will try it too, I already installed this a few hours afterwards whilst messing around with some Opera versions, but I didn't know it added ws2_32.dll
as the APIs are way too mismatched (+ a bunch of other stuff), it didn't work :P
You would have to patch the version requested when wsastartup is called.
All the Berkeley sockets stuff should be the same in both (bind, connect, read, write, close, shutdown etc.). The Windows specific WSA functions might not be available in the old dll.
It's useless, as .NET uses WSA functions from what I was able to determine
I can also confirm that W95ws2setup works perfectly fine! (the received data is decoded to ASCII and then printed)
With this I can also confirm that multi-threading and winforms invoking works too
Although the exception handling isn't working as expected, the exception was supposed to be No connection could be made because the target machine actively refused it
That Win95Crap namespace.... 😂
I did think about doing this, but at that point, I didn't want to commit to handling more than one app and just wanted to focus on .NET. That being said, I'm not necessarily opposed to spinning this work off into continuation/alternative to KernelEx (seems like the one for 98/ME hasn't been maintained for some time).
KernelEx is still maintained via a third party fork, though I think the original developer ceased work on it about ten years ago.
It's very much still a WIP and is intended primarily for developers, but I was able to get it to run some fairly modern XP programs like Firefox 52ESR & MyPal 29 (Pale Moon-based version): https://imgur.com/a/DGymVZc
In fact, there are a couple of large forum threads on MSFN discussing the development of KernelEx, which may have some useful information for your project if you're willing to comb through them (which I'm sure you are based on the time & dedication you tend to put into your projects =P):
https://msfn.org/board/topic/175276-kernelex-unified-topics-links-index-thread/
In particular, you'll want to check out the threads for KernelEx updates by Jumper, Kext (DIY KernelEx extensions), KernelEx Auxiliary DLL's, and ImportPatcher. Those are the third party updates & tools that are still being developed on-and-off for it.
Though, KernelEx is not particlarly stable. If you try to run such modern software on it such as web browsers, you'll get a BSOD just about every minute telling you you've ran out of resources, and very intense stuttering & lag.
I'm unsure how much of this is attributed to Windows 9x itself and how much is a problem with KernelEx, as it's not a traditional extended kernel, but rather is an API extension that injects into the process at runtime, which may or may not be perfectly stable depending on how it's implemented.
Closing this issue, for now, as it is pretty trivial to fix by installing the Windows Socket 2 Update
but couldn't you just
Yes, set the version to 1.1 (
MAKEWORD(1,1)) when calling the original dll.However, MSDN says there is a thing called "Windows Socket 2 Update" for 95 and that might install the new dll? It also claims 95 OSR2 supports 2.2 out of the box.
https://web.archive.org/web/20040320073520/http://download.microsoft.com/download/0/e/0/0e05231b-6bd1-4def-a216-c656fbd22b4e/W95ws2setup.exe (https://web.archive.org/web/20000229194643/http://www.microsoft.com/windows95/downloads/contents/wuadmintools/s_wunetworkingtools/w95sockets2/releasenotes/releasenotes.asp claims you might need https://web.archive.org/web/20000511213719/http://download.microsoft.com/msdownload/dcom/95/x86/en/dcom95.exe first)
KernelEx is still maintained via a third party fork, though I think the original developer ceased work on it about ten years ago. It's very much still a WIP and is intended primarily for developers, but I was able to get it to run some fairly modern XP programs like Firefox 52ESR & MyPal 29 (Pale Moon-based version): https://imgur.com/a/DGymVZc
Can you provide a link to that fork? Is it on SF? GH?
Can you provide a link to that fork? Is it on SF? GH?
@rcmaehl It's on MSFN, as mentioned. It isn't simple to set up, since you need to comb through hundreds of pages of forum threads to find all of the right binaries, write your own KernelEx config file with the right load order & stubs, and other things.
I can also confirm that W95ws2setup works perfectly fine! (the received data is decoded to ASCII and then printed) With this I can also confirm that multi-threading and winforms invoking works too
Also talking about this project being functional, check out this
Sweet, I've added a link to W95ws2setup in the README for future reference.