Microsoft talks about more API device support for Windows 8.1

In June at BUILD 2013, Microsoft announced that it will be adding native support for 3D printers in Windows 8.1. As it turns out, that's just part of the improvements Microsoft is making for the OS update in terms of adding more support for external hardware devices.

In a new blog post, Microsoft states that Windows 8.1 will add device support for more scanning and Point of Sale products. More importantly, the company is introducing what it calls device protocol APIs that will allow any Windows 8 app to "talk" to a device using standard protocols such as USB, Bluetooth, WiFi Direct and more.

Microsoft states:

As a developer, all you need to do is simply identify the device (leveraging metadata) and then open a communication channel to the device. Opening a channel prompts for user consent. This is a critical step to help prevent apps from accidentally or maliciously communicating with one or more devices without the user’s awareness. Once access is granted, the app can communicate with a device, including starting long data transfers, which can continue even if the user swipes to another app.

Microsoft say adding access for Windows 8 apps to devices via device protocol APIs will allow developers to create custom apps for controlling their devices without the need for them to also make custom drivers. Microsoft went on to add that even a high school student will be able to make an app that controls a hardware add-on for a science project, thanks to the device protocol API model.

Source: Microsoft | Image via Microsoft

Report a problem with article
Previous Story

Google chief likes to ogle - women that is

Next Story

UK web traffic for porn higher than for all social networks combined

30 Comments

Commenting is disabled on this article.

Windows 8.1 should have been released instead of 8 at first place. Just like wp8 should have been for wp7. I don't know when microsoft will abandon this pre mature release mode. There was dramatically less controversies and ignorance from people if they would have done it.

You basically saw a company panicking because they didn't have a real answer to either the iPhone or iPad. Something was whipped up last-minute so they at least had something on the store shelves with a Windows logo on it.

I don't think it was "whipped up at the last minute" - it had a full three years from the release of 7.

However it was released at least a year short of where it needed to be development-wise, with a lot of really quite crucial functionality missing, including gaps like the PC settings/Control Panel confusion.

The problem they have now is that even if Windows 8.1 and beyond remedy most of the issues with the original release, the Windows 8.x brand may be irrevocably tarnished. They may need to re-launch the brand with a new name as with Vista -.> 7 (7 is really only a relatively minor update to Vista but it fixed the main problems and reset the brand - I doubt it would have sold so well as Windows Vista R2).

I really don't have issues with Windows 8, yes it lacks some stuff, it comes with stuff I don't want/use.
But hey, that's the case for every Windows release, or even every OS release in history.
It works perfectly fine as a desktop OS, so why would I have to stick around with Win7 for 1+ more year, while I could be using Win8, which I prefer.

This is one of the most important things about Windows 8.1.

With Windows 8.0, device support in WinRT was cumbersome at best, pushing developers to use workarounds to access devices. Traditional desktop applications had access to the older user mode drivers and direct access via a few generic interfaces; however, WinRT/Modern Apps couldn't easily touch devices, requiring a lot of extra work to implement if it needed to deal with hardware. (In a way WinRT on Windows 8 was like NT 3.1 days all over, with very few device driver interfaces available for the newer Win32 API sets.)

The brilliant part of what Microsoft is doing with Windows 8.1, is that instead of just offering access to the same old driver mechanisms available to desktop applications, they have created a new and very rich set of device APIs that can be MFR specific, protocol specific, or even completely generic allowing App developers to access hardware that no concept of a driver exists.

Basically Microsoft is giving WinRT developers access to a new 'paradigm' of device APIs that are richer in features while also being safer and more stable. (They aren't compromising NT or WinRT security to offer this new level of hardware access.)

This opens the flood gates for hobbyists, engineers, and developers to create a new generation of Apps, that go beyond what was possible for traditional desktop applications.

Instead of 'Modern' Apps holding a device developer back, it now will be a preferred platform over the desktop and is now several generations ahead of other OS device driver offerings in both the mobile and desktop world.

I'm glad to see this is finally getting some press, as this is a cornerstone to the success of WinRT/Modern Apps by easily offering features to developers not found anywhere else.

So apps won't be utterly crippled when it comes to accessing hardware devices, ok.

Doesn't change the down outlook on Win RT, Win phone/tablet, or the metro ecosystem in general.

Also "rich" looks like the buzzword of the thread.

startscreennope said,
So apps won't be utterly crippled when it comes to accessing hardware devices, ok.

Doesn't change the down outlook on Win RT, Win phone/tablet, or the metro ecosystem in general.

Also "rich" looks like the buzzword of the thread.

1) Statistically, the trend is up on WinRT and WP8 development, so if you are seeing a 'down outlook' you are not following the numbers.

2) Next time I promise to use something like effulgent so you don't assume I'm being sheepish.

In just the last couple of months WP8 has seen a large number of major App releases filling in the few remaining holes in the WP8 ecosystem. Windows 8 Apps are still catching up to fill in holes, and create a new ecosystem with the duality of Windows 8 running on tablets and desktop.

Windows RT (ARM) tablets already have advantages over iOS and Android in out of the box driver support through existed ported drivers for printers and devices.

This new model will allow developers to work with devices that do not have a driver and support devices outside of Microsoft's efforts, which is important to the ARM (RT) based tablets.

This new driver model being offered to 'Modern/WinRT' Apps at a basic level is 'architecture agnostic', so Apps on x86, x64, and ARM will become more equal with regard to device support. (Vendors can still code architecture specific drivers and expand on the functionality as well.)

So look forward to an effulgent range of Apps supporting hardware directly.

Moving up from 2% to 4% marketshare is not "an up look". Those numbers are still abysmal and MS is still losing a ton of money.

Oh, they went from 4% to 5% marketshare but wrote off $900,000 in unsold surface tablets, that's surely an "up look", right? Bleeding for every %, I suppose.

startscreennope said,
Moving up from 2% to 4% marketshare is not "an up look". Those numbers are still abysmal and MS is still losing a ton of money.

Oh, they went from 4% to 5% marketshare but wrote off $900,000 in unsold surface tablets, that's surely an "up look", right? Bleeding for every %, I suppose.

Surface RT is one hardware product, as RT based devices are doing ok overall.

Additionally, are you purposely trying to separate WP8 and W8 developer interest gains?

If Microsoft actually cared about science projects, they'd make it possible to access a serial port from Modern apps for use with things like the Arduino and countless other bits and pieces.

Would that still not be the point of all this? The ability to write for it? I'm not sure (and I can't find the answer online or by going through my own connection topology) but does the Netduino not use a similar connection protocol? USB to Serial? Because MS used a Netduino as a device example for "Independent developers" in their source article

Looks exactly like a Netduino Plus V1

Under innovative devices, that looks like a LEGO MindStorms V2, what protocols did that use for PC to device communication?

EDIT: All this of course assuming that the pictures mean things

According to Wikipedia, the RCX is programmable from 64bit Windows via a serial port only, as the USB stack seemingly only works in a native 32bit OS. There is a 3rd party interface that allows device programming of the RCX using VisualBasic, and this gets deployed via a COM+ protocol

So again, if pictures mean things (lets hope they do), it might be possible that these changes will allow for what you want. I'll have to look into the documentation of the APIs when that becomes available

Edited by Sraf, Jul 29 2013, 5:00am :

Thanks for your effort. I've looked at a number of Microsoft's presentations and it's all very high-level superficial stuff. There are far more questions than answers.

Just found that I was reading about the RCX, which was the V1 Mindstorms brain, and the pick is of an NXT. NXT uses USB, but I didn't get anything more than that

Okay, I'm watching the "Apps for USB Devices" video, and it looks like so long as the physical transport layer is USB, you can have any communication protocol underneath it (a given example was serial over USB, IRDA, and even "Vendor Specific (custom)")

The full list is on MSDN, I'm going to see if it is in a public area

EDIT: http://msdn.microsoft.com/en-u...ws/apps/bg182882.aspx#three

CDC control class (class code: 0x02; subclass code: any; protocol code: any)
Physical class (class code: 0x05; subclass code: any; protocol code: any)
PersonalHealthcare class (class code: 0x0f; subclass code: 0x00; protocol code: 0x00)
ActiveSync class (class code: 0xef; subclass code: 0x01; protocol code: 0x01)
PalmSync class (class code: 0xef; subclass code: 0x01; protocol code: 0x02)
DeviceFirmwareUpdate class (class code: 0xfe; subclass code: 0x01; protocol code: 0x01)
IrDA class (class code: 0; subclass code: 0x02; protocol code: 0x00)
Measurement class (class code: 0xfe; subclass code: 0x03; protocol code: any)
Vendor-specific class (class code: 0xff; subclass code: any; protocol code: any)

Edited by Sraf, Jul 29 2013, 6:23am :

BattleDaggit said,
If Microsoft actually cared about science projects, they'd make it possible to access a serial port from Modern apps for use with things like the Arduino and countless other bits and pieces.

I think Microsoft is trying to push things forward. Quite a lot of machines don't even have serial ports these days, but they do have USB, Wi-fi, Bluetooth, etc.

The Metro UX would make for a great POS service. Really would love to see the end of XP embedded junk in favor of a rich Metro POS UX.

Dot Matrix said,
The Metro UX would make for a great POS service. Really would love to see the end of XP embedded junk in favor of a rich Metro POS UX.

For once I agree with you, xp is still used in a lot of supermarket and atm computers in the UK and some of them are very unresponsive and poorly calibrated.

startscreennope said,
Metro looks like a fisher price toy vomited all over a monitor, and controls about as well.

Exactly the same thing people said about XP.