Is "app" just a term that refers to a family of tiny, light-weight mobile-device-centric applications -- a trend that started with the Apple i-generation of devices and later found its way to Android and Windows 8?
If the same program were available both as an app and as an application for the same platform, what difference does it make to the system running it? For instance, Angry Birds for Windows is available as :
Angry Birds app for Windows 8/RT and Angry Birds app for Windows 7 (runs on Pokki)
versus
Angry Birds for PC
From a developer's perspective, are the above two just the same code compiled differently to produce binaries suitable to the target?
Also, now that platforms like Mac(iOS/OSX) and Windows 8 are common to mobile computers as well as desktops, is the line distinguising apps from native applications being blurred?
UPDATE:
I'm not questioning the choice of the word usage as in Appropriate use of “app” vs “application”. This question has more to do with how apps differ from native applications in terms of memory footprint, resource utilization, dependence of execution subject to presence of runtime environments on the client machine etc.
UPDATE 2:
Microsoft is encouraging Windows developers to build apps for Windows 8. Apart from additionally having to adhere to Windows Store app guidelines, how is what they build different from what they've been building all along?
App is just short for application. On some platforms the abbreviated name seems to have stuck... There is no technical meaning other than "application for this platform".
On windows 8 the new style programs are built differently from "desktop" applications. (They really have to sort out the names, metro apps at least gave you a name for it...). It's not just the same program rebuild for a different platform as the methods of interfacing with the system is a bit different. There is a new runtime library and a much more restricted runtime environment.
Windows 8 is different than Windows 7 and previous OSs because it has some additional features that developers can use to make their apps more alluring for the users, features like:
1. charms - settings, search, share
2. snap view
3. concept of store apps
4. new design language for store apps
5. Live tiles etc.
Windows 8.1 is different than Windows 8 because it essentially provides an update to the W8 features, for example:
1. roaming settings
2. Hero search
3. snap view - split the screen into any size
4. concept of universal app development
Windows 10 is different than windows 8.1 in a more stronger sense so to speak because a lot has changed, such as:
1. Concept of app targeting to single UAP
2. new XAML controls
3. cortana
4. action center
5. inking
Hope this helps.
Related
What are the various options to distribute a Windows 10 application? The application will be built using the Metro UI. Are there advantages or restrictions involved with the various options? I'm new to Windows development and haven't been able to find a definitive answer to this question.
Our application may end up being a Universal Windows Platform application. Does that decision imply things with regard to distribution?
I've read some things that imply distribution through the Windows Store means you are limited to a smaller set of APIs.
Our client has Microsoft SCCM set up. How is SCCM different from the Windows Store?
In order to run Windows apps you only have the option of publishing them on the Store or enable developer mode on all machines you install it on and sideload the app.
The usable API and its limitations are in both cases the same.
See also: Sideload your app package
I have a decade old MFC VC++ desktop application. Beauty of the application is it works from Windows 2000 to Windows 7, in more than 15 languages. Its multithreaded with IPC and SSL on top of winsocket.
Lately i am reading that win Windows 8 Metro style we will not be able to run the existing application. Does that mean Windows is heading towards killing VC++ or MFC?
Is there a possibility of me keeping same code base for all windows versions? Do I have alternative APIs for winsock and MFC? Is it compulsory to write the app in HTML5?
Lately i am reading that win Windows 8 Metro style we will not be able
to run the existing application
I find it easier to think about things in terms of the Windows Runtime (WinRT). The ARM based Windows 8 systems will only support WinRT programs. The x86 based Windows 8 systems are capable of running both WinRT programs and existing Win32 programs.
There is an implication (or possibly an assumption?) that all Metro style applications are WinRT applications. Certainly WinRT is intended for use in building Metro style applications. I could imagine building traditional Win32 applications that looked like Metro apps - big square active tiles, an application surface that stretched to the left and right of the visible desktop etc. I'm not sure those would really be considered "Metro style" apps even if they were built in the same style as a Metro app.
Existing applications will not run on ARM based Windows 8 systems and will not run in the non-Desktop part of the x86 based Windows 8 systems. They will run in the desktop part of the x86 based Windows system. That's where Visual Studio runs, that's where PhotoShop will probably run, that's where all the programs that currently run on Windows 7 will run.
Does that mean Windows is heading towards killing VC++ or MFC?
Absolutely not. MFC applications will run just fine in the desktop environment of Windows 8 on x86 based systems. MFC applications will not run on ARM based Windows 8 systems - but then there are lots of places MFC applications won't run.
As for VC++, you can build Metro style applications using C++ if you want to, you just have to follow the Metro "style".
Is there a possibility of me keeping same code base for all windows
versions?
It depends on what you mean by "all windows versions". The code that runs on Windows 7 x86 based systems today will run on Windows 8 x86 based systems tomorrow. If that's your target market then you're done, you don't need to change your code. The only thing you won't have is an active tile. But you could build an active tile using the Metro style APIs and tie that back into your app's logic if that makes sense.
If you want to support ARM based Windows 8 systems as well as x86 based systems, or if you want all of your program to have the Metro look and feel when running on x86 based systems then you'll have to change your program to use HTML/CSS or XAML and the WinRT APIs instead of MFC and the Win32 APIs.
Or if you want both worlds, perhaps you might even seperate your program's logic from the UI and then build an MFC skin and a Metro skin around that common logic
Do I have alternative APIs for winsock and MFC?
For networking there are a number of classes you can use from JavaScript, Visual Basic, C# and C++. For building UI you either use HTML/CSS or you use XAML.
Or you continue to use MFC if that fits your needs. You're probably never going to ever build a Metro style app that's got a Multiple Document Interface with a Tabbed UI!
Metro Style is all about user experience and different UI layout. If you want to utilize metro style UI in your app then you many need to write a WinRT wrapper around you app to utilize it. That doesnt mean that your application will not run at all in Windows 8, all the leagacy application still run in Windows 8
This article (from the Windows engineering team) says:
WOA [Windows On ARM] will not support any type of virtualization or emulation approach,
and will not enable existing x86/64 applications to be ported or run.
Does that mean I won't even be able to recompile an x86/64 application from source for ARM?
If yes, what exactly prevents me from doing that? My understanding is that the Win32 API is present on Windows 8 ARM.
If no, what do they mean by not being able to port x86/64 applications to ARM?
From the Windows article you link to, the second quoted paragraph is the killer. Porting existing apps is definitely NOT supported.
Developers wishing to target WOA do so by writing applications for the WinRT (Windows APIs for building Metro style apps) using the new Visual Studio 11 tools in a variety of languages, including C#/VB/XAML and Jscript/ HTML5. Native code targeting WinRT is also supported using C and C++, which can be targeted across architectures and distributed through the Windows Store. WOA does not support running, emulating, or porting existing x86/64 desktop apps. Code that uses only system or OS services from WinRT can be used within an app and distributed through the Windows Store for both WOA and x86/64. Consumers obtain all software, including device drivers, through the Windows Store and Microsoft Update or Windows Update.
If we enabled the broad porting of existing code we would fail to deliver on our commitment to longer battery life, predictable performance, and especially a reliable experience over time. The conventions used by today’s Windows apps do not necessarily provide this, whether it is background processes, polling loops, timers, system hooks, startup programs, registry changes, kernel mode code, admin rights, unsigned drivers, add-ins, or a host of other common techniques. By avoiding these constructs, WOA can deliver on a new level of customer satisfaction: your WOA PC will continue to perform well over time as apps are isolated from the system and each other, and you will remain in control of what additional software is running on your behalf, all while letting the capabilities of diverse hardware shine through.
Only a subset of Win32 is supported on Win8 for ARM:
http://msdn.microsoft.com/en-us/library/windows/apps/br205757.aspx
If you try to build an application that uses a Win32 API that's not supported, it won't build because the API won't be in the library. If you try to create your own library to support the APIs, the application still won't be usable because the only way to deploy apps to customers will be through the MS app store, which will no doubt check for API conformance.
From The "Building Windows for the ARM processor architecture" article:
Consumers obtain all software, including device drivers, through the Windows Store and Microsoft Update or Windows Update.
It might be possible to do so on your development machine (but maybe not - I'm really not sure if such a 'hack' will be possible, supported or not), but you certainly won't be able to deploy it in any kind of widespread fashion.
In short, any existing Win32 application will likely need significant work to be ported to Win8 for ARM. It won't be a matter of recompile and fix any errors that pop out to get the application to run on ARM.
They do provide this caveat a little further in your cited article:
Additionally, developers with existing code, whether in C, C++, C#, Visual Basic, or JavaScript, are free to incorporate that code into their apps, so long as it targets the WinRT API set for Windows services.
They've got version of Office and IE available; I'm positive those weren't ground-up reimplementations.
What are any cross-platform compatibility gotchas when running Silverlight 4 apps both on Mac and Windows?
I'd like to believe that any program whatsoever written for Silverlight will magically run the same on Mac and Windows, but I find it very hard to believe that this is the case.
I have run across a couple:
The WebBrowser and WebBrowserBrush work differently. On Macs, the underlying rendering engine is WebKit/Safari, while on Windows it's IE.
For out-of-browser apps, be careful about hard-coding any assumptions about the location of the My Documents folder. The documents folder to which OOB apps have access on macs is /Users/<username>/Documents.
Any COM+ automation/interop obviously won't work on the Mac at all.
Other than that, the runtime is pretty well-supported on the Mac and things do generally run the same between those platforms.
It is worth pointing out however that Microsoft seems to be changing their strategy with respect to pushing Silverlight as a cross-platform runtime. Silverlight 5 has a few features that almost certainly will be windows-only (P/Invoke comes to mind), and early reports are that Silverlight will find a home as the managed-code runtime for Windows 8.
I have an iPhone, an Ipad, don't have yet windows phone 7, but will get it right now if rebol can run on windows phone 7 so does/will rebol support it :)
Note: rebol could run on windows mobile so my question : will it continue to run on next version ?
Well if they don't release NDK, I will buy a tablet with classic Windows 7, that for sure can run rebol and a bunch of softwares I already have :)
When the ARM core library will be compiled, it may be possible for someone to port the host-kit to many new hand-held devices including Windows Phone 7, Android and even the iPhone (since they relaxed their TOS).
The ARM library is already high on the wish list of many people who are willing and able to work on the host-kit part of REBOL 3.
With 5 host-kit platforms already maintained by different developers (some indie) already at different levels of completion, the answer is not IF but rather WHEN will R3 run on these new exciting devices.
IMHO R3 still needs a little more stability work for mass porting, but in the last 2 months, I think R3 has matured to levels that are starting to catch up to R2 in many areas.
One good thing is that the extension API is proving to be highly effective and fast. Its design is also stabilizing which is a good sign of the current maturity of the host-kit.
A caveat
One must understand that many mobile platforms have strict development licenses and some even have hard to integrate APIs into which executables must try and link in.
Many don't even want binaries to work directly and the road to integration isn't meant to be easy on purpose. AFAIK winphone7 is probably the easiest one of the bunch, so don't despair.
Not until Microsoft or a third party releases a "native development kit" (NDK). The same problem hampers others, such as Firefox, who cannot readily port their apps to Silverlight, XNA or the .NET CF (which are the only Microsoft-supported development platforms at the moment).