Re: Building SVN (dependencies) on Windows

[Adam Humpherys]

For what it's worth, I was able to get my build environment working based
on the script here: https://github.com/Jan-E/svn-windows which builds
(most) of the dependencies, but uses a pre-built version of Apache 2.4 from
apachelounge.com.

--
Adam Humpherys




On Wed, May 6, 2020 at 4:32 AM  wrote:

> Quite a few of the Windows dependencies can easily be built by the VCPKG
> package manager.
>
>
>
> For SharpSvn I maintained quite a few custom NAnt scripts that do about
> the same work (
> https://ctf.open.collab.net/svn/repos/sharpsvn/trunk/imports
>
> (or https://github.com/AmpScm/SharpSvn/tree/master/imports, but I think
> this mirror lags a bit )
>
>
>
> Somewhere in the CollabNet open source repositories there should be a
> slightly simpler -not as many development options- MSBuild version of the
> scripts to build the dependencies, but I’m not sure at which url.
>
>
>
>   Bert
>
> *Van:* Graham Bloice 
> *Verzonden:* donderdag 23 april 2020 18:17
> *Aan:* dev@subversion.apache.org
> *Onderwerp:* Re: Building SVN (dependencies) on Windows
>
>
>
> Apologies for butting in, but as a long time maintainer of the (mainly
> Windows) build process for Wireshark, another cross platform project, I'd
> like to offer my thoughts on such matters to the svn project.
>
>1. We moved to CMake quite some time ago, getting rid of automake and
>nmake and VS solution files.  Such a relief to have one build tool, usable
>on all platforms.  This is obviously a big step to take.
>2. Wireshark has lots of dependencies on 3rd party libraries and on
>Windows the usual issues of obtaining them and where to put them.  The
>project has "solved" this by maintaining an svn repo (even though the
>project has switched to git for the sources) of "-dev" zip packages
>containing the items required to build; headers, .lib and .dll files, e.g.
>https://anonsvn.wireshark.org/wireshark-win64-libs/trunk/packages/Part
>of the CMake generation step runs a PowerShell script that checks for
>updates, downloads the required zips and expands them to a "known"
>location, configurable by env vars.  The locations of these files are
>passed as hints to the CMake findxxx modules (modified by the project) so
>that CMake is happy.  Some build tools and libraries are exclude from this
>process and have to be manually installed, e.g. Perl, Python, Qt.
>3. Production of the "-dev" packages takes a few forms, cross building
>on OpenSUSE or using vcpkg, the details are listed for each library, e.g.
>https://www.wireshark.org/docs/wsdg_html_chunked/ChLibsGLib.html.
>When a library is updated, a single "tag" file in the main source tree is
>updated causing all builders to check for changes.
>4. All required artefacts are built\copied by CMake directives into
>the run-time directory so tests can be run without requiring installation.
>5. The installers are also built by CMake and pick up the required
>artefacts from the run-time directory.
>
> I see a number of advantages with the Wireshark solution:
>
>1. Much smaller barrier to entry for those attempting to build.  Still
>quite a setup needed, hence the developer's guide step-by-step section, see
>here:https://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html
>2. No need to build (or even download unless there are changes) the
>3rd party libraries reducing build times
>3. Consistency across builds for all users, no local
>variations causing oddities.
>
> You can see the sausages being made over at the Wireshark buildbot:
> https://buildbot.wireshark.org/wireshark-master/waterfall, in particular
> the "ran CMake" generation step, although if there are no updates to the
> libraries it's a standard CMake experience.
>
>
>
> I'm not subscribed to the list, just observe infrequently via the
> svn.haxx.se archive, so if you have any questions please add me in
> replies.
>
>
>
> P.S. I did build svn on Windows once, many years ago and I found it an
> awkward process.
>
>
>
> --
>
> Graham Bloice
>

RE: Building SVN (dependencies) on Windows

[bert]

Quite a few of the Windows dependencies can easily be built by the VCPKG 
package manager.

 

For SharpSvn I maintained quite a few custom NAnt scripts that do about the 
same work (https://ctf.open.collab.net/svn/repos/sharpsvn/trunk/imports

(or  <https://github.com/AmpScm/SharpSvn/tree/master/imports> 
https://github.com/AmpScm/SharpSvn/tree/master/imports, but I think this mirror 
lags a bit )

 

Somewhere in the CollabNet open source repositories there should be a slightly 
simpler -not as many development options- MSBuild version of the scripts to 
build the dependencies, but I’m not sure at which url.

 

  Bert

Van: Graham Bloice  
Verzonden: donderdag 23 april 2020 18:17
Aan: dev@subversion.apache.org
Onderwerp: Re: Building SVN (dependencies) on Windows

 

Apologies for butting in, but as a long time maintainer of the (mainly Windows) 
build process for Wireshark, another cross platform project, I'd like to offer 
my thoughts on such matters to the svn project.

1.  We moved to CMake quite some time ago, getting rid of automake and 
nmake and VS solution files.  Such a relief to have one build tool, usable on 
all platforms.  This is obviously a big step to take.
2.  Wireshark has lots of dependencies on 3rd party libraries and on 
Windows the usual issues of obtaining them and where to put them.  The project 
has "solved" this by maintaining an svn repo (even though the project has 
switched to git for the sources) of "-dev" zip packages containing the items 
required to build; headers, .lib and .dll files, e.g.  
https://anonsvn.wireshark.org/wireshark-win64-libs/trunk/packages/Part of 
the CMake generation step runs a PowerShell script that checks for updates, 
downloads the required zips and expands them to a "known" location, 
configurable by env vars.  The locations of these files are passed as hints to 
the CMake findxxx modules (modified by the project) so that CMake is happy.  
Some build tools and libraries are exclude from this process and have to be 
manually installed, e.g. Perl, Python, Qt.
3.  Production of the "-dev" packages takes a few forms, cross building on 
OpenSUSE or using vcpkg, the details are listed for each library, e.g. 
https://www.wireshark.org/docs/wsdg_html_chunked/ChLibsGLib.html.  When a 
library is updated, a single "tag" file in the main source tree is updated 
causing all builders to check for changes.
4.  All required artefacts are built\copied by CMake directives into the 
run-time directory so tests can be run without requiring installation.
5.  The installers are also built by CMake and pick up the required 
artefacts from the run-time directory.

I see a number of advantages with the Wireshark solution:

1.  Much smaller barrier to entry for those attempting to build.  Still 
quite a setup needed, hence the developer's guide step-by-step section, see 
here:https://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html
2.  No need to build (or even download unless there are changes) the 3rd 
party libraries reducing build times
3.  Consistency across builds for all users, no local variations causing 
oddities.

You can see the sausages being made over at the Wireshark buildbot: 
https://buildbot.wireshark.org/wireshark-master/waterfall, in particular the 
"ran CMake" generation step, although if there are no updates to the libraries 
it's a standard CMake experience.

 

I'm not subscribed to the list, just observe infrequently via the svn.haxx.se 
<http://svn.haxx.se>  archive, so if you have any questions please add me in 
replies.

 

P.S. I did build svn on Windows once, many years ago and I found it an awkward 
process.

 

-- 

Graham Bloice

Re: Building SVN (dependencies) on Windows

[Daniel Shahaf]

Graham Bloice wrote on Thu, 23 Apr 2020 17:17 +0100:
> Apologies for butting in, but as a long time maintainer of the (mainly
> Windows) build process for Wireshark, another cross platform project, I'd
> like to offer my thoughts on such matters to the svn project.

Welcome & thanks!

> I see a number of advantages with the Wireshark solution:
> 
>3. Consistency across builds for all users, no local variations causing
>oddities.

I'm not so sure about this.  As a sysadmin, uniformity enables
scalability, which is good — but as developers of software to be used on
any Unix-like or Windows-like operating system, uniformity enables
hidden dependencies and hides bugs.

In our case, our buildbot builders use different architectures,
operating systems, C compilers, dependency libraries, and configure-
 and build-time options; that's deliberate, to make sure we don't write,
say, code that's only correct on little-endian architectures, or
depends on a particular compiler vendor's language extensions, etc..

(Also, there's the single point of failure concern: what happens if
someone manages to replace the centralized set of .dll's with
a malicious one?)

> You can see the sausages being made over at the Wireshark buildbot:
> https://buildbot.wireshark.org/wireshark-master/waterfall, in particular
> the "ran CMake" generation step, although if there are no updates to the
> libraries it's a standard CMake experience.
> 

For reference, our buildbot is at https://subversion.apache.org/buildbot/all
(though the signal-to-noise of that particular view is a little low due
to the the hourly builders on the first few columns).

> P.S. I did build svn on Windows once, many years ago and I found it an
> awkward process.

I think when I first built svn on Windows, it took me a week to get it
to work…

Cheers,

Daniel

Re: Building SVN (dependencies) on Windows

[Nathan Hartman]

On Tue, Apr 28, 2020 at 2:14 AM Graham Bloice
 wrote:
>
> Apologies for butting in

No apologies necessary! We welcome participation with open arms. :-)

> We moved to CMake quite some time ago, getting rid of automake and nmake and 
> VS solution files.  Such a relief to have one build tool, usable on all 
> platforms.  This is obviously a big step to take.

CMake has come up in discussions from time to time. Once, it came up
when someone wanted to build the svn libraries for Android, IIRC. But,
so far no one has taken it upon themselves to reimplement the build
system using CMake (which, as you point out, is a big step). As we're
completely driven by volunteers, if anyone wants to give it a try,
please speak up!

Thanks for writing and mentioning how Wireshark is handling this...
(Also, thanks for Wireshark itself!)

Cheers,
Nathan

Re: Building SVN (dependencies) on Windows

[Graham Bloice]

Apologies for butting in, but as a long time maintainer of the (mainly
Windows) build process for Wireshark, another cross platform project, I'd
like to offer my thoughts on such matters to the svn project.

   1. We moved to CMake quite some time ago, getting rid of automake and
   nmake and VS solution files.  Such a relief to have one build tool, usable
   on all platforms.  This is obviously a big step to take.
   2. Wireshark has lots of dependencies on 3rd party libraries and on
   Windows the usual issues of obtaining them and where to put them.  The
   project has "solved" this by maintaining an svn repo (even though the
   project has switched to git for the sources) of "-dev" zip packages
   containing the items required to build; headers, .lib and .dll files, e.g.
   https://anonsvn.wireshark.org/wireshark-win64-libs/trunk/packages/Part
   of the CMake generation step runs a PowerShell script that checks for
   updates, downloads the required zips and expands them to a "known"
   location, configurable by env vars.  The locations of these files are
   passed as hints to the CMake findxxx modules (modified by the project) so
   that CMake is happy.  Some build tools and libraries are exclude from this
   process and have to be manually installed, e.g. Perl, Python, Qt.
   3. Production of the "-dev" packages takes a few forms, cross building
   on OpenSUSE or using vcpkg, the details are listed for each library, e.g.
   https://www.wireshark.org/docs/wsdg_html_chunked/ChLibsGLib.html.  When
   a library is updated, a single "tag" file in the main source tree is
   updated causing all builders to check for changes.
   4. All required artefacts are built\copied by CMake directives into the
   run-time directory so tests can be run without requiring installation.
   5. The installers are also built by CMake and pick up the required
   artefacts from the run-time directory.

I see a number of advantages with the Wireshark solution:

   1. Much smaller barrier to entry for those attempting to build.  Still
   quite a setup needed, hence the developer's guide step-by-step section, see
   here:https://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html
   2. No need to build (or even download unless there are changes) the 3rd
   party libraries reducing build times
   3. Consistency across builds for all users, no local variations causing
   oddities.

You can see the sausages being made over at the Wireshark buildbot:
https://buildbot.wireshark.org/wireshark-master/waterfall, in particular
the "ran CMake" generation step, although if there are no updates to the
libraries it's a standard CMake experience.

I'm not subscribed to the list, just observe infrequently via the
svn.haxx.se archive, so if you have any questions please add me in replies.

P.S. I did build svn on Windows once, many years ago and I found it an
awkward process.

-- 
Graham Bloice

Re: Building SVN (dependencies) on Windows

[Johan Corveleyn]

On Tue, Apr 21, 2020 at 9:33 PM Barry Scott  wrote:
>
> I know this pain well. I build svn for macOS and Windows to do the binary 
> pysvn releases.
>
> I have the build for the svn client side of things fully automated.
> In case this is helpful to you here is what I use.
>
> The scripts I use are here:
>
> https://svn.code.sf.net/p/pysvn/code/trunk/pysvn/ReleaseEngineering/Windows
>
> The build-all-deps.cmd is the entry point thats get you to a working svn 
> client.
>
> To build svn 1.13 compatible with python 3.5 and later I use:
>
> build-all-deps 3.5 1.13 win64
>
> The version of the source code to use is setup in build-config-svn-1.13.cmd.
>
> Any patches that are needed to make the builds work are in:
>
> https://svn.code.sf.net/p/pysvn/code/trunk/pysvn/ReleaseEngineering/Windows/patches
>
> And you would need to have the compilers installed and the source kits of all 
> the
> deps for the above to work of course.
>
> Barry

Hi Barry,

Thanks a lot for sharing. Yes, it can be so hard :-).

I do need to build all of it myself (not only the client), for testing
and signing off on the release, so including mod_dav_svn etc. But
scripts that can build the client easily might already be a big help
to some. And the build patches can certainly be useful.

I'll try to take a closer look later (or perhaps someone else here
will), but thanks already for sending your bits and pieces here :-).

-- 
Johan

Re: Building SVN (dependencies) on Windows

[Barry Scott]

I know this pain well. I build svn for macOS and Windows to do the binary pysvn 
releases.

I have the build for the svn client side of things fully automated.
In case this is helpful to you here is what I use.

The scripts I use are here:


https://svn.code.sf.net/p/pysvn/code/trunk/pysvn/ReleaseEngineering/Windows

The build-all-deps.cmd is the entry point thats get you to a working svn client.

To build svn 1.13 compatible with python 3.5 and later I use:

build-all-deps 3.5 1.13 win64

The version of the source code to use is setup in build-config-svn-1.13.cmd.

Any patches that are needed to make the builds work are in:


https://svn.code.sf.net/p/pysvn/code/trunk/pysvn/ReleaseEngineering/Windows/patches

And you would need to have the compilers installed and the source kits of all 
the
deps for the above to work of course.

Barry


> On 20 Apr 2020, at 14:36, Johan Corveleyn  wrote:
> 
> Let's start a new thread with the bits of information I posted about building 
> on Windows in the "Release Notes: TODO regarding Py3 support" thread [1].
> 
> Building SVN on Windows is pretty hard, especially the dependencies. A lot of 
> the dependencies have (Windows-specific) problems or quirks in their build 
> scripts.
> 
> Useful documents / tools in our own source tree (but they are a but rusty / 
> out-of-date):
> - INSTALL: definitely needs a refresh / update.
> - tools/dev/windows-build: contains a Makefile that can be useful on Windows, 
> if you don't want to build from within the VS IDE (and as a config "wrapper" 
> around gen-make.py).
> - tools/dev/build-svn-deps-win.pl : needs 
> resurrection, i.e. update and cleanup of old vs updated components. It 
> contains a couple of scripted fixes for some of the externally broken build 
> scripts (e.g. httpd). Perhaps those fixes should be brought upstream (at 
> least they should be checked against the latest version of their component). 
> Perhaps could use Debug vs. Release configuration, as well as x86 vs. x64. 
> Cross pointing between this script and INSTALL would be ideal.
> 
> 
> My personal notes for building SVN's dependencies (trying to build an x86 
> Release build):
> 
> - Get the following tools, and make sure they are in your PATH:
> * Perl (I've taken the last Strawberry distribution from perl.org 
> )
> * Python from python.org  (download both a 2.7 and a 3.x 
> build, you'll probably need both, as there are still problems with 3.x for 
> svn builds).
> * awk (from https://www.cs.princeton.edu/~bwk/btl.mirror/awk95.exe 
> )
> * test.exe, from GnuWin32 (used by that Makefile from tools/dev/windows-build)
> 
> zlib:
> # clean: nmake -f win32/Makefile.msc clean
> nmake -f win32/Makefile.msc
> nmake -f win32/Makefile.msc test
> (workaround for svn build: it looks for zlibstat.lib) nmake /nologo -f 
> win32/Makefile.msc STATICLIB=zlibstat.lib all
>  
> building DEBUG configuration:
> set CC_OPTS=/MDd /Gm /ZI /Od /GZ /D_DEBUG
> nmake /nologo -f win32/Makefile.msc STATICLIB=zlibstatD.lib all
> 
> Do not try to build the assembler optimized versions, it causes headaches
> 
> openssl:
> Need Netwide Assembler, a.k.a. NASM, available from https://www.nasm.us 
>  (after install, put in PATH)
> perl Configure enable-zlib --with-zlib-include=../zlib-1.2.11 
> --with-zlib-lib=../zlib-1.2.11/zlib.lib VC-WIN32
> For openssl 1.0.2*:
>   call ms\do_nasm
>   nmake -f ms\ntdll.mak
>   nmake -f ms\ntdll.mak test
> For openssl 1.1.x:
>   nmake
>   nmake test
> 
> PCRE (from pcre.org , needed for httpd -- not pcre2, only 
> pcre (version 1) works):
> cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo 
> -DBUILD_SHARED_LIBS:BOOL=ON -DPCRE_NO_RECURSE:BOOL=ON .
> nmake
> nmake test
>  
> expat (needed for httpd / apr-util):
> download and extract expat (https://libexpat.github.io/ 
> )
> (Follow instructions from cmake.README):
> cd expat
> mkdir build
> cd build
> cmake ..
> msbuild expat.sln (debug build)
> msbuild expat.sln /p:Configuration=Release
>  This is 64-bit build!! httpd now also needs to be built 64bit
>  or: open expat.sln > Configuration Mgr > Add x86 (win32) 
> configuration, save & exit + edit all vcprojx files and remove " /machine:x64"
> 
> httpd:
> download and extract httpd
> download and extract apr, apr-util, apr-iconv into httpd\srclib\apr 
> ..\apr-util ..\apr-iconv
> Attention: Do not try to use junctions (windows symlinks), just copy the 
> directories.
> Attention 2: Check if the downloaded / extracted files are marked by 
> Windows as "Blocked" (rightclick -> Properties). If so unblock them in bulk 
> from within Powershell (Run as Administrator), with "dir -s | 

Re: Building SVN (dependencies) on Windows

[Nathan Hartman]

On Mon, Apr 20, 2020 at 9:56 AM Yasuhito FUTATSUKI  wrote:
> On 2020/04/20 22:47, Nathan Hartman wrote:
> > https://github.com/onetrueawk/awk
> >
> > I *think* this is the source for the original and also the version
> > that was at some point hosted by Princeton as awk95.exe.
>
> As I wrote above, there is no executable in github project page.

Sorry, I read too quickly the last time!

I will try to use the awk from Visual Studio. If that works, it's one
less step, and one less thing to install or build.

Thanks,
Nathan

Re: Building SVN (dependencies) on Windows

[Branko Čibej]

On 20.04.2020 16:31, Johan Corveleyn wrote:
> On Mon, Apr 20, 2020 at 4:17 PM Branko Čibej  wrote:
>> On 20.04.2020 15:36, Johan Corveleyn wrote:
>>> openssl:
>>> Need Netwide Assembler, a.k.a. NASM, available from
>>> https://www.nasm.us (after install, put in PATH)
>>> perl Configure enable-zlib --with-zlib-include=../zlib-1.2.11
>>> --with-zlib-lib=../zlib-1.2.11/zlib.lib VC-WIN32
>> OpenSSL has a CMake-base build these days, and works without NASM.
>>
> Are you sure? I followed INSTALL and NOTES.WIN from their 1.1.1f
> tarball, from which I derived the above "procedure". Those documents
> don't mention CMake currently (at least not in the 1.1.1f tarball).
>
> In NOTES.WIN they say: "Netwide Assembler, a.k.a. NASM, available from
> https://www.nasm.us is required."

Sorry, I must have confused OpenSSL with some other dependency that
started using CMake ...

-- Brane

Re: Building SVN (dependencies) on Windows

[Johan Corveleyn]

On Mon, Apr 20, 2020 at 4:17 PM Branko Čibej  wrote:
>
> On 20.04.2020 15:36, Johan Corveleyn wrote:
> > openssl:
> > Need Netwide Assembler, a.k.a. NASM, available from
> > https://www.nasm.us (after install, put in PATH)
> > perl Configure enable-zlib --with-zlib-include=../zlib-1.2.11
> > --with-zlib-lib=../zlib-1.2.11/zlib.lib VC-WIN32
>
> OpenSSL has a CMake-base build these days, and works without NASM.
>

Are you sure? I followed INSTALL and NOTES.WIN from their 1.1.1f
tarball, from which I derived the above "procedure". Those documents
don't mention CMake currently (at least not in the 1.1.1f tarball).

In NOTES.WIN they say: "Netwide Assembler, a.k.a. NASM, available from
https://www.nasm.us is required."

-- 
Johan

Re: Building SVN (dependencies) on Windows

[Branko Čibej]

On 20.04.2020 15:36, Johan Corveleyn wrote:
> openssl:
>     Need Netwide Assembler, a.k.a. NASM, available from
> https://www.nasm.us (after install, put in PATH)
>     perl Configure enable-zlib --with-zlib-include=../zlib-1.2.11
> --with-zlib-lib=../zlib-1.2.11/zlib.lib VC-WIN32

OpenSSL has a CMake-base build these days, and works without NASM.

Re: Building SVN (dependencies) on Windows

[Justin Erenkrantz]

On Mon, Apr 20, 2020 at 9:36 AM Johan Corveleyn  wrote:

> Let's start a new thread with the bits of information I posted about
> building on Windows in the "Release Notes: TODO regarding Py3 support"
> thread [1].
>
> Building SVN on Windows is pretty hard, especially the dependencies. A lot
> of the dependencies have (Windows-specific) problems or quirks in their
> build scripts.
>
>
I totally agree on the pain here.  It's also the same for Serf on Windows.
It seems like folks are moving towards CMake on Windows - especially as
Microsoft is now including it with Visual Studio.  Expat and APR/APR-Util
already have CMake projects; notably OpenSSL does not yet, AFAICT.  Serf
has one too in its as-of-yet-unreleased 1.4.x branch that I'm making fitful
progress on validating in prep for a 1.4.0 release.

My pie-in-the-sky would be to help create a Buildstream project file that
could pull all of this together to make it easier on Windows and
Linux...but, there's some work to be done here, so it's not an overnight
thing.  (Sander and I are doing hack sessions around it; Buildstream is
also moving to Apache shortly[1].)

Cheers.  -- justin

1. https://mail.gnome.org/archives/buildstream-list/2020-April/msg00010.html

Re: Building SVN (dependencies) on Windows

[Yasuhito FUTATSUKI]

On 2020/04/20 22:47, Nathan Hartman wrote:
> On Mon, Apr 20, 2020 at 9:36 AM Yasuhito FUTATSUKI  
> wrote:
>> On 2020/04/20 0:47, Johan Corveleyn wrote:
>>> * awk (from https://www.cs.princeton.edu/~bwk/btl.mirror/awk95.exe)
>> This is dead link now. https://www.cs.princeton.edu/~bwk/btl.mirror/
>> saids "Awk is now hosted at Github" (https://github.com/onetrueawk/awk),
>> and there is no executable.
>>
>> However, I could find awk.exe (actually GNU Awk 4.1.4) under the
>> Visuall Studio 2017 install directory.
>>
>> Also, newer version is found in
>>
>> https://sourceforge.net/projects/ezwinports/files/
> 
> Also, this:
> 
> https://github.com/onetrueawk/awk
> 
> I *think* this is the source for the original and also the version
> that was at some point hosted by Princeton as awk95.exe.

As I wrote above, there is no executable in github project page.

The point is not compatibility to original awk but capability to
build apache httpd, I think.

Cheers,
-- 
Yasuhito FUTATSUKI /

Re: Building SVN (dependencies) on Windows

[Nathan Hartman]

On Mon, Apr 20, 2020 at 9:36 AM Yasuhito FUTATSUKI  wrote:
> On 2020/04/20 0:47, Johan Corveleyn wrote:
> > * awk (from https://www.cs.princeton.edu/~bwk/btl.mirror/awk95.exe)
> This is dead link now. https://www.cs.princeton.edu/~bwk/btl.mirror/
> saids "Awk is now hosted at Github" (https://github.com/onetrueawk/awk),
> and there is no executable.
>
> However, I could find awk.exe (actually GNU Awk 4.1.4) under the
> Visuall Studio 2017 install directory.
>
> Also, newer version is found in
>
> https://sourceforge.net/projects/ezwinports/files/

Also, this:

https://github.com/onetrueawk/awk

I *think* this is the source for the original and also the version
that was at some point hosted by Princeton as awk95.exe.

Nathan