Update INSTALL-WIN32.md to reflect changes in R15B

1 files changed, 431 insertions, 184 deletions

diff --git a/INSTALL-WIN32.md b/INSTALL-WIN32.md
index 1158d72f37..190980541f 100644
--- a/INSTALL-WIN32.md
+++ b/INSTALL-WIN32.md
@@ -6,29 +6,31 @@ Introduction
 
 This file describes how to build the Erlang emulator and the OTP
 libraries on Windows. The instructions apply to versions of Windows
-supporting the Cygwin emulated gnuish environment for Windows. We've
-built on the following platforms: Windows 2000 Professional, Windows
-2003 server, Windows XP Home/Professional, and Windows Vista. Any
-Windows95'ish platform will surely get you into trouble, what I'm not
-sure of, but it certainly will...
-
-The procedure described uses Cygwin as a build environment, you run
-the bash shell in Cygwin and uses gnu make/configure/autoconf etc to
-do the build. The emulator C-source code is, however, mostly compiled
-with Microsoft Visual C++™, producing a native Windows binary. This
-is the same procedure as we use to build the pre-built binaries. The
-fact that we use VC++ and not gcc is explained further in the FAQ
-section.
+supporting the Cygwin emulated gnuish environment for Windows or the
+Msys ditto. We've built on the following platforms: Windows 2003
+server, Windows XP Home/Professional, Windows Vista and Windows 7 (32
+and 64 bit). You can probably build on Windows 2000, but you will not
+be able to install the latest Microsoft SDK, so you have to go back to
+some earlier compiler. Any Windows95'ish platform will surely get you
+into trouble, what I'm not sure of, but it certainly will...
+
+The procedure described uses either Cygwin or Msys as a build
+environment, you run the bash shell in Cygwin/Msys and use gnu
+make/configure/autoconf etc to do the build. The emulator C-source
+code is, however, mostly compiled with Microsoft Visual C++™,
+producing a native Windows binary. This is the same procedure as we
+use to build the pre-built binaries. The fact that we use VC++ and not
+gcc is explained further in the FAQ section.
 
 I describe the build procedure to make it possible for open source
 customers to build the emulator, given that they have the needed
 tools. The binary Windows releases is still a preferred alternative if
 one does not have Microsoft's development tools and/or don't want to
-install Cygwin.
+install Cygwin or Msys.
 
-To use Cygwin, one needs basic experience from a Unix environment, if
+To use Cygwin/Msys, one needs basic experience from a Unix environment, if
 one does not know how to set environment variables, run programs etc
-in a Unix environment, one will be quite lost in the Cygwin
+in a Unix environment, one will be quite lost in the Cygwin os Msys
 ditto. I can unfortunately not teach all the world how to use
 Cygwin and bash, neither how to install Cygwin nor perform basic tasks
 on a computer. Please refer to other documentation on the net for
@@ -41,11 +43,11 @@ to make the Erlang/OTP distribution for Windows better. Please submit
 any suggestions and patches to the appropriate [mailing lists] [1] to let
 them find their way into the next version of Erlang. If making changes
 to the build system (like makefiles etc) please bear in mind that the
-same makefiles are used on Unix/VxWorks/OSEDelta, so that your changes
+same makefiles are used on Unix/VxWorks, so that your changes
 don't break other platforms. That of course goes for C-code too, system
 specific code resides in the `$ERL_TOP/erts/emulator/sys/win32` and
 `$ERL_TOP/erts/etc/win32` directories mostly. The
-`$ERL_TOP/erts/emulator/beam directory` is for common code.
+`$ERL_TOP/erts/emulator/beam` directory is for common code.
 
 Before the R9C release of Erlang/OTP, the Windows release was built
 partly on a Unix (Solaris) box and partly on a Windows box, using Perl
@@ -61,6 +63,21 @@ their problems, please try to solve the problems and submit
 solutions/workarounds. Remember, it's all about sharing, not about
 demanding...
 
+Starting with R15B, our build system runs both on Cygwin and Msys
+(MinGW's fork of an early cygwin version). Msys is a smaller package
+to install and may on some machines run slightly faster. If Cygwin
+gives you trouble, try Msys instead, and v.v. Beginning with R15B
+there is also a native 64bit version of Erlang for 64bit Windows 7
+(only). These instructions apply to both the 32bit VM and the 64bit
+ditto.
+
+Note that even if you build a 64bit VM, most of the directories and
+files involved are still named win32. You can view the name win32 as
+meaning any windows version not beeing 16bit. A few occurences of the
+name Win64 are however present in the system, for example the
+installation file for a 64 bit windows version of Erlang is by default
+named `otp_win64_<version>.exe`.
+
 Lets go then, I'll start with a little FAQ, based on in house questions
 and misunderstandings.
 
@@ -70,10 +87,13 @@ Frequently Asked Questions
 
 *   Q: So, now I can build Erlang using GCC on Windows?
 
-    A: No, unfortunately not. You'll need Microsoft's Visual C++ still, a
-    Bourne-shell script (cc.sh) wraps the Visual C++ compiler and runs it
-    from within the Cygwin environment. All other tools needed to build
-    Erlang are free-ware/open source, but not the C compiler.
+    A: No, unfortunately not. You'll need Microsoft's Visual C++
+    still, a Bourne-shell script (cc.sh) wraps the Visual C++ compiler
+    and runs it from within the Cygwin environment. All other tools
+    needed to build Erlang are free-ware/open source, but not the C
+    compiler. The Windows SDK is however enough to build Erlang, you
+    do not need to buy Visual C++, just download the SDK (SDK version
+    7.1 == Visual studio 2010).
 
 *   Q: Why haven't you got rid of VC++ then, you \*\*\*\*\*\*?
 
@@ -83,18 +103,22 @@ Frequently Asked Questions
     directories). Unfortunately the development of the SMP version for
     Windows broke the mingw build and we chose to focus on the VC++ build
     as the performance has been much better in the VC++ versions. The
-    mingw build will be back, but as long as VC++ gives better
+    mingw build will possibly be back, but as long as VC++ gives better
     performance, the commercial build will be a VC++ one.
 
-*   Q: OK, VC++ you need, but now you've started to demand a very recent
+*   Q: OK, you need VC++, but now you've started to demand a very recent
     (and expensive) version of Visual studio, not the old and stable VC++
     6.0 that was used in earlier versions. Why?
 
-    A: The SMP version of Erlang needs features in the Visual Studio 2005.
-    Can't live without them. Besides the new compiler gives the Erlang
-    emulator a ~40% performance boost(!). Alternatively you can build Erlang
-    successfully using the free (proprietary) Visual Studio 2008 Express
-    edition C++ compiler.
+    A: Well, it's not expensive, it's free (as in free beer). Just
+    download and install the latest Windows SDK from Microsoft and all
+    the tools you need are there. The included debugger (WinDbg) is
+    also quite usable, it's what I used when porting Erlang to 64bit
+    Windows. Another reason to use the latest Microsoft compilers is
+    DLL compatibility. DLL's using a new version of the standard
+    library might not load if the VM is compiled with an old VC++
+    version, why we should aim to use the latest freely available SDK
+    and compiler.
 
 *   Q: Can/will I build a Cygwin binary with the procedure you describe?
 
@@ -112,15 +136,15 @@ Frequently Asked Questions
 
 *   Q: Hah, I saw you, you used GCC even though you said you didn't!
 
-    A: OK, I admit, one of the files is compiled using Cygwin's GCC and
-    the resulting object code is then converted to MS VC++ compatible coff
-    using a small C hack. It's because that particular file, `beam_emu.c`
-    benefits immensely from being able to use the GCC labels-as-values
-    extension, which boosts emulator performance by up to 50%. That does
-    unfortunately not (yet) mean that all of OTP could be compiled using
-    GCC, that particular source code does not do anything system specific
-    and actually is adopted to the fact that GCC is used to compile it on
-    Windows.
+    A: OK, I admit, one of the files is compiled using Cygwin's or
+    MinGW's GCC and the resulting object code is then converted to MS
+    VC++ compatible coff using a small C hack. It's because that
+    particular file, `beam_emu.c` benefits immensely from being able
+    to use the GCC labels-as-values extension, which boosts emulator
+    performance by up to 50%. That does unfortunately not (yet) mean
+    that all of OTP could be compiled using GCC, that particular
+    source code does not do anything system specific and actually is
+    adopted to the fact that GCC is used to compile it on Windows.
 
 *   Q: So now there's a MS VC++ project file somewhere and I can build OTP
     using the nifty VC++ GUI?
@@ -135,31 +159,36 @@ Frequently Asked Questions
 
 *   Q: So how does it all work then?
 
-    A: Cygwin is the environment, which closely resembles the environments
-    found on any Unix machine. It's almost like you had a virtual Unix
-    machine inside Windows. Configure, given certain parameters, then
-    creates makefiles that are used by the Cygwin gnu-make to built the
-    system. Most of the actual compilers etc are not, however, Cygwin
-    tools, so I've written a couple of wrappers (Bourne-shell scripts),
-    which reside in `$ERL_TOP/etc/win32/cygwin_tools` and they all do
-    conversion of parameters and switches common in the Unix environment
-    to fit the native Windows tools. Most notable is of course the paths,
-    which in Cygwin are Unix-like paths with "forward slashes" (/) and no
-    drive letters, the Cygwin specific command `cygpath` is used for most
-    of the path conversions. Luckily most compilers accept forward slashes
-    instead of backslashes as path separators, one still have to get the
-    drive letters etc right, though. The wrapper scripts are not general
-    in the sense that, for example, cc.sh would understand and translates
-    every possible gcc option and passes correct options to cl.exe. The
-    principle is that the scripts are powerful enough to allow building of
-    Erlang/OTP, no more, no less. They might need extensions to cope with
-    changes during the development of Erlang, that's one of the reasons I
-    made them into shell-scripts and not Perl-scripts, I believe they are
-    easier to understand and change that way. I might be wrong though,
-    cause another reason I didn't write them in Perl is because I've never
-    liked Perl and my Perl code is no pleasant reading...
-
-    In `$ERL_TOP`, there is a script called `otp_build`, that script handles
+    A: Cygwin or Msys is the environment, which closely resembles the
+    environments found on any Unix machine. It's almost like you had a
+    virtual Unix machine inside Windows. Configure, given certain
+    parameters, then creates makefiles that are used by the
+    Cygwin/Msys gnu-make to built the system. Most of the actual
+    compilers etc are not, however, Cygwin/Msys tools, so I've written
+    a couple of wrappers (Bourne-shell scripts), which reside in
+    `$ERL_TOP/etc/win32/cygwin_tools` and
+    `$ERL_TOP/etc/win32/msys_tools`. They all do conversion of
+    parameters and switches common in the Unix environment to fit the
+    native Windows tools. Most notable is of course the paths, which
+    in Cygwin/Msys are Unix-like paths with "forward slashes" (/) and
+    no drive letters, the Cygwin specific command `cygpath` is used
+    for most of the path conversions in a Cygwin environment, other
+    tools are used (when needed) in the corresponding Msys
+    environment. Luckily most compilers accept forward slashes instead
+    of backslashes as path separators, but one still have to get the drive
+    letters etc right, though. The wrapper scripts are not general in
+    the sense that, for example, cc.sh would understand and translates
+    every possible gcc option and passes correct options to
+    cl.exe. The principle is that the scripts are powerful enough to
+    allow building of Erlang/OTP, no more, no less. They might need
+    extensions to cope with changes during the development of Erlang,
+    that's one of the reasons I made them into shell-scripts and not
+    Perl-scripts, I believe they are easier to understand and change
+    that way. I might be wrong though, cause another reason I didn't
+    write them in Perl is because I've never liked Perl and my Perl
+    code is no pleasant reading...
+
+    In `$ERL_TOP`, there is a script called `otp_build`. That script handles
     the hassle of giving all the right parameters to `configure`/`make` and
     also helps you set up the correct environment variables to work with
     the Erlang source under Cygwin.
@@ -177,17 +206,19 @@ Frequently Asked Questions
 
     A: Yes, we use the exactly same build procedure.
 
-*   Q: Which version of Cygwin and other tools do you use then?
+*   Q: Which version of Cygwin/Msys and other tools do you use then?
 
-    A: For Cygwin we try to use the latest releases available when
-    building. What versions you use shouldn't really matter, I try to
-    include workarounds for the bugs I've found in different Cygwin
-    releases, please help me to add workarounds for new Cygwin-related
-    bugs as soon as you encounter them. Also please do submit bug reports
-    to the appropriate Cygwin developers. The Cygwin GCC we used for %OTP-REL%
-    was version 3.4.4. We used VC++ 8.0 (i.e. Visual studio 2005 SP1),
-    Sun's JDK 1.5.0\_17, NSIS 2.37, and Win32 OpenSSL 0.9.8e. Please read
-    the next section for details on what you need.
+    A: For Cygwin and Msys alike, we try to use the latest releases
+    available when building. What versions you use shouldn't really
+    matter, I try to include workarounds for the bugs I've found in
+    different Cygwin/Msys releases, please help me to add workarounds
+    for new Cygwin/Msys-related bugs as soon as you encounter
+    them. Also please do submit bug reports to the appropriate Cygwin
+    adn/or Msys developers. The GCC we used for %OTP-REL% was version
+    4.7.0 (MinGW 64bit) and 4.3.4 (Cygwin 32bit). We used VC++ 10.0
+    (i.e. Visual studio 2010), Sun's JDK 1.5.0\_17 (32bit) and Sun's
+    JDK 1.7.0\_1 (64bit), NSIS 2.46, and Win32 OpenSSL 0.9.8r. Please
+    read the next section for details on what you need.
 
 *   Q: Can you help me setup X in Cygwin?
 
@@ -201,24 +232,21 @@ Frequently Asked Questions
     described as much as I could about the installation of the needed
     tools. Once the tools are installed, building is quite easy. I also
     have tried to make this instruction understandable for people with
-    limited Unix experience. Cygwin is a whole new environment to some
+    limited Unix experience. Cygwin/Msys is a whole new environment to some
     Windows users, why careful explanation of environment variables etc
     seemed to be in place. The short story, for the experienced and
     impatient is:
 
-    *   Get and install complete Cygwin (latest)
-
-    *   (Buy and) Install Microsoft Visual studio 2005 and SP1 (or higher)
+    *   Get and install complete Cygwin (latest) or complete MinGW with msys
 
-    *   Alternatively install the free MS Visual Studio 2008 Express [msvc++]
-    and the Windows SDK [32bit-SDK] or [64bit-SDK] depending on the Windows
-    platform you are running.
+    *   Install Microsofts Windows SDK 7.1 (and .Net 4)
 
-    *   Get and install Sun's JDK 1.4.2
+    *   Get and install Sun's JDK 1.5.0 or higher
 
     *   Get and install NSIS 2.01 or higher (up to 2.46 tried and working)
 
-    *   Get and install OpenSSL 0.9.7c or higher (up to 1.0.0a tried & working)
+    * Get, build and install OpenSSL 0.9.8r or higher (up to 1.0.0a
+        tried & working) with static libs.
 
     *   Get the Erlang source distribution (from
         <http://www.erlang.org/download.html>) and unpack with Cygwin's `tar`.
@@ -251,10 +279,9 @@ Tools you Need and Their Environment
 ------------------------------------
 
 You need some tools to be able to build Erlang/OTP on Windows. Most
-notably you'll need Cygwin and Microsoft VC++, but you also might want
-a Java compiler, the NSIS install system and OpenSSL. Only VC++ costs
-money, but then again it costs a lot of money, I know...
-Well' here's the list:
+notably you'll need Cygwin or Msys and Microsofts Windows SDK, but
+you also might want a Java compiler, the NSIS install system and
+OpenSSL. Well' here's the list:
 
 *   Cygwin, the very latest is usually best. Get all the development
     tools and of course all the basic ditto. In fact getting the complete
@@ -263,6 +290,10 @@ Well' here's the list:
     sure *not* to install a Cygwin'ish Java... The Cygwin jar command is
     used but Sun's Java compiler and virtual machine...
 
+    If you are going to build a 64bit Windows version, you should make
+    sure to get MinGWs 64bit gcc installed with cygwin. It's in one of
+    the development packages.
+
     URL: <http://www.cygwin.com>
 
     Get the installer from the web site and use that to install
@@ -302,72 +333,205 @@ Well' here's the list:
     haven't tried and know of no one that has. I expect
     that you use bash in all shell examples.
 
-*   Microsoft Visual Studio 2005 SP1. Please don't skip the service
-    pack! The installer might update your environment so that you can run
-    the `cl` command from the bash prompt, then again it might
-    not... There is always a BAT file in VC\Bin under the installation
-    directory (default `C:\Program Files\Microsoft Visual Studio 8`) called
-    `VCVARS32.BAT`. Either add the environment settings in that file to the
-    global environment settings in Windows or add the corresponding BASH
-    environment settings to your `.profile`/`.bashrc`. For example, in my case
-    I could add the following to `.profile`
-
-        #Visual C++ Root directory as Cygwin style pathname
-        VCROOT=/cygdrive/c/Program\ Files/Microsoft\ Visual\ Studio 8
-
-        # Visual C++ Root directory as Windows style pathname
-        WIN_VCROOT="C:\\Program Files\\Microsoft Visual Studio 8"
-
-        # The PATH variable should be Cygwin'ish
-        PATH=$VCROOT/Common7/IDE:$VCROOT/VC/BIN:$VCROOT/Common7/Tools:\
-        $VCROOT/Common7/Tools/bin:$VCROOT/VC/PlatformSDK/bin:$VCROOT/SDK/v2.0/bin:\
-        $VCROOT/VC/VCPackages:$PATH
-
-        # Lib and INCLUDE should be Windows'ish
-        # Note that semicolon (;) is used to separate Windows style paths but
-        # colon (:) to separate Cygwin ditto!
-
-        LIBPATH=$WIN_VCROOT\\VC\\ATLMFC\\LIB
-
-        LIB=$WIN_VCROOT\\VC\\ATLMFC\\LIB\;$WIN_VCROOT\\VC\\LIB\;\
-        $WIN_VCROOT\\VC\\PlatformSDK\\lib\;$WIN_VCROOT\\SDK\\v2.0\\lib
-
-        INCLUDE=$WIN_VCROOT\\VC\\ATLMFC\\INCLUDE\;$WIN_VCROOT\\VC\\INCLUDE\;\
-        $WIN_VCROOT\\VC\\PlatformSDK\\include
-
-        export PATH LIB INCLUDE
-
-    Make a simple hello world and try to compile it with the `cl` command
-    from within bash. If that does not work, your environment needs
-    fixing. Also remember to fix up the PATH environment, especially old
-    Erlang installations might have inserted quoted paths that Cygwin does
-    not understand. Remove or correct such paths. There should be no
-    backslashes in your path environment variable in Cygwin bash, but LIB
-    and INCLUDE should contain Windows style paths with semicolon,
-    drive letters and backslashes.
-
-    If you wish to use Visual Studio 2008, a couple things need to be tweaked,
-    namely the fact that some of the SDK stuff is installed in (by default)
-    `C:\Program Files\Microsoft SDKs\v6.0A` . Just ensure that that
-    `C:\Program Files\Microsoft SDKs\v6.0A\Lib` is in `LIB` and
-    `C:\Program Files\Microsoft SDKs\v6.0A\Include` is in `INCLUDE`. A symptom
-    of not doing this is errors about finding kernel32.lib and windows.h.
-
-    Additionally, if you encounter errors about mc.exe not being found, you must
-    install the entire Windows SDK (the partial SDK included in visual studio
-    apparently does not include it). After installing it you'll want to add
-    something like: `/c/cygdrive/Program\ Files/Microsoft\ SDKs/v7.0/bin` to
-    your `PATH` to allow the environment to find mc.exe. The next Visual Studio
-    (2010) is expected to include this tool.
-
-    Alternatively install the free MS Visual Studio 2008 Express [msvc++] and
-    the Windows SDK [32bit-SDK] or [64bit-SDK] depending on the Windows
-    platform you are running, which includes the missing mc.exe message
-    compiler.
-
-[msvc++]:	http://download.microsoft.com/download/E/8/E/E8EEB394-7F42-4963-A2D8-29559B738298/VS2008ExpressWithSP1ENUX1504728.iso
-[32bit-SDK]:	http://download.microsoft.com/download/2/E/9/2E911956-F90F-4BFB-8231-E292A7B6F287/GRMSDK_EN_DVD.iso
-[64bit-SDK]:	http://download.microsoft.com/download/2/E/9/2E911956-F90F-4BFB-8231-E292A7B6F287/GRMSDKX_EN_DVD.iso
+*   Alternatively you download MinGW and Msys. You'll find the latest
+    installer at:
+
+    URL: <http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/>
+
+    Make sure to install everything they've got. 
+
+    To be able to build the 64bit VM, you will also need the 64bit
+    MinGW compiler from:
+
+    URL: <http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/>
+
+    The latest version should do it. Make sure you download the
+    `mingw-w64-bin_i686-mingw_<something>.zip`, not a linux
+    version. You unzip the package on top of your MinGW installation
+    (`c:\MinGW`) and that's it.
+
+    Setting up your environment in Msys is similar to setting it up in
+    Cygwin.
+
+* Microsofts Windows SDK version 7.1 (corresponding to VC++ 10.0 and
+    Visual Studio 2010). You'll find it here:
+    
+    URL: <http://www.microsoft.com/download/en/details.aspx?id=8279>
+
+    but before you install that, you need to have .Net 4 installed,
+    you'll find that here:
+
+    URL: <http://www.microsoft.com/download/en/details.aspx?id=17851>
+
+    Use the web installer for the SDK, at least when I tried
+    downloading the whole package as an image, I got SDK 7.0 instead,
+    which is not what you want...
+
+    There will be a Windows command file in `%PROGRAMFILES%\Mirosoft
+    SDKs\Windows\v7.1\Bin\SetEnv.cmd` that set's the appropriate
+    environment for a Windows command prompt. This is not appropriate
+    for bash, so you'll need to convert it to bash-style environments
+    by editing your `.bash_profile`. In my case, where the SDK is
+    installed in the default directory and `%PROGRAMFILES%` is
+    `C:\Program Files`, the commands for setting up a 32bit build
+    environment (on a 64bit or 32bit machine) look like this (in cygwin):
+
+        # Some common paths
+        C_DRV=/cygdrive/c
+        PRG_FLS=$C_DRV/Program\ Files
+
+        # nsis
+        NSIS_BIN=$PRG_FLS/NSIS
+        # java
+        JAVA_BIN=$PRG_FLS/Java/jdk1.6.0_16/bin
+
+        ##
+        ## MS SDK
+        ##
+
+        CYGWIN=nowinsymlinks
+        MVS10="$PRG_FILES/Microsoft Visual Studio 10.0"
+        WIN_MVS10="C:\\Program Files\\Microsoft Visual Studio 10.0"
+        SDK10="$PRG_FILES/Microsoft SDKs/Windows/v7.1"
+        WIN_SDK10="C:\\Program Files\\Microsoft SDKs\\Windows\\v7.1"
+
+        PATH="$NSIS_BIN:\
+        $MVS10/Common7/IDE:\
+        $MVS10/Common7/Tools:\
+        $MVS10/VC/Bin:\
+        $MVS10/VC/Bin/VCPackages:\
+        $SDK10/Bin/NETFX 4.0 Tools:\
+        $SDK10/Bin:\
+        /usr/local/bin:/usr/bin:/bin:\
+        /cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:\
+        /cygdrive/c/WINDOWS/system32/Wbem:\
+        $JAVA_BIN"
+
+        LIBPATH="$WIN_MVS10\\VC\\LIB"
+
+        LIB="$WIN_MVS10\\VC\\LIB;$WIN_SDK10\\LIB"
+
+        INCLUDE="$WIN_MVS10\\VC\\INCLUDE;$WIN_SDK10\\INCLUDE;$WIN_SDK10\\INCLUDE\\gl"
+
+        export CYGWIN PATH LIBPATH LIB INCLUDE 
+
+    If you're using Msys instead, the only thing you need to change is
+    the `C_DRV` setting, which would read:
+
+        C_DRV=/c
+
+    And of course you might need to change `C:\Program Files` etc if
+    you're using a non-english version of Windows (XP). Note that in
+    later versions of Windows, the national adoptions of the program
+    files directories etc are not on the file system but only in the
+    explorer, so even if explorer says that your programs reside in
+    e.g. `C:\Program`, they might still reside in `C:\Program Files`
+    in reality...
+
+    If you are building a 64 bit verision of Erlang, you should set up
+    PATHs etc a little differently. I use the following script to
+    make things work in both Cygwin and Msys:
+
+         make_winpath()
+         {
+                P=$1
+                if [ "$IN_CYGWIN" = "true" ]; then 
+                   cygpath -d "$P"
+                else
+                   (cd "$P" && /bin/cmd //C "for %i in (".") do @echo %~fsi")
+                fi
+         }
+
+         make_upath()
+         {
+                P=$1
+                if [ "$IN_CYGWIN" = "true" ]; then 
+                   cygpath "$P"
+                else
+                   echo "$P" | /bin/sed 's,^\([a-zA-Z]\):\\,/\L\1/,;s,\\,/,g'
+                fi
+         }
+
+         # Some common paths
+         if [ -x /usr/bin/msysinfo ]; then
+            # Without this the path conversion won't work
+            COMSPEC='C:\Windows\SysWOW64\cmd.exe'
+            MSYSTEM=MINGW32
+            export MSYSTEM COMSPEC
+            IN_CYGWIN=false
+         else
+            CYGWIN=nowinsymlinks
+            export CYGWIN
+            IN_CYGWIN=true
+         fi
+
+         if [ "$IN_CYGWIN" = "true" ]; then 
+            PATH=/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:\
+            /cygdrive/c/windows/system32:/cygdrive/c/windows:/cygdrive/c/windows/system32/Wbem
+         else
+            PATH=/usr/local/bin:/mingw/bin:/bin:/c/Windows/system32:/c/Windows:\
+            /c/Windows/System32/Wbem
+         fi
+
+         if [ "$IN_CYGWIN" = "true" ]; then 
+            C_DRV=/cygdrive/c
+         else
+            C_DRV=/c
+         fi
+
+         PRG_FLS64=$C_DRV/Program\ Files
+         PRG_FLS32=$C_DRV/Program\ Files\ \(x86\)
+         VISUAL_STUDIO_ROOT32=$PRG_FLS32/Microsoft\ Visual\ Studio\ 10.0
+         MS_SDK_ROOT64=$PRG_FLS64/Microsoft\ SDKs/Windows/v7.1
+
+         # Okay, now mangle the paths and get rid of spaces by using short names
+         WIN_VCROOT32=`make_winpath "$VISUAL_STUDIO_ROOT32"`
+         VCROOT32=`make_upath $WIN_VCROOT32`
+         WIN_SDKROOT64=`make_winpath "$MS_SDK_ROOT64"`
+         SDKROOT64=`make_upath $WIN_SDKROOT64`
+         WIN_PROGRAMFILES32=`make_winpath "$PRG_FLS32"`
+         PROGRAMFILES32=`make_upath $WIN_PROGRAMFILES32`
+    
+         WIN_PROGRAMFILES64=`make_winpath "$PRG_FLS64"`
+         PROGRAMFILES64=`make_upath $WIN_PROGRAMFILES64`
+
+         # nsis
+         NSIS_BIN=$PROGRAMFILES32/NSIS
+         # java
+         JAVA_BIN=$PROGRAMFILES64/Java/jdk1.7.0_01/bin
+
+         ## The PATH variable should be Unix'ish
+         VCPATH=$VCROOT32/Common7/IDE:$VCROOT32/VC/BIN/amd64:$VCROOT32/Common7/Tools:\
+         $VCROOT32/VC/VCPackages:$SDKROOT64/bin/NETFX4~1.0TO/x64:$SDKROOT64/bin/x64:\
+         $SDKROOT64/bin
+
+         ## Microsoft SDK libs
+
+         LIBPATH=$WIN_VCROOT32\\VC\\LIB\\amd64
+         LIB=$WIN_VCROOT32\\VC\\LIB\\amd64\;$WIN_SDKROOT64\\LIB\\X64
+         INCLUDE=$WIN_VCROOT32\\VC\\INCLUDE\;$WIN_SDKROOT64\\include\;\
+         $WIN_SDKROOT64\\include\\gl
+
+         # Put nsis, c compiler and java in path
+         PATH=$NSIS_BIN:$VCPATH:$PATH:$JAVA_BIN
+
+         # Make sure LIB and INCLUDE is available for others
+         export PATH LIBPATH LIB INCLUDE
+
+    All this is derived from the SetEnv.cmd command file mentioned
+    earlier. The bottom line is to set the PATH so that NSIS and
+    Microsoft SDK is found before the Msys/Cygwin tools and that Java
+    is last in the PATH.
+
+    Make a simple hello world (maybe one that prints out 
+    `sizeof(void *)`) and try to compile it with the `cl` command from within
+    bash. If that does not work, your environment needs fixing. Also
+    remember to fix up the PATH environment, especially old Erlang
+    installations might have inserted quoted paths that Cygwin/Msys
+    does not understand. Remove or correct such paths. There should be
+    no backslashes in your path environment variable in Cygwin bash,
+    but LIB and INCLUDE should contain Windows style paths with
+    semicolon, drive letters and backslashes.
 
 *   Sun's Java JDK 1.5.0 or higher. Our Java code (jinterface, ic) is
     written for JDK 1.5.0. Get it for Windows and install it, the JRE is
@@ -378,11 +542,11 @@ Well' here's the list:
 
     Add javac *LAST* to your path environment in bash, in my case this means:
 
-        PATH="$PATH:/cygdrive/c/Program Files/Java/jdk1.5.0_17/bin"
+        `PATH="$PATH:/cygdrive/c/Program Files/Java/jdk1.5.0_17/bin"`
 
     No `CLASSPATH` or anything is needed. Type `javac` at the bash prompt
     and you should get a list of available Java options. Make sure by
-    typing `which java` that you use the Java you installed. Note however that
+    typing `type java` that you use the Java you installed. Note however that
     Cygwin's `jar.exe` is used, that's why the JDK bin-directory should be
     added last in the `PATH`.
 
@@ -402,29 +566,75 @@ Well' here's the list:
     type makensis at the bash prompt and you should get a list of options
     if everything is OK.
 
-*   OpenSSL for Windows. This is if you want the SSL and crypto
-    applications to compile (and run). Go to <http://www.openssl.org>, click
-    on the `Related` link and then on the `Binaries` link (upper right
-    corner of the page last time I looked), you can then reach the
-    "Shining Lights Productions" Web site for Windows binaries
-    distributions. Get the latest 32-bit installer, or use 0.9.7c if you get
-    trouble with the latest, and install to C:\OpenSSL which is where the
-    Makefiles are expecting to find it. It's a nifty installer. The rest should
-    be handled by `configure`, you needn't put anything in the path or anything.
-
-    If you want to build openssl for windows yourself (which might be
-    possible, as you wouldn't be reading this if you weren't a
-    compile-it-yourself person), you either have to put the resulting
-    DLL's in your path or in the windows system directory and either
-    specify where you put the includes etc with the configure-parameter
-    `--with-ssl=<cygwin path to the root>` or put your installation directly
-    under `c:\OpenSSL`. The directory structure under the installation root
-    for OpenSSL is expected to be one with subdirectories named `include`,
-    `bin` and `lib`, possibly with a `VC` subdirectory of `lib` containing
-    the actual `.lib` files. Note that the cygwin distributed OpenSSL cannot be
-    used, it results in cygwin depending binaries and it has unix style
-    archives (`.a`, not `.lib`).
+* OpenSSL. This is if you want the SSL and crypto applications to
+    compile (and run). There are prebuilt binaries available, but I
+    strongly recommend building this yourself. It's quite easy.
+
+    First get the source from 
+
+    URL: <http://openssl.org/source/>
+
+    I would recommend using 0.9.8r. 
+
+    Download the tar file and unpack it (using your bash prompt) into
+    a directory of your choise.
+
+    You will need a Windowish Perl for the build. ActiveState has one:
+
+    URL: <http://www.activestate.com/activeperl/downloads>
+
+    Download and install that. Disable options to associate it with
+    the .pl suffix and/or adding things to PATH, they are not needed. 
+
+    Now fire up the Microsoft Windows SDK command prompt in RELEASE
+    mode for the architecture you are going to build. The easiest is
+    to copy the shortcut from the SDKs start menu item and edit the
+    command line in the shortcut (Right click->Properties) to end with
+    `/Release`. Make sure the banner when you double click your
+    shortcut (the text in the resulting command window) says
+    `Targeting Windows XP x64 Release` if you are going to do a 64 bit
+    build and `Targeting Windows XP x86 Release` if you are building a
+    32 bit version.
+
+    Now cd to where you unpacked the OpenSSL source using your Release
+    Windows command prompt (it should be on the same drive as where
+    you are going to install it if everything is to work smothly).
+
+      `C:\> cd <some dir>`
+
+    Add ActiveState (or some other windows perl, not cygwins) to your PATH:
+
+      `C:\...\> set PATH=C:\Perl\bin;%PATH%`
+
+    Configure OpenSSL for 32 bit:
 
+      `C:\...\> perl Configure VC-WIN32 --prefix=/OpenSSL`
+
+    Or for 64 bit:
+
+      `C:\...\> perl Configure VC-WIN64A --prefix=/OpenSSL-Win64`
+
+    Do some setup (for 32 bit):
+
+      `C:\...\> ms\do_win32`
+
+    The same for 64 bit:
+
+      `C:\...\> ms\do_win64a`
+
+    Then build static libraries and install:
+
+      `C:\...\> nmake -f ms\nt.mak`
+      `C:\...\> nmake -f ms\nt.mak install`
+
+    That's it - you now have your perfectly consistent static build of
+    openssl. If you want to get rid of any possibly patented
+    algorithms in the lib, just read up on the OpenSSL FAQ and follow
+    the instructions.
+
+    The installation locations chosen are where configure will look
+    for OpenSSL, so try to keep them as is.
+       
 *   Building with wxWidgets. Download wxWidgets-2.8.9 or higher patch
     release (2.9.\*  is a developer release which currently does not work
     with wxErlang).
@@ -473,6 +683,9 @@ Well' here's the list:
     erlang system without gs (which might be okay as you probably will use
     wx anyway).
 
+    Note that there is no special 64bit version of TCL/TK needed, you
+    can use the 32bit program even for a 64bit build.
+
 The Shell Environment
 ---------------------
 
@@ -500,6 +713,12 @@ the ksh variant:
     $ cd $ERL_TOP
     $ eval $(./otp_build env_win32)
 
+If you are building a 64 bit version, you supply `otp_build` with an architecture parameter:
+
+    $ cd $ERL_TOP
+    $ eval `./otp_build env_win32 x64`
+     
+
 This should do the final touch to the environment and building should
 be easy after this. You could run `./otp_build env_win32` without
 `eval` just to see what it does, and to see that the environment it
@@ -509,10 +728,11 @@ style short names instead), the variables `OVERRIDE_TARGET`, `CC`, `CXX`,
 `$ERL_TOP/erts/etc/win32/cygwin_tools/vc` and
 `$ERL_TOP/erts/etc/win32/cygwin_tool` are added first in the PATH.
 
-Try now a `which erlc`. That should result in the erlc wrapper script
+Try now a `type erlc`. That should result in the erlc wrapper script
 (which does not have the .sh extension, for reasons best kept
-untold...). It should reside in `$ERL_TOP/erts/etc/win32/cygwin_tools`.
-You could also try `which cc.sh`, which `ar.sh` etc.
+untold...). It should reside in `$ERL_TOP/erts/etc/win32/cygwin_tools`
+or `$ERL_TOP/erts/etc/win32/msys_tools`.  You could also try `which
+cc.sh`, which `ar.sh` etc.
 
 Now you're ready to build...
 
@@ -520,8 +740,8 @@ Now you're ready to build...
 Building and Installing
 -----------------------
 
-Now it's assumed that you have executed `` eval `./otp_build env_win32` ``
-for this particular shell...
+Now it's assumed that you have executed `` eval `./otp_build env_win32` `` or 
+`` eval `./otp_build env_win32 x64` `` for this particular shell...
 
 Building is easiest using the `otp_build` script. That script takes care
 of running configure, bootstrapping etc on Windows in a simple
@@ -613,6 +833,13 @@ Lets get into more detail:
         $ release/win32/otp_win32_%OTP-REL% /S
         ...
 
+    or
+
+        $ cd $ERL_TOP
+        $ release/win32/otp_win64_%OTP-REL% /S
+        ...
+    
+
     and after a while Erlang/OTP-%OTP-REL% will have been installed in
     `C:\Program Files\erl%ERTS-VSN%\`, with shortcuts in the menu etc.
 
@@ -735,6 +962,22 @@ Remember that:
 
 That's basically all you need to get going.
 
+Using GIT
+---------
+
+You might want to check out versions of the source code from GitHUB. That is possible directly in cygwin, but not in Msys. There is a project MsysGIT:
+
+URL:<http://code.google.com/p/msysgit/>
+
+that makes a nice Git port. The msys prompt you get from MsysGIT is
+however not compatible with the full version from MinGW, so you will
+need to check out files using MsysGITs command prompt and then switch
+to a common Msys command prompt for building. Also all test suites
+cannot be built as MsysGIT/Msys does not handle symbolic links. To
+build test suites on Windows, you will need Cygwin for now. Hopefully
+all symbolic links will disappear from our repository soon and this
+issue will disappear.
+
 Final Words
 -----------
 My hope is that the possibility to build the whole system on Windows
@@ -752,11 +995,15 @@ be good. The idea to do this came from his work, so credit is well
 deserved.
 
 Of course this would have been completely impossible without the
-excellent Cygwin package. The guys at Cygnus solutions and Redhat
-deserves a huge THANKS! as well as all the other people in the free
-software community who have helped in creating the magnificent
+excellent Cygwin. The guys at Cygnus solutions and
+Redhat deserves a huge THANKS! as well as all the other people in the
+free software community who have helped in creating the magnificent
 software that constitutes Cygwin.
 
+Also the people developing the alternative command prompt Msys anfd
+the MinGW compiler are worth huge THANKS! The 64bit port would have
+been impossible without the 64bit MinGW compiler.
+
 Good luck and Happy Hacking,
 Patrik, OTP