Bugzilla

By following the new instances of including `comdef.h`, I found the line that causes the situation described above. I believe you are correct that in past builds, the dependency to `comsupp.lib` was probably already present but somehow optimized away. It seems that since the webrtc update it is now kept, and that the reason for this is that the webrtc code actually uses one of its definitions, namely the `_bstr_t` class.

By [removing the use of `_bstr_t`](https://hg.mozilla.org/try/rev/8fdaab7b80030dbc68b73f6dd209bc65ea54798d) in `third_party/libwebrtc/modules/desktop_capture/win/desktop_capture_utils.cc`, `comsupp.lib` doesn't get linked anymore, and all the chain of consequences from above disappears. Moreover, in this specific case, the `_bstr_t` type doesn't seem required at all, I think it should work to use a standard `%ls` or Microsoft `%S` specifier with `rtc::SimpleStringBuilder::AppendFormat`, which uses `vsnprintf` under the hood. This means that right now we could technically probably remove the dependency to `comsupp.lib` if we wanted.

Forgetting about this specific case, we need to think more generally whether what is defined in `comsupp.lib` should be allowed in `xul.dll`, in which case we should keep the preloading of `oleaut32.dll` even though we don't have a strict requirement for it yet, or if we want to ban `comsupp.lib` usage until we realize that we really need it, in which case we should add continuous integration checks that there is no `vtMissing` in `xul.dll`.

By following the new instances of including `comdef.h`, I found the line that causes the situation described above. I believe you are correct that in past builds, the dependency to `comsupp.lib` was probably already present but somehow optimized away. It seems that since the webrtc update it is now kept, and that the reason for this is that the webrtc code actually uses one of its definitions, namely the `_bstr_t` class.

By [removing the use of `_bstr_t`](https://hg.mozilla.org/try/rev/8fdaab7b80030dbc68b73f6dd209bc65ea54798d) in `third_party/libwebrtc/modules/desktop_capture/win/desktop_capture_utils.cc`, `comsupp.lib` doesn't get linked anymore, and all the chain of consequences from above disappears. Moreover, in this specific case, the `_bstr_t` type doesn't seem required at all, I think it should work to use a standard `%ls` or Microsoft `%S` wide string specifier with `rtc::SimpleStringBuilder::AppendFormat`, which uses `vsnprintf` under the hood. This means that right now we could technically probably remove the dependency to `comsupp.lib` if we wanted.

Forgetting about this specific case, we need to think more generally whether what is defined in `comsupp.lib` should be allowed in `xul.dll`, in which case we should keep the preloading of `oleaut32.dll` even though we don't have a strict requirement for it yet, or if we want to ban `comsupp.lib` usage until we realize that we really need it, in which case we should add continuous integration checks that there is no `vtMissing` in `xul.dll`.

By following the new instances of including `comdef.h`, I found the line that causes the situation described above. I believe you are correct that in past builds, the dependency to `comsupp.lib` was probably already present but somehow optimized away. It seems that since the webrtc update it is now kept, and that the reason for this is that the webrtc code actually uses one of its definitions, namely the `_bstr_t` class.

By [removing the use of `_bstr_t`](https://hg.mozilla.org/try/rev/8fdaab7b80030dbc68b73f6dd209bc65ea54798d) in `third_party/libwebrtc/modules/desktop_capture/win/desktop_capture_utils.cc`, `comsupp.lib` doesn't get linked anymore, and all the chain of consequences from above disappears. Moreover, in this specific case, the `_bstr_t` type doesn't seem required at all, I think it should work to use a standard `%ls` or Microsoft `%S` wide string specifier with `rtc::SimpleStringBuilder::AppendFormat`, which uses `vsnprintf` under the hood. This means that right now we could technically probably remove the dependency to `comsupp.lib` if we wanted.

Forgetting about this specific case, we need to think more generally whether what is defined in `comsupp.lib` should be allowed in `xul.dll`, in which case we should keep the preloading of `oleaut32.dll` even though we don't have a strict requirement for it yet, or if we want to ban `comsupp.lib` usage until we realize some day that we have a new real need it, in which case we should add continuous integration checks that there is no `vtMissing` in `xul.dll`.

By following the new instances of including `comdef.h`, I found the line that causes the situation described above. I believe you are correct that in past builds, the dependency to `comsupp.lib` was probably already present but somehow optimized away. It seems that since the webrtc update it is now kept, and that the reason for this is that the webrtc code now actually uses one of its definitions, namely the `_bstr_t` class.

By [removing the use of `_bstr_t`](https://hg.mozilla.org/try/rev/8fdaab7b80030dbc68b73f6dd209bc65ea54798d) in `third_party/libwebrtc/modules/desktop_capture/win/desktop_capture_utils.cc`, `comsupp.lib` doesn't get linked anymore, and all the chain of consequences from above disappears. Moreover, in this specific case, the `_bstr_t` type doesn't seem required at all, I think it should work to use a standard `%ls` or Microsoft `%S` wide string specifier with `rtc::SimpleStringBuilder::AppendFormat`, which uses `vsnprintf` under the hood. This means that right now we could technically probably remove the dependency to `comsupp.lib` if we wanted.

Forgetting about this specific case, we need to think more generally whether what is defined in `comsupp.lib` should be allowed in `xul.dll`, in which case we should keep the preloading of `oleaut32.dll` even though we don't have a strict requirement for it yet, or if we want to ban `comsupp.lib` usage until we realize some day that we have a new real need it, in which case we should add continuous integration checks that there is no `vtMissing` in `xul.dll`.

By following the new instances of `#include <comdef.h>`, I found the line that causes the situation described above. I believe you are correct that in past builds, the dependency to `comsupp.lib` was probably already present but somehow optimized away. It seems that since the webrtc update it is now kept, and that the reason for this is that the webrtc code now actually uses one of its definitions, namely the `_bstr_t` class.

By [removing the use of `_bstr_t`](https://hg.mozilla.org/try/rev/8fdaab7b80030dbc68b73f6dd209bc65ea54798d) in `third_party/libwebrtc/modules/desktop_capture/win/desktop_capture_utils.cc`, `comsupp.lib` doesn't get linked anymore, and all the chain of consequences from above disappears. Moreover, in this specific case, the `_bstr_t` type doesn't seem required at all, I think it should work to use a standard `%ls` or Microsoft `%S` wide string specifier with `rtc::SimpleStringBuilder::AppendFormat`, which uses `vsnprintf` under the hood. This means that right now we could technically probably remove the dependency to `comsupp.lib` if we wanted.

Forgetting about this specific case, we need to think more generally whether what is defined in `comsupp.lib` should be allowed in `xul.dll`, in which case we should keep the preloading of `oleaut32.dll` even though we don't have a strict requirement for it yet, or if we want to ban `comsupp.lib` usage until we realize some day that we have a new real need it, in which case we should add continuous integration checks that there is no `vtMissing` in `xul.dll`.

By following the new instances of `#include <comdef.h>`, I found the line that causes the situation described above. I believe you are correct that in past builds, the dependency to `comsupp.lib` was probably already present but somehow optimized away. It seems that since the webrtc update it is now kept, and that the reason for this is that the webrtc code now actually uses one of its definitions, namely the `_bstr_t` class.

By [removing the use of `_bstr_t`](https://hg.mozilla.org/try/rev/8fdaab7b80030dbc68b73f6dd209bc65ea54798d) in `third_party/libwebrtc/modules/desktop_capture/win/desktop_capture_utils.cc`, `comsupp.lib` doesn't get linked anymore, and all the chain of consequences from above disappears. Moreover, in this specific case, the use of `_bstr_t` doesn't seem required at all, I think it should work to use a standard `%ls` or Microsoft `%S` wide string specifier with `rtc::SimpleStringBuilder::AppendFormat`, which uses `vsnprintf` under the hood. This means that right now we could technically probably remove the dependency to `comsupp.lib` if we wanted.

Forgetting about this specific case, we need to think more generally whether what is defined in `comsupp.lib` should be allowed in `xul.dll`, in which case we should keep the preloading of `oleaut32.dll` even though we don't have a strict requirement for it yet, or if we want to ban `comsupp.lib` usage until we realize some day that we have a new real need it, in which case we should add continuous integration checks that there is no `vtMissing` in `xul.dll`.

By following the new instances of `#include <comdef.h>`, I found the line that causes the situation described above. I believe you are correct that in past builds, the dependency to `comsupp.lib` was probably already present but somehow optimized away. It seems that since the webrtc update it is now kept, and that the reason for this is that the webrtc code now actually uses one of its definitions, namely the `_bstr_t` class.

By [removing the use of `_bstr_t`](https://hg.mozilla.org/try/rev/8fdaab7b80030dbc68b73f6dd209bc65ea54798d) in `third_party/libwebrtc/modules/desktop_capture/win/desktop_capture_utils.cc`, `comsupp.lib` doesn't get linked anymore, and all the chain of consequences from above disappears. Moreover, in this specific case, the use of `_bstr_t` doesn't seem required at all, I think it should work to use a standard `%ls` or Microsoft `%S` wide string specifier with `rtc::SimpleStringBuilder::AppendFormat`, which uses `vsnprintf` under the hood. This means that right now, technically speaking we could probably remove the dependency to `comsupp.lib` if we wanted.

Forgetting about this specific case, we need to think more generally whether what is defined in `comsupp.lib` should be allowed in `xul.dll`, in which case we should keep the preloading of `oleaut32.dll` even though we don't have a strict requirement for it yet, or if we want to ban `comsupp.lib` usage until we realize some day that we have a new real need it, in which case we should add continuous integration checks that there is no `vtMissing` in `xul.dll`.

By following the new instances of `#include <comdef.h>`, I found the line that causes the situation described above. I believe you are correct that in past builds, the dependency to `comsupp.lib` was probably already present but somehow optimized away. It seems that since the webrtc update the dependency is now kept, and that the reason for this is that the webrtc code now actually uses one of its definitions, namely the `_bstr_t` class.

By [removing the use of `_bstr_t`](https://hg.mozilla.org/try/rev/8fdaab7b80030dbc68b73f6dd209bc65ea54798d) in `third_party/libwebrtc/modules/desktop_capture/win/desktop_capture_utils.cc`, `comsupp.lib` doesn't get linked anymore, and all the chain of consequences from above disappears. Moreover, in this specific case, the use of `_bstr_t` doesn't seem required at all, I think it should work to use a standard `%ls` or Microsoft `%S` wide string specifier with `rtc::SimpleStringBuilder::AppendFormat`, which uses `vsnprintf` under the hood. This means that with the current code base, technically speaking we could probably remove the dependency to `comsupp.lib` if we wanted.

Forgetting about this specific case though, we need to think more generally whether (1) we want to allow the use of what is defined in `comsupp.lib` in `xul.dll` even though we don't have a strict requirement for it right now, or (2) we want to ban `comsupp.lib` usage in `xul.dll` until the day we realize that we now have a strict requirement for it. In case (1), we should keep the preloading of `oleaut32.dll` and consider it a dependency for `comsupp.lib`, while in case (2) we should remove the preloading and add continuous integration checks that there is no `vtMissing` in `xul.dll`.

By following the new instances of `#include <comdef.h>`, I found the line that causes the situation described above. I believe you are correct that in past builds, the dependency to `comsupp.lib` was probably already present but somehow optimized away. It seems that since the webrtc update the dependency is now kept, and that the reason for this is that the webrtc code now actually uses one of its definitions, namely the `_bstr_t` class.

By [removing the use of `_bstr_t`](https://hg.mozilla.org/try/rev/8fdaab7b80030dbc68b73f6dd209bc65ea54798d) in `third_party/libwebrtc/modules/desktop_capture/win/desktop_capture_utils.cc`, `comsupp.lib` doesn't get linked anymore, and all the chain of consequences from above disappears. Moreover, in this specific case, the use of `_bstr_t` doesn't seem required at all, I think it should work to use a standard `%ls` or Microsoft `%S` wide string specifier with `rtc::SimpleStringBuilder::AppendFormat`, which uses `vsnprintf` under the hood. This means that with the current code base, technically speaking we could probably remove the dependency to `comsupp.lib` if we wanted.

Forgetting about this specific case though, we need to think more generally whether (1) we want to allow the use of what is defined in `comsupp.lib` in `xul.dll` even though we don't have a strict requirement for it right now, or (2) we want to ban `comsupp.lib` usage in `xul.dll` until the day we realize that we now have a strict requirement for it. In case (1), we should keep the preloading of `oleaut32.dll` and consider it a required dependency for using `comsupp.lib`, while in case (2) we should remove the preloading and add continuous integration checks that there is no `vtMissing` in `xul.dll`.

By following the new instances of `#include <comdef.h>`, I found the line that causes the situation described above. I believe you are correct that in past builds, the dependency to `comsupp.lib` was probably already present but somehow optimized away. It seems that since the webrtc update the dependency is now kept, and that the reason for this is that the webrtc code now actually uses one of its definitions, namely the `_bstr_t` class.

By [removing the use of `_bstr_t`](https://hg.mozilla.org/try/rev/8fdaab7b80030dbc68b73f6dd209bc65ea54798d) in `third_party/libwebrtc/modules/desktop_capture/win/desktop_capture_utils.cc`, `comsupp.lib` doesn't get linked anymore, and all the chain of consequences from above disappears. Moreover, in this specific case, the use of `_bstr_t` doesn't seem required at all, I think it should work to use a standard `%ls` or Microsoft `%S` wide string specifier with `rtc::SimpleStringBuilder::AppendFormat`, which uses `vsnprintf` under the hood. This means that with the current code base, technically speaking we could probably remove the dependency to `comsupp.lib` if we wanted.

Forgetting about this specific case though, we need to think more generally whether (1) we want to allow the use of what is defined in `comsupp.lib` in `xul.dll` even though we don't have a strict requirement for it right now, or (2) we want to ban `comsupp.lib` usage in `xul.dll` until the day we realize that we now have a strict requirement for it. In case (1), we should keep the pre-loading of `oleaut32.dll` and consider it a required dependency for using `comsupp.lib`, while in case (2) we should remove the preloading and add continuous integration checks that there is no `vtMissing` in `xul.dll`.

By following the new instances of `#include <comdef.h>`, I found the line that causes the situation described above. I believe you are correct that in past builds, the dependency to `comsupp.lib` was probably already present but somehow optimized away. It seems that since the webrtc update the dependency is now kept, and that the reason for this is that the webrtc code now actually uses one of its definitions, namely the `_bstr_t` class.

By [removing the use of `_bstr_t`](https://hg.mozilla.org/try/rev/8fdaab7b80030dbc68b73f6dd209bc65ea54798d) in `third_party/libwebrtc/modules/desktop_capture/win/desktop_capture_utils.cc`, `comsupp.lib` doesn't get linked anymore, and all the chain of consequences from above disappears. Moreover, in this specific case, the use of `_bstr_t` doesn't seem required at all, I think it should work to use a standard `%ls` or Microsoft `%S` wide string specifier with `rtc::SimpleStringBuilder::AppendFormat`, which uses `vsnprintf` under the hood. This means that with the current code base, technically speaking we could probably remove the dependency to `comsupp.lib` if we wanted.

Forgetting about this specific case though, we need to think more generally whether (1) we want to allow the use of what is defined in `comsupp.lib` in `xul.dll` even though we don't have a strict requirement for it right now, or (2) we want to ban `comsupp.lib` usage in `xul.dll` until the day we realize that we now have a strict requirement for it. In case (1), we should keep the pre-loading of `oleaut32.dll` and consider it a required dependency for using `comsupp.lib`, while in case (2), we should remove the preloading and add continuous integration checks that there is no `vtMissing` in `xul.dll`.

By following the new instances of `#include <comdef.h>`, I found the line that causes the situation described above. I believe you are correct that in past builds, the dependency to `comsupp.lib` was probably already present but somehow optimized away. It seems that since the webrtc update the dependency is now kept, and that the reason for this is that the webrtc code now actually uses one of its definitions, namely the `_bstr_t` class.

By [removing the use of `_bstr_t`](https://hg.mozilla.org/try/rev/8fdaab7b80030dbc68b73f6dd209bc65ea54798d) in `third_party/libwebrtc/modules/desktop_capture/win/desktop_capture_utils.cc`, `comsupp.lib` doesn't get linked anymore, and all the chain of consequences from above disappears. Moreover, in this specific case, the use of `_bstr_t` doesn't seem required at all, I think it should work to use a standard `%ls` or Microsoft `%S` wide string specifier with `rtc::SimpleStringBuilder::AppendFormat`, which uses `vsnprintf` under the hood. This means that with the current code base, technically speaking we could probably remove the dependency to `comsupp.lib` if we wanted.

Forgetting about this specific case though, we need to think more generally whether (1) we want to allow the use of what is defined in `comsupp.lib` in `xul.dll` even though we don't have a strict requirement for it right now, or (2) we want to ban `comsupp.lib` usage in `xul.dll` until the day we realize that we now have a strict requirement for it. In case (1), we should keep the pre-loading of `oleaut32.dll` and consider it a required dependency for using `comsupp.lib`, while in case (2), we should remove the pre-loading and add continuous integration checks that there is no `vtMissing` in `xul.dll`.

By following the new instances of `#include <comdef.h>`, I found the line that causes the situation described above. I believe you are correct that in past builds, the dependency to `comsupp.lib` was probably already present but somehow optimized away. It seems that since the webrtc update the dependency is now kept, and that the reason for this is that the webrtc code now actually uses one of its definitions, namely the [`_bstr_t` class](https://docs.microsoft.com/en-us/cpp/cpp/bstr-t-class).

By [removing the use of `_bstr_t`](https://hg.mozilla.org/try/rev/8fdaab7b80030dbc68b73f6dd209bc65ea54798d) in `third_party/libwebrtc/modules/desktop_capture/win/desktop_capture_utils.cc`, `comsupp.lib` doesn't get linked anymore, and all the chain of consequences from above disappears. Moreover, in this specific case, the use of `_bstr_t` doesn't seem required at all, I think it should work to use a standard `%ls` or Microsoft `%S` wide string specifier with `rtc::SimpleStringBuilder::AppendFormat`, which uses `vsnprintf` under the hood. This means that with the current code base, technically speaking we could probably remove the dependency to `comsupp.lib` if we wanted.

Forgetting about this specific case though, we need to think more generally whether (1) we want to allow the use of what is defined in `comsupp.lib` in `xul.dll` even though we don't have a strict requirement for it right now, or (2) we want to ban `comsupp.lib` usage in `xul.dll` until the day we realize that we now have a strict requirement for it. In case (1), we should keep the pre-loading of `oleaut32.dll` and consider it a required dependency for using `comsupp.lib`, while in case (2), we should remove the pre-loading and add continuous integration checks that there is no `vtMissing` in `xul.dll`.