Microsoft still in denial phase over W8.. possible "relaunch" in February

1 hour ago, MasterPie wrote

@bondsbw: Can you list the specific access you need that WinRT doesn't provide currently?

• Communication with applications via loopback
• Runtime extensibility (loading and executing code that was not originally part of the app package)
• Serial port communication (this is a big one; our clients have a lot of money invested in hardware that communicates over serial)

49 minutes ago, evildictait​or wrote

*snip*

If your app is to be installed from the appstore, it shouldn't be able to do bad things to the machine it is running on.

Totally understandable, but I don't give a hoot about the Windows store.  I want to sideload our apps.

If you need to mess with hardware or with other people's apps, you need to be a desktop application, albeit with a Metro frontend doing the "driving". Your desktop application can be invisible and expose itself as a server to the Metro application over a loopback socket.

Which requires a loopback exemption to be set.  Doing this appears to be a hassle at best.

You can use Intune to configure non-domain joined WinRT/iPad/iPhone/Android/AndroidTab/Windows devices centrally. If you have several small clients, you can also be the administrator of several entirely distinct "groups". Each group gets a "company store" of side-loadable apps that the user can choose to install from.

So if I understand this correctly (and this is for some reason the first time I've heard of Intune), our users will have the option to have their IT staff use Intune, or we will become the administrators for their devices.

If so, I don't like the implications of that last statement.  We are software vendors, not IT.  We would be willing to administer the deployment of our software only.  Those users must be able to administer their devices without us*.  Also, this solution does not sound like it would work well for multiple vendors in our situation.  (Which one takes control, and why should some vendors have to rely on another potentially competing vendor to install and manage their software?)

Also, my cursory look over the details of Intune licensing suggests that it requires a sideloading product key.  Are those available for purchase yet?  Who would be responsible for purchasing those keys?  I am under the impression that they must be bought in bulk, and therefore our customers would not purchase them.  (And if we purchase the keys for our customers, would we be back in the multiple vendor situation I described in the last paragraph?)

I seriously want an answer, but it feels like every solution I find uncovers more new problems.  How far down is the rabbit hole?

EDIT:

*Again, reading back to my original problem description, the assumption here is that some of our customers are individual non-IT users who just want to "set it and forget it" (if I may steal a Ronco reference).  We come in one day and install our software and train them, and then we occasionally send out updates and new software extensions to everyone with as little direct interference as possible.

49 minutes ago, evildictait​or wrote

If you need to mess with hardware or with other people's apps, you need to be a desktop application, albeit with a Metro frontend doing the "driving".

In fact, this is exactly what I wanted to begin with:  The ability to create a Modern-style, chromeless window with a live tile for a desktop application.  Bonus points for running in the same process.

(Sure, you could simulate the window by making it full screen, but then it wouldn't interact with the Metro world so well.  It wouldn't have access to contracts like sharing, toast and badge notifications, live tiles or secondary tiles.  It wouldn't work with snap view, and its touchscreen keyboard integration wouldn't automatically pan and zoom the application as needed.)

How much easier would it be than all that mess we've been talking about sideloading and loopback exemptions and Intune deployments and product keys?

46 minutes ago, bondsbw wrote

Totally understandable, but I don't give a hoot about the Windows store.  I want to sideload our apps.

Cool. That makes it easier.

Which requires a loopback exemption to be set.  Doing this appears to be a hassle at best.

It's not too much of a hastle if you're installing the Metro app outside of the Windows Store. This gives guidelines of how to do it as part of your installer:

http://msdn.microsoft.com/en-us/library/windows/apps/Hh780593.aspx#enable_loopback_for_network_access

Note that the warnings are targetted at "normal" metro app developers who intend to write their app for the Windows Store (enabling loopback is explicitly forbidden for WS apps), but since you don't want to use that anyway, this is still a valid thing to do.

So if I understand this correctly (and this is for some reason the first time I've heard of Intune), our users will have the option to have their IT staff use Intune, or we will become the administrators for their devices.

Intune has two types of account; normal users and IT administrators. The IT administrator user type is analogous to someone running as the domain admin in a domain, so whoever is the Intune administrator has a lot of control.

If you're simply writing software that is to be side-loaded separately, then you just write your app as normal. The Intune side of things is handled by the IT administrators, not by the developers. Your customers (who are the IT department for the company) use Intune to add your app to the "Company Store" for sideloading.

So for example, let's suppose your company makes some enterprise app like, say, a remote-help piece of software for which you want a metro interface but needs to interact with weird and wonderful stuff on the desktop. This is how it goes:

1. You write your metro app as normal, but loops back to a desktop service to do the heavy lifting. Your metro app won't qualify for the Windows store, but you don't care.

2. You write an installer which plonks the metro app and the service on the machine and registers the metro app for the loopback exemption. Since this is an installer, it'll need admin privs to install, but we'll get to that later.

3. You deliver this installer to your customer's IT department who use Intune. They add it to their company store.

4. One of the customer's of that company enrolls their device to Intune. She now has the company store available either via a URL in the browser or via the Windows8 start menu. Suddenly there's a new app (yours) in there that she can see, and if she wants it she can click it.

5. This click routes a call all the way through Intune which then picks up your app from the company store and sends it to a service on the device and auto-installs it. It drops the metro app, the service and exempts the metro app from the loopback restriction. The installer automagically gets admin permissions for the installer because Intune handles all of that for you.

6. The user now sees the metro app in their Start screen and can click it. They are now using your app.

7 ...

8. Profit!

The cool bit about this is that developers just write code as normal, apart from you need to separate the metro app from the high permissions app (which is good for security anyway). Managing devices is left to the IT administrators who just add your app to the company store, and users don't have to think about stuff, they just click the thing in the store and it'll all magically work.

@evildictaitor:I must remember to use emoticons when I write something tongue-in-cheek.

@evildictaitor: Thanks for the info.  Much of this information has been updated just recently, since I last looked into it.  (And I'm at least happy that Microsoft is continuing to put forth an effort on the business side.)

1 hour ago, evildictait​or wrote

Intune has two types of account; normal users and IT administrators.

You described in very good detail the scenario for the IT administrator account type.  Can you point me to any information about the normal user type?

A large number of our users are not set up with any IT staff... I may not have been clear on that.  Some of them are one-man shops.  Those users bring their Windows 8 device to us, and we install our software, train them to use it, and they go on their way.  For our desktop apps, they don't have to interact with us ever again unless they need app support.

So, with or without Intune, can we sideload our applications in such a way that we don't have to administer their computers at all after installation (keeping in mind that they do not have access to IT specialists)?

Also, with Intune, if the user stops paying the monthly fee to Microsoft, does our applications stop working on his device?  Or can he continue using the applications he has already downloaded?

Sorry for continuing with all the questions.  I tend to do as much research as possible instead of asking questions on forums, but I'm having trouble immediately finding these answers at the Intune website, and you seem to have a clear understanding of the technology.

5 minutes ago, bondsbw wrote

You described in very good detail the scenario for the IT administrator account type.  Can you point me to any information about the normal user type?

It depends what you mean by normal users. Intune is really geared towards SMOs managing a number of "company owned" but not domain joined devices (or at a push BYODs). Intune "normal users" therefore are just average folk in the company, and the administrator is the IT admin for the company.

In the case where the machines are domain joined, you don't need Intune to push out stuff to domain joined devices; but you do need all of the machines to be Enterprise licenced. You can then push out Metro apps directly.

In the event that your customers are essentially outsourcing their IT to you (example: you are providing IT to a selection of local coffee shops where you essentially act as an admin on their behalf, cleaning up viruses, installing software and managing their Windows Updates). In this case, Intune is an ideal solution as it will take most of the pain out of your day-to-day job as well as enabling side-loading of apps.

In the event that your customers don't have enterprise licences, you aren't managing their IT, and they don't have Intune, the Windows Store is definitely the best option, but in the exceptionally rare cases where you have an app that can't be in the WinStore on a consumer edition of Windows where you don't manage their IT and they don't have Intune, you need to do the following:

1. Package your app as an app-x project.

2. Run the Windows Store validation (try and be as compliant as possible - it makes your app safer and more secure, and makes it easier to migrate into the general user sphere later if you want to) http://msdn.microsoft.com/en-us/library/windows/apps/hh694081.aspx.

3. Sign your app-x project using a trusted certificate from any trusted CA. DO NOT mess with the CAs on the target device.

4. On the target machine, set the following (requires elevation)

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Appx\AllowAllTrustedApps = 1

5. You should now be able to run the app.

More info:

http://blogs.msdn.com/b/b8/archive/2012/04/19/managing-quot-byo-quot-pcs-in-the-enterprise-including-woa.aspx

http://blogs.msdn.com/b/windowsstore/archive/2012/04/25/deploying-metro-style-apps-to-businesses.aspx

@evildictaitor: Very good info, and thoughtfully put together.

From what I understand, the only way to sideload in my "exceptionally rare" case is to purchase a sideloading product key for each device.  I worry about $30 per device, which for say 1000 machines, comes to $30,000.

Using a regular desktop app, it comes to $0 extra and not a bit of the hassle.

My case is not exceptionally rare.  Seriously, our software just uses a barcode scanner that communicates over a serial-to-USB interface (non-HID).  But that's a major component... take it away, the usefulness of our solution goes down quickly.

If it comes down to these choices:

1. $200 extra per user to get new barcode hardware that works with Modern apps in some way (if this even exists)
2. $30 extra per user to sideload a Modern app
3. $0 extra to continue without some of the nice features available to Modern apps

... our clients will choose option 3.  And based on that option, they will probably not choose to upgrade to Windows 8 any time soon.

Actually... I just had another thought.

Option 4:  upload our app to the Windows Store.  When our users come in for training, we download the app on their device, install our desktop component, and set the loopback exemption.

Thoughts?  Would this work, or am I missing something?

36 minutes ago, bondsbw wrote

My case is not exceptionally rare.  Seriously, our software just uses a barcode scanner that communicates over a serial-to-USB interface (non-HID).  But that's a major component... take it away, the usefulness of our solution goes down quickly.

Sounds like you need to watch this: http://channel9.msdn.com/Events/BUILD/BUILD2011/HW-747T

It seems to be almost entirely talking about your situation.

It might be possible for you to use the stuff from that talk to do away with the whole desktop service requirement and be able to create an app that can actually go in the store.

Actually... I just had another thought.

Option 4:  upload our app to the Windows Store.  When our users come in for training, we download the app on their device, install our desktop component, and set the loopback exemption.

Thoughts?  Would this work, or am I missing something?

Metro apps (in the store) are not allowed to talk to desktop components.

3.1 You must use only the Windows Runtime APIs to implement the features of your Windows Store app

We describe these APIs in the Windows Store apps API reference. Your app may only depend on software listed in the Windows Store.

Windows Store apps must not communicate with local desktop applications or services via local mechanisms, including via files and registry keys.

1 hour ago, evildictait​or wrote

*snip*

Sounds like you need to watch this: http://channel9.msdn.com/Events/BUILD/BUILD2011/HW-747T

It seems to be almost entirely talking about your situation.

Good info, but we don't provide the hardware or the drivers.  The hardware vendor, FTDI, supplies a serial-over-USB interface, but serial access is not a supported scenario for Modern apps.  They also supply a DLL interface that can't be loaded by Modern apps.

Our only option seems to be to write our own driver for another company's undocumented hardware.  I hope Microsoft doesn't seriously think that this is a workable option for most developers.

It might be possible for you to use the stuff from that talk to do away with the whole desktop service requirement and be able to create an app that can actually go in the store.

Even if the hardware issue is resolved, it only provides the third of the three scenarios I listed above.  The other two, loading runtime extensions and communicating with desktop apps, are unsupported outside of expensive sideloading.  (Communication with a desktop app has always been my "plan B".  It could be used/abused to simulate runtime extensibility, and it could be used to allow communication with external devices that do not support Modern apps.)

52 minutes ago, bondsbw wrote

Good info, but we don't provide the hardware or the drivers.  The hardware vendor, FTDI, supplies a serial-over-USB interface, but serial access is not a supported scenario for Modern apps.  They also supply a DLL interface that can't be loaded by Modern apps.

Is the device exposed via a class driver or a device driver? If it's exposed by a class driver there's a chance there'll be a Metro api for it, otherwise we're starting to get into complicated territory.

The easiest thing would be if the barcode scanner presents as a generic image scanner. If that's the case, you might be able to avoid playing shenanigans with their driver at all by taking a picture via the generic device and then pulling the data out using a scanner library.

Unfortunately lots of device companies are epically lame, and so there's a chance that it won't expose itself as anything useful and just expect you to use the DLL they shipped with the device. In this case there's really not a whole lot you can do but badger them to get their house in order, but you can tell them the following:

Store apps aren't allowed to just grab a handle to a driver and start poking it for obvious security / consistency reasons. If you want to talk to a device, the device needs to "inform" Windows that it's available for being poked by apps by adding a device manifest (http://msdn.microsoft.com/en-us/library/windows/hardware/hh454247).

The documentation is a bit confusing because the manifest allows a variety of things to happen. In essence, the manifest provides an icon for the device (for the popin dialog), a link to the Windows Store to autoinstall the device vendor's "flagship" app (e.g. a Nikon app when you plug in a Nikon camera), but it also exposes a list of API collections.

One of these collections is the "public" collection that everyone can use, and the others are locked to particular apps. This allows for instance any app to tell the Kaspersky driver to initiate a scan, but only the Kaspersky app to quarantine a particular file.

Your device vendor needs to construct one of these manifests detailing what their API is and who can call it. They can push it out without a code-change via WinQual here: http://msdn.microsoft.com/en-us/library/windows/hardware/hh801890.aspx.

Once this is done, any store app can poke the interfaces exposed to them by the driver.

Even if the hardware issue is resolved, it only provides the third of the three scenarios I listed above.  The other two, loading runtime extensions and communicating with desktop apps, are unsupported outside of expensive sideloading.  (Communication with a desktop app has always been my "plan B".  It could be used/abused to simulate runtime extensibility, and it could be used to allow communication with external devices that do not support Modern apps.)

Also, runtime extensions and communicating with desktop apps are means to an end, not an end in itself.

If no-one outside of your company writes extensions for your app (or if a small number of external people do), just compile them all in and selectively enable them. You can always add new features later by updating via the store.

And if your metro app is the only interface to your software, why does it need to mess with other apps on the desktop? (This is explicitly verboten in the security model of metro apps).

I don't quite get why in this situation I wouldn't just keep it as a desktop app at least until the API and/or hardware situation improves. I mean, where is the requirement to make a "metro" app actually coming from?

@evildictaitor:Reading from Hardware Compatibility List for WinRT, when searching for "barcode" as keyword, I can only find 1 magnetic strip reader as "supported". That's really low for a common device category.

@cheong: I see 16 ones compatible with Windows8 (although only one is certified).

Also, barcodes aren't a particularly common device category; certainly not like USB drives or harddrives or graphics cards or printers or the bajillion HIDs that Windows has to support; although that's cold comfort when you need to make use of one.

Anyway, it might be that the only solution to this problem is to badger the device manufacturer to sort their drivers out for Windows8.

1 day ago, evildictait​or wrote

*snip*

The default for Windows8 is great for "normal" users, but for the folks where losing the start menu is non-negotiable, they can upgrade to Windows8 and get Stardock. From Microsoft's perspective this is great!

Somehow this greatness eludes most people. Metrophones (Windows Phone) are a complete niche compared to Android and IOS (who look more WIMP-like)  And the "success" of W8 is nothing to write home about.

Acer's boss Jim Wong recently accused W8 of being too complicated and one of the reasons for bad notebook sales. They want now to establish "Experience Centers" to get customers accustomed to it.

Wong: "I think Windows 8 is too complicated. People do not understand the system. We must help them now".

The OEMs are ALL crying (was there a single OEM praising 8's performance?) of all Windows sales in the past decade, W8 is the most lack luster, it gets slammed by usability experts, even science magazines join the slam.. how's that in any way great?

Most OEMs cancelled or postponed their RT devices ("entirely and unashamedly optimised for consumption") because of lack of demand. So much for the love "normal" users have for it.

1 day ago, evildictait​or wrote

The vast majority of home user don't create content. Most people use them for browsing sites like facebook and gmail, possibly doing stuff in Office and to consume media like Hulu and angry birds. The rare few who do create content outside of office will presumably continue to do so via their desktop applications. But they weren't going to do that on a surface anyway, because content creation is hard on a small screen anyway, as anyone who has tried to type an email into an iPad will know.

Metro is not about content creation. It never has been. It is entirely and unashamedly optimised for consumption.

I fail to see what it has to with my points at all? I am not for the abandonment of metro, but for the full classical interface as an option. It took the more work to remove it then letting it in. The first beta had the start screen AND a fully-working start menu onboard, switchable through a registry tweak (so they put effort INTO annoying users). And no, Start8 is no viable solution. That one needs to pay additional money to a third party to make Windows competitive with older versions of it again for anything beyond Angry Birds is not a solution!

Sure, maybe some extra sales to some geeks.

What? Windows 8 scares "normal" people the most. Not everyone is just on Angry Birds, PCs are still used a lot. And Windows 8 makes exactly those things harder, that most Windows PCs are used for - it actually eliminates the point of buying new computers (if your old W7 PC is more optimized for PC-tasks than the new W8 PC - what's point of the W8 computer?)  No wonder there are complaints. Radically altering Windows and expecting everyone will swallow it without problems is fantasy. Geeks have the knowledge about Classic Shell and Start8; it's the normal Windows user who is bound for frustrations with no reasonable escape. Let's not forget that the metro interface and its design philosophy is foreign even to most tablet and smartphone users. Almost everyone of the normal people has Windows and/or Mac experience, but who has metro experience? Metro is a total alien for pretty much everyone.

Users should be able to safely install apps without it damaging their machine in a way that people installing fun EXEs from the web really aren't safe. Determining if software is malicious is equivalent to the halting problem, so the only way to do this is to sandbox them. And most desktop apps don't support being run with hyper-low privileges (for instance, LoadLibrary will normally fail from AppContainer because of the lowbox).

Since Mac does it, it's possible. END.

Expand the appstore mechanism and create a different sandbox (or none at all) for desktop applications. Make the additonal risks of desktop applications aware to the customers, but the option should still be there (I am not asking this for W8 by the way, but for one of the next versions)

Screening of the submitted programs and the registration of developers should elimate most malware.

It already is.

Intune as a solution for sideloading? That's a joke, right? That's like saying "money is no problem, just go rob banks".

2. The fewer buttons and dials and configuration options the user has to press and tweak, the less likely the app will break, the more likely it will work on a tablet and the more likely the user will get to spend their time enjoying the content of the app and not the mechanics of your config files.

It kind of baffles me to hear someone complaining that the UI isn't complex enough. Come on. This is progress. We don't want to have to navigate stupid menus or find hidden settings in order to consume content. Let your users get the content without having to think about it. Every second they are wasting navigating your menus or clicking your buttons is a second they are pissed off at your app for not letting them do what they wanted to do, i.e. consume the media your app exposes.

So, something like this is progress? If showing buttons makes something less aesthetically pleasing but more helpful than you go for the buttons. It's that simple.

imo it's progress over the Win7 situation where the settings dialog/menu is in a different place in every app (and in some apps already was hidden, e.g. in Explorer or Media Player under "Alt").

@contextfree`:

1 day ago, contextfree` wrote

I don't quite get why in this situation I wouldn't just keep it as a desktop app at least until the API and/or hardware situation improves. I mean, where is the requirement to make a "metro" app actually coming from?

Our software is mobile in nature.  Our clients are, thusly, salivating over the iPads and Android devices, and now Windows 8/RT devices.

Now, our mobile apps are designed to use a keyboard and mouse.  If they want a tablet, we'll have to start over on the UI front.  That's a big step... so I'm looking at the future.  Is WinRT the future for developing on the Microsoft stack?  I go back to my original post:

My message to Microsoft:  Give developers the power of desktop applications in the Modern world.  This MUST happen if your vision of reducing and finally removing the desktop from existence can ever come true.

I need to develop on a stable platform.  The Windows platform appears to be a moving target right now.  If I am to invest my software development in this platform, I need to know:

1. Will Microsoft build out WinRT as the ultimate replacement for Win32 and desktop applications?
2. If so, will the WinRT platform incorporate these use cases I have described?

My assumption for question 1 is "yes".  I have to assume that, since Microsoft may have put their entire company on the line with this new platform.  My current answer to 2 seems to still be "no", or at least, "not without hassle".  If that is going to change in the next couple of years, I'll start porting my application to WinRT.  Otherwise, I may need to look into another mobile platform.