I will refer applications in Windows Store for either Windows 8/8.1 or Windows 10 as UWP applications as Wikipedia does, if I do not mistake it. Windows RT(not WinRT though) is not discussed to avoid confusion.
I wonder what API's no matter public or undocumented that Windows 8/8.1/10 have implemented that Windows Store and UWP applications rely on, so that they cannot be port to Windows 7, which is NT 6 as Windows 8/8.1/10 do.
If nothing much are there, but only due to M$'s market strategy to promote new technology'd Metro, there might have been some 3rd-party runtime/framework for Windows 7 on which Windows Store will work and UWP applications can run, which will surely spend no more effort and cause no more legal or compatibility trouble than Mono or Wine.
Edit: As How does Windows 8 Runtime (WinRT / Windows Store apps / Windows 10 Universal App) compare to Silverlight and WPF? says, it's a layer quite similar to .NET that lies between COM and application, if I didn't misread.
It's not a marketing strategy by the evil M$, and writing things like that makes you look rather juvenile. There's a giant layer of code (arguably an entire operating system within an operating system) that was written to enable Metro/Modern/UWP apps to run in Windows 8, tweaked in 8.1, and further refined in 10. That layer simply isn't there in Windows 7, wasn't backported, isn't going to be backported, and can't reasonably be backported by a third party who lacks access to the undocumented details of the implementation.
There is no conspiracy afoot here. It is a simple matter of new operating systems supporting things that old operating systems don't. The new features that Windows 8/8.1/10 have implemented that Windows Store and UWP applications rely on is the entire notion of a Windows Store and a UWP application.
The version number ("NT 6", as you point out) doesn't matter. All that tells you is they didn't massively rewrite the kernel. You don't have to rewrite the kernel in order to write a new layer on top of it.
If you want to run Metro/Modern/UWP/Store applications, you need to update to a later version of Windows. Alternatively, you can just write a regular Win32 application, which will run on all versions of Windows, including the latest builds of Windows 10.
Related
Is Universal Windows Platform the replacement of WinRT of Windows 8 and Windows Phone apps?
I mean, there was a WinRT platform to develop metro apps exclusively for Windows 8. Now, that is replaced by UWP, isn't it?
That is correct, UWP is the new platform for ALL Windows devices going forward (Win 10+). However WinRT is not replaced by UWP but is instead an extension on top of it, making UWP a much broader set of APIs that can be used across even more devices. As Microsoft themselves state:
With this evolution, apps that target the UWP can call not only the WinRT APIs that are common to all devices, but also APIs (including Win32 and .NET APIs) that are specific to the device family the app is running on.
The UWP platform supports the "Universal Device Family" class of APIs which is then supported on ALL windows platforms (Xbox, Phone, Desktop etc). There are some extension families that you can use that will limit the apps reach, such as a "Mobile Device Family".
These specific device family APIs can however be checked for and used at runtime gracefully. For example you could show your own position using GPS on a phone, but not enable that functionality on a Xbox.
I hope this answer helps you, if you have any more questions about this I recommend reading this article about the UWP platform:
Source: https://msdn.microsoft.com/library/windows/apps/dn894631.aspx
Have a wonderful day!
This is a bit confusing because in Windows 8.x, "Windows Runtime" was actually used to refer to a few different things:
A new pattern (and supporting code/OS components) for defining and consuming Windows APIs, meant to largely supersede "Win32" (i.e., flat C-style) and classic COM for new APIs in most scenarios. This was/is really about language interop: allowing the Windows team (and potentially others) to create components in C++ that expose APIs that don't depend on GC or a runtime like the CLR, but still feel relatively natural to use from C# or JavaScript without needing manually written wrappers.
The set of Windows APIs that follow the above pattern.
A new platform/environment for building and running a new type of Windows app, which are meant to have some of the characteristics of mobile and web apps in terms of causing fewer potential problems with system security, reliability, performance, battery life, etc. This is what evolved into UWP with Windows 10.
In the Windows 8 days, these apps were called "Metro style apps" during most of 8.0's public preview period, and officially dubbed "Windows Store apps" just before RTM. The platform/environment for these apps ... officially didn't really have a name (other than "platform for Metro style apps"). Unofficially, people (including at Microsoft) sometimes referred to it as "Metro" (a whole can of worms in itself) or ... "WinRT".
So what's the relationship between WinRT "proper" (definitions 1 and 2), and unofficial WinRT definition (3) aka UWP aka the formerly-nameless "platform for Metro style apps"? Well, since WinRT and the new app platform were both introduced in Windows 8, most of the WinRT APIs at that time were specific to the new platform. The app platform (and Store policy) at the time was also much more restrictive about which legacy Win32 APIs were allowed for use in apps - for the most part this was less about any technical limitation and more about the team hoping to use the new apps as an excuse to clean up the bloated Win32 API surface. But technically, WinRT is meant to be the common pattern for new Windows APIs in general, whether used in UWAs or not, and "UWA vs. classic app" and "WinRT vs. Win32" are mostly independent; over time, they've gradually enabled more WinRT APIs for use outside UWAs and also relaxed their policies on using a lot of legacy Win32 APIs in apps (and also continued to introduce new flat C-style APIs for certain use cases).
So to summarize, it's not technically accurate to say that "UWP replaced WinRT", though understandable since this stuff is pretty confusing. UWP replaced the nameless app platform (3); essentially it's just an updated version that's been ported to other device types and integrated with the classic desktop UI. WinRT, in its proper definition (1), continues to be the basis for new Windows APIs for use in UWAs and even outside them.
Windows Universal Platform is the development platform going forward for devices running Windows. Previously, development was separate for Desktops and Tablets vs Phones. With UWP you are now able to target any device running Windows 10, could be phone, desktop, tablet, xbox. The beauty is that you can now use one Binary for all of these platforms and has brought us much closer to a truly to a universal Windows app.
So, to answer your question, yes, UWP is the platform going forward for any device which runs Windows 10
Does Windows (some modern flavour) have an mDNS server installed and/or running by default? If so then how does one tell it, preferably dynamically, to start/stop advertising a new service?
If there is no standard then how does one deal with the problem of conflicts trying to run multiple mDNS servers in that environment?
Basically, I want to implement a service that will run on Linux, Windows and Mac OS X and which needs to advertise its zeroconf webserver location using mDNS. On Linux I just use avahi-publish (or install a config file). I'm guessing that the answer will be straightforward for OS X. I'm struggling to find information for Windows.
Starting with Windows 10, Microsoft made strides towards a native Windows implementation of mDNS and DNS-SD.
While earlier iterations have been limited to UWP apps, a general Win32 API has been exposed from at least SDK version 10.0.18362.0 (1903/19H1, May 2019).
Note: This implementation is currently confirmed working only for 64bit build targets, there is an open issue preventing compilation for 32bit targets.
Outdated note from a previous version of this answer:
Early iterations resulted in mDNS network flooding:
Windows 10, in its default configuration, will spam its local networks
by responding to all mDNS requests with null response packets.
This issue was fixed in Windows 10 1511 (10586) and above
Last time I needed one, Apple's Bonjour Print Services for Windows was the most convenient mDNS client for Windows I could find. Only 5MB.
No, Microsoft doesn't directly support Multicast-DNS.
However, there appear to be several 3rd-party alternatives:
http://bens.me.uk/2013/multicast-dns-and-development-virtual-machines
http://en.wikipedia.org/wiki/Bonjour_%28software%29
http://www.icir.org/gregor/tools/autoconf-protocols.html
http://www.zeroconf.org/
... and ...
http://blogs.technet.com/b/networking/archive/2008/04/01/how-to-benefit-from-link-local-multicast-name-resolution.aspx
Have also successfully used C++/WinRT for dnssd discovery directly from C++ now. It appears from our perspective to be quicker and more reliable to query services and will let you easily install a watcher to get notifications when devices arrive etc. Of course, this is limited to versions of Windows 10 with support for C++/WinRT, which starts with 10.0.17134.0 (Windows 10, version 1803).
One caveat: We've noticed that it does not provide, nor recognise, a FQDN (trailing dot). So for a device that Bonjour OR Avahi would give an address of mydevice.local., Windows instead gives mydevice.local. Attempting to ping mydevice.local. under Windows 10 (1809) fails.
Windows 10 supports natively mDNS/Zeroconf, but only for modern APIs, not for Win32 applications.
If you have such an application, a third party service is required.
Source: https://social.technet.microsoft.com/Forums/en-US/8a0346de-2296-4f46-bc36-ff3fb13e283b/builtin-mdnsdnssd-zeroconf-support-in-windows-10
The short answer is to support both Avahi and Bonjour. You'll need Bonjour support to run on OSX anyway, and if a Windows user has installed iTunes they'll already be running it.
As a fallback for Windows users not running iTunes, you can compile Avahi as a library for Windows (with a bit of effort) and bundle it. This is a non-trivial bit of packaging, but the alternative is requiring your Windows users to install iTunes in order to use your application.
AFAIK, only Metro style apps can run on Windows 8 ARM, and Metro style apps can only be written with WinRT APIs.
According to this thread Can we access Windows 8 WinRT API from desktop application and Windows Phone 8 app? If so, are they in different namespaces?
Windows Phone 8 use ARM architecture, too. So if our app is written with WinRT APIs, it can run on both Windows 8 x86, Windows 8 for ARM and WP8, right ?
Not exactly. The situation with WinRT and Windows Phone Runtime is similar to WPF/Silverlight. There is overlap, but not 100% coverage. To address this issue Microsoft encourages using Portable Class Libraries to target multiple platforms (since each platform has its own runtime). More information on PCLs: http://msdn.microsoft.com/en-us/library/gg597391.aspx
Also, even if you manage to have most of your classes working under a Portable Class Library, you'll still have to write separate User Interfaces for each platform (the PCL does not support sharing UI). While this may seem upsetting, it actually is more necessary than you think. Here's a link on what Microsoft suggests in terms of sharing XAML UI.
This shouldn’t be seen as a complete roadblock for sharing between
Windows Phone 8 and Windows 8. The clear guidance is to design and
build your UI separately for each platform, embracing the design
guidelines for each. It is technically possible to circumvent these
obstacles. You could create your UI during page initialization from
code. You could load platform-specific XAML from resources at runtime
and inject it as a string into the page. However, none of these
techniques scale and they make the construction of your core asset—how
your app looks to your user—a tedious and error-prone task. Your code
sharing investment will give you a much larger return further down
your app stack, by trying to share app logic, data models, viewmodels,
etc.
Basically, Microsoft is saying design your user interfaces specifically to the platform, because an application running on the phone (smaller screen) should have a different user interface than one that runs on a tablet/desktop (larger screens).
As far as running WinRT apps on different platforms... Yes, you can. Microsoft has stated that applications written in WinRT can run on Windows 8 and WOA (Windows on ARM). Here's a link from Microsoft talking about this. But, the first portion of my answer still stands... if you want to target different runtimes (WinRT/Windows Phone Runtime)... then use Portable Class Libraries. Selecting "Windows Store" and "Windows Phone 8" will allow your code to run on Windows 8 x86/x64/ARM, and Windows Phone 8.
Windows Phone implements a subset of the Windows 8 WinRT API, dubbed WinPRT (P == Phone). You can find a good overview here with an exact list of support Win(P)RT APIs to be found here.
Word of caution - the XAML on Win8 is similar, but different, to the XAML on WP8 so expect to have to rewrite a lot of your UI for WP. What you really want to do is read this Getting Started guide that steps you through a lot of the considerations and techniques involved in developing apps between these platforms.
I planned to create a Windows 8 Store App but reluctantly had to switch to desktop application. I found that Windows 8 Store Apps fail to detect second screen, which is necessary for me.
The intention still is to mimic the behaviour of Windows Store App as much as possible. Partly to educate myself but also to use a modern nice design.
I use WPF with very similar design (App bars, Navigation bar, snappy await-async pattern, etc)
Now I come to the point where I need to store settings!
I would really like to use the very convenient central storage available through Microsoft Live login. Is that possible even if I don't have Windows Store App?
Clients might be Windows 7 or Windows 8.
Can I make the user login to Microsoft Live and use these facilities?
Many WinRT APIs are available from desktop applications, in addition to Windows Store applications. Windows.Storage.ApplicationData appears to support desktop apps. Look under the "Requirements" section in the documentation:
Minimum supported client: Windows 8 [Windows Store apps, desktop apps]
Someone at Intel posted on how to use WinRT APIs from desktop apps. The post is from September, 2012, and the screenshots appear to be for an older version of the MSDN documentation. Just keep that in mind.
Dave Bennett of Microsoft has a useful blog post which will introduce you to roaming your app data.
I may have misunderstood you, but I think what I mention above is what you want instead of using the Live Connect APIs.
We are developing a lightswitch app that will have a silverlight plug in controller that will allow for handwriting recognition and translation. we want to use this exclusively on a win8 tablet. we know that it has to be used on the desktop side of the tablet. We also know that the win8rt side has access to different tools that allow of handwriting recognition. (InkManager class) - is there any way to get access to these necessary classes from the desktop side of the win8 tablet.
This post by Scott Hanselman might help you.
Quote:
I was trying to access some of the sensors that are built into this
Intel Ultrabook that runs Windows 8. However, while there's support
for Location Sensors built into the .NET 4 libraries on Windows 7 and
up, I want to access the complete Sensor and Location Platform that is
built into Windows 8 itself. Those APIs are available via COM and I
could call them via COM, but calling them via the WinRT layer is so
much nicer. Plus, this is kind of why WinRT exists.
There's also an example using VB.NET on TheCodeProject