none
Windows 8 Serial Port Support

    Question

  • Will Windows 8 support the Serial Port, managed code and Metro apps like it has in the past?  Meaning, will we still be able to do something like below to communicate with a USB/Virtual COM that uses serial data (e.g. COM1, 9600, etc. )?

    SerialPort spTest = new SerialPort("COM1");

    Hope so.... this is a biggie for us.  Thanks

    Sunday, September 18, 2011 2:48 PM

Answers

  • in a classic app, you have everything you had before. for a new metro app, there is a different API set you can call
    d -- This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, September 20, 2011 5:12 PM
    Owner
  • Can you point to any ARM tablet (Win8 or not) which has a physical serial port?

    On "normal" desktop machines, Win8 supports real or simulated serial ports just like Win7. I believe with sufficient effort we can bridge serial ports to the metro stuff, whether or not MS wants us to do so - but why? All normal Windows (non-metro) programs will work as is.

    OTOH, devices connected to USB will have a USB driver on Win8 side, so new Win8 apps will use the new interface model. Having  scores of "COMnn" ports and remembering which of them is your GPS and which a BT modem, never has been fun.

    -- pa

     

    Sunday, June 24, 2012 4:02 PM
  • these are internal UARTs on a SOC, they are not exposed as serial ports to applications. Hid class over i2c is still HID, sensor fusion is a way to create a virtual sensor out of many physical sensors (and sensors are not exposed as COM ports either)


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, June 26, 2012 3:50 AM
    Owner
  • This isn’t a scenario we targeted.  The option of last resort – is you write a custom driver, which isn’t an option for everyone, and even then it can only be accessed by one privileged app declared in device metadata.   A desktop app may be a better answer.

    Best Wishes - Eric

    Monday, September 24, 2012 10:53 PM
    Moderator
  • correct. you can't write the custom driver on Windows RT. for x86/x64 based systems, you need a specific device instance on which you can isntall your driver package and custom metadata.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, September 25, 2012 5:56 AM
    Owner
  • for your scenario, I would suggest using an intel SOC system which can still run a desktop app


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, September 28, 2012 7:09 PM
    Owner

All replies

  • i don't think there is an ABI that exposes serial port communication in win8
    d -- This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, September 19, 2011 4:24 PM
    Owner
  • Too bad, just like the Windows Phone... this will be a major decision for my company while deciding to update our apps to this OS then.  Hopefully others will get the word out to get this support in new Metro-style apps.

    Thanks

    Tuesday, September 20, 2011 12:09 AM
  • i think nearly all machines running metro style apps won't even have a physical serial port.
    d -- This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, September 20, 2011 7:25 AM
    Owner
  • They probably won't have a physical DB9 port, but should have USB ports and could use as a virtual COM port.
    Tuesday, September 20, 2011 11:51 AM
  • Wait, what? The .Net Framework v4's SerialPort class is unsupported on win8?

    I don't think you meant that. And If your platform has a serial port and it has Win8 installed I'm pretty sure the serial port will work just as it always has worked.


    Mark Roddy Windows Driver and OS consultant www.hollistech.com

    Tuesday, September 20, 2011 12:28 PM
    Moderator
  • This is only based on what I saw at the BUILD conference and blogs over the last week.  Here is what I know...

    Desktop apps will still support the full .NET framework, so File.IO and SerialPort will still work.

    The new Metro-style apps is a "sandbox" and will not have certain access to things ( at least without the new contracts ). eg. File.IO, sockets, etc.

    I'm wanting to know if the SerialPort class ( or something similar ) will be available in the new Metro ( WinRT ) apps?  If it is not supported, will there be something else that allows us to read/write to serial devices?

    It appears there is a new driver model to make things easier to connect to devices, but vendors will have to develop new interfaces for this.  I hope that Microsoft ( and community ) can deliver something consistent for serial communications.

    Tuesday, September 20, 2011 2:20 PM
  • in a classic app, you have everything you had before. for a new metro app, there is a different API set you can call
    d -- This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, September 20, 2011 5:12 PM
    Owner
  • you should not be communicating with a usb device as a virtual com port. use more native USB abstractions (Which also are not projected into a metro app either unless it is WPD or storage most likely)
    d -- This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, September 20, 2011 5:12 PM
    Owner
  • If it doesnt support USB CDC class serial port access - too bad will stick with current tools
    Thursday, June 21, 2012 7:50 AM
  • Rubbish -obviously you have no embedded development experience or appreciation of that market -the CDC class is 'native'.

    Sort yourself out microsoft and dont quote Doron on subjects you obvously know nothing about!!!
    Thursday, June 21, 2012 8:12 AM
  • you should not be communicating with a usb device as a virtual com port. use more native USB abstractions (Which also are not projected into a metro app either unless it is WPD or storage most likely)
    d -- This posting is provided "AS IS" with no warranties, and confers no rights.
    you seem to think that one is able to control both sides (app developer on the Host side and a fixed situation of a virtual COM port on the device side).  There are plenty of existing devices that can only communicate via the USB Virtual COM Port.
    Friday, June 22, 2012 9:37 PM
  • when you have a choice, using serial to talk to a usb device is usually one of the worst paths to go down. unnecessary abstraction.  if you have no choice, you have no choice.  if you want to talk to a serial port in a metro app, that is not going to work.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, June 22, 2012 10:33 PM
    Owner
  •  There are plenty of existing devices that can only communicate via the USB Virtual COM Port.

    So is this really a big problem? Just ignore that Metro stuff and use the same applications, almost in same way as they work today on Win7.

    This covers all machines compatible with Win7.  For ARM tablets... no idea.

    --pa

    Friday, June 22, 2012 11:25 PM
  • Since we don't have a serial solution on Win8 or WP7/8, my company is forced to stay on Win7 and PocketPC.  There is nothing wrong with using WPF and is great to use for these types of apps.  I do believe, if MS is saying WinRT is the future, they should have a solution for this platform.  I'm just trying to found out what support the new WinRT will have for serial communications.  There are ( and will be ) many devices that use serial communications for years to come and this should be a MUST to have in WinRT.  I really like the ease of use of the SerialPort Class and would like for it to be ported and included out-of-box in WinRT.  If not the SerialPort Class, it would be nice to have something!

    Hope MS is listening on this feature.

    Saturday, June 23, 2012 5:12 PM
  • Can you point to any ARM tablet (Win8 or not) which has a physical serial port?

    On "normal" desktop machines, Win8 supports real or simulated serial ports just like Win7. I believe with sufficient effort we can bridge serial ports to the metro stuff, whether or not MS wants us to do so - but why? All normal Windows (non-metro) programs will work as is.

    OTOH, devices connected to USB will have a USB driver on Win8 side, so new Win8 apps will use the new interface model. Having  scores of "COMnn" ports and remembering which of them is your GPS and which a BT modem, never has been fun.

    -- pa

     

    Sunday, June 24, 2012 4:02 PM
  • Who said it had to be a physical serial port? And who said it had to be on ARM?

    I can think of lots of applications that can be used without serial interfacing when unavailable, and can be augmented with extra functionality when the serial device is available.

    There are many devices that incorporate the Bluetooth Serial Port Profile. Let's just start with any regular GPS module. (Nearly) all GPS modules communicate through serial NMEA output.

    I know you could use the sensor API for generic GPS positioning data, but when using industry grade GPS receivers that's of no decent use: you'd want the raw data. And what about hardware to control? Barcode scanners, robotics, EEPROM flashing, even my iRobot robotic home vacuum cleaner supports a serial interface.

    Is there really no way to bypass this limitation? It would be a huge no-no for our company if serial support is abandoned. I'm not afraid of putting in some extra mileage when the overly simplyfied SerialPort class is depricated and I won't mind introducting low level handling myself. But serial access is really a necessity!

    Monday, June 25, 2012 7:09 AM
  • Could you remind again, is your product(s) software or hardware or both? Any other details to help us understand your requirements?

    -- pa

    Monday, June 25, 2012 11:53 AM
  • We have several needs to communicate with serial devices.  This includes WPF/WinForm apps using the SerialPort Class to communicate via the PC's serial ports ( either the physical 9-pin or a USB virtual COM dongle ).

    There are several different protocols we use to communicate serially with our products or other devices.  Example of this would be Modbus @ 9600 baud.

    I agree with @Joep, in that it is not a MUST to have the same SerialPort Class for WinRT and Metro-style apps.  However, it would be very nice as this is an easy-to-use API.  If the SerialPort Class can not be provided, then at least have a solution using the new HID Driver interface, etc..  I'm assuming companies like FTDI will provide this.  I just hope it will be around the time Win8 and WP8 RTM.

    Also, another thing to point out... Microsoft removed the SerialPort Class in Visual Studio 2003.  There was such a demand for this, so they added it back in VS 2005.  I hope MS will listen to our needs and add for their new platform, as well.

    Thanks 

    Monday, June 25, 2012 12:15 PM
  • As long as  your applications are not Metro, they are not affected at all. Just do the same as in Win7.

    --pa

    Monday, June 25, 2012 10:06 PM
  • Again, I realize that the desktop mode in Win8 will continue to support the SerialPort Class in .NET.  My questions/concerns are related specifically to WinRT... meaning, what will be the solution for connecting and communicating with serial devices ( including supported devices and the APIs to use ).

    I came across this Build 2011 session ( see link below ), but have not watch yet.  If you notice in the description it mentions UARTs.  I would like Microsoft to provide more documentation and examples on how to communicate using this new HID Class, Sensor Fusion ( or whatever it is ).  Again, I know Win8 has not even RTMed yet, but would be nice to know how this will work, who/what types of devices will be supported and possibly where to get started.

    http://channel9.msdn.com/events/BUILD/BUILD2011/HW-251T

    Thanks again.

    Monday, June 25, 2012 10:26 PM
  • these are internal UARTs on a SOC, they are not exposed as serial ports to applications. Hid class over i2c is still HID, sensor fusion is a way to create a virtual sensor out of many physical sensors (and sensors are not exposed as COM ports either)


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, June 26, 2012 3:50 AM
    Owner
  • @Doron

    No dis-respect Doron but you dont seem to know the embedded community and what/how the USB port is used for-

    Again state its a shame there is no CDC class support. 

    To enlighten yourself please check out an ARM website for USB -
    http://www.keil.com/rl-arm/rl-usb.asp

    The *** CDC class is the defacto standard *** for coms using a virtual serial port.  No actual serial port is required.  So any solution not involving a complete firmware re-write for Metro Apps and paying thousands for Windows driver???

    Thursday, August 02, 2012 6:04 PM
  • on the arm systems we are shipping, CDC support is not needed.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, August 02, 2012 6:57 PM
    Owner
  • Yes you still dont have a clue -

    Nothing to do with your ARM equipment - which would use an high-end A8/A9 etc. 

    This is the embedded market which ARM are just 1 manufacturer. Here's another microcontroller link using CDC  http://www.atmel.com/Images/doc8447.pdf.

    CDC is the best method for USB comms.

    Saturday, August 04, 2012 7:35 PM
  • Ok, so CDC is the best method to expose virtual serial ports.

    Now could you explain how virtual serial ports can be high priority for the Microsoft's ARM tablet, competitor of iPad and Android tablets?

    Do many iPad users badly lack virtual serial ports?

    Note that these tablets already have BT, various sensors, touch - all that without needing a virtual com port.

    -- pa

    Saturday, August 04, 2012 10:33 PM
  • Actually in my company's industry, the answer is yes... IPad and Android does badly lack this.  Even with BT, they do not have a good solution for the Serial Port Profile ( SPP ) for BT.

    I agree, in most cases with tablets... they won't be used for serial communications today.  In my industry ( where we communicate with many various serial embedded devices ), we will need this for both tablets and PCs.  If tablets and smartphones are the future... then yes... they will be required to have serial communications ( USB and/or BT ).

    The main reason I created this thread a year ago is because Microsoft is stating it is moving toward this new WinRT platform.  I understand there will still be the desktop mode ( at least for Win 8 ) and we will still be able to use the regular .NET SerialPort Class within that mode.  I'm simply asking what is the option Microsoft is providing on the new WinRT platform since it is the "future".  When I mentioned "virtual COM ports" I wasn't requesting that virtual COM ports were a must have, but instead saying serial communications was a must have regardless of the method provided.  I was asking how will developers will be able to send and receive serial data out of the USB and BT ports.

    Example in C#:

    TheNewWinRtPort port = new TheNewWinRtPort();

    port.Baud = 9600;

    port.Open();

    port.WriteBytes("hello world");   // Send bytes out of port.

    port.Close();

    I honestly believe that companies like FTDI will provide some type of new method to communicate serially ( I guess with the Sensor API ), but again I'm wanting to know what the direction is and how WinRT is going to provide this.  Is there a standard for this in WinRT?  Will this method be a standard between Intel and ARM?  Will this standard work the same serially from a standpoint of USB ports and BT ports?

    Don't get me wrong, I like WinRT and it will bring nice opportunities for me and my company... I just want a simple answer from Microsoft what this answer is.  Do we need to fill out a NDA?  If so, please send the info on how to get this information.

    Also, I attempted to contact the Sensor API group, but no response.

    One last note... I noticed on the BT profiles released for Win8 that it did not include the Serial Port Profile ( SPP ).

    Thanks again.


    • Edited by shaggygi Sunday, August 05, 2012 12:22 AM
    Sunday, August 05, 2012 12:18 AM
  • While you're waiting answers from FTDI and MS, please consider that Modbus is a very ancient protocol. Today you can buy (or even hack yourself) an Ethernet adapter for your Modbus devices, and just run them over network. It will be also much faster, because IIRC Modbus over the PC serial port requires kind of timing that Windows hardly can sustain at high baudrates.  I haven't checked recently if USB to Modbus (not raw serial!) adapters exist -  if not, you can again hack your own. Either LAN or USB is much faster and reliable than raw serial.

    -- pa

    Sunday, August 05, 2012 1:07 AM
  • @ Shaggyqi : Finally somebody with sense!! Good post.

                          I bet FTDI will produce a driver but thats an expensive way of doing things. Most microcontrollers supoort USB / CDC 

    @ Pavel : Yes obviously its not a priority to support CDC/virtual serial ports otherwise microsoft would have done it.

                   I think you are confused with RS232 serial & "Modbus"??? For short its call just 'Serial'

    My point is, its widely used on a PC/Mac/Linux. The code/firmware exists on both the microcontroller and computer - making its easy to develop USB based products.

    Since the the embedded market is unknown to some, I will give an example for my company's need:

    >>>> To display & store  car diagnostic signals - attaching a device which converts the 'cars' signals to USB. <<<<<

    When you work in certain fields ie web-designer, or desktop programmer, its sometimes not immediately apparent the other multitudes of uses a tablet/PC might have!!! This is 1, I could think of industrial, medical etc. where a company wants a generic USB standard.

    Have a nice day...

    Monday, August 06, 2012 12:40 PM
  • I was just looking into this as a way to connect an RFID reader to an ARM Win8 tablet for an embedded scenario.  It would be highly convenient to have a tablet-type device w/touchscreen instead of a full laptop as the "intelligence" behind a mobile timing system.  The RFID reader I currently work with (passive tags, very low cost per tag) uses a serial interface.  In the past working on an earlier version of this system I've used a C# library for serial port communication back before it was supported as part of .NET.  I would love to be able to use an ARM tablet as the intelligence behind it.

    From TI's site:

    "Each reader is accompanied with PC compatible software that allows the user to read and program tags. Serial communications RS232 or RS422/485 are required."

    I don't care about the PC software (I want to write my own) but the serial port is a must.  This is by far the best line of products from a hardware perspective for my task.  I don't want it to be a desktop app, but rather an immersive app that's touchscreen focused.  Is there any way to get this to work?  Even if it involves buying some sort of hardware converter that takes the serial port connector and outputs something that works with the sensor fusion stuff, that would be fine.

    FYI, in the past I've used a serial -> USB device to plug it into modern computers.  This has never been an issue for me.

    Even if I needed x86 that would be fine if there was a way to access it via the immersive environment and not the desktop.  I'd prefer something as cheap, light, and power-efficient as possible though so ARM seems like a good fit.

    Any thoughts on solving this problem? (on Windows 8)

    Tuesday, August 07, 2012 4:25 AM
  • If its a TI pre-built device with R232 then that pretty much limits you to a USB to serial converter and i believe x86 with the full version of Windows (non WinRT) 8 for now.  And I would test it well to ensure the device still communicates well with no timming issues with the original software.

    I bet the gap left by microsoft's CDC serial support will be filled by some 3rd party driver solution but until then we have to wait and see. Dare I say, but it may be worth considering an alternative platform in the future if your company is supplying the tablet & writing the software.

    Contact myself should you find you need to out-source your design - our website is

    http://www.obdsystems.com/services/page.html

    Good luck that sounds an interesting project, Steve.

    Tuesday, August 07, 2012 10:03 AM
  • the only 3rd party drivers for arm that can be written are by the OEM and its partners. there are no after market drivers you can install on a winrt tablet. also, to create a winrt tablet, you must work directly with Microsoft for the entire process. so that means while TI has a bunch of parts you may want to use, you can't create an off the shelf product with them without first working with us.  X86 is a different story.


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, August 07, 2012 8:06 PM
    Owner
  • We are the 'OEM' ? We are the guys who build the device to connect to the tablet.

    Ok driver by a 3rd party company specializing in USB driver development such as jungo.

    http://msdn.microsoft.com/en-us/library/windows/hardware/hh833785

    Metro style device app development - whole section on USB. CDC 'is' missing lols of course. Heavy reading but quite possible -

    Its my job to use a 'bunch of parts' :)
    Few late nights ahead...

    Tuesday, August 07, 2012 9:56 PM
  • This is a big concern for us as well, we currently develop software for Android tablets and the iPad since both of them provide a Bluetooth serial link (Apple's might not be referred to as the serial port protocol - but that is what their external accessory protocol is really).

    We need to access the embedded controllers through a Bluetooth serial stream - from your screen name I suspect that we're in similar industries "OBDSystems.com"! Microsoft are unfortunately missing out here, I would far rather develop for Windows/Windows RT than the other platforms but since they have the support for serial over Bluetooth then that is what we will have to work with.

    Tuesday, September 18, 2012 8:39 AM
  • Until we find consensus on whether or not serial communications is the way to go:

    Could someone at Microsoft elaborate on what our options are? The fact is that we require communications with bluetooth devices which only support SPP protocols. There is no way we can change that, not even the OEM can, since the devices already exist and cannot be updated for what communications are concerned.

    In our line of business we are talking about devices in the price range of a decent SUV, some of them a multiple of that. So replacing 20 of them overnight is not an option. That's why I won't mind putting extra effort in to write custom drivers or something like that. But I would need a pointer in the right direction.

    I know about driver certification and signing etc. But one step at a time: this is for now only to be used in our internal environment, so running in test mode wouldn't be an immediate problem. And we could take it from there if needed and proven successful...

    Thursday, September 20, 2012 8:57 AM
  • Thursday, September 20, 2012 7:59 PM
  • -> Metro and hardware forum.

    -- pa

    How is that helpful? That's just another thread about this lack of functionality that also doen't give any useful info.
    Monday, September 24, 2012 8:20 AM
  • Just trying to keep this thread up, in hope that Doron and other MS folks are reading. The more they are aware of real usage cases, the better.

    As we all know, some time ago MS & PC ecosystem rulers declared the serial port obsolete and started phasing it out. But they can reconsider / redesign the serial support,  if there's a real need (= real money).

    -- pa


    • Edited by Pavel A Monday, September 24, 2012 9:38 AM
    Monday, September 24, 2012 9:38 AM
  • This isn’t a scenario we targeted.  The option of last resort – is you write a custom driver, which isn’t an option for everyone, and even then it can only be accessed by one privileged app declared in device metadata.   A desktop app may be a better answer.

    Best Wishes - Eric

    Monday, September 24, 2012 10:53 PM
    Moderator
  • Hi Eric,

    Writing a custom driver is not so hard (imagine a tool that creates all the metadata stuff based on OEM binary). The real issue is that WinRT will not allow users to _install_ any custom drivers, correct?

    -- pa

    Tuesday, September 25, 2012 1:12 AM
  • correct. you can't write the custom driver on Windows RT. for x86/x64 based systems, you need a specific device instance on which you can isntall your driver package and custom metadata.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, September 25, 2012 5:56 AM
    Owner
  • Does this mean that no hardware company can create a software solution for WinRT for pre-existing hardware if it doesn't use any of the standard contracts that Microsoft implemented? That's odd...

    Whether or not a desktop app is better depends on the intended use. Our systems are designed to be used out in the field - truely mobile. We want our devices as portable as feasable, and x86 systems supporting desktop apps will never be that portable. It's insane to require heavier (both physical and financial) hardware when the lighter hardware has all the required capabilites, but it's OS just lacks the ability to expose it...

    The fact that tablets of competitors don't support SPP is not an argument to not support it on WinRT. The lack of support with other vendors was one of the main reasons to stick with Windows for this application.

    Sandboxing applications is a great concept for regular use, but if the end-user really really really wants to allow a specific app to break out of the box it should be possible somehow. Especially in corporate environments. If it is allowed to bypass the Store by side loading applications by the domain administrators, you would expect these domain administrators to be able to lower the gates for specific applications somehow.


    Friday, September 28, 2012 8:11 AM
  • for your scenario, I would suggest using an intel SOC system which can still run a desktop app


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, September 28, 2012 7:09 PM
    Owner
  • So what's the point? Windows - including Win8 - is, and always has been, very friendly to "makers". Most of cross toolchains happily run on Windows. Toolkits for Android, ARM, JTAG and so on.

    The real enablers for "makers" are companies that specialize in interface solutions, such as FTDI. They provide complete solution on the host side (drivers, API libs) so that "makers" don't have to bother.

    Windows *RT* is locked down, but this is apparently what it is made for. So just don't use it for developer work. There are plenty of other Win7 and Win8 machines.

    -- pa

    Wednesday, October 31, 2012 4:13 PM
  • Has there been any update on this?

    I have several very expensive data acquisition devices (spectrophotometers, colorimeters etc) that I would love to write Metro tablet apps for. Not having any support for Serial protocols over USB or BT seems absolutely ridiculous to me. Like others have pointed out in the Maker Blog this is not about having a physical serial port on a device - it's about supporting a protocol that is used by a myriad of embedded applications in engineering, educational, medical, military and many other fields.

    I really don't understand what Microsoft is thinking here. Making it a lower priority (as compared to other popular features on modern tablet devices) is ok, but not giving it any consideration at all, and without providing any reasonable alternatives is very disappointing.

    Sunday, January 20, 2013 4:56 AM
  • For an x86 or x64 tablet, you can write a driver and use metadata to bind it to your modern app.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Sunday, January 20, 2013 5:10 AM
    Owner
  • I have been reading through the Device Access API / Custom Driver Access Samples on MSDN all evening. Is that the proposed solution you are referring to? From what I understood, this approach will not work on WinRT, because no device driver installations are permitted, or is that not the case?

    I found this article: http://social.msdn.microsoft.com/Forums/en-US/tailoringappsfordevices/thread/6bdaa46f-fa49-4854-a97b-81b003ef3495?prof=required

    I'm not fully clear on whether this also applies to Metro tablet apps, but assuming that it does, it still means that each application would have to supply its own driver. Also, given that older devices are no longer supported by the manufacturers, and device documentation is generally not available and requires reverse engineering, it will be nearly impossible to make this work in any reasonable amount of time.


    • Edited by gmpreussner Sunday, January 20, 2013 5:37 AM
    Sunday, January 20, 2013 5:17 AM
  • Correct , my approach doesn't work on windows rt. That is why I mentioned x86 and x64. You could create a proxy root enumerated driver which just forwards Io to the real device. Not too complicated and it lets you reuse all of the existing drivers. The proxy driver can be umdf so all if your development could be in user mode.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Sunday, January 20, 2013 5:48 AM
    Owner
  • Would such approach still pass WACK and Store Certification?

    I'm currently looking into a solution using an IP-based service which can run on an external system for the Store App to consume. I assume that would pass certification for sure, right? It's just a web-interface on an arbitrary system.

    But what would happen if the end user decided to install that service on his local system and enables the local loopback (intended for testing only)? I can't control what my end users do to their local system. If they like to disable the lookback restriction manually, i'm not going to stop them...

    Or would configurability of the web-service address violate store certification and is a fixed service address required?

    Monday, January 21, 2013 3:30 PM
  • I don't know the specifics to your scenario.  the scenario I proposed should pass the WACK if you use the modern brokered interfaces to talk to open a handle to the virtual device and used them to send IOCTLs to the driver.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, January 21, 2013 7:15 PM
    Owner
  • Hello,

    just my two cents on this discussion which I followed for some time. Fully understand the need to have serial communication working on Windows 8 for industrial devices, for sure.

    Here is what I see may happen if you really want to have Windows 8 device and get it working with your industrial equipment over serial link

    Windows 8 on x86 or X64 platform

    ---------------------------------

    comes with traditional COM1: type device driver and your application can access it in traditional API way (CreateFile() etc.). In addition for notebooks without serial hardware a usb-to-serial adapters are available and their manufacturer provides device drivers, digitally signed, which you can install on Windows 8, thus getting almost exactly the same case as on Windows 7

    Windows 8 on ARM platform

    -----------------------------

    comes without traditional COM1: device driver. It does have internal SoC type UARTs which do have device drivers but those are not accessible to applications. Common usb-to-serial adapters either don't have drivers for ARM or Windows RT won't let you install those.

    Workaround ? Let's say you are in a need to make this happen. Lot's money are on the table as the cost of losing your equipment to work is huge. Then you contact tablet manufacturer, say Nvidia, and make them to produce small number of custom versions of Windows RT tablets for you. In those special industrial-geared tablets Nvidia will work with FTDI and Microsoft to allow incorporation of usb-to-serial drivers in Windows rt so that you can get your communication to equipment working over serial on Windows rt. It is possible I am sure but the effort to make this happen may be non reasonable.

    Hope this helps


    • Edited by SergeiR [MCTS] Tuesday, January 22, 2013 6:04 PM typo corrected
    Tuesday, January 22, 2013 5:59 PM
  • Magnificently still missing the point entirely.

    We want to develop Store Apps that can use a serial interface, either via USB or Bluetooth. It doesn't have to be ARM per se.

    These drivers are readily available for the x86/x64 platform, but for reasons nobody can explain or understand, these drivers cannot be addressed from within the Store App sandbox. Reasons mentioned so far are mostly incorrect.

    For example the fact that an App shouldn't be dependent of external hardware. If that was true, even OneNote shouldn't be in the store, since it depends on my physical stylus. And the app could (if well designed) be usable without the hardware too, but also use hardware when available.

    Another reason that's mentioned is the fact that Apps could suspend and resume, and the hardware shouldn't depend on the App. True too, but that's true for any app using the camera too. And again: if well designed that's no problem again. Skype is still useful if you don't have a cam, and the cam can be used without Skype too...

    Contacting a tablet manufacturer wouldn't help at all - and would be out of scope for nearly everyone. Even more, there is no way nVidia can help me with my serial over Bluetooth connection.

    What we need is a legitimate workaround for a horrible limitation. Either be able to use such drivers that already exist and work on the desktop, or get a legitimate way to contact a desktop service that can work as a message broker. Of course only with the users consent.

    • Edited by Joep Beusenberg Tuesday, January 22, 2013 6:34 PM linebreaks went missing
    Tuesday, January 22, 2013 6:29 PM
  • But can you tell, why you want your apps to be Metro? Is it just matter of fashion or a genuine business/process need?

    On a normal Win8 (not RT), normal desktop apps can use touch, the stylus and look "immersive". There is a lot of ways to sell desktop apps.

    Please note that serial devices likely will keep the system permanently powered so the power saving won't be as advertised. For those who hoped RT is much more secure  the recent pack of patches showed that is false (not a surprise).

    (Or well, go ahead, make store apps for ARM tablets, serial hw and industrial use. But it won't be the Microsoft's store.)

    -- pa


    Tuesday, January 22, 2013 9:13 PM
  • We want our apps to be genuine full screen 'Modern UI' Apps to enable our end users to use 'Modern UI' Apps.

    I know it sounds stupid, but it's actually true. We want the simple App-type user experience. The end user should know about his work process, not his pc/tablet. That's what the 'Modern UI' is all about: less chrome, more content.

    Our people work out in the field in any outdoor condition possible (sub-zero this week, hot in the summer, dusty on construction sites, being shaken on an off-shore oil rig). In these conditions, they want their device be as portable as possible - 10" or 11" is perfect - and they want to be able to control their tablet with one hand with ease, having frozen and smudgy fingers - no pixel perfect stylus tapping possible. Metro or 'Modern UI' is perfect for that. Full screen experience, no task bar, no using a stylus to exactly tap on the tiny buttons, etc. But still having a decent device that enables them to use e-mail, domain specific software, etc.

    We are currently developing the app as a desktop app that mimics the RT-style. Full-screen, app-bar-like buttonstrips. Multi-touch mapping control. But we keep having to build workaround over workaround. For example: when a user enters or leaves a text box, we want the on-screen keyboard to appear and disappear. That happens automagically in RT, but not in the desktop. I know there are means to show the KB, but you can't make it disappear or make it adapt to it's context (url entry, number entry, address entry). When a file dialog is invoked, the file name textbox is highlighted, but no keyboard appears. And the user can't invoke it, because we hid the taskbar. And if we invoke it in advance and the user closes it, he can't get it back.

    When scrolling in 'Modern UI', the content in the scrollviewer will nudge further and dog-ear back as expected. In desktop mode however, the whole window gets nudged. With a lot of (hardly documented) work that can be overriden, but even then for some reason the taskbar appears over the application. Only to disappear on release.

    When an application overlays full screen, the user can still swipe from the right to get to the RT start menu, but there is no intuitive way to return to the desktop. When the desktop is selected, the app reappears.

    That said, we want our app to be available on ARM RT tablets too. We know the serial comms are out of the window (no pun intended) on ARM, but nevertheless it's a useful app stand-alone too. When ran on x86 - on slighty heavier hardware - the same software can be extended to use external sensors and controllers.

    I've tried, but it's really impossible to cross-develop an app in both WinRT and WPF. The languages are the same, but the framework is just too different.

    Last but not least, there's performance. WinRT is greatly overhauled for perfomance. And they did a good job too. Windows.UI.Xaml has much less features, but for the good of perfomance. But most of the improvements do not apply to WPF...

     
    Tuesday, January 22, 2013 9:43 PM
  • Hi All,

    I originally posted this thread over a year ago as I was really excited about the new platform ( WinRT ) and was curious in what the solution Microsoft was going to provide for serial communications. I'm thankful for all the feedback and support ( good and bad ) and hope developers continue to request this to be added to WinRT in the future.

    I also want to say, that I'm a Microsoft faithful and believe in .NET and their products... including the new WinRT. I will not rant or threaten to leave to go to another platform as some have suggested because this feature is not available today. However, I'm very disappointed as I tried to explain as much as possible what my needs are and I've attempted to contact Microsoft in various ways to provide them with my use-cases. I understand serial communications ( a.k.a SerialPort Class ) is still available using the desktop mode and that is what my company is restricted to using when customers ask for applications that communicate with serial devices. I also have to recommend other platforms as they support this... but it is usually my last options.

    As I stated in my earlier threads, I have no problem using the desktop mode to create a WPF app to perform serial communications. My question was based on a couple of things.

    1.) If Microsoft is wanting developers to create apps using their new "killer" platform, then there needs to be a solution to allow us to communicate serially. I don't care if it is a physical DB-9 port or a USB port. There needs to be a solution similar to the SerialPort Class for .NET and should be something that is consistant between platforms ( ARM, x84, 64, etc. ) and work across the various related devices hardware vendors create ( FTDI, Cypress, etc. ).

    2.) I keep hearing that WinRT is the future and the desktop is going away. I understand the desktop will be here for years to come, but again... we need a solution using technology that is going to replace the desktop.

    I've seen people post questions on why we could not use an alternative to the serial port ( DB-9 or USB ). In my industry ( building automation ), there is several legacy devices that will need to be supported for years to come. If there is a device that can be a substitute ( IP/Serial Port ) that uses a trivial API and easy to setup with WinRT... please let me know. I don't believe that should be the solution, especially since there will be many device form factors and most will include USB ports that could provide a method of reading and writing data serially.

    I've contacted FTDI and they stated they are not able to provide a dongle ( and APIs ) based on WinRT due to the limitations Microsoft has on the new platform. This may be a "public answer" for now as they could possibly be working on something. Until then... that is what FTDI is claiming and that is sad, sad news :(

    I've also watched videos based on driver development and peripheral makers and it appears somewhat confusing. They stated that if you create a device and drivers to run on WinRT, then your WinRT application would have to include a reference id or similar before publishing to the store. This approach seems a little odd as I could not use a generic serial dongle ( like one provided by FTDI today ) to use between different apps that perform serial communications. I might be misunderstanding this concept, but I read this in more than one place related to this restriction.

    I hope that Microsoft is listening to these types of requests from concerned customers/developers. I've had patience on this topic as we still have alternatives today and WinRT is at revision 1. This concerned developer is just asking for a little bit of information on what the story is going to be for the future ( WinRT that is ).

    Thanks for reading this far.

    Wednesday, January 23, 2013 12:06 AM
  • I've contacted FTDI and they stated they are not able to provide a dongle ( and APIs ) based on WinRT due to the limitations Microsoft has on the new platform. This may be a "public answer" for now as they could possibly be working on something. Until then... that is what FTDI is claiming and that is sad, sad news

    +1. especially, as they ship Android oriented products for quite a while.

    It was the election day today - hope you've made a good choice ;)  Pragmatic developers vote for flexibility and openness.

    -- pa

    Wednesday, January 23, 2013 1:01 AM
  • We want it Metro because we want to support the consumer with whatever device they have. Yes, it is easy to do it with x86 hardware. All it takes is a $5 USB to RS232 converter. Unfortunately, x86 devices are considerably more expensive than RT devices. Also, RT devices have a considerably longer battery life. I am looking at a system where we need an 8 hour battery life in the field w/ no AC power available.

    Because we could not use the serial port, we have an ugly kludge. Instead of a USB converter, we have been forced to use a $50 WiFi to serial converter and communicate using UDP. All to send signals less then 3 feet. The code is complicated. Communications are subject to EFI. It is harder for the user to configure their system. Also, while they are using their tablet to control our hardware, they cannot talk to the Internet! (I admit that they often will not have WiFi connectivity anyways.)

    I have yet to see any rational reason why the serial port is not supported. Why do you say that they "will keep the system permanently powered"? It is no more likely to keep the system powered than any other HID interface. When I use USB/RS232 adapters on existing x86 systems, it does not prevent them from sleeping or powering off. Why is it more secure? I would think that talking over a wire is infinitely more secure that using WiFi.

    Embedded systems and microcontrollers almost always have a serial interface. By stripping support for SerialIO from WindowsRT, Microsoft is cutting themselves off from a potentially lucrative market. My client was looking at OEMing WinRT tablets to go with their hardware. Without the serial port and the resulting kludge, that is no longer an option.

    Thursday, April 25, 2013 4:59 AM
  • I've tried, but it's really impossible to cross-develop an app in both WinRT and WPF. The languages are the same, but the framework is just too different.

    Last but not least, there's performance. WinRT is greatly overhauled for perfomance. And they did a good job too. Windows.UI.Xaml has much less features, but for the good of perfomance. But most of the improvements do not apply to WPF...

     
    I agree completely! I, too, have tried to write applications for both WinRT and WPF. Why they couldn't make the framework the same is beyond me. They rewrote everything several times over, why couldn't they do it right? (Did anyone else try writing WinRT apps using Visual Studio 2010, VS2012 consumer preview, VS2012 Release Candidate, and finally VS2012 RTM? You had to throw out your old code and start over with each new version.)
    Thursday, April 25, 2013 5:16 AM
  • For this very reason, since they could not make a simple, elegant solution using a WinRT device, my client now has teams working on iOS, MacOS, and Android solutions for their control interface. A year ago when we started this project, the other OS's were not in the picture.

    Thursday, April 25, 2013 5:20 AM
  • I'm now finding there isn't any System.IO.Ports namespace, and with some further digging (this forum now included) it appears as though it's been left out on purpose? This is rather mind boggling as, although many of the actual "COM Ports" aren't included as hardware on our PC's, the communication is still essential. As "legacy" as the serial port may be, we use it frequently in the robotics field. I'm an Electromechanical Engineer by day, and "hobby robotisist" in the evenings. In the industrial automation field, most of our Allen Bradley hardware (both PLC's and our HMI's), weld controllers, and servo drives, still rely on COM Ports. This is also the case regarding my own robots' microcontrollers & CNC machines I use to create the structures. I don't know, but IMHO this move really cuts out a chunk of market potential... as well as limits future innovations whose dubbed "dated hardware" would benefit greatly form the allowance of these resources on the software development side.
    Saturday, May 04, 2013 7:41 PM
  • Thought I would share some news I came across for Windows Blue.  I hope this is true.  If so, it should fix what I've been asking for on this thread.

    "Finally, Angel says that Windows 8.1 will support "any" USB or IO device.

    "One of the big limitations of Win8 WinRT apps is their lack of ability to interact with connected and built-in devices unless previously exposed by WinRT," Angel writes. "It seems that’s about to change in Windows 8.1 with the introduction of the new Windows.Devices.Usb and Windows.Devices.Custom namespaces.  Both of these namespace provide IOutputStream and IInputStream to any USB or IO device. It’s fair to assume it’ll be heavily gated by permissions, but it’s still a great feature that opens up new avenues for Win8.1 apps." "

    • Proposed as answer by Dave Robinson Monday, July 07, 2014 2:45 PM
    Sunday, May 26, 2013 11:59 AM
  • Rumors and gossip... nothing serious. Here is the link, by the way.

    -- pa

    Sunday, May 26, 2013 3:45 PM
  • I agree, but hope is all we have for now.  We shall see at Build 2013.  Justin Angel is usually close to what is expected.   Here is the original post...  http://www.justinangel.net/Win81APIs
    Sunday, May 26, 2013 7:39 PM
  • Thursday, June 27, 2013 11:05 AM
  • Finally, the new serial framework documentation!

    Still not clear whether devices based on this framework are compatible with Metro apps. /* my guess is not, simply because none of new IOCTLs allow sending and receiving data, and metro apps cannot use Read and Write */

    -- pa



    • Edited by Pavel A Friday, June 28, 2013 1:55 PM fix link
    Thursday, June 27, 2013 4:08 PM
  • Sercx(2) are driver interfaces, not metro abi

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, June 27, 2013 5:36 PM
    Owner
  • Again, thank you Microsoft for listening!

    See 8:40 mark on http://channel9.msdn.com/Events/Build/2013/3-026

    Friday, June 28, 2013 1:32 AM