Bugzilla

Here are some final notes on this. I was able to reproduce that behavior with a custom executable file built from a new project within Visual Studio:
- Just including `comdef.h` without using anything specific within it doesn't actually lead to linking with `comsupp.lib`, which gets optimized away.
- Adding a use of `_bstr_t` makes the linking happen.

I have updated [my script](https://raw.githubusercontent.com/yjugl/comsuppdetector/master/comsuppdetector.py), and here is the new output for the different cases I tested.

Including `comdef.h` without using `_bstr_t`:

```
>python comsuppdetector.py comsupptests\x64\Release\comsupptests.exe
No import for oleaut32.dll was found.
It is safe to assume that neither comsupp.lib, comsuppw.lib, comsuppd.lib, nor comsuppwd.lib were statically linked into 'comsupptests\x64\Release\comsupptests.exe'.

>python comsuppdetector.py comsupptests\x64\Debug\comsupptests.exe
No import for oleaut32.dll was found.
It is safe to assume that neither comsupp.lib, comsuppw.lib, comsuppd.lib, nor comsuppwd.lib were statically linked into 'comsupptests\x64\Debug\comsupptests.exe'.
```

Including `comdef.h` and using `_bstr_t`:

```
C:\Users\y>python comsuppdetector.py comsupptests\x64\Release\comsupptests.exe
Found a potential instance of `dynamic_atexit_destructor_for_'vtMissing'' at 0x1400029d0, vtMissing would be at 0x140005008.
It is likely that comsupp.lib or comsuppw.lib was statically linked into 'comsupptests\x64\Release\comsupptests.exe'.

>python comsuppdetector.py comsupptests\x64\Debug\comsupptests.exe
Found a potential instance of _variant_t::~_variant_t at 0x140014f10.
It is likely that comsuppd.lib or comsuppwd.lib was statically linked into 'comsupptests\x64\Debug\comsupptests.exe'.
```

And the output for shipped versions of Firefox:
```
>python comsuppdetector.py "C:\Program Files\Mozilla Firefox\xul.dll"
It appears safe to assume that neither comsupp.lib, comsuppw.lib, comsuppd.lib, nor comsuppwd.lib were statically linked into 'C:\Program Files\Mozilla Firefox\xul.dll'.

>python comsuppdetector.py "C:\Program Files\Firefox Nightly\xul.dll"
Found a potential instance of `dynamic_atexit_destructor_for_'vtMissing'' at 0x1854b79e0, vtMissing would be at 0x1863b5008.
It is likely that comsupp.lib or comsuppw.lib was statically linked into 'C:\Program Files\Firefox Nightly\xul.dll'.
```

Here are some final notes on this. I was able to reproduce the same behavior with a custom executable file built from a new project within Visual Studio:
- Just including `comdef.h` without using anything specific within it doesn't actually lead to linking with `comsupp.lib`, which gets optimized away.
- Adding a use of `_bstr_t` makes the linking happen.

I have updated [my script](https://raw.githubusercontent.com/yjugl/comsuppdetector/master/comsuppdetector.py), and here is the new output for the different cases I tested.

Including `comdef.h` without using `_bstr_t`:

```
>python comsuppdetector.py comsupptests\x64\Release\comsupptests.exe
No import for oleaut32.dll was found.
It is safe to assume that neither comsupp.lib, comsuppw.lib, comsuppd.lib, nor comsuppwd.lib were statically linked into 'comsupptests\x64\Release\comsupptests.exe'.

>python comsuppdetector.py comsupptests\x64\Debug\comsupptests.exe
No import for oleaut32.dll was found.
It is safe to assume that neither comsupp.lib, comsuppw.lib, comsuppd.lib, nor comsuppwd.lib were statically linked into 'comsupptests\x64\Debug\comsupptests.exe'.
```

Including `comdef.h` and using `_bstr_t`:

```
C:\Users\y>python comsuppdetector.py comsupptests\x64\Release\comsupptests.exe
Found a potential instance of `dynamic_atexit_destructor_for_'vtMissing'' at 0x1400029d0, vtMissing would be at 0x140005008.
It is likely that comsupp.lib or comsuppw.lib was statically linked into 'comsupptests\x64\Release\comsupptests.exe'.

>python comsuppdetector.py comsupptests\x64\Debug\comsupptests.exe
Found a potential instance of _variant_t::~_variant_t at 0x140014f10.
It is likely that comsuppd.lib or comsuppwd.lib was statically linked into 'comsupptests\x64\Debug\comsupptests.exe'.
```

And the output for shipped versions of Firefox:
```
>python comsuppdetector.py "C:\Program Files\Mozilla Firefox\xul.dll"
It appears safe to assume that neither comsupp.lib, comsuppw.lib, comsuppd.lib, nor comsuppwd.lib were statically linked into 'C:\Program Files\Mozilla Firefox\xul.dll'.

>python comsuppdetector.py "C:\Program Files\Firefox Nightly\xul.dll"
Found a potential instance of `dynamic_atexit_destructor_for_'vtMissing'' at 0x1854b79e0, vtMissing would be at 0x1863b5008.
It is likely that comsupp.lib or comsuppw.lib was statically linked into 'C:\Program Files\Firefox Nightly\xul.dll'.
```

Here are some final notes on this. I was able to reproduce the same behavior with a custom executable file built from a new project within Visual Studio:
- Just including `comdef.h` without using anything specific doesn't actually lead to linking with `comsupp.lib`, which gets optimized away.
- Adding a use of `_bstr_t` makes the linking happen.

I have updated [my script](https://raw.githubusercontent.com/yjugl/comsuppdetector/master/comsuppdetector.py), and here is the new output for the different cases I tested.

Including `comdef.h` without using `_bstr_t`:

```
>python comsuppdetector.py comsupptests\x64\Release\comsupptests.exe
No import for oleaut32.dll was found.
It is safe to assume that neither comsupp.lib, comsuppw.lib, comsuppd.lib, nor comsuppwd.lib were statically linked into 'comsupptests\x64\Release\comsupptests.exe'.

>python comsuppdetector.py comsupptests\x64\Debug\comsupptests.exe
No import for oleaut32.dll was found.
It is safe to assume that neither comsupp.lib, comsuppw.lib, comsuppd.lib, nor comsuppwd.lib were statically linked into 'comsupptests\x64\Debug\comsupptests.exe'.
```

Including `comdef.h` and using `_bstr_t`:

```
C:\Users\y>python comsuppdetector.py comsupptests\x64\Release\comsupptests.exe
Found a potential instance of `dynamic_atexit_destructor_for_'vtMissing'' at 0x1400029d0, vtMissing would be at 0x140005008.
It is likely that comsupp.lib or comsuppw.lib was statically linked into 'comsupptests\x64\Release\comsupptests.exe'.

>python comsuppdetector.py comsupptests\x64\Debug\comsupptests.exe
Found a potential instance of _variant_t::~_variant_t at 0x140014f10.
It is likely that comsuppd.lib or comsuppwd.lib was statically linked into 'comsupptests\x64\Debug\comsupptests.exe'.
```

And the output for shipped versions of Firefox:
```
>python comsuppdetector.py "C:\Program Files\Mozilla Firefox\xul.dll"
It appears safe to assume that neither comsupp.lib, comsuppw.lib, comsuppd.lib, nor comsuppwd.lib were statically linked into 'C:\Program Files\Mozilla Firefox\xul.dll'.

>python comsuppdetector.py "C:\Program Files\Firefox Nightly\xul.dll"
Found a potential instance of `dynamic_atexit_destructor_for_'vtMissing'' at 0x1854b79e0, vtMissing would be at 0x1863b5008.
It is likely that comsupp.lib or comsuppw.lib was statically linked into 'C:\Program Files\Firefox Nightly\xul.dll'.
```

Here are some final notes on this. I was able to reproduce the same behavior with a custom executable file built from a new project within Visual Studio:
- Just including `comdef.h` without using anything specific doesn't actually lead to linking with `comsupp.lib`, which gets optimized away.
- Adding a use of `_bstr_t` makes the linking happen.

I have updated [my script](https://raw.githubusercontent.com/yjugl/comsuppdetector/master/comsuppdetector.py), and here is the new output for the different cases I tested.

Including `comdef.h` without using `_bstr_t`:

```
>python comsuppdetector.py comsupptests\x64\Release\comsupptests.exe
No import for oleaut32.dll was found.
It is safe to assume that neither comsupp.lib, comsuppw.lib, comsuppd.lib, nor comsuppwd.lib were statically linked into 'comsupptests\x64\Release\comsupptests.exe'.

>python comsuppdetector.py comsupptests\x64\Debug\comsupptests.exe
No import for oleaut32.dll was found.
It is safe to assume that neither comsupp.lib, comsuppw.lib, comsuppd.lib, nor comsuppwd.lib were statically linked into 'comsupptests\x64\Debug\comsupptests.exe'.
```

Including `comdef.h` and using `_bstr_t`:

```
>python comsuppdetector.py comsupptests\x64\Release\comsupptests.exe
Found a potential instance of `dynamic_atexit_destructor_for_'vtMissing'' at 0x1400029d0, vtMissing would be at 0x140005008.
It is likely that comsupp.lib or comsuppw.lib was statically linked into 'comsupptests\x64\Release\comsupptests.exe'.

>python comsuppdetector.py comsupptests\x64\Debug\comsupptests.exe
Found a potential instance of _variant_t::~_variant_t at 0x140014f10.
It is likely that comsuppd.lib or comsuppwd.lib was statically linked into 'comsupptests\x64\Debug\comsupptests.exe'.
```

And the output for shipped versions of Firefox:
```
>python comsuppdetector.py "C:\Program Files\Mozilla Firefox\xul.dll"
It appears safe to assume that neither comsupp.lib, comsuppw.lib, comsuppd.lib, nor comsuppwd.lib were statically linked into 'C:\Program Files\Mozilla Firefox\xul.dll'.

>python comsuppdetector.py "C:\Program Files\Firefox Nightly\xul.dll"
Found a potential instance of `dynamic_atexit_destructor_for_'vtMissing'' at 0x1854b79e0, vtMissing would be at 0x1863b5008.
It is likely that comsupp.lib or comsuppw.lib was statically linked into 'C:\Program Files\Firefox Nightly\xul.dll'.
```

Here are some final notes on this. I was able to reproduce the same behavior with a custom executable file built from a new project within Visual Studio:
- Just including `comdef.h` without using anything specific doesn't actually lead to linking with `comsupp.lib`, which gets optimized away.
- Adding a use of `_bstr_t` makes the linking happen.

I have updated [my detector script](https://raw.githubusercontent.com/yjugl/comsuppdetector/master/comsuppdetector.py), and here is the new output for the different cases I tested.

Including `comdef.h` without using `_bstr_t`:

```
>python comsuppdetector.py comsupptests\x64\Release\comsupptests.exe
No import for oleaut32.dll was found.
It is safe to assume that neither comsupp.lib, comsuppw.lib, comsuppd.lib, nor comsuppwd.lib were statically linked into 'comsupptests\x64\Release\comsupptests.exe'.

>python comsuppdetector.py comsupptests\x64\Debug\comsupptests.exe
No import for oleaut32.dll was found.
It is safe to assume that neither comsupp.lib, comsuppw.lib, comsuppd.lib, nor comsuppwd.lib were statically linked into 'comsupptests\x64\Debug\comsupptests.exe'.
```

Including `comdef.h` and using `_bstr_t`:

```
>python comsuppdetector.py comsupptests\x64\Release\comsupptests.exe
Found a potential instance of `dynamic_atexit_destructor_for_'vtMissing'' at 0x1400029d0, vtMissing would be at 0x140005008.
It is likely that comsupp.lib or comsuppw.lib was statically linked into 'comsupptests\x64\Release\comsupptests.exe'.

>python comsuppdetector.py comsupptests\x64\Debug\comsupptests.exe
Found a potential instance of _variant_t::~_variant_t at 0x140014f10.
It is likely that comsuppd.lib or comsuppwd.lib was statically linked into 'comsupptests\x64\Debug\comsupptests.exe'.
```

And the output for shipped versions of Firefox:
```
>python comsuppdetector.py "C:\Program Files\Mozilla Firefox\xul.dll"
It appears safe to assume that neither comsupp.lib, comsuppw.lib, comsuppd.lib, nor comsuppwd.lib were statically linked into 'C:\Program Files\Mozilla Firefox\xul.dll'.

>python comsuppdetector.py "C:\Program Files\Firefox Nightly\xul.dll"
Found a potential instance of `dynamic_atexit_destructor_for_'vtMissing'' at 0x1854b79e0, vtMissing would be at 0x1863b5008.
It is likely that comsupp.lib or comsuppw.lib was statically linked into 'C:\Program Files\Firefox Nightly\xul.dll'.
```