Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

node-gyp: allow node.exe/iojs.exe to be renamed #1251

Merged
merged 1 commit into from
Mar 25, 2015

Conversation

piscisaureus
Copy link
Contributor

win,node-gyp: allow node.exe/iojs.exe to be renamed
On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This makes it impossible to rename node.exe or iojs.exe, because when
that happens the module can't find its dependencies.

With this patch, a delay-load hook is added to all modules that are
compiled with node-gyp. The delay-load hook ensures that whenever a
module tries to load imports from node.exe/iojs.exe, it'll just refer
back to the process image, thus making it possible to rename the
iojs/node binary.

Bug: iojs#751
Bug: iojs#965
Upstream PR: nodejs/node-gyp#599

R=@bnoordhuis
R=@rvagg
R=@iojs/platform-windows

@mscdex mscdex added the c++ Issues and PRs that require attention from people who are familiar with C++. label Mar 25, 2015
@piscisaureus piscisaureus added the windows Issues and PRs related to the Windows platform. label Mar 25, 2015
@am11
Copy link

am11 commented Mar 25, 2015

This is outstanding. Thank you! 👍 🌟

Is it possible that we could rename iojs.exe to anything other than node.exe?
(ex. jsl.exe (next to cl.exe) or jsrunner.exe)

@piscisaureus
Copy link
Contributor Author

@am11 yes, you can rename it to anything you like now.

@rvagg
Copy link
Member

rvagg commented Mar 25, 2015

it's a bit beyond me, so windozy, but lgtm none the less

can someone verify a few addons on windows with this? I don't have time to fiddle right now unfortunately

@piscisaureus
Copy link
Contributor Author

Here's the ones I tested myself:

bson\build\Release\bson.node
node-sass\build\Release\binding.node
bufferutil\build\Release\bufferutil.node
utf-8-validate\build\Release\validation.node
kerberos\build\Release\kerberos.node
sqlite3\build\Release\node_sqlite3.nodeelease\kerberos.node

@piscisaureus
Copy link
Contributor Author

@rvagg Made it a teensy bit less windozy, but unfortunately this is as good as it gets...

On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This makes it impossible to rename node.exe or iojs.exe, because when
that happens the module can't find its dependencies.

With this patch, a delay-load hook is added to all modules that are
compiled with node-gyp. The delay-load hook ensures that whenever a
module tries to load imports from node.exe/iojs.exe, it'll just refer
back to the process image, thus making it possible to rename the
iojs/node binary.

Bug: nodejs#751
Bug: nodejs#965
Upstream PR: nodejs/node-gyp#599

PR-URL: nodejs#1251
Reviewed-By: Rod Vagg <[email protected]>
@piscisaureus piscisaureus merged commit 3d46fef into nodejs:v1.x Mar 25, 2015
piscisaureus added a commit to piscisaureus/node-gyp that referenced this pull request Mar 25, 2015
On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This makes it impossible to rename node.exe or iojs.exe, because when
that happens the module can't find its dependencies.

With this patch, a delay-load hook is added to all modules that are
compiled with node-gyp. The delay-load hook ensures that whenever a
module tries to load imports from node.exe/iojs.exe, it'll just refer
back to the process image, thus making it possible to rename the
iojs/node binary.

Bug: nodejs/node#751
Bug: nodejs/node#965
Downstream PR: nodejs/node#1251
@am11
Copy link

am11 commented Mar 25, 2015

I have also tested with node-sass binary and it is working perfectly fine.

@rvagg, we are using pangyp with node-sass and so do other folks. Once this get merged (already merged!) here, should we apply this patch to pangyp as well?

@othiym23
Copy link
Contributor

@piscisaureus I'm keeping an eye on @TooTallNate/node-gyp#599 now, but this is going to need to be added to the floating patch we apply to npm when it's merged to io.js until such time as a new version of node-gyp is released upstream, no? Can you do me a favor and ping me on issues that touch things under deps/npm so I know they need to be preserved on merges?

@piscisaureus
Copy link
Contributor Author

@othiym23
I think we're currently floating two patches:

@othiym23
Copy link
Contributor

OK! You're going on the reviewers list for npm updates now, because I'm not sure I'll remember this (although I am making a note of it).

@Fishrock123
Copy link
Contributor

@othiym23 @piscisaureus though next update, with should just merge the commits again for floating, so as to just have one if possible.

@othiym23
Copy link
Contributor

@Fishrock123

should just merge the commits again for floating, if possible.

Can you expand? I'm not sure I get what you're saying.

othiym23 pushed a commit to npm/node that referenced this pull request Mar 27, 2015
The delay-load hook that was landed in 3d46fef to make compiled addons
work on Windows regardless of the iojs.exe/node.exe filename causes
issues with a small amount of compiled addons.

Therefore this patch makes it an opt-in feature. An addon may set the
'win_delay_load_hook' option to 'true' in its binding.gyp to enable this
feature.

Example:

```
{
  'targets': [
    {
      'target_name': 'ernie',
      'win_delay_load_hook': 'true',
      ...
```

Refs: nodejs#1251
PR-URL: nodejs#1266
Reviewed-By: Ben Noordhuis <[email protected]>
am11 added a commit to am11/pangyp that referenced this pull request Mar 29, 2015
am11 added a commit to am11/pangyp that referenced this pull request Mar 29, 2015
 * nodejs/node#1251 and
 * nodejs/node#1266

Note: this is a disableable/optional feature and
it is disabled by default (since there are
chances that MSVCR chokes on linking, given if
the module exports data)

Issue URL: #4.
PR URL: rvagg#5.
piscisaureus added a commit that referenced this pull request Mar 30, 2015
On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This causes many compiled addons to break when node.exe or iojs.exe are
renamed, because when the binary has been renamed the addon DLL can't
find the (right) .exe file to load its imports from.

This patch gives compiled addon developers an option to overcome this
restriction by compiling a delay-load hook into their binary. The
delay-load hook ensures that whenever a module tries to load imports
from node.exe/iojs.exe, it'll just look at the process image, thereby
making the addon work regardless of what name the node/iojs binary has.

To enable this feature, the addon developer must set the
'win_delay_load_hook' option to 'true' in their binding.gyp file, like
this:

```
{
  'targets': [
    {
      'target_name': 'ernie',
      'win_delay_load_hook': 'true',
      ...
```

Bug: #751
Bug: #965
Upstream PR: nodejs/node-gyp#599

PR-URL: #1251
Reviewed-By: Rod Vagg <[email protected]>

PR-URL: #1266
Reviewed-By: Ben Noordhuis <[email protected]>
rvagg added a commit that referenced this pull request Mar 31, 2015
Notable changes:

 * fs: corruption can be caused by fs.writeFileSync() and append-mode
   fs.writeFile() and fs.writeFileSync() under certain circumstances,
   reported in #1058, fixed in #1063 (Olov Lassus).
 * iojs: an "internal modules" API has been introduced to allow core
   code to share JavaScript modules internally only without having to
   expose them as a public API, this feature is for core-only #848
   (Vladimir Kurchatkin).
 * timers: two minor problems with timers have been fixed:
   - Timer#close() is now properly idempotent #1288 (Petka Antonov).
   - setTimeout() will only run the callback once now after an
     unref() during the callback #1231 (Roman Reiss).
 * Windows: a "delay-load hook" has been added for compiled add-ons
   on Windows that should alleviate some of the problems that Windows
   users may be experiencing with add-ons in io.js #1251
   (Bert Belder).
 * V8: minor bug-fix upgrade for V8 to 4.1.0.27.
 * npm: upgrade npm to 2.7.4. See npm CHANGELOG.md for details.
othiym23 pushed a commit to npm/node that referenced this pull request Apr 3, 2015
On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This causes many compiled addons to break when node.exe or iojs.exe are
renamed, because when the binary has been renamed the addon DLL can't
find the (right) .exe file to load its imports from.

This patch gives compiled addon developers an option to overcome this
restriction by compiling a delay-load hook into their binary. The
delay-load hook ensures that whenever a module tries to load imports
from node.exe/iojs.exe, it'll just look at the process image, thereby
making the addon work regardless of what name the node/iojs binary has.

To enable this feature, the addon developer must set the
'win_delay_load_hook' option to 'true' in their binding.gyp file, like
this:

```
{
  'targets': [
    {
      'target_name': 'ernie',
      'win_delay_load_hook': 'true',
      ...
```

Bug: nodejs#751
Bug: nodejs#965
Upstream PR: nodejs/node-gyp#599

PR-URL: nodejs#1251
Reviewed-By: Rod Vagg <[email protected]>

PR-URL: nodejs#1266
Reviewed-By: Ben Noordhuis <[email protected]>
piscisaureus added a commit that referenced this pull request Apr 4, 2015
On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This causes many compiled addons to break when node.exe or iojs.exe are
renamed, because when the binary has been renamed the addon DLL can't
find the (right) .exe file to load its imports from.

This patch gives compiled addon developers an option to overcome this
restriction by compiling a delay-load hook into their binary. The
delay-load hook ensures that whenever a module tries to load imports
from node.exe/iojs.exe, it'll just look at the process image, thereby
making the addon work regardless of what name the node/iojs binary has.

To enable this feature, the addon developer must set the
'win_delay_load_hook' option to 'true' in their binding.gyp file, like
this:

```
{
  'targets': [
    {
      'target_name': 'ernie',
      'win_delay_load_hook': 'true',
      ...
```

Bug: #751
Bug: #965
Upstream PR: nodejs/node-gyp#599

PR-URL: #1251
Reviewed-By: Rod Vagg <[email protected]>

PR-URL: #1266
Reviewed-By: Ben Noordhuis <[email protected]>
othiym23 pushed a commit to npm/node that referenced this pull request Apr 10, 2015
On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This causes many compiled addons to break when node.exe or iojs.exe are
renamed, because when the binary has been renamed the addon DLL can't
find the (right) .exe file to load its imports from.

This patch gives compiled addon developers an option to overcome this
restriction by compiling a delay-load hook into their binary. The
delay-load hook ensures that whenever a module tries to load imports
from node.exe/iojs.exe, it'll just look at the process image, thereby
making the addon work regardless of what name the node/iojs binary has.

To enable this feature, the addon developer must set the
'win_delay_load_hook' option to 'true' in their binding.gyp file, like
this:

```
{
  'targets': [
    {
      'target_name': 'ernie',
      'win_delay_load_hook': 'true',
      ...
```

Bug: nodejs#751
Bug: nodejs#965
Upstream PR: nodejs/node-gyp#599

PR-URL: nodejs#1251
Reviewed-By: Rod Vagg <[email protected]>

PR-URL: nodejs#1266
Reviewed-By: Ben Noordhuis <[email protected]>
othiym23 pushed a commit to npm/node that referenced this pull request Apr 10, 2015
On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This causes many compiled addons to break when node.exe or iojs.exe are
renamed, because when the binary has been renamed the addon DLL can't
find the (right) .exe file to load its imports from.

This patch gives compiled addon developers an option to overcome this
restriction by compiling a delay-load hook into their binary. The
delay-load hook ensures that whenever a module tries to load imports
from node.exe/iojs.exe, it'll just look at the process image, thereby
making the addon work regardless of what name the node/iojs binary has.

To enable this feature, the addon developer must set the
'win_delay_load_hook' option to 'true' in their binding.gyp file, like
this:

```
{
  'targets': [
    {
      'target_name': 'ernie',
      'win_delay_load_hook': 'true',
      ...
```

Bug: nodejs#751
Bug: nodejs#965
Upstream PR: nodejs/node-gyp#599

PR-URL: nodejs#1251
Reviewed-By: Rod Vagg <[email protected]>

PR-URL: nodejs#1266
Reviewed-By: Ben Noordhuis <[email protected]>
othiym23 pushed a commit to npm/node that referenced this pull request Apr 10, 2015
On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This causes many compiled addons to break when node.exe or iojs.exe are
renamed, because when the binary has been renamed the addon DLL can't
find the (right) .exe file to load its imports from.

This patch gives compiled addon developers an option to overcome this
restriction by compiling a delay-load hook into their binary. The
delay-load hook ensures that whenever a module tries to load imports
from node.exe/iojs.exe, it'll just look at the process image, thereby
making the addon work regardless of what name the node/iojs binary has.

To enable this feature, the addon developer must set the
'win_delay_load_hook' option to 'true' in their binding.gyp file, like
this:

```
{
  'targets': [
    {
      'target_name': 'ernie',
      'win_delay_load_hook': 'true',
      ...
```

Bug: nodejs#751
Bug: nodejs#965
Upstream PR: nodejs/node-gyp#599

PR-URL: nodejs#1251
Reviewed-By: Rod Vagg <[email protected]>

PR-URL: nodejs#1266
Reviewed-By: Ben Noordhuis <[email protected]>
othiym23 pushed a commit to npm/node that referenced this pull request Apr 17, 2015
On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This causes many compiled addons to break when node.exe or iojs.exe are
renamed, because when the binary has been renamed the addon DLL can't
find the (right) .exe file to load its imports from.

This patch gives compiled addon developers an option to overcome this
restriction by compiling a delay-load hook into their binary. The
delay-load hook ensures that whenever a module tries to load imports
from node.exe/iojs.exe, it'll just look at the process image, thereby
making the addon work regardless of what name the node/iojs binary has.

To enable this feature, the addon developer must set the
'win_delay_load_hook' option to 'true' in their binding.gyp file, like
this:

```
{
  'targets': [
    {
      'target_name': 'ernie',
      'win_delay_load_hook': 'true',
      ...
```

Bug: nodejs#751
Bug: nodejs#965
Upstream PR: nodejs/node-gyp#599

PR-URL: nodejs#1251
Reviewed-By: Rod Vagg <[email protected]>

PR-URL: nodejs#1266
Reviewed-By: Ben Noordhuis <[email protected]>
piscisaureus added a commit that referenced this pull request Apr 17, 2015
On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This causes many compiled addons to break when node.exe or iojs.exe are
renamed, because when the binary has been renamed the addon DLL can't
find the (right) .exe file to load its imports from.

This patch gives compiled addon developers an option to overcome this
restriction by compiling a delay-load hook into their binary. The
delay-load hook ensures that whenever a module tries to load imports
from node.exe/iojs.exe, it'll just look at the process image, thereby
making the addon work regardless of what name the node/iojs binary has.

To enable this feature, the addon developer must set the
'win_delay_load_hook' option to 'true' in their binding.gyp file, like
this:

```
{
  'targets': [
    {
      'target_name': 'ernie',
      'win_delay_load_hook': 'true',
      ...
```

Bug: #751
Bug: #965
Upstream PR: nodejs/node-gyp#599

PR-URL: #1251
Reviewed-By: Rod Vagg <[email protected]>

PR-URL: #1266
Reviewed-By: Ben Noordhuis <[email protected]>
piscisaureus added a commit that referenced this pull request Apr 17, 2015
On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This causes many compiled addons to break when node.exe or iojs.exe are
renamed, because when the binary has been renamed the addon DLL can't
find the (right) .exe file to load its imports from.

This patch gives compiled addon developers an option to overcome this
restriction by compiling a delay-load hook into their binary. The
delay-load hook ensures that whenever a module tries to load imports
from node.exe/iojs.exe, it'll just look at the process image, thereby
making the addon work regardless of what name the node/iojs binary has.

To enable this feature, the addon developer must set the
'win_delay_load_hook' option to 'true' in their binding.gyp file, like
this:

```
{
  'targets': [
    {
      'target_name': 'ernie',
      'win_delay_load_hook': 'true',
      ...
```

Bug: #751
Bug: #965
Upstream PR: nodejs/node-gyp#599

PR-URL: #1251
Reviewed-By: Rod Vagg <[email protected]>

PR-URL: #1266
Reviewed-By: Ben Noordhuis <[email protected]>
piscisaureus added a commit that referenced this pull request Apr 17, 2015
On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This causes many compiled addons to break when node.exe or iojs.exe are
renamed, because when the binary has been renamed the addon DLL can't
find the (right) .exe file to load its imports from.

This patch gives compiled addon developers an option to overcome this
restriction by compiling a delay-load hook into their binary. The
delay-load hook ensures that whenever a module tries to load imports
from node.exe/iojs.exe, it'll just look at the process image, thereby
making the addon work regardless of what name the node/iojs binary has.

To enable this feature, the addon developer must set the
'win_delay_load_hook' option to 'true' in their binding.gyp file, like
this:

```
{
  'targets': [
    {
      'target_name': 'ernie',
      'win_delay_load_hook': 'true',
      ...
```

Bug: #751
Bug: #965
Upstream PR: nodejs/node-gyp#599

PR-URL: #1251
Reviewed-By: Rod Vagg <[email protected]>

PR-URL: #1266
Reviewed-By: Ben Noordhuis <[email protected]>
othiym23 pushed a commit to npm/node that referenced this pull request Apr 24, 2015
On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This causes many compiled addons to break when node.exe or iojs.exe are
renamed, because when the binary has been renamed the addon DLL can't
find the (right) .exe file to load its imports from.

This patch gives compiled addon developers an option to overcome this
restriction by compiling a delay-load hook into their binary. The
delay-load hook ensures that whenever a module tries to load imports
from node.exe/iojs.exe, it'll just look at the process image, thereby
making the addon work regardless of what name the node/iojs binary has.

To enable this feature, the addon developer must set the
'win_delay_load_hook' option to 'true' in their binding.gyp file, like
this:

```
{
  'targets': [
    {
      'target_name': 'ernie',
      'win_delay_load_hook': 'true',
      ...
```

Bug: nodejs#751
Bug: nodejs#965
Upstream PR: nodejs/node-gyp#599

PR-URL: nodejs#1251
Reviewed-By: Rod Vagg <[email protected]>

PR-URL: nodejs#1266
Reviewed-By: Ben Noordhuis <[email protected]>
othiym23 pushed a commit to npm/node that referenced this pull request May 1, 2015
On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This causes many compiled addons to break when node.exe or iojs.exe are
renamed, because when the binary has been renamed the addon DLL can't
find the (right) .exe file to load its imports from.

This patch gives compiled addon developers an option to overcome this
restriction by compiling a delay-load hook into their binary. The
delay-load hook ensures that whenever a module tries to load imports
from node.exe/iojs.exe, it'll just look at the process image, thereby
making the addon work regardless of what name the node/iojs binary has.

To enable this feature, the addon developer must set the
'win_delay_load_hook' option to 'true' in their binding.gyp file, like
this:

```
{
  'targets': [
    {
      'target_name': 'ernie',
      'win_delay_load_hook': 'true',
      ...
```

Bug: nodejs#751
Bug: nodejs#965
Upstream PR: nodejs/node-gyp#599

PR-URL: nodejs#1251
Reviewed-By: Rod Vagg <[email protected]>

PR-URL: nodejs#1266
Reviewed-By: Ben Noordhuis <[email protected]>
othiym23 pushed a commit to npm/node that referenced this pull request May 1, 2015
On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This causes many compiled addons to break when node.exe or iojs.exe are
renamed, because when the binary has been renamed the addon DLL can't
find the (right) .exe file to load its imports from.

This patch gives compiled addon developers an option to overcome this
restriction by compiling a delay-load hook into their binary. The
delay-load hook ensures that whenever a module tries to load imports
from node.exe/iojs.exe, it'll just look at the process image, thereby
making the addon work regardless of what name the node/iojs binary has.

To enable this feature, the addon developer must set the
'win_delay_load_hook' option to 'true' in their binding.gyp file, like
this:

```
{
  'targets': [
    {
      'target_name': 'ernie',
      'win_delay_load_hook': 'true',
      ...
```

Bug: nodejs#751
Bug: nodejs#965
Upstream PR: nodejs/node-gyp#599

PR-URL: nodejs#1251
Reviewed-By: Rod Vagg <[email protected]>

PR-URL: nodejs#1266
Reviewed-By: Ben Noordhuis <[email protected]>
othiym23 pushed a commit to npm/node that referenced this pull request May 1, 2015
On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This causes many compiled addons to break when node.exe or iojs.exe are
renamed, because when the binary has been renamed the addon DLL can't
find the (right) .exe file to load its imports from.

This patch gives compiled addon developers an option to overcome this
restriction by compiling a delay-load hook into their binary. The
delay-load hook ensures that whenever a module tries to load imports
from node.exe/iojs.exe, it'll just look at the process image, thereby
making the addon work regardless of what name the node/iojs binary has.

To enable this feature, the addon developer must set the
'win_delay_load_hook' option to 'true' in their binding.gyp file, like
this:

```
{
  'targets': [
    {
      'target_name': 'ernie',
      'win_delay_load_hook': 'true',
      ...
```

Bug: nodejs#751
Bug: nodejs#965
Upstream PR: nodejs/node-gyp#599

PR-URL: nodejs#1251
Reviewed-By: Rod Vagg <[email protected]>

PR-URL: nodejs#1266
Reviewed-By: Ben Noordhuis <[email protected]>
othiym23 pushed a commit to npm/node that referenced this pull request May 2, 2015
On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This causes many compiled addons to break when node.exe or iojs.exe are
renamed, because when the binary has been renamed the addon DLL can't
find the (right) .exe file to load its imports from.

This patch gives compiled addon developers an option to overcome this
restriction by compiling a delay-load hook into their binary. The
delay-load hook ensures that whenever a module tries to load imports
from node.exe/iojs.exe, it'll just look at the process image, thereby
making the addon work regardless of what name the node/iojs binary has.

To enable this feature, the addon developer must set the
'win_delay_load_hook' option to 'true' in their binding.gyp file, like
this:

```
{
  'targets': [
    {
      'target_name': 'ernie',
      'win_delay_load_hook': 'true',
      ...
```

Bug: nodejs#751
Bug: nodejs#965
Upstream PR: nodejs/node-gyp#599

PR-URL: nodejs#1251
Reviewed-By: Rod Vagg <[email protected]>

PR-URL: nodejs#1266
Reviewed-By: Ben Noordhuis <[email protected]>
othiym23 pushed a commit to npm/node that referenced this pull request May 8, 2015
On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This causes many compiled addons to break when node.exe or iojs.exe are
renamed, because when the binary has been renamed the addon DLL can't
find the (right) .exe file to load its imports from.

This patch gives compiled addon developers an option to overcome this
restriction by compiling a delay-load hook into their binary. The
delay-load hook ensures that whenever a module tries to load imports
from node.exe/iojs.exe, it'll just look at the process image, thereby
making the addon work regardless of what name the node/iojs binary has.

To enable this feature, the addon developer must set the
'win_delay_load_hook' option to 'true' in their binding.gyp file, like
this:

```
{
  'targets': [
    {
      'target_name': 'ernie',
      'win_delay_load_hook': 'true',
      ...
```

Bug: nodejs#751
Bug: nodejs#965
Upstream PR: nodejs/node-gyp#599

PR-URL: nodejs#1251
Reviewed-By: Rod Vagg <[email protected]>

PR-URL: nodejs#1266
Reviewed-By: Ben Noordhuis <[email protected]>
iarna pushed a commit to npm/node that referenced this pull request May 22, 2015
On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This causes many compiled addons to break when node.exe or iojs.exe are
renamed, because when the binary has been renamed the addon DLL can't
find the (right) .exe file to load its imports from.

This patch gives compiled addon developers an option to overcome this
restriction by compiling a delay-load hook into their binary. The
delay-load hook ensures that whenever a module tries to load imports
from node.exe/iojs.exe, it'll just look at the process image, thereby
making the addon work regardless of what name the node/iojs binary has.

To enable this feature, the addon developer must set the
'win_delay_load_hook' option to 'true' in their binding.gyp file, like
this:

```
{
  'targets': [
    {
      'target_name': 'ernie',
      'win_delay_load_hook': 'true',
      ...
```

Bug: nodejs#751
Bug: nodejs#965
Upstream PR: nodejs/node-gyp#599

PR-URL: nodejs#1251
Reviewed-By: Rod Vagg <[email protected]>

PR-URL: nodejs#1266
Reviewed-By: Ben Noordhuis <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ Issues and PRs that require attention from people who are familiar with C++. windows Issues and PRs related to the Windows platform.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants