Develop Reference

A local server that allows mobile users to download and install apps... is such a thing even possible?

We will soon have a respectable pool of apps available for our company's employees, we have both flavors: iOs and Android. Those apps have tremendous value for our production and sales teams but are worthless outside the company.
My boss is asking me to develop a server program from which our local mobile users can discover, download and install those apps quick and easy, very much like the App Store and Play Store, but everything inside our local network. I'm not sure if this software is even possible...
Are App Store and Play Store the only possible sources of mobile apps?... If so, which alternatives do I have for this project? If not, please point me in the right direction.

You may want to look into the Enterprise program for iOS:
https://developer.apple.com/programs/ios/enterprise/
Another alternative is signing and sideloading with using MacBuildServer. See these for more information:
http://ios.wonderhowto.com/how-to/sideload-install-open-source-ios-apps-your-iphone-using-macbuildserver-without-jailbreaking-0147456/
Side loading iPhone apps to device without certificate

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.

How can a Metro app in Windows 8 communicate with a backend desktop app on the same machine?

In a situation where you have the UI frontend built using the new Metro style of apps for windows 8, and would like it to communicate with a .NET application running on the desktop on the same local machine (e.g. a windows service app).
What forms of interprocess communication are available between the metro app and the desktop app?
Thanks to Pavel Minaev of the Visual Studio team, who has provided some initial info here in a comment, quoted:
According to Martyn Lovell, there isn't any deliberate mechanism for
that, and some that could be used for it are intentionally restricted.
Named pipes aren't there, for example, nor are memory mapped files.
There are sockets (including server sockets), but when connecting to
localhost, you can only connect to the same app. You could use normal
files in one of the shared "known folders" (Documents, Pictures etc),
but that is a fairly crude hack that necessitates polling and is
visible to the user. -- Pavel Minaev commenting on this issue
So failing normal approaches I was thinking of using web services or reading/writing to a database in order to get some form of communication happening, both of which seem like overkill when the processes are running on the same machine.
Is what I'm attempting here making sense? I can see a need for a metro app to be the frontend UI for an existing service which is running on the desktop. Or is it better to just use WPF for the frontend UI running on the desktop (i.e. a non-metro app).

I'm porting my existing project to Win8 right now. It consists of windows service and tray application which are talking to each other via NamedPipes WCF. As you may already know Metro doesn't support named pipes. I ended up using TcpBinding for full duplex connection.
This post describes what functionality is supported.
Sample of my WCF server that Metro client can consume is here.
Also keep in mind that you can't use synchronous WCF in Metro. You'll have to use Task-based wrapper which is only asynchronous.
And thank you for you question. I was good starting point for me :)

There were a number of questions like this at the end of a //build/ session I attended. Aleš Holeček, the exec who did one of the big picture sessions, came up out of the audience to handle them. Even if you're not a C++ developer, download that session and watch the Q & A. http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C
Metro apps can't count on desktop apps or services being installed on the machine. And desktop apps can't count on Metro apps running since they can be suspended any time. You need to start thinking differently. Listen to Aleš on this one.

Take note that with Windows 8.1 Update, communication between Windows Store apps and desktop components written in C# for .NET 4.5+ is now officially supported for side-loaded applications in Enterprise scenarios:
Brokered Windows Runtime Components for side-loaded Windows Store apps
To quote:
Recognizing that critical business functions and rules are embodied in existing software assets and that enterprises have a wide variety of scenarios for which the new application style will be highly productive, the Windows 8.1 Update includes a new feature called Brokered Windows Runtime Components for side-loaded applications. We use the term IPC (inter-process communication) to describe the ability to run existing desktop software assets in one process (desktop component) while interacting with this code in a Windows Store app. This is a familiar model to enterprise developers as data base applications and applications utilizing NT Services in Windows share a similar multi-process architecture.
Although implementing this approach is a bit on the complicated side initially, it allows for deep integration across Windows Store and desktop components. Just keep in mind that for the time being, it won't pass public Windows Store certification.

There is an article on InfoQ about how to build loosely coupled Metro apps with protocol handlers. This is something which has been supported by Windows for a long time and one could foresee an desktop application register itself as a protocol handler and maybe the metro application can communicate through this mechanism.
I have no idea if this is possible, but it might be interesting to check out.

Christophe Nasarre has blogged about a rather hacky way to do it using local files. The result is communication between desktop app/windows store app (referred to as DA/WSA in the blog), without having to switch between the UI of the two apps. He also blogged about another less hacky technique involving protocol handlers.
Note that having a WSA which communicates with a DA is explicitly forbidden by the store App certification requirements
Windows Store apps must not communicate with local desktop applications or services via local mechanisms, including via files and registry keys.
... but it restricts "local mechanisms" only. So I guess one can build a web service for routing the communications.

If you think that you can make an additional manual cmd operation,
you can try :
X:/> CheckNetIsolation.exe LoopbackExempt –a –n=<packageID>;
CheckNetIsolation.exe is included in winRT install, so there is nothing extra to be installed.
I tried it: it works, even after package updating.
As shown on: http://msdn.microsoft.com/en-us/library/windows/apps/Hh780593.aspx
Here it is explained how to find out the packageID for your app: http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/82bad7d4-d52b-4731-a396-13ab9004c1cc/how-to-get-the-appid-of-a-metro-style-app-

It is possible to communicate on the same machine from Metro app to desktop app using local service.
I've implemented some time ago simple "proof of concept", how to bypass the WinRT sandbox using local service. It still needs some kind of "social engineering" or direct guide for installing the service, but anyway, it is possible.
I'm not sure though about the certification rules about "local service" communication when adding such app to Windows Store.
Sample here
By design Metro application cannot access underlying PC directly, only using WinRT API and available capabilities. But when you create back-end service for accessing the PC and all data there, it's basically no longer running in sandbox.
The only "problem" is that user must manually install this back-end service, but that won't be a problem using some "social engineering":
User downloads "PC browser" Metro app, user can browse all pictures, music and videos, using WinRT API, but the app also shows message at the bottom:
"Download our PC browser powerpack and browse your entire PC, for FREE"
User is redirected to web page, from where user can download classic desktop installer containing "PC browser" back-end service for accessing files on users entire PC. Once this desktop service is installed, the Metro app can detect it and use it for browsing the entire PC. User is happy, but the WinRT sandbox is compromised.
Of course this won't work on Windows 8 ARM tablets. Using this workaround it could be even possible to build Metro app clients for classic desktop apps like antiviruses, torrent/P2P clients, etc.

Maybe I missed the point but when activating the Private networks capability I can connect to a local running (http) server using the local IP address (not localhost). This enables my scenario where a winrt app communicates with a wpf desktop app

Windows Mobile - Notify/Restrict Application Install/UnInstall

I am using .NET CF 2.0 with C#.
I need to create Policy enforcement application, which restricts backlisted application installation on windows mobile devices. How can I get notification for new application installation with an option to close the installation. I also need to get notification when someone uninstalls my application with an option to close the uninstall process.

Policy enforcement on Windows Mobile can be tricky. I'd recommend not trying to do this yourself if possible.
I've had success with the SPB Kiosk Engine in the past and found it much simpler than locking down the device yourself. Previoulsy I've only been able to lock down specific devices with software from the device manufacturers.
To detect installation of other apps you would need to create an app/service to monitor installed applications.
There isn't a way to detect/prevent uninstallation without use of another proces to monitor this. Even then I'd expect it to be VERY tricky.