I know that the new UWP app model has some limitations when comparing to "traditional" Win32 apps.
Let's take Visual Studio Code as an example of a desktop app.
What features of Visual Studio Code were missing or had to be different from user perspective, if it was an UWP app?
EDIT:
I've done exams for microsoft certification "Essentials of Developing Windows Store Apps Using C#" and Exam 70-355: Universal Windows Platform – App Data, Services, and Coding Patterns. So I know something about win rt api.
Please don't bother with answers like "uwp app runs in sandbox". They are useless, because they say nothing about the limitations from users' perspective. I intentionally took real life example, so we can go concrete.
The limitation could be, that your app cannot support 3rd party plugins like custom syntax highlighter or refactorin extension(it was limitation of windows store apps, not sure if its still valid).
Another limitation could be, that your app is not able to take screenshot, because there is no api in uwp for it (not sure it its true, actually)
The phrase "Win32 desktop app" is a ill-defined since the Win32 API programming model has been around since Windows NT 3.1. It can also cover dozens of development languages and UI frameworks over the intervening two decades.
Here's a quick overview of the key UWP differences:
API surface area. The UWP platform supports many but not all Win32 and COM APIs, and introduces new APIs. If your "Win32 desktop app" is using mostly ANSI APIs that date back to Windows 95, then you have a lot of updating to do. If you are using mostly Windows Vista era UNICODE APIs, then a lot of stuff "just works". See Win32 and COM API for Windows Runtime apps (System).
Security context. The UWP platform runs applications in an AppContainer security context. "Win32 desktop apps" on Windows Vista or later run as "Standard User" or as "Administrator". UWP apps have less access rights than "Standard User" and can never run as "Administrator". UWP apps can request additional capabilities to get a few more rights with permission from the user, but have limited access to the system and user data. For example, you cannot read most of the filesystem, only your installed location, an isolated application data folder, and an isolated temporary file folder. See File access and permissions (Windows Runtime apps). This also means UWP apps have limited access to devices. See Device and sensor overviews.
Windows Vista User Account Control that introduced Standard User was focused on protecting the system and other users data compared to the older "everything is administrator" model, but did little to protect the current user's data files since all apps could access or even modify it. AppContainer isolation is protecting both the system and the current user's data and settings. "Win32 desktop apps" were encouraged to install to C:\Program Files which was read-only at runtime and to use application data folders, but they were not required to.
Deployment via AppX. "Win32 desktop apps" use any number of ways of deployment, often something using MSI technology and running as "Administrator". UWP apps are packaged in AppX files and are always deployed by the system. There is no "Custom Install Step", and therefore UWP apps cannot install drivers or services, change ACLs, etc. The system takes care of deploying the C/C++ Runtime (which must be Visual C++ 2015 or later).
Interface model. There is a plethora of interface frameworks for "Win32 desktop apps" like WinForms, MFC, WPF, etc. The vast majority of these are not compatible with UWP because UWP does not support classic Win32 windowing, WM_ messages, or GDI/GDI+. For UWP apps, you can use XAML with C++ or C# code-behind, DirectX (Direct2D and/or Direct3D) with C++ (or C# via 3rd party assemblies like SharpDX), or HTML5 with JavaScript.
Deployment via MSIX.
Answering your question is therefore extremely difficult, if not impossible, without a complete understanding of the product's code base and dependencies.
See Get started with Windows apps
Related
I would like to embed a universal windows app into a classic windows application on windows 10. Is this possible?
The short answer is no. However... depending on what you're trying to do, the information below may help you.
If you just want to get the look and feel of a desktop application, you should be aware that Windows 10 apps (unlike Windows 8 apps) run in non-fullscreen mode by default, and can be resized. Desktop apps in Windows 10 have top-right icons (min/max/resize) that look similar to how UWP apps look in the title bar and top-right icons.
If you're creating a UWP app with XAML, you won't be able to embed it in a desktop application. However, if you're building a Windows 10 app using HTML5 and JavaScript, you could repackage it inside a browser control embedded in a desktop application.
If you're creating a game using a 3rd-party tool such as Unity, you can export it as a Windows desktop application just as easily as exporting to a UWP app for Windows 10. Unity can be used for non-game apps as well, so you could export it to a desktop application today, and still have the option of publish a UWP of the same game/app.
If you were thinking of accessing the full Windows SDK from you UWP app, you won't be able to do so, as you will be restricted by the UWP sandbox. But Windows 10 has made many improvements in helping you get access to many advanced features, e.g. accessing certain locations in the file system, so you may be able to get by with all that UWP has to offer.
If you want to avoid the Windows Store, you may sideload your app, as suggested by an earlier comment.
Hope that helps! :)
I could not google a straight simple answer to this, so i'm trying my luck here.
is there a problem installing Microsoft office 2007\2010\2013 on a network windows-based server, to be able to do some server-side conversions and simple automatic operations using its inter ops libraries on user generated documents?
If it is, is there anything i need to know prior to installing it ? any licenses needed ? cost of these ? is it the same as installing office on a client pc ?
Thanks in advance.
Microsoft Office supports Windows Server OS - feel free to install it on your server. But it doesn't support automation on the Server server side. The Considerations for server-side Automation of Office page states the following:
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
Developers can use Automation in Microsoft Office to build custom solutions that use the capabilities and the features that are built into the Office product. Although such programmatic development can be implemented on a client system with relative ease, a number of complications can occur if Automation takes place from server-side code such as Microsoft Active Server Pages (ASP), ASP.NET, DCOM, or a Windows NT service.
I am trying to build my ios application for android. Is there any chance to use windows azure mobile services framework in native objective-c code? Or should I use java and call my azure mobile services table items from it ? Thank you in advance.
If there's an Android version of azure, you could use BridgeKit to bridge the android library to objective c APIs.
http://docs.apportable.com/using-java
There are native Azure Mobile Services SDKs for all major mobile platforms (iOS / Objective-C, Android / Java, Windows Phone, etc). There are excellent tutorials available on the Azure website:
iOS: http://azure.microsoft.com/en-us/documentation/articles/mobile-services-ios-get-started/
Android: http://azure.microsoft.com/en-us/documentation/articles/mobile-services-android-get-started/
If you are looking for cross-platform development you could leverage Xamarin (C#), Sencha or PhoneGap which all have samples at the above site as well.
If you want to serve multiple platforms a better approach would be to create a service layer which works against your Mobile Service (f.e. build with ASP.NET Web API). This service layer would be called from your clients. The big advantage is that you don't have to write code multiple times and changes can be done at a central point. If you concentrate on RESTful services nearly every platform can call it.
Currently that seems to be a lot of overhead with an already finished iOS implementation, but imagine the situation when you want to support other platforms, such as Windows 8 or Windows Phone 8. At this point you have the same problems again.
I have taken over a Windows-CE 6.0 application that I would like to port to other platforms. It is a relatively straightforward, self-contained GUI application, written in Embedded C++ Version 4.0
The very first target I am interested in would be a regular Windows desktop (i.e. XP, Vista, Windows-7).
I understand that porting a desktop application to CE is nontrivial; but what about the reverse, which is what I am interested in? Is going from Windows-CE to Windows Desktop (somewhat) upward-compatible? I sure would love to hear "buy this $1000 Microsoft XYZ C++ development environment and just compile and go!"
(FYI I have no experience with GUI applications nor with programming in the Windows environment; pretend I am but a simple linux/unix guy with decades of C/C++ experience but absolutely no Windows-Fu... ;-)
Porting up should, actually, be pretty straightforward. CE is mostly a subset of Win32, with heavy emphasis on Unicode.
You can probably make sure UNICODE is defined, build and, with a little luck, most of it will "just work". Places that are going to be hangups are:
The UI is likely to be set for a resolution that doesn't match your PC - often CE apps are targeted to a specific device and resolution and this doesn't necessarily come out very aesthetic on a PC.
Anything dynamically loaded (GetProcAddress) from coredll will have to be re-mapped to kernel32/user32/etc
If the device uses the SIP (software input panel - i.e. on-screen keyboard) then all of that has to get stripped out.
If the app uses any Notifications (icons, etc) that has to get replaced
If the app uses any power management, that has to get ripped out
If the app uses any device-specific stuff - especially direct calls to drivers, all of that has to be replaced
If the app is using point to point queues, that has to get replaced
If the app is using the device manager (e.g. to get notifications of copnnected devices) that has to get replaced
Any calls into aygshell.dll are likely to be problematic as well.
Can Sharepoint apps be developed in a Visual Studio 2010 dev box only or does the dev box need to connect to a Sharepoint server? Can the Sharepoint Server be a stand alone machine (no domain controller between the two machines)?
The best practise for SharePoint development is to use a virtual server that contains the SharePoint install itself (and a copy of the portal you're working with), because assuming you are programming directly against the SP API, you will need to be executing your code on the machine that contains the Sharepoint installation itself.
You can program against SharePoint from a non-SharePoint machine through the use of the standard set of SharePoint web services provided, and you can of course create your own services (again sitting on the SP box/VM) to interrogate too. The catch to this approach is that you'll be dealing with return types that are primitive or XML based and you won't have the luxury of SP objects, for example SPUser, SPSite, etc, but for simple query operations at least this is not a bad approach.
IMHO, however, you've far greater flexbility programming against the API itself (Microsoft.Sharepoint.dll) so I'd advise you to get a VM going with all the necessary installs. Yes, it's a pain and time-consuming to set up, but well worth it.
As for Stand-alone options: SharePoint 2007 is not supported on anything non-server in terms of OS, so you'll need something like Server 2008 in order for it to work. SharePoint 2010, however, whilst claiming to only work on Server 2008, can actually work on Windows 7 (Pro and above) with a few hacks. You also have the benefit of 'sandbox' feature deployment in 2010, where you don't in 2007, meaning dev work is more cleanly isolated and less of a risk to a farm as a whole.
Good luck!
You can develop for SharePoint 2010 using VS 2010 using a stand alone setup - this is supported by Microsoft and very much recomended. Infact most of the tools built into VS2010 that will make your life significantly easier will only work with a local copy of SharePoint 2010.
MSDN - Setting Up the Development Environment for SharePoint 2010 on Windows Vista, Windows 7...
Yes, if you have Windows 7 or Vista (you need WAS - Windows Activation Services). We have tried it but found that it was better to develop on a Windows 2008 with your own AD.
It will depend on what you are developing, for webparts you will not notice the difference. You will notice the difference when working on the security part og the app.
Sahil Maliks book has a whole chapter on the different options.
you can do sharepoint development by copying certain dlls to your local enviroment but to my understanding this is unsupported and the recommended practice is to use a virtual machine or development on the machine in which the service resides.