Windows: Broken node alias #751
Comments
|
/cc @piscisaureus do we need to do that stub executable after all? |
|
Perhaps node.exe can spawn iojs.exe with the same command line arguments and redirected stdin, stdout and stderr? |
|
This issue is that the name of the library that compiled addons link against is fixed. For this reason it also has never been possible to rename node.exe on windows and have compiled addons still work. In theory this issue could be solved by delay-loading the symbols that come from iojs.exe and adding a delay-load notification hook to the compiled addon. Unfortunately I've never gotten around to implementing this.
The original plan I had where node.exe would "load" iojs.exe as a dynamic library turned out not to work.
That's possible but it I'm afraid it'll break other scripts that assume that they can obtain the PID for their child node process. |
|
delayload might not work. It is not allowed to delay-load imported data, which happens when someone uses |
Right, I didn't think of that. |
|
Is it possible to break out all shared functionality into a real dynamic library, make addons link against that and have two thin frontends, "node.exe" and "iojs.exe"? Addons would then not necessarily be tied to executable names. If there still is a need for a registration callback inside the frontends then that can be found by dynamically loading the right library based on In short: turn iojs.exe into iojs.dll, make new iojs.exe and node.exe as frontends for iojs.dll. node_main.cc could become the new iojs executable target by itself and the rest of iojs would become libiojs, now dynamically link iojs to libiojs and have addons link to libiojs. Now addons would no longer be dependent on the name of the main executable. |
|
kkoopa: +1. I think this should have happened long time ago and I think I have filled an issue related to this already. I'm interested if there is anything I can help with. |
|
I have filled this one, which is related: nodejs/roadmap#9 |
|
Suggestion: Adding a symbolic link in the iojs_install_path > cd iojs_install_path
> mklink node.exe iojs.exeFor systems that node and iojs need to co-exists, additional work around is needed. Not sure if the suggestion will solve the issue @kkoopa reported. Edit: I experimented on node-sqlite3 which did not build for me out of the box. To resolve I added a symbolic link to the node.lib <== ==>iojs.lib in the proper ~.node-gyp path and patched node-sqlite3/package.json to support the 1.1.0 version. The result is a successful build with iojs on windows. |
|
For future references, nodejs/node-gyp#564 is an attempt to fix this problem on build tools' level. |
|
This problem cannot be fixed from there. Addons have to register with the executable. If they depend on exports from iojs.exe, they cannot resolve them against node.exe and vice versa. |
|
Redirecting from #871. If we use nvmw, this problem does not happen because nvmw only downloads Unfortunately, AppVeyor does not use nvmw, but their own version manager, which downloads and extracts io.js' As you can see in #871 comments by @piscisaureus, Nonetheless, @kkoopa's solution is interesting: make @kkoopa, on that note, can this be worked out using Adjuster Thunk in assembly: http://stackoverflow.com/a/1090914/863980? The linked blog by Raymond Chen provides some insights on v-table thunking. On a related note, this project SharpNeedle by @ChadSki injects C# assembly in any running process using DllMain injection as prescribe in another blog. Perhaps we can compose a workaround for "fixed library name" problem and add it to uv_dlopen ( |
|
Related to #895 |
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
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]>
|
Is this still a issue? |
|
It does still exist unfortunately. It still exists specifically for apps that statically link to node but have a different executable name, e.g. electron.exe, nw.exe, etc. The delay load hook hack is a way to work around it. I have a PR out for This would allow embedders to ship their own build of node.dll and automatically get compatibility with native modules compiled against node. Node would not have to ship a |
|
This won't be an issue in the converged 4.0.0 release. Since it's impractical to address in io.js (1.0.0> <4.0.0), I'm going to close this. |
The node compatibility link is unusable on windows. Addons depend on doing a callback to the specified executable module via node_module_register, which is not possible when the name is wrong.
If an addon depends on iojs.exe, it cannot be used through node.exe and vice versa, giving the 'Module did not self-register.' error.
The text was updated successfully, but these errors were encountered: