[tor-dev] building from source in a 64-bit windows environment..

[Zack Weinberg]

On 2013-05-17 10:07 PM, not me wrote:
> Hi,
>
> It seems fairly self-evident that tor hasn't been build for 64-bit
> windows and questionable whether it's ever been built in an
> environment that doesn't utilize mingw. There are literally hundreds
> of thousands of warnings about integer truncation, at least some of
> which seem somewhat problematic (64-bit pointer being stored in a
> 32-bit integer (why?! why?!)), a small amount of signed/unsigned
> comparisons or sign extensions, and a bunch of calls to functions
> without including the proper header files or using the correct
> function name ('open()' vs '_open()' without including io.h) and so
> on.
>
> This of course is ignoring all the calls to
> str{,n}cpy/{v,}s{,n}printf/etc and posix function names long since
> deprecated (fileno() vs _fileno()) and so on. Errors relating to MSVC
> finally including a stdint header (cstdint) and typedef's for intptr_t
> not producing the right size primitive, etc.

Please understand that we can turn every single one of these complaints 
on its head and make it a failing of Windows:

* Win64 is the *only* flat-memory-space ABI ever promulgated in
   which pointers cannot safely be converted to 'unsigned long'
   and back without loss of information.  This is a willful
   violation of requirements in C89 and is IMNSHO sufficient
   justification to refuse to port to this platform, all by itself.

* The POSIX functions 'open', 'close', 'fcntl', etc are not deprecated
   and do not have underscores in their names.  That Windows provides
   headers that *purport* to provide a subset of POSIX functionality,
   but with all the symbols renamed (and claiming that the renames were
   necessary for C89 conformance, which is not true) can only be
   interpreted as a deliberate snub to people attempting to write
   code which runs on both Windows and Unix systems.  It would have
   been more honest not to provide these functions at all.

* The "security enhanced" functions that I suspect you think we should
   be using are not actually a security enhancement over proper use of
   functions that already existed.  In fact, most of the _s functions are
   just new, less-portable names for existing functions, sometimes with
   gratuitous and inconvenient interface changes on top. For instance,
   snprintf is secure when used correctly, and snprintf_s provides no
   additional benefit whatsoever.  I will grant you that strcpy is easy
   to misuse, but I expect that if you check you will find that in
   *this* codebase it is used safely.

Now, I don't mean to discourage you by saying all that; I only want you 
to understand why the Windows port is not our favorite thing to hack on 
ourselves.  We probably *would* take patches to allow Tor to build and 
operate correctly using current MSVC.  I am not sure whether we would 
take patches to allow Tor to build as a Win64 program; it depends how 
invasive they are and whether it would make life harder for people 
maintaining other platforms.

It is not clear to me why you need Tor to be 64-bit.  It runs as a 
separate process and acts as a local network proxy.  It should be able 
to do that just fine for 64-bit processes while continuing to be 32-bit 
itself.  Please clarify.

zw