We are not targeting ARM devices. We are targeting Intel (which as we understand it is the only way to do what I mentioned before, which is to write a desktop app to proxy communications to the device). So that's not an issue. Just talking to a virtual serial port on an Intel device.
Thanks Larry. I've passed the message on, and we'll see what happens.
Just for completeness, would it be possible for you to forward the question to someone on the devices team or Windows team internally at MS to see if they have a creative solution that doesn't require buying new hardware? It'd be nice to get a canonical "do it this way" or "it can't be done", just for completeness if nothing else.
@evildictator: couldn't you use the in-built camera of the RT device to "scan" the barcode? I mean, I know the Surface's cameras aren't the highest resolution, but I think they are reasonably sharp to distinguish standard barcodes...
just a thought...
We thought of that too, but it still doesn't fix the problem that the point-of-sale retailer has a barcode scanner and would like to use that to scan barcodes, instead of picking up the entire Windows RT device and waving it over the product.
Let's see if we can get a proper Microsoft response to a question asked in this thread in the Coffeehouse.
Basically the premise is this:
Suppose you are an application developer for a point-of-sale type Windows Store App, and you want to integrate the ability for a customer with a barcode scanner to be able to use it. In this scenario the developer of the app is not the manufacturer of the barcode scanner, and the barcode scanner is pretty old and isn't built with a Windows8-app style manifest.
Is it possible, and if so, how is it possible for a Windows RT device to communicate with the barcode scanner?
Here's some stuff we've already thought of (all of which have reasons why they are bad).
3. We could sideload the app, but that requires an Enterprise licence, or we could even use Windows Intune to sideload, but that requires a regular subscription, and is a bit of an overkill just in order to get a point-of-sale app to talk to a barcode scanner.
So anyway, is there an elegant solution to being able to get a non-enterprise non-Intune Windows RT app to talk to an improperly manifested non Windows-8 compliant device for application developers that don't make the device (and thus can't change the driver easily) in a way that doesn't violate the Windows App Store guidelines?
Windows 8 Enterprise SCCM 2012 Active Directory Windows Server 2008R2 DC's and 2008 Forest level
1) Deploy required apps via SCCM to Windows 8, app is set to install for all users and is targeted at a device collection and to install without user logged in. In our environment computers versus users is not one to one and users may use several different devices during the day. The software is a site license so it can and should be installed on all systems. What we currently see is that shortcuts will not be created on the start screen for all users, there doesn't appear to be an all users start screen so does Microsoft either a) expect each user on each machine to naturally search for apps or b) expect some serious scripting to replicate icons on each users start screen or c) System Center SP1 addresses this?
2) Windows 8 App Store, I take it this is not for business or education use as there doesn't appear to be any way for centralized control of purchases or account management for Microsoft Accounts by the company that purchases both the hardware and software. I know App Locker and group policy can do some things in this area but it doesn't address Windows RT devices at all. I know the just released version of Intune has some RT options but it doesn't address the creation and authorization of Microsoft Accounts beyond what would appear to be a very manual and time consuming process. I feel sorry for K12 schools because they though RT was the answer to the iPad and the Chromebook with Live@EDU and the ability for them to generate Microsoft Accounts, oops they are royally hosed.
I strongly suggest that you take a look at Windows Intune. You can get a free 30 day trial. It allows you to push apps to all Intune devices, run a company store and it connects to SCCM / ActiveDirectory and works with all Windows8 devices including Windows RT. You can also configure iOS and Android devices using it - including foreign BYOD deviecs, so it's a good all-purpose solution for the enterprise and seems to solve lots of the problems you're coming across.
@felix9: AppContainer is a bit of a misnomer. The kernel name for AppContainer is "lowbox", and all of the security provisions of AppContainer are available to normal apps as well.
In fact, IE10 on the desktop runs as two processes (as it has since IE8); the low "rendering" process which always used to run as "Low-integrity" on Windows Vista and above now runs as "AppContainer" on Windows8, even though the renderer is not an app.
Although not formally exposed and technically subject to change without notice, you can create your own AppContainer processes via ntdll!NtCreateLowBoxToken API, which you can use to create appcontainer protected desktop apps by using it as the user token to advapi32!CreateProcessAsUser.
behaves as a static-if in Visual Studio's release builds, because the compiler is smart enough to see that the condition can be determined at compile-time and the unused branch can be removed.
Similarly (3 * foo) typically becomes ((foo << 1) + foo) in release builds to avoid the multiply - something that other programming languages might try and do by having a meta-programming multiply_by_constant that is clever enough to know tricks to avoid performing multiplies on the hardware.
Meta-programming is certainly interesting from a language perspective, but without a good grounding in compiler theory, it's easy to overstate its important from a performance perspective.