Bugzilla

(In reply to James Teh [:Jamie] from comment #2)
> I'm not sure what the correct course of action here is. It seems there are missing constants in the headers being used here. I guess we can conditionally define them, but that seems pretty ugly.

Hi [:Jamie], the long-term fix for this situation is to update [uiautomationclient.idl](https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/uiautomationclient.idl) and [uiautomationclient.h](https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/uiautomationclient.h) upstream in mingw-w64 based on Microsoft's version of the IDL file. The files are indeed outdated at the moment. The Microsoft file is located at `C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\um\UIAutomationCore.idl` on my machine. It seems we can then generate the `.h` file from the `.idl` file using [widl](https://www.winehq.org/docs/widl). I can take that part unless you would like to give it a try.

The short-term fix is to use a `#ifdef __MINGW32__`. We can use it to comment out the faulty code in mingw builds assuming it is OK to not have this feature in Tor. Or we can use it as the guard condition under which we want to manually define the missing constants. It's up to you to choose what's most appropriate. Then when we update to a more recent version of mingw-w64 we will be able to remove that `#ifdef` if we went for the long-term fix. But please make sure to implement a short-term fix anyway so that we can have the mingw builds back.

(In reply to James Teh [:Jamie] from comment #2)
> I'm not sure what the correct course of action here is. It seems there are missing constants in the headers being used here. I guess we can conditionally define them, but that seems pretty ugly.

Hi [:Jamie], the long-term fix for this situation is to update [uiautomationclient.idl](https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/uiautomationclient.idl) and [uiautomationclient.h](https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/uiautomationclient.h) upstream in mingw-w64 based on Microsoft's version of the IDL file. The files are indeed outdated in mingw-w64 at the moment. The Microsoft file is located at `C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\um\UIAutomationCore.idl` on my machine. It seems we can then generate the `.h` file from the `.idl` file using [widl](https://www.winehq.org/docs/widl). I can take that part unless you would like to give it a try.

The short-term fix is to use a `#ifdef __MINGW32__`. We can use it to comment out the faulty code in mingw builds assuming it is OK to not have this feature in Tor. Or we can use it as the guard condition under which we want to manually define the missing constants. It's up to you to choose what's most appropriate. Then when we update to a more recent version of mingw-w64 we will be able to remove that `#ifdef` if we went for the long-term fix. But please make sure to implement a short-term fix anyway so that we can have the mingw builds back.

(In reply to James Teh [:Jamie] from comment #2)
> I'm not sure what the correct course of action here is. It seems there are missing constants in the headers being used here. I guess we can conditionally define them, but that seems pretty ugly.

Hi [:Jamie], the long-term fix for this situation (if we think it's useful) is to update [uiautomationclient.idl](https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/uiautomationclient.idl) and [uiautomationclient.h](https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/uiautomationclient.h) upstream in mingw-w64 based on Microsoft's version of the IDL file. The files are indeed outdated in mingw-w64 at the moment. The Microsoft file is located at `C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\um\UIAutomationCore.idl` on my machine. It seems we can then generate the `.h` file from the `.idl` file using [widl](https://www.winehq.org/docs/widl). I can take that part unless you would like to give it a try.

The short-term fix is to use a `#ifdef __MINGW32__`. We can use it to comment out the faulty code in mingw builds assuming it is OK to not have this feature in Tor. Or we can use it as the guard condition under which we want to manually define the missing constants. It's up to you to choose what's most appropriate. Then when we update to a more recent version of mingw-w64 we will be able to remove that `#ifdef` if we went for the long-term fix. But please make sure to implement a short-term fix anyway so that we can have the mingw builds back.

(In reply to James Teh [:Jamie] from comment #2)
> I'm not sure what the correct course of action here is. It seems there are missing constants in the headers being used here. I guess we can conditionally define them, but that seems pretty ugly.

Hi [:Jamie], if we think it's useful the long-term fix for this situation is to update [uiautomationclient.idl](https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/uiautomationclient.idl) and [uiautomationclient.h](https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/uiautomationclient.h) upstream in mingw-w64 based on Microsoft's version of the IDL file. The files are indeed outdated in mingw-w64 at the moment. The Microsoft file is located at `C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\um\UIAutomationCore.idl` on my machine. It seems we can then generate the `.h` file from the `.idl` file using [widl](https://www.winehq.org/docs/widl). I can take that part unless you would like to give it a try.

The short-term fix is to use a `#ifdef __MINGW32__`. We can use it to comment out the faulty code in mingw builds assuming it is OK to not have this feature in Tor. Or we can use it as the guard condition under which we want to manually define the missing constants. It's up to you to choose what's most appropriate. Then when we update to a more recent version of mingw-w64 we will be able to remove that `#ifdef` if we went for the long-term fix. But please make sure to implement a short-term fix anyway so that we can have the mingw builds back.

(In reply to James Teh [:Jamie] from comment #2)
> I'm not sure what the correct course of action here is. It seems there are missing constants in the headers being used here. I guess we can conditionally define them, but that seems pretty ugly.

Hi [:Jamie], if we think it's useful the long-term fix for this situation is to update [uiautomationclient.idl](https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/uiautomationclient.idl) and [uiautomationclient.h](https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/uiautomationclient.h) upstream in mingw-w64 based on Microsoft's version of the IDL file. The files are indeed outdated in mingw-w64 at the moment. The Microsoft file is located at `C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\um\UIAutomationCore.idl` on my machine. It seems we can then generate the `.h` file from the `.idl` file using [widl](https://www.winehq.org/docs/widl). I can take that part unless you would like to give it a try.

The short-term fix is to use a `#ifdef __MINGW32__` block. We can use it to comment out the faulty code in mingw builds assuming it is OK to not have this feature in Tor. Or we can use it as the guard condition under which we want to manually define the missing constants. It's up to you to choose what's most appropriate. Then when we update to a more recent version of mingw-w64 we will be able to remove that `#ifdef` if we went for the long-term fix. But please make sure to implement a short-term fix anyway so that we can have the mingw builds back.

(In reply to James Teh [:Jamie] from comment #2)
> I'm not sure what the correct course of action here is. It seems there are missing constants in the headers being used here. I guess we can conditionally define them, but that seems pretty ugly.

Hi [:Jamie], if we think it's useful the long-term fix for this situation is to update [uiautomationclient.idl](https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/uiautomationclient.idl) and [uiautomationclient.h](https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/uiautomationclient.h) upstream in mingw-w64 based on Microsoft's version of the IDL file. The files are indeed outdated in mingw-w64 at the moment. The Microsoft file is located at `C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\um\UIAutomationClient.idl` on my machine. It seems we can then generate the `.h` file from the `.idl` file using [widl](https://www.winehq.org/docs/widl). I can take that part unless you would like to give it a try.

The short-term fix is to use a `#ifdef __MINGW32__` block. We can use it to comment out the faulty code in mingw builds assuming it is OK to not have this feature in Tor. Or we can use it as the guard condition under which we want to manually define the missing constants. It's up to you to choose what's most appropriate. Then when we update to a more recent version of mingw-w64 we will be able to remove that `#ifdef` if we went for the long-term fix. But please make sure to implement a short-term fix anyway so that we can have the mingw builds back.