src: s/ia32/x86 for process.release.libUrl for win

[rvagg]

as per nodejs/node-gyp#711 (comment), fixes this:

$ node -pe process.release
{ name: 'io.js',
  sourceUrl: 'https://iojs.org/download/release/v3.3.0/iojs-v3.3.0.tar.gz',
  headersUrl: 'https://iojs.org/download/release/v3.3.0/iojs-v3.3.0-headers.tar.gz',
  libUrl: 'https://iojs.org/download/release/v3.3.0/win-ia32/iojs.lib' }

We don't use ia32 anywhere in our downloads directories or files (any more), it's been banished and https://iojs.org/download/release/v3.3.0/win-ia32/iojs.lib should actually be https://iojs.org/download/release/v3.3.0/win-x86/iojs.lib. Unfortunately we're still shipping with process.arch=='ia32' which I would equally love to banish but alas, it's well and truly baked in to history.

I'm also going to put a special case in node-gyp to account for ^3.0.0 and do some rewriting, which is a bit yuk but we've let this go wild since v3.x.

/cc @nodejs/build and anyone else who feels like critiquing my C++ style

[rvagg]

switched style, went from:

  READONLY_PROPERTY(release,
                    "libUrl",
                    OneByteString(env->isolate(),
                    strcmp(NODE_ARCH, "ia32") ? _RELEASE_URLPFX "win-"
                                                NODE_ARCH "/node.lib"
                                              : _RELEASE_URLPFX
                                                "win-x86/node.lib"));

from this, which I prefer but probably isn't as idiomatic for core:

  READONLY_PROPERTY(release,
                    "libUrl",
                    OneByteString(env->isolate(),
                    strcmp(NODE_ARCH, "ia32")
                      ? _RELEASE_URLPFX "win-" NODE_ARCH "/node.lib"
                      : _RELEASE_URLPFX "win-x86/node.lib"));

[thefourtheye]

Basically if the architecture is ia32 then we pick the library from x86 directory. Mmmm. LGTM.

[rvagg]

Yeah, when we get "ia32", we decide that it's actually based on x86, i.e. the 80x86 family and could also be referred to as x32 but not to be confused by x64 which is really x86-64 i.e. x86_64, and found in the wild sometimes as amd64 and promoted by Intel as IA64 which is where ia32 comes from, a marketing name, probably bitter over being pipped to 64-bit by AMD which lead to the awkward predominance of "amd64" in Linux land; which has further leaked in to 32-bit as amd32, if I were on that marketing team I'd do a France on them and like outlawing the use of "Champagne®" I'd force everyone to banish archaic names like EM64T and ia32e and impose Intel®64 and Intel®32 on everyone wanting to refer to 64-bit and 32-bit versions of the 80x86 family.

Clear?

[thefourtheye]

@rvagg Thanks for the explanation. It's clear now. :)

[rvagg]

reviewers please, ping

[rvagg]

rebased so it's not so unwieldy to review, see 4854c42

[thefourtheye]

cc @nodejs/collaborators @nodejs/platform-windows

[orangemocha]

found in the wild sometimes as amd64 and promoted by Intel as IA64

IA64 is actually a completely different architecture.

The change LGTM

[bnoordhuis]

Just a note: macros (and identifiers in general) starting with an underscore are reserved.

[rvagg]

thanks, didn't know, changed these to NODE_RELEASE_URLPFX

[rvagg]

https://ci.nodejs.org/job/node-test-pull-request/265/ in case I've missed anything

[rvagg]

landed 278a926