Building OpenSSL with Visual Studio 2010 for x64 / Win64 causes error


Today I was trying to build the latest OpenSSL 1.0.1c with Visual Studio 2010. Following instructions form the INSTALL.W32, I was able to successfully build the 32-bit version. Trying the same with 64-bit (x64) version, again following the official instructions from INSTALL.W64.
To build for Win64/x64:
> perl Configure VC-WIN64A
> ms\do_win64a
> nmake -f ms\ntdll.mak
> cd out32dll
> ..\ms\test

The first line ‘perl Configure VC-WIN64A’ went without any errors:
Configuring for VC-WIN64A
no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
no-gmp [default] OPENSSL_NO_GMP (skip dir)
no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir)
no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
no-md2 [default] OPENSSL_NO_MD2 (skip dir)
no-rc5 [default] OPENSSL_NO_RC5 (skip dir)
no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir)
no-sctp [default] OPENSSL_NO_SCTP (skip dir)
no-shared [default]
no-store [experimental] OPENSSL_NO_STORE (skip dir)
no-zlib [default]
no-zlib-dynamic [default]
DES_INT used
RC4_CHUNK is unsigned long long
Configured for VC-WIN64A.

The second line ‘ms\do_win64a’ always returned errors:
ml64 -c -Foms\uptable.obj ms\uptable.asm
Microsoft (R) Macro Assembler (x64) Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.

Assembling: ms\uptable.asm
ms\uptable.asm(356) : error A2088:END directive required at end of file
ms\uptable.asm(356) : fatal error A1010:unmatched block nesting : _lazy18

Luckily I found solution in
Translation from Russian:
To prevent this, need to change file ms\do_win64a.bat like this: instead of

perl ms\ masm > ms\uptable.asm
ml64 -c -Foms\uptable.obj ms\uptable.asm


perl ms\ masm > ms\uptable.asm
ml64 -c -Foms\uptable.obj ms\uptable.asm

It seems like race condition to me. Command ‘ping’ just adds a pause between two commands.

Thanks to Белая рысь (cyber_lynx)! Source:

Did you know that IP addresses (IPv4) can be written in shorter representations?

Did you know that IPv4 addresses can be written in shorter representations, like IPv6 addresses?

Everyone have seen form of IPv6 represented as “shorter form”:
Example from IPv6:

  • 2001::7334
  • ::1
  • ::

You can use our free tool to convert these addresses to long form. The result is:

  • 2001:0000:0000:0000:0000:0000:0000:7334
  • 0000:0000:0000:0000:0000:0000:0000:0001
  • 0000:0000:0000:0000:0000:0000:0000:0000

What admins / programmers usually do not know, is that the same principle applies to IPv4 addresses:

  • 127.1
  • 1
  • 192.168.257
  • 192.168.65535
  • 192.168.65535
  • 192.168
  • 10.1

To test these, use built in ping command. I used ping in Windows 7 and Ubuntu 10, and the result addresses are:

  • 127.1 ->
  • 1 ->
  • 192.168.257 ->
  • 192.168.65535 ->
  • 192.168 ->
  • 10.1 ->

As a bonus, you can try to ping other IP address representations:

  • ping 0x7F000001 – hex
  • ping 010 – octal, does not work in Ubuntu
  • ping 2130706433 – decimal

Why it works this way? Because network funcions built into OS support a such behavior, for example:

Have a fun, and remember, that year of IPv6 is near.