Develop Reference

Detecting programmatically whether a specific UWP app is installed on system

Without going through Windows Registry, is there a quicker way to detect programmatically whether a specific Universal Windows Platform (UWP) app is installed on a system? App will be installed through Windows Apps Store and its installation need to be verified from a Winform program written in C#. But the language doesn't matter.

You should be able to use PackageManager.FindPackage or PackageManager.FindPackageForUser to see if the target package is available universally or for the specific or current user.
See Calling Windows 10 APIs From a Desktop Application for info on how to call this from your WinForms app.
Also check out the Enumerate app packages by user SID sample which demonstrates enumerating app packages from a C# console app. The project used is out of date (it's for VS2013), but the overall code flow should still work.
Depending on your specific scenario (why do you need to know this and what will you do with that information?) there may be better ways for your specific use case. For example: you asked elsewhere about launching a UWP app. If you define and launch a protocol for the app you don't need to check if it's already there first as the protocol launch will offer to look for the app in the store if it's not installed.

Inter-app communication between WinRT/Windows Store apps that meets the store requirements?

Is there a way for apps running on WinRT to share information? I know about WinRT's sandboxing and the reasons behind it, but is there some mechanism for two apps created by the same author to share information or pass data between each other? A global property bag, or existing inter-app push notification or messaging scheme? I already use the Share contract mechanism for other tasks but that involves invoking the Share charm and I just want to pass a simple text message between two WinRT apps I authored. Perhaps a shared storage area restricted to apps with the same publisher ID?
I found the following related posts but none of them provide a Windows Store requirements compatible solution:
Communication between Windows Store app and native desktop application
How can a Metro app in Windows 8 communicate with a backend desktop app on the same machine?
Inter application communication in WinRT

You could use protocol activation to pass short strings between apps. Also you could point both apps at a file and use it to store shared data, but you'd need user input to be able to access the file. The good thing is though - if you'd store the file in say your OneDrive folder - your file would get automatically backed up and synced between devices. Since we are there - you could use the OneDrive SDK.

Check if picture password is activated in Windows 8

I need to write a script that verifies that the user is not using the "Picture Password" feature in Windows 8. I'm using .NET 4.
I tried to search for info about it, but couldn't find anything. Do you have any clue how it can be done?

my company information securiy forbids using picture password when using other specific product (can`t give more info). I need to enforce this request by code.
You don't enforce these kinds of things with code, you enforce them with Group Policies.
To do so, open the Group Policy editor (gpedit.msc) and navigate to the following path:
Computer Configuration\Administrative Templates\System\Logon
Double-click the "Turn off picture password sign-in" setting, and set either the "Enabled" or "Disabled" option.
Of course, you don't have to do this on each local machine. You can create Group Policies that apply network-wide to specific groups of users. Ask on Server Fault to get more help on setting that up, or talk to your network administrator. Presumably if you have information security policies, you already have a department that handles these sorts of things.

I see that you have Windows-RT as a keyword on the question. So if the application needs to do the checking is a Windows 8 Store app (Modern/Metro app), you will not be able to achieve this.
There is no API to check for this in 8, and as far as I know there isn't one in 8.1 either.
There is no access to the registry for Store apps.
Even if you did manage a way to detect the settings via some other method, you need to ensure it's done through the Windows 8 API otherwise you won't pass certification (section 3.1).
You can however push the policy via GPO if that's an option.
Based on Windows 8 RT being removed from keywords, that means it's not a Windows 8 Store app. Leaving prior answer in case someone finds this and is asking about Store apps.
You should be able to review the setting via the registry at "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System" and checking the value of either BlockDomainPicturePassword or AllowDomainPicturePassword.
I don't know why there is two, I'll leave the testing to you as to which one is the right one.

In-App purchases for Desktop applications

I need to accept in-app purchases from within my desktop application and was wondering if the new Windows 8 API allows thein-app purchasing to be used with Desktop apps aswell as Modern UI apps? (http://msdn.microsoft.com/en-us/library/windows/apps/hh465433.aspx). I have read the docs and it doesn't say that you can't use it in Desktop apps, but there is also no documentation for it for desktop apps and all I have seen online are questions about whether it can be used in desktop apps but no real definitive answers.
This isn't purely a purchasing option. It's more about how I would need to implement this for a Desktop application if it can even be done to begin with.
Aside from that: Are there any in-app purchasing frameworks/SDK's that you could recommend if the one from Microsoft is not an option?

Update:
An article here will outline how you can submit a desktop application to the store. Unfortunately how this works is when the user downloads a Desktop Application from the store, it will load a Metro style portion and then navigate them away from the store to download. The Store will handle said transaction and compensate you accordingly based on the acquisition.
As part of the submission process, you must supply a purchase page URL
for your app. This URL is a link that sends the user directly to the
page where a customer can acquire your app with the fewest clicks
possible. This is a great feature for customers; if you provide them
with a clean and easy way to acquire your app, you’re already making a
great impression by giving them a simple and clear acquisition
experience.
When you submit a desktop app, you must supply a purchase URL for
32-bit and 64-bit systems. This URL can be the same for both.
During the app submission process, we request that you supply a URL
for users who need the x86 version of an app and one for those who
need the x64 version. For Release Preview, both URL fields are
required, and should correspond to the version of Windows that a user
is running. If the acquisition page is the same for both, we recommend
that you use the same URL in both fields. The Windows Store detects
whether a user is running the x86 or x64 version of Windows, and users
can only see apps that correspond to this version.
Essentially Microsoft will only be handling the commerce of your application; all other aspects will be handled outside of the store. The only aspect that Microsoft will directly handle is the initial commerce, with In-App purchases you might be able to have the commerce portion handled, but you'll still need to provide the information to be handled outside of the store.
Also, the current outline for a said feature in desktop applications really hasn't been covered any the documentation, perhaps as 8.1 approaches more details will be announced.

Restrict access to audio device under Windows XP-8 to specific application/user

I have written an c# 4.0 application that analyses the microphone input and records DTMF tones that represent credit card numbers entered by our clients. This all works well, but since we are working under PCI Compliance (see www.pcisecuritystandards.org), we don't want to allow the logged in user (call centre staff) to listen or even record the microphone input so that they then can parse the credit card numbers on their own with a 3rd party app or their phones. So the question I have is:
How can I restrict the microphone input to a specific application so
that it can't be heard or recorded somewhere else?
If there is no solution to this, the 2nd question arises:
How can I restrict the microphone input to a specific user so that it
can't be heard or recorded somewhere else (I could run the software
as a Windows service under specific user credentials)?
Kind regards,
JB

The main way to restrict access to device is setting of Security Descriptor on the device. So granting of the permission for specific user group is the way in which you should go.
The exact implementation for Windows XP could be different from later versions of Windows. Windows 8 have new possibilities too. Audio Mixer APIs can be used in Windows XP. Starting with Vista Windows Multimedia Device (MMDevice) API can be used. MMDevice API's implementation of the property store. You can use IPropertyStore::SetValue and IPropertyStore::Commit to change properties. Unified Device Property Model are introduced starting with Windows Vista. There are different Windows API which uses internally SetupAPI to access to devices and to set it's properties (see here). I think that you should set PKEY_Device_SecuritySDS property to secure device. One can use old APIs like SetupDiSetDeviceRegistryProperty and SetupDiSetClassRegistryProperty to set the properties on Windows XP (see here).
If I start on my computer devmgmt.msc and examine default property of microphone device then I can see Security Descriptor
What you need is to change it so that only specific user groups (or users) access it.
There are PKEY_Device_SecuritySDS and PKEY_Device_Security properties which can be change by SetupDiSetDeviceProperty and SPDRP_SECURITY_SDS or SPDRP_SECURITY (see here). Usage of SDS parameters (PKEY_Device_SecuritySDS or SPDRP_SECURITY_SDS) could be easier because there use readable Security Descriptor Definition Language (SDDL).
After you change security descriptor on the device you need use SetupDiSetClassInstallParams and SetupDiCallClassInstaller with DIF_PROPERTYCHANGE and DICS_PROPCHANGE to reset the device. You can find the code example in the source code of devcon utility on WinDDK. Alternatively you can use CM_Disable_DevNode and CM_Enable_DevNode to restart it with new properties.

You should be able to do it with the Core Audio API. For each playback device and capture device in the system, you can control whether the device can be used in exclusive mode.
One drawback - there is no support for Core Audio API under Windows XP.

I think the solution to your problem is to write a KS Filter
Create a Kernel Streaming filter that is able to decode the DTMF on demand of your application and send the decoded data to your application. When the filter is in DTMF decoding mode, it just outputs silence to the rest of the filter stack.
If an USB audio device is used, you could also write a GFX Filter instead, which can be configured on a per-user-base. But this only seems to work for 32-bit operating systems. WinDDK has a sample called gfxswap.xp.

You can use ASIO audio drivers in your application.
ASIO is a technology developed by Steinberg to provide low latency audio input and output, and as a side effect, requiring a device using an ASIO driver completely restricts the device use to the process that required it, in addition to multiple other advantages that may be irrelevant to your needs.
It is available for every soundcard thanks to the ASIO4ALL project, so compatibility won't be an issue as long as you provide it with your application
For more informations, check out the wikipedia article about ASIO here, or pick up the SDK here ( you will need to register a Steinberg Developer account to proceed )

Will it be helpful if you can control (MUTE) the VOLUME of the sound device and set it back to it's former state once you are done? You can look at this link for ideas. Good luck.