Windows 10: How to get the latest DPI of System with win32 API.

tushar gupta1 · Jun 28, 2022

Hi I went through the documentation for GetDeviceCaps;In my C++ application , for which DPI_AWARENESS is per monitor, I want to get the latest DPI.Let us say, I launch my application, that time System DPI was 96, post that I modified system dpi to 120.GetDeviceCapsGetDC , LOGPIXELSX => it's returning 96 not 120.Let us say, I launch my application, that time System DPI was 120 , post that I modified system dpi to 144.GetDeviceCapsGetDC , LOGPIXELSX => it's returning 120 in that case , not 144.So what I observed is the dpi i.e. coming is the DPI when I launched the exe,

:)

Brink · Jun 28, 2022

Microsoft filling in divide between Win32 apps and new Windows APIs

Many new and sought-after Windows APIs and features such as BackgroundTasks, Notifications, LiveTiles, Share and more, are either not available or not easily callable from non-packaged Win32 applications. This is due to the programming model for UWP APIs that integrate with the system and have a dependency on the following concepts:

Identity – The need for package or application identity to identify the caller, and an identifier to scope data and resources.

Registration – The need for configuration of machine state during application deployment, which is required by the API and indexed by the package or application identity.

For packaged applications, Identity declared in the Appxmanifest.xml, and Registration is handled by the MSIX deployment pipeline based on the information in the AppxManifest.xml. This allows a simplified calling pattern for UWP APIs where the application code just uses an API. Compare this to a typical Win32 API that requires a register-use-unregister pattern for managing a callback.

We’ve heard your feedback, and in response we’re filling in the divide between Win32 apps and new Windows APIs & features so that you can take advantage of these new APIs & features and enhance your applications. As of Windows Build 10.0.19000.0 we’re introducing the following new AppModel concepts to provide your Win32 app with deeper integration into the OS:

Sparse Package registration
Signed MSIX packages can be installed on Windows today but all content referenced in the package’s Appxmanifest.xml must be present inside the package. A ‘Sparse’ Package contains an AppxManifest.xml but unlike a regular/full package, the manifest can reference files outside its package in a predetermined ‘external location’. This allows applications that are not yet able to adopt complete MSIX packaging to gain Identity, configure state (Registration) as required by UWP APIs and then take advantage of these APIs.

Package ‘External Location’
To support a Sparse Package, a package definition now has a new <allowExternalContent> element. This is what allows your package AppxManifest.xml to reference content outside its package, in a specific location on disk. For example, if your existing Win32 app installs content in C:\Program Files\MyWin32App\ , you can create a Sparse Package that declares the <allowExternalContent> element and during app installation or first run of your app, you can register the Sparse Package and declare C:\Program Files\MyWin32App\ as the external location your app will be using. This way you can continue deploying all your other app artifacts in the locations you do today while taking advantage of the Sparse Package.

Win32 type RuntimeBehavior
To help with compatibility of your existing Win32 app when using a Sparse Package, the app can register to have its application process be run like a non-packaged Win32 app as much as possible. This differs from a fully packaged Win32 app in that it is not subject to filesystem + registry virtualization, lifetime management by the system and other runtime attributes of fully packaged applications. The main runtime similarity between such an app and a fully packaged app is the presence of app/package identity in the running process.

Activation via CreateProcess
The activation path for UWP applications today ensures the app has PackageIdentity in its process token. This is used by UWP APIs to identify the caller and refer to later – either to perform a callback or to look up state that was configured during deployment. Because of this requirement, calling CreateProcess() on a UWP exe will fail as the CreateProcess() pipeline was not enlightened about Identity. In order to support Sparse Packages with an External Location, we leverage the classic Win32 application.manifest to provide Identity in CreateProcess() scenarios.

At their core, these features are about providing a foundation for non-packaged Win32 processes to use our latest APIs and features.

*Please note that these are still new and somewhat advanced development features that do not yet have full Visual Studio integration i.e. there are still some gaps in the end to end authoring experience such as having to create a Sparse Package outside of Visual Studio...
Click to expand...

Read more: Identity, Registration and Activation of Non-packaged Win32 Apps - Windows Developer Blog

Tweet

— Twitter API (@user) View on Twitter
Click to expand...

Neil Siegried · Jun 28, 2022

Win32 API Center Window

Hi. I've been trying to use the WIN32 API to Center the Active Window. I'm using Visual Basic and
http://www.pivoke.net to get the WIN32 calls. I've been reading an article at

https://www.codeproject.com/tips/250672/centerwindow-in-win32 but I just can't figure it out. Help please.

Brink · Jun 28, 2022

Microsoft Making Win32 APIs More Accessible to More Languages

Introduction

Win32 APIs provide powerful functionality that let you get the most out of Windows in your applications. While these APIs are readily accessible to C and C++ developers, other languages like C# and Rust require wrappers or bindings in order to access these APIs. In C#, this is commonly known as platform invoking or P/Invoke.

Historically this has required developers to handcraft the wrappers or bindings, which is error prone and doesn’t scale to broad API coverage. In recent years, given the strong demand for calling Win32 APIs from various languages, several community projects have spawned to provide more strongly typed and idiomatic representations of these wrappers and bindings to provide an improved developer experience and spare developers the overhead of creating them themselves. Some notable projects include PInvoke for .NET and winapi-rs for Rust.

The main challenge with these projects is they are manually maintained, which makes broad and sustained API coverage difficult and costly, and their work doesn’t really benefit other languages.

As owners of the Windows SDK, we wanted to see where we could provide unique value here, take some of the burden off of the community, and make achieving broad and sustainable API coverage across languages a reality.

The result of this is our win32metadata project and corresponding Win32 language projections now in preview on GitHub!

Win32 Metadata

The goal of the win32metadata project is to provide a complete description of the Win32 API surface in metadata so that it can be projected to any language in an automated way, improving correctness and minimizing maintenance overhead. The output of this project is effectively an ECMA-335 compliant Windows metadata file (winmd) published to Nuget.org containing metadata describing the entire Win32 API surface.

Win32 APIs have existed for a long time, so accurately describing all of them will take some iteration. We will be developing this tooling in the open and welcome community contributions to ensure an accurate representation of the Win32 API surface that will benefit all languages.

For this metadata to enable developers to call Win32 APIs idiomatically from the language of their choice, we need language projections built on top of it. The first such language projection is #/Win32.

C#/Win32

Built in partnership with Andrew Arnott, the owner of the PInvoke project for .NET, C#/Win32 parses the metadata and generates the P/Invoke wrappers required to call the APIs you care about.

Simply add a reference to the Microsoft.Windows.CsWin32 package from NuGet.org and add a file called NativeMethods.txt to the root of your project with a list of Win32 functions you want to call. The file can contain one function per line or even wildcards like BCrypt.* for including entire modules. Once populated, C#/Win32 will generate the P/Invoke wrappers for the functions you request and all of their dependencies.

[IMG width="750px"]https://blogs.windows.com/wp-content/uploads/prod/sites/3/2021/01/CsWin32.gif[/IMG]

You can see in the animation above, after adding CreateFile to NativeMethods.txt and a using statement for the Microsoft.Windows.Sdk namespace, CreateFile can be called via the PInvoke static class. C#/Win32 provides rich Intellisense, strong types for parameters, and also includes the relevant documentation from docs.microsoft.com, all dynamically generated from metadata based on the APIs you request! No additional dependencies are required, broad API coverage is achieved with improved correctness and minimal maintenance overhead, and the APIs are expressed idiomatically as C# developers would expect.

You can learn more about C#/Win32 and try it for yourself by visiting the repo.

C#/Win32 is just an early example of what’s possible with dynamically created projections of Win32 APIs. We envision projections like this for many languages, all expressing Win32 APIs in whatever idiomatic patterns developers of the language expect. The windows Rust crate is another example.

Rust

The Rust language projection follows in the tradition established by C++/WinRT of building language projections for Windows using standard languages and compilers, providing a natural and idiomatic way for Rust developers to call Windows APIs. The windows crate lets you call any Windows API using code generated on the fly directly from the metadata, enabling you to call the APIs as if they were just another Rust module. It does not attempt to partition Windows APIs by technology, instead providing a single way to call any Windows API regardless of the underlying technology. You can seamlessly make use of APIs based on C-style exports, COM interfaces, or WinRT types.

Other Languages

In addition to C# and Rust, we are also working on a Modern C++ projection in the open on GitHub and welcome community contributions there. These projects are early previews and under active development so are subject to change significantly as we absorb feedback and make progress. We will work with the community to support other languages based on demand, partnering with existing community projects where appropriate.

Under the umbrella of the win32metadata project, we hope to advocate a set of principles that all language projections should follow for the best developer experience while providing flexibility for each projection to do what’s best for their community.

Conclusion

Making Win32 APIs more accessible to more languages will allow developers to make the most out of Windows regardless of their preferred language. We are excited to engage with the community to expand API coverage and language support and minimize the maintenance overhead of existing projects.

You can view our roadmap, FAQs, and other useful details in our repo.
Click to expand...

Source: https://blogs.windows.com/windowsdev...ore-languages/

Windows 10: How to get the latest DPI of System with win32 API.

How to get the latest DPI of System with win32 API.

How to get the latest DPI of System with win32 API.

How to get the latest DPI of System with win32 API.

How to get the latest DPI of System with win32 API. - Similar Threads - latest DPI System

How to get rid of "Win32/CoinMiner.I" malware

How to calibrate monitor colors using Win32 API on Lenovo IdeaPad 3

How to calibrate monitor colors using Win32 API on Lenovo IdeaPad 3

How to calibrate monitor colors using Win32 API on Lenovo IdeaPad 3

How to get the latest DPI of System with win32 API.

How to get the latest DPI of System with win32 API.

Microsoft Making Win32 APIs More Accessible to More Languages

[Win32 API] Resizing a borderless window?

How to get started with windows 10 APIs?