Built into every version of Windows since Windows 95 is WinINet, which provides HTTP, FTP, and (in XP/2003 and earlier) Gopher. Obviously for older Windows versions, this library won't include support for recent technologies like TLS 1.3 or HTTP/2.
Not long ago I remember coming across some discussions about upgrading SChannel (the actual TLS component in Windows) in older versions using OpenSSL or other TLS libraries, but can't find at the moment. The advantage of doing so is all other apps going through WinInet automatically get the upgrade.
One solution that works network-wide is to use a MITM proxy; I run one mainly for adblocking and filtering, but another feature it has is automatically upgrading TLS requests to the latest version it supports - currently TLS 1.3. Unfortunately, thanks to Big Tech's monopoly, I get blocked by many sites because the requests it makes doesn't look enough like an officially sanctioned browser, which is another thing I need to get around to fixing eventually.
Not long ago I remember coming across some discussions about upgrading SChannel (the actual TLS component in Windows) in older versions using OpenSSL or other TLS libraries, but can't find at the moment.
> Today's MSDN docs are a minefield of incorrect version information.
I've discovered the same thing a year ago when me a colleague and I wanted to add Win2k support to an old tool (hobby project obviously, not work related :D). Ended up in a visual basic 6 forum where someone created an html table with all the exports of the core DLLs for almost the entire NT line. Was really useful and I ended up adding limited NT4.0 support to the tool just for fun.
Honestly, the weirdest thing about reading this for me was the use of a .js file to drive it. But then I started to remember how horrible batch scripting was.
For reference, cscript/wscript (which can call other languages too) are calling "jscript", which just is microsoft's implementation of ecmascript/javascript with nonstandard extensions.
ES JSc IE(/other)
- 1 3.0 (part of Win95 OSR2 by default)
- 2 (IIS 3.0)
1 3 4.0 (part of Win95 OSR2.5 and Win98 by default)
" 4 (VS6)
(2) 5 5.0 (part of Win98SE by default. ES2 is mostly just wording changes compared to ES1)
" 5.1 5.01 (part of Win2k by default)
3 5.5 5.5 (part of WinME by default. ES3 is what standardized exceptions, among other things - I'm not sure what MS extensions were like before this)
" 5.6 6.0 (part of WinXP by default)
" 5.7 7.0 (part of WinXP SP3 by default)
" 5.8 8.0 (part of Win7 by default)
" 11 (Windows 11)
I'll give their screenshot program a shot on my Win2k laptop once it's further along. Right now on my Windows 95/98/NT4/2000 systems I usually use HyperSnap-DX 4 (2002). It only does local files though so not really the same thing as the author is going for: http://www.hypersnap.com/hsdx/docs/HprSnap.pdf
and this is exactly why I dont use C anymore. why go through the trouble of this blog post, when you can just use a modern language? HTTPS is a solved problem. here is a Go program, 15 lines:
Given that the author explicitly is targeting Windows 2000 as a starting point with the goal of reaching Windows 95(!) -
> While I'm currently getting things running on Windows 2000 Professional SP4, I'd like to get this working on Windows 95 and 98 too. To that end, I'll be using Visual Studio.NET 2003, which was the last version to support Windows 95. I'm also building everything in Windows 2000, but that part's optional.
- I would say Go is completely irrelevant, since AFAICT as of https://github.com/golang/go/issues/57003 it only supports... Windows 8+? It's actually really hard to find an official answer to what platform versions are supported, but I think we can rule out this particular usecase. (EDIT3: Found it - https://go.dev/wiki/Windows only lists back to Go 1.10.8 supporting XP and says only 10+ is supported now.)
---
EDIT: Now for all that at least the official Go compiler is out, Rust, somehow!, is in the running with https://seri.tools/blog/announcing-rust9x/ , which even explicitly calls out:
> TLS is supported via rustls starting from Windows XP, as its dependency ring needs RtlGenRandom. I haven't looked into it too much, but from what I could tell, this should be the only additional API dependency, so by falling back to another way of getting randomness (probably compromising security in the process :)) this should work all the way down to Windows 95/NT 4.0 as well.
... so that's apparently a way to get "a modern language" that actually can do the job at hand. Which is... absolutely wild, and pretty cool.
---
EDIT2: Now in fairness, I guess I have to ask... does anyone happen to know of any attempts to build a (soft) fork of Go that can target older OSs? I can't immediately think of any true hard blockers on the technical side, you'd just need somebody crazy enough to write it...
It's rather long, but iirc the gist was that the installer wouldn't work on 95, so he figured out what the installer did (files, registry) and created a new one. Then a few WinAPI functions were missing and he created stub dlls that would provide them and pass through everything else. And probably some other minor roadblocks.
Not long ago I remember coming across some discussions about upgrading SChannel (the actual TLS component in Windows) in older versions using OpenSSL or other TLS libraries, but can't find at the moment. The advantage of doing so is all other apps going through WinInet automatically get the upgrade.
One solution that works network-wide is to use a MITM proxy; I run one mainly for adblocking and filtering, but another feature it has is automatically upgrading TLS requests to the latest version it supports - currently TLS 1.3. Unfortunately, thanks to Big Tech's monopoly, I get blocked by many sites because the requests it makes doesn't look enough like an officially sanctioned browser, which is another thing I need to get around to fixing eventually.