7

From my understanding creating an application that runs on multiple architectures requires virtualization, and virtualization reduces performance since it creates a layer of abstraction.

With Windows 8 supporting both Intel and ARM architectures should we expect slower performance with a WinRT app versus a .Net app running on an Intel device?

Also, will WinRT support database connectivity and active directory access?

jerrykobes
  • 515
  • 1
  • 4
  • 7
  • 1
    Just realized it's actually 3 different questions in one question... I hadn't even realized your title was completely different than the 1st question in the body, which was the one I originally answered. – haylem Jul 04 '12 at 05:29
  • Where did you read that WinRT has virtualization? That is one huge misconception. .NET and JS are multi-platform and C++ is compiled in both x86 and ARM. There is no virtualization. – Euphoric Jul 04 '12 at 06:58
  • @Euphoric: I think / assume it was just an unvoluntary abuse of the word virtualization to mean abstraction. – haylem Jul 04 '12 at 14:09

2 Answers2

12

From what I've seen, WinRT is actually an "unmanaged" software layer based on native COM objects, so I would NOT expect to see a big performance impact when invoking the APIs. In fact, it's quite likely that these will perform better than .NET apps on the CLR, as they are likely to be "closer to the metal" than pure .NET apps.

Windows 8 Platform

Note also that you can implement invoke WinRT APIs from .NET apps (or, as they want the buzz to pick up and attract web hipsters, in shiny HTML5 + JavaScript), but are free to implement your application entirely in C++ if you prefer and are concerned about additional layers.

WinRT is essentially a COM-based API, although relying on an enhanced COM. [...] WinRT allows relatively easy interfacing from multiple languages, [...] it's essentially an unmanaged, native API. This common [.NET-based ECMA 335] metadata format allows for significantly less overhead when invoking WinRT from .NET applications compared to a P/Invoke, and much simpler syntax.

      - From Wikipedia's WinRT (emphasis mine)

Also, consider looking at the C++/CX Component Extensions Language:

The new C++/CX (Component Extensions) language, which borrows some C++/CLI syntax, allows the authoring and consumption of WinRT components with less glue visible to the programmer compared to classic COM programming in C++ [...]. Regular C++ [...] can also be used to program with WinRT components, with [a] library called Windows Runtime C++ Template Library (WRL), which is similar in purpose to what Active Template Library provides for COM. The MSDN Library, however, recommends using C++/CX instead of WRL.

      - From Wikipedia's WinRT (emphasis mine)

The Guardian also provides an interesting article on the apparent rebuff of .NET in favor of C++ to develop WinRT-based apps.

The same article points to a great explanation of WinRT compared to Silverlight and WPF on StackOverflow.com.

Regarding your other points, WinRT in itself certainly doesn't limit you or prevent you from interfacing to a database or AD. It just doesn't make it easy, and the question is more how you want to do it.

Community
  • 1
haylem
  • 28,856
  • 10
  • 103
  • 119
0

Regarding your question about database connectivity part, as of now winRT does not have support for most of the database drivers. SQLLite is the one which is supported as of now.

Ideal-way would be to access your data layer via services. and your should not be directly connecting to database like sql server, oracle and any other DB for that matter.

you can use Indexed db and sqllite for local data storage options.

Explorer
  • 9
  • 1