In almost every text about the new WinRT API I came to statements like "WinRT is the new API for Windows and replaces the old Win32 API". Since WinRT aims the development Windows Store apps, this statement to me does not seem to hold true.
There are lots of applications I just can not imagine to be done with WinRT (e.g. Microsoft Office, Adobe Products, 3D Designer Programs and even Visual Studio). These applications still need the functionality of the Windows API (aka Win32).
So why is it so often said, that the WinRT API replaces the Windows API?
This has kind of changed, recently due to a couple reasons, but here's the rundown of why you want to use WinRT over Win32 in current Windows application development (circa 2017):
WinRT is leveraged by UWP apps
Win32 apps can be converted into UWP apps using the Desktop Bridge
Windows 10 S requires all apps to go through the Windows Store
Ergo, using WinRT will invoke less time spent converting projects and code for the new Windows 10 S Store-only application paradigm.
In regards to WinRT vs. Win32API vs. .NET, both .NET and WinRT are partially built with Win32; IIRC, they use subsets of it. At least that's what was communicated back in 2012 from ArsTechnica in Peter Bright's article, "Turning to the past to power Windows’ future: An in-depth look at WinRT". That's where this stack chart comes from, or at least it was used there:
I'm not sure if it's often said that the Windows Runtime (WinRT) API replaces the Win32 API. It's not something Microsoft is saying. In many ways WinRT tries to learn from the failure of the .NET Framework to replace the Win32 API. That includes Microsoft not trying to push WinRT as a replacement, but merely a new way of doing things.
There isn't actually much of a reason why the applications you mentioned couldn't be be implemented using the WinRT API. The new API includes a lot of the functionality of the old. You can write WinRT applications in C++ and the resulting applications are native executables, not managed ones. It's even possible to use a subset of the Win32 APIs.
While Adobe has little to gain by porting its applications to WinRT, expect Microsoft to do so. They rewrote most of Visual Studio to use the .NET framework. If anything the WinRT API makes it practical to implement much more of it the new environment.
Related
I am trying to develop an Add-In for Microsoft Word on macOS. The Windows version of the Add-In is already in development, but I don't have access to its source code. It seems like the following is the 'landing' page for developing Add-Ins for Office:
https://learn.microsoft.com/en-us/office/dev/add-ins/
The above documentation seems to say that Add-Ins have to developed using web-technologies, and, upon examination of existing, Third-party, Add-Ins, this seems to be the case at least for the UI. What I don't understand, is, if the entire plugin has to be written using web-oriented languages, or if there is a macOS oriented SDK that allows to implement at least the underlying logic using a macOS native SDK, perhaps using Objective-C or Swift. I was hoping that somebody more expert could bring me in the right direction. Thanks for your attention.
There is no platform specific SDK for developing Office add-ins. You can use web technologies for developing cross-platform Office add-ins, see https://learn.microsoft.com/en-us/office/dev/add-ins/overview/office-add-ins for more information.
You also can use AppleScript for automating tasks in Word on the MacOS.
In my company we have an existing product that runs on Windows 7 and communicates with our web services.
We wish to make a Windows 8 tablet version of our product, and my first thought was:
"Hey, its just a new Windows version, so we can probably use our existing model, data access and business layer logic projects, and just focus on making a new UI layer"
But I fear that this is not the case, or am I wrong?
I tried opening our VS2010 solution file in VS2012 Express, but received an error "This edition of Visual Studio only supports Windows Store apps".
So, my naive hope now is: Can anyone tell me the easiest way to make our existing code work in a Windows 8 App?
EDIT:
The code is .NET C#, and my thought was that I just wanted to make a Windows 8 app so that the product had a tablet/touch friendly interface.
In general, you'll make a new UI using XAML, reuse a lot of your existing code, and change the data access to use SQLite.
VS2012 Express Edition is for making Windows Store apps. By "Windows Store" app, I mean an app which uses the WinRT APIs. Depending on your code, making a Windows Store version of your app can be straightforward.
If you need other features, you might need a different version of Visual Studio 2012. You definitely need to be on 2012 though. You can't build a Windows Store application with Visual Studio 2010. I think you know this already though.
If your existing .NET app uses WPF for the UI, you can reuse a lot of your XAML knowledge for the Windows 8 port. It's not as simple as recompiling, but it should be straightforward.
SQL CE is currently not an option for Windows Store applications. Instead, consider using SQLite.
Take a look at a post on MSDN called .NET for Windows Store apps - supported APIs. Some APIs you may be familiar with have been moved to WinRT. Sometimes porting is as simple as changing namespaces.
You mention that you also write to the C: drive. There's a sample on MSDN on how to read and write files.
So You need to build a new Metro Style Interface.
Wen You built interface just copy the Logic of your old application.
You can open old application in old VS 2010 and copy code line by line.
You can't convert old Windows app to Metro Style App.
Right now I am working on c# windows applications developement. But my concern is I want to know what is the difference between winforms in c# .
what is the difference between winforms and windows forms in c#?
Thanks
Winforms and Windows Forms are the same thing. Winforms is the shortened name for Windows Forms.
From Wikipedia:
Windows Forms (WinForms) is the name given to the graphical
application programming interface (API) included as a part of
Microsoft .NET Framework
Additional info from MSDN answer:
Based on my understanding, you want to know the difference between
Windows based application and WinForms application development using
c#. Windows based application is that the application is
developed under Window Operating System, excluding such application
developed under other Operating System like Linux & Unix.
However,there are two kinds of windows based application in .net, WinForm &
Web application. you can develop several different kinds of
Windows-based applications. You can create Windows Forms and Windows
service applications that leverage the power of the .NET Framework, or
you can use Visual C++ to create Windows Win32-based applications
However, the WinForm application is a kind of managed application,
develop on .Net platform. It's the extension of the Windows-based
application. The Windows Forms classes contained in the .NET Framework
are designed to be used for GUI development. You can easily create
command windows, buttons, menus, toolbars, and other screen elements
with the flexibility necessary to accommodate shifting business needs.
The topics in this section provide details about how to use the
features offered by Windows Forms.
I have many years of experience with Windows Mobile, but I have not yet done anything with Windows Phone 7.
I'm interested in knowing what the major differences are between developing for the two platforms. I know they both use C# and .NET, but that's about it.
The biggest different is that the default application platform for .NET on Windows Mobile is .NET Compact Framework (.NET 3.5 SP1) and a "compact" version Windows Forms. For Windows Phone 7, you'll still be dealing with a compact version of the .NET framework, but the main application platform is Silverlight rather than Windows Forms. Silverlight is based on the newer presentation framework WPF.
The other big difference is the OS/platform APIs. Windows Mobile has okay support for hardware APIs, but the OS itself and the hardware tended to be really clunky and hard to work with, from both a developer's and user's perspective. The network connection manager on Windows Mobile is one of the most miserable APIs I've worked with lately. The Windows Phone 7 hardware overall is way nicer, and I would hope that the platform APIs are a little cleaner and less clunky, but I haven't worked with it enough to say at this point.
Another major difference is that for WinMo you use Studio 2008, for Phone you use Studio 2010.
The biggest change is the use of SilverLight now.
Take a look at this...
http://msdn.microsoft.com/en-us/library/ff402529(v=vs.92).aspx
I'm also working in Windows Mobile and was quite excited about Windows Phone 7 but unfortunately it seems to be almost useless for full-on business apps because I believe that you can't have a local sql database running on the device :(
What is the need to use delphi prism instead of Visual studio;
i am a delphi programmer so i like object pascal but what else are that delphi prism have that other does not have
What do you mean by "Delphi Prism instead of Visual Studio"?! Delphi Prism is a pascal-flavor in .NET platform. Visual Studio is an IDE. Delphi Prism uses Visual Studio as its IDE. So when you code in Delphi Prism or debug your prism codes, you are doing it in Visual Studio, just as doing with C# or VB.NET.
.NET is supposed to support multiple programming languages and providing common types and libraries to all languages targeting it. Delphi Prism is just another .NET language. It has access to all the stuff that .NET provides to languages. It also has some distinct language features (refer to PRUZ post).
So you can use Delphi Prism when you want to code in Pascal for .NET platform, or if you really need any of its distinct language features in your .NET applications.
Of course Microsoft's own languages (C#, VB.NET, F#) have little edge in .NET over third-party language providers:
There are so many books and articles - including MSDN -
written about MS languages, or written about .NET with C# or VB.NET sample codes (recently Delphi
Prism added a tool to automatically
convert C# code snippet to Delphi
Prism code).
New .NET features would be
available first to Microsoft's own
languages first, and then to other
languages, so if you need a really
new .NET feature, you might have to
wait a few months to have it in your
favorite language.
And, some IDE features like visual
form designer for .NET compact
edition are only provided for C#
and VB.NET.
Like any other programming language, we don't need Delphi Prism. But Prism is an option for software developers with a Pascal/Delphi background to start developing for DotNET. Is this important? For some, yes. For others, not really.I have over 20 years of experience with Pascal and am familiar with every Delphi version since the first one. But 8 years ago, I also learned C# simply because Delphi was too weak as a tool for developing DotNET applications. And unfortunately, no matter how much Embarcadero/Borland tries, their development of Prism will also be behind the generic DotNET products that Microsoft keeps publishing.The advantage of Prism is that it's an add-on for Visual Studio. And you can use Prism to write applications for the Mono platform, which is used on Apple's Mac computers. It can also work together with C# and VB.NET applications and you can create mixed projects where you use Delphi, C# and VB.NET to create a single product. (Made of multiple assemblies, though.) Prism allows you to create Pascal code that you can use in your regular WIN32 environment but also in DotNET. This code can't be too platform-specific but in general you can get some very good results this way.Delphi Prism isn't fully developed by Borland/Embarcadero, though! It started with RemObjects, who created an alternative compiler for Delphi-like code, but with some additional features that you won't find in regular Delphi code. RemObjects started to just push out Delphi for DotNET from the market, since RemObjects provided a nicer product and they had focused more on the DotNET issues. So the two started to work together to create Prism.Like any programming language, Prism has some features that you won't find elsewhere. If those features are practical always depends on if you can find some practical usage for them. In my personal opinion, if you already have Visual Studio and you're only creating applications for the Windows platform then you won't really need Prism. If you have additional Delphi experience, you might like Prism for some projects. If you need to port a Delphi/WIN32 application to DotNET then Prism might help with that. But I don't know of any advantage that would make Prism a requirement.
Personally I think Delphi Prism do more bad than good for the (real) Delphi ecosystem.
I can not deny that the RemObject's product has many interesting things and technically well done, but as a (real) Delphi programmer and enthusiast I see that thay are dangerously distracting the attention and giving some ambiguos non clear message to new comers and .Net programmers.
A (MS) .Net programmer will never move to D. Prism, only Delphi programmers who wants a smooth transition while leaving the boat.
Since there is no tie between D. Prism and (real) Delphi it was a bad move to name it Delphi. They share some basic pascal syntaxis but that's all. They even do not share their improvments, nor they can be used fully integrated.
I bought Rad Studio for Delphi and C++ but I spend most of my time with Prism. As for the old saw that third party products for net are behind the Microsoft products, I say that is just ignorance talking in this case. Prism is not lacking anything that C octothorpe or Visual Basic has. The net system is best programmed by Hejilsburgs' best language, object pascal, and Rem Objects has been improving the best language for net all the time. Those guys at Rem Objects move fast and make things happen. All the updates come from them, Embarcadero just stands and salutes. By the way, the C# to Prism convertor really works. I grab code at msdn and paste it into Prism with no worries.
You can view old question Will you use Delphi Prism, about many opining about Delphi prism from Delphi developers and others.