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

win,node-gyp: make delay-load hook optional #1266

Closed
wants to merge 1 commit into from

Conversation

piscisaureus
Copy link
Contributor

The delay-load hook that was supposed to make compiled addons work on
Windows regardless of the iojs.exe/node.exe filename causes issues with
a small amount of compiled addons.

It seems a bit irresponsible to land it as part of a patch release.

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',
      ...

R=@rvagg (FYI as the release Meister)
R=@am11 (could you test this with node-sass?)
R=@bnoordhuis, @TooTallNate

The delay-load hook that was supposed 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',
      ...
```
@mscdex
Copy link
Contributor

mscdex commented Mar 26, 2015

Can you elaborate a bit on what kinds of issues this is currently causing?

@mscdex mscdex added c++ Issues and PRs that require attention from people who are familiar with C++. windows Issues and PRs related to the Windows platform. labels Mar 26, 2015
@Fishrock123
Copy link
Contributor

@mscdex #1251 (comment)

@piscisaureus
Copy link
Contributor Author

@mscdex

Can you elaborate a bit on what kinds of issues this is currently causing?

So delay loading doesn't work when data references are imported from a DLL. This is also triggered when the addon inherits from a base class that has virtual members, because the vtable needs to be imported. The issue is pretty easy to spot, it causes a linker error that tells the user not to use delay loading.

@kkoopa already pointed that out here, but I couldn't reproduce that, even after testing with more than a handful of modules.
However eventually I ran into the issue myself when I was trying to install node-heapdump.

So most modules should just enable this option and call it a day, but we can't just assume that it always works.

@bnoordhuis
Copy link
Member

LGTM

piscisaureus added a commit that referenced this pull request Mar 26, 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: #1251
PR-URL: #1266
Reviewed-By: Ben Noordhuis <[email protected]>
@piscisaureus piscisaureus deleted the hook-optional branch March 26, 2015 20:37
@piscisaureus
Copy link
Contributor Author

Thanks, me.
Landed in 08acf13.

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]>
@rvagg rvagg mentioned this pull request Mar 28, 2015
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]>
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]>
trgoofi added a commit to trgoofi/telepod that referenced this pull request Apr 10, 2015
```
Error: Module did not self-register.
    at Error (native)
    at Module.load (module.js:335:32)
```
nodejs/node#1266
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]>
@rvagg rvagg mentioned this pull request Apr 11, 2015
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]>
@rvagg rvagg mentioned this pull request May 2, 2015
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.

4 participants