Obviously, given age, doesn't have to be as secure and fancy and the modern builds, but is there there a git build for Windows 9x, just like there is for Windows XP? Also wondering whether there is a Linux/GNU-like set of utilities compatible with Windows 9x, such as sort or tail?

  • 4
    IIRC Cygwin used to work on Windows 95 (you may have to use an earlier version), so it should be possible to compile git from source, if necessary.
    – dirkt
    Dec 3 '19 at 5:04
  • 1
    I've gathered a lot of unix like commands that I compiled for the amiga, like "sed" or "grep" that I could build from source. Some simpler implementations of those commands exist. Don't know for git. The question is a bit broad. Dec 3 '19 at 6:11
  • I leeched tail.c from there and could compile it with amiga SAS-C. Should build from windows too... github.com/DoctorWkt/xv6-freebsd/blob/master/cmd/simple/… Dec 3 '19 at 6:13
  • 3
    Just to be clear this is asking for a build of git for Windows 95, not a git repository containing the source of Windows 95. 😋 Dec 3 '19 at 6:57
  • 1
    Just out of curiosity: Why do you like to know? Dec 3 '19 at 7:12

Install Cygwin using setup-legacy.exe from the Cygwin Time Machine, pointing it at the cygwin-legacy URL, which pins the package versions to the last set released for Cygwin 1.5, the last release for Windows 9x.

The Cygwin Time Machine serves frozen-in-place versions of Cygwin, so it will work as well today as it did back then, which was pretty good, actually. There are many good reasons why Cygwin steamrolled all of the other Unix-on-Windows efforts.

(Beware: The Cygwin Time Machine service is a single person's hobby, so do not expect high speed file service, quick response to support questions, etc. Be patient with it.)

One of the many packages available for Cygwin 1.5 is Git 1.6, which may be new enough to work with your current repos. You get everything else you ask for in your question, too: sort, tail, etc. Basically, Cygwin is the command-line userland of a Linux environment contemporaneous with its release.

I say it may work because software that old often won't talk directly to modern systems, especially where cryptography is involved, which means using Git over HTTPS or SSH may not work if the remote system is sufficiently tightened down. What ends up happening is that the cryptosystems that were current at the time that software was last maintained are no longer in use, so that your old system cannot negotiate a mutually acceptable ciphersuite with the remote system.

You have many options for coping with this problem:

1. Unencrypted Access

Use Git over HTTP rather than HTTPS.

The main problem with this option is that HTTP access is getting hard to come by as modern security practice is to automatically forward all HTTP hits to HTTPS, providing no actual service over HTTP.

2. Proxy HTTPS or SSH

There are a couple of variations on this option:

  1. Many web servers can be set up to do HTTP proxying, and some of these can speak HTTPS outbound. Thus, you could point Git on Win9x at the HTTP side of that proxy, and it would speak to your remote Git repo over HTTPS by configuration.

  2. SSH allows port forwarding, so you could use a modern system to SSH into the remote system and use that to expose a tunnel to the Win9x box that it could use to securely access the remote repo.

The details of setting such things up are well beyond the scope of this answer.

3. Backport a Newer Version of Git

Download the source code for a modern version of Git and whatever dependencies it has, then use the Cygwin toolchain to build up a current environment atop the old substrate. This will be roughly as difficult as backporting Git to a 10-year-old version of Linux: doable, but not trivial.

4. Double Clone

Git is a distributed version control system. This means you can clone from a clone, and you can push changes up through another clone to a third system.

Therefore, you could use a modern system to clone from a remote repo that will only talk to the modern system then expose that intermediate repo to the Win9x box over a less secure channel that the old version of Git will talk to. (SMB, local HTTP-only proxy, etc.)

The modern system could be another computer on the same LAN, with an IP matching rule that allows only the Win9x box to talk to it over the insecure channel, thus maintaining a reasonable overall level of security.

Pushes to the intermediate repo work the same way: Win9x to the modern system, and the modern system up to the secure remote system.

  • 3
    The on-disk Git repo format is simple and very backwards-compatible, so reading a repo created by a modern Git shouldn't be an issue. Very old HTTPS implementations are unlikely to interoperate with modern ones due to the old ones using only protocols now known to be insecure. SSH 1 is incompatible with SSH-2 (introduced in 2006) and SSH-1 is no longer used due to security issues inherent to the protocol itself, so old SSH implementations will also not work with GitHub, etc. Thus, it looks like HTTP and file sharing/copying are your best avenues for getting repos.
    – cjs
    Dec 4 '19 at 14:27
  • @CurtJ.Sampson: Shouldn't the backport pickup the latest openssl and actually have TLS 1.2 on Windows 95?
    – Joshua
    Feb 9 '20 at 15:35
  • @Joshua It depends on what's available to and decisions made by whomever did the port. It's not looking good that one's starting with Cygwin 1.5, which was obsoleted in 2009, only a year after TLS 1.2 was standardized.
    – cjs
    Feb 9 '20 at 19:15
  • @CurtJ.Sampson: I'm expecting it boils down to rebuild everything other than libc from source.
    – Joshua
    Feb 9 '20 at 20:18

Not the answer you're looking for? Browse other questions tagged or ask your own question.