-
Notifications
You must be signed in to change notification settings - Fork 2.8k
UWP doesn't allow reading regkeys #594
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
Conversation
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed (or fixed any issues), please reply here with What to do if you already signed the CLAIndividual signers
Corporate signers
ℹ️ Googlers: Go here for more info. |
Unfortunately, UWP also doesn't offer an API for returning nominal processor frequency at this moment. Other options would require apps depending on abseil-cpp to be packaged with extra manifest data or libraries for bridging platforms. This change pushes the unsupported APIs accessing the registry behind a define guard. This define guard makes GetNominalCPUFrequency to compile and run as usual on desktop, but it will return the value 1.0 on UWP Apps (Store).
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
…lding for UWP or Desktop.
I will run this through our internal testing system. |
Hi guys, I have another issue: [1]. https://docs.microsoft.com/en-us/windows/win32/api/dbghelp/nf-dbghelp-symfromaddr
[3]. #10301 |
@JackBoosY The purpose of this PR is to fix the abseil build used by WebRTC for UWP. WINAPI_PARTITION_PKG_WER is not the right way to gate code based on UWP/Desktop partitions. Feel free to file another bug and post a different PR to fix SOURCE/absl/debugging/symbolize_win32.inc. |
@LoadLibrary Okay, but I'm not sure my changes is correct. |
-- 2c5c118f0615ba90e48ee2f18eccc9f511740f6d by Samuel Benzaquen <[email protected]>: Rename internal macros to follow the convention in absl. PiperOrigin-RevId: 299906738 -- 92d84a707c7ebc4ec19bdd92d5765d1b6d218c1e by Derek Mauro <[email protected]>: Import GitHub #629: Skip the .exe suffix in the helpshort filter on Windows PiperOrigin-RevId: 299892396 -- 2a6910d4be6c67a8376628764121b528ff53504d by Abseil Team <[email protected]>: Use unsigned int128 intrinsic when available. It generates better branchless code. PiperOrigin-RevId: 299848585 -- 110c16cf0a739e1df5028fb6fbd03ef5dde1d278 by Derek Mauro <[email protected]>: Import GitHub #594: Avoid reading the registry for Windows UWP apps PiperOrigin-RevId: 299821671 -- d8397d367e88163e5e8a47f379c716352dc91d03 by Greg Falcon <[email protected]>: Add absl::Hash support for Cord. The hash function is heterogeneous with other string types: a Cord and a string with the same byte sequence will hash to the same value. SwissTable types know about Cord, and will allow heterogeneous lookup (e.g., you can pass a Cord to flat_hash_map<string, T>::find(), and vice versa.) Add a missing dependency to the cmake Cord target. PiperOrigin-RevId: 299443713 GitOrigin-RevId: 2c5c118f0615ba90e48ee2f18eccc9f511740f6d Change-Id: I7b087c7984b0cb52c4b337d49266c467b98ebdf9
* UWP doesn't allow reading regkeys. Unfortunately, UWP also doesn't offer an API for returning nominal processor frequency at this moment. Other options would require apps depending on abseil-cpp to be packaged with extra manifest data or libraries for bridging platforms. This change pushes the unsupported APIs accessing the registry behind a define guard. This define guard makes GetNominalCPUFrequency to compile and run as usual on desktop, but it will return the value 1.0 on UWP Apps (Store). * Using WINAPI_FAMILY_PARTITION family of macros for detecting when building for UWP or Desktop. * Simplifying comment to please the lint tool.
-- 2c5c118f0615ba90e48ee2f18eccc9f511740f6d by Samuel Benzaquen <[email protected]>: Rename internal macros to follow the convention in absl. PiperOrigin-RevId: 299906738 -- 92d84a707c7ebc4ec19bdd92d5765d1b6d218c1e by Derek Mauro <[email protected]>: Import GitHub abseil#629: Skip the .exe suffix in the helpshort filter on Windows PiperOrigin-RevId: 299892396 -- 2a6910d4be6c67a8376628764121b528ff53504d by Abseil Team <[email protected]>: Use unsigned int128 intrinsic when available. It generates better branchless code. PiperOrigin-RevId: 299848585 -- 110c16cf0a739e1df5028fb6fbd03ef5dde1d278 by Derek Mauro <[email protected]>: Import GitHub abseil#594: Avoid reading the registry for Windows UWP apps PiperOrigin-RevId: 299821671 -- d8397d367e88163e5e8a47f379c716352dc91d03 by Greg Falcon <[email protected]>: Add absl::Hash support for Cord. The hash function is heterogeneous with other string types: a Cord and a string with the same byte sequence will hash to the same value. SwissTable types know about Cord, and will allow heterogeneous lookup (e.g., you can pass a Cord to flat_hash_map<string, T>::find(), and vice versa.) Add a missing dependency to the cmake Cord target. PiperOrigin-RevId: 299443713 GitOrigin-RevId: 2c5c118f0615ba90e48ee2f18eccc9f511740f6d Change-Id: I7b087c7984b0cb52c4b337d49266c467b98ebdf9
UWP doesn't allow reading regkeys. Unfortunately, UWP also doesn't offer an API for returning nominal processor frequency at this moment. Other options would require apps depending on abseil-cpp to be packaged with extra manifest data or libraries for bridging platforms.
This change pushes the unsupported APIs accessing the registry behind a define guard. This define guard makes GetNominalCPUFrequency to compile and run as usual on desktop, but it will return the value 1.0 on UWP Apps (Store).
Fixes: #593