Loading WinRT component without referencing the DLL/assembly - c++

I have been experimenting with WinRT components using C#, C++/CX and WRL in C++. So far I managed to do everything I tried even if compared to COM some stuff have changed and are either confusing or frustrating.
The last thing I'm trying and that so far I couldn't do is a basic architecture pattern of COM. I simply want to create an instance of a WRL component without referencing the DLL in the project which is using the component. As far as I remember this is the basic behavior of COM, provide the GUID of the CoClass of the COM, the using program knows only about the interface and CoCreateInstance will dynamically loads the COM and create an instance attached to the interface you're requesting.
I cannot find how to do that with WRL. I have defined few simple interfaces and I cannot even find them in the registry. However as it is possible with COM to use object without the registry and that there is now window metadata I suppose that this is the reason.
Does someone out there knows if this is not a restriction of WinRT (which would make it a very poor architecture...) or in the case it is possible how to achieve late binding with WRL.
To make it clear, in the calling program I would like to only provide the information of the interface (this can be the .h) then I need to be able to create an instance of the WinRT component using its GUID or a moniker name. This is an architecture pattern I have used in C++/COM, C# and Java as you can write an application and support new features without touching a line of the application, not even recompiling it.
Thanks
O. Rouit

So far it's unclear what you're actually trying to do. WRL is just a C++ helper library for WinRT, if you're using C++ (think of it as WRL-is-to-WinRT-as-ATL-is-to-COM).
Let's take C++, since that's the 'most raw' and has no vm or runtime like C# or JS. You're trying to instantiate a WinRT object that you didn't link with? If so, that's simple - ActivateInstance(activateableclassid). The real question is what are you trying to instantiate? If it's a 1st party (inbox/Windows) component, it should just work. This is very much like COM, where there ACID is like a CLSID and ActivateInstance() is like CoCreateInstance().
If you're trying to instantiate a 3rd party WinRT component (not shipped w/Windows), it's a little simpler. The ONLY way to register 3rd party WinRT components is by including them in your package. Packages are isolated from each other, so you cannot have, e.g. AngryBirds deliver a FOO WinRT object and use it in an app in the Scrabble package. Unlike COM where registration is machine wide (or in the rare even you register under HKCU instead of HKLM, user-wide), WinRT 3rd party (package'd) WinRT objects are only registered for use by apps in that package.(1)
(1) That's a little white lie. Technically your application can instantiate WinRT components provided with Windows and WinRT components provided by packages in your package graph. You can make a Framework package which includes WinRT objects, and have your application's package dependent on that. Windows figures our your package depends on the framework and thus your 'package graph' has 2 packages in it -- your app's package and the framework package. BUT you cannot submit Framework packages to the Store. Local development and enterprise/side-loading deployments can do this (they don't go through the Store and thus don't need to meet Store submission criteria), but any application package submitted to the Store can only depend on the Windows provided frameworks (WinJS, VCLibs, PlayReady/DRM). That's how PlayReady works - it's a Framework package containing (among other things) some WinRT objects; if your application's package declares a on it your package graph will contain 2 packages (your app's package + playready's package), and ActivateInstance() can resolve ACIDs across the union of packages in your package graph.
There's a lot of protections built into the application model. This is one of them. This prevents 'COM Hell' and 'DLL Hell' - everything's fine, then 6 months later you install app Y and for no apparent reason app X no longer works. The new appmodel is designed to prevent that scenario.
Another protection is the limitation of where package'd WinRT objects can be found. Even if you put a file in your app's local folder (e.g. ApplicationData.current.localFolder), ActivateInstance() won't find it. WinRT doesn't look under AppData (or oodles of other places) for registered WinRT objects -- only those in your package graph (and 1st party (Windows) components provided with the OS, e.g. StorageFolder).
provide the GUID of the CoClass of the COM, the using program knows
only about the interface and CoCreateInstance will dynamically load
the COM and create an instance attached to the interface you're
requesting.
The WinRT equivalent is to provide the ACID of the runtimeclass of the WinRT [component], the using program knows only about the interface and ActivateInstance() will dynamically load the WinRT [component] and create an instance attached to the interface you're requesting.
The caveat is, the WinRT component's implementation must be registered in your package graph, i.e. must be listed in your app's package's AppXManifest.xml, or a dependency's AppXManifest.xml.
That's at the most raw level, if you deal directly with WinRT at the ABI level. C++ projections are equivalent, just more convenient syntax. The CLR and JS runtimes provide their own additions and variations of enforcement (e.g. search for "windows 8 javascript local vs web compartment") but they just further color the behavior. They can't overrule the underlying OS' baseline behavior.
As Damir noted
You won't be able to put new files to install folder any other way and
that's the only location from which executable code can be loaded by
the app.
"Executable code" comes in varying forms, depending on your definition.
WinRT components can be loaded from other places (Windows provided WinRT components, dependent packages e.g. the PlayReady framework package).
(Non-WinRT, non-COM) 'native' DLLs can be loaded from other places (executable's directory, System32, etc). See Search Order for Windows store apps.
.NET assemblies in DLLs have their own similar restrictions e.g. Assembly.Load().
Some people consider Javascript "code", and there's the whole local vs web compartment thing to further color where code can be resolved from.
As a general rule, you can dynamically load code in a variety of ways, but it needs to be known code. There's no supported way you can create e.g. a C++ app that will load DLLs (WinRT or non-WinRT) that's not known at Store submission time. You can write an app using optional (conditionally loaded) code, you can have 'plugins' -- but they need to be in your package when you submit to the Store.
You can't build e.g. Outlook as is today, where Outlook is submitted to the Store with an open-ended plugin model and sometime later install an OutlookNiftyCalendar add-on which Outlook could find and use. Not in Windows 8.
(there are some ways you can bend this rule a bit in a Javascript app via web compartment, but that's a complex topic in its own right, and even that has limits both hard and soft/policy. And irrelevant if you're not writing a Javascript applications)

Related

Qt app with dynamic set of functionalities

Please let me present the idea. I would like to build a Qt app which allows the user to load functionality from a external file (.dll ?) while the app is running. The file could be downloaded from the internet.
I'm planning to build the user interface with QUiLoader and I think the functionality should come from such an external file. Does it make sense?
As an example, to begin with, I'm imagining to provide the user simple functionality like sum and multiplication. And other functionality should be provided afterwards.
Since I have no ideia where to begin (as the question might suggest), I'm here to ask for directions?
Yes, what you need is a plugin mechanism.
For developing a plugin, you should decide how those plugin to be load and to get information from plugin, i.e. you should define a interface first hand, by that interface, your program can communicate with plugins developed by others.

Integrating TideSDK with C *.dll

I've already written some backend *.dll files that I intend to use in a project. I need to visualize a simulation of the code, for which I intend to use charts and graphs from Chart.JS, by using it along with TideSDK for a desktop application.
I have no clue on how to call the C libraries via JS though. And I want to avoid creating wrapper classes in Python and going through that circuitous route. Any other options? Or are there any alternatives when trying to create an HTML/CSS/JS desktop application connected to a backend C/C++ library? Will AppJS make things easier?
TideSDK is capable of extension with modules that can be compiled and included in its runtime. It was written to be extended but I would recommend waiting for TideKit. TideSDK is a bit old and setting up a toolchain could be problematic at this point.
We've been investing in a broader vision with TideKit that is getting ready for release. You will be able to extend it with native modules and you won't need to wait too much longer to see what we've been up to. http://youtu.be/aE7gN-d0GhUthat
If you have started anything with TideSDK, you will be able to migrate your code easily to TideKit. The ability to work with with native or JavaScript modularity, and to develop for all screens from a single project code base is where all our efforts have been going.
Note that AppJS was discontinued earlier this year. An alternative is writing C extensions in node through node-webkit. Note that if you are going cross platform on this and you needed OSX as well, you cannot achieve Apple AppStore compliance with node-webkit due to private APIs as a result of its port of webkit.

Using a C++ CLR Library in a C# Metro Application

I have been writing some applications for windows metro in c# and have been trying to create a twitter program, using the tweet sharp library, that will allow the user to tweet and view the tweets of the people they are following and check for updates in a background task.
The problem that I was having is I wanted to use c++ for sorted maps. The sorted maps was, at least what I found, to be the quickest way to sort through and organize the large amounts of tweeters and their tweets. Which is especially helpful because of the constraints that background tasks have when it comes to accessing the CPU.
But I found that my CLR libraries couldn't be used in my metro application because of the improper build target for the dll file.
Is it possible to use a CLR library with WinRT applications and deploy them on the app store or does anyone know of an alternative way to manage these large amounts of tweets considering the CPU constraints.
Thanks in advance.
According to this post it currently is not possible.
Apart from that, WinRT has a different system for processing metadata in apps and class libraries.
For one, you can look at .NET for Windows Store apps overview and secondly about CLR integration (C++/CX).

How to use SQLite within a WinRT DLL?

I am trying to develop a WinRT DLL which uses SQLite to write database.
But it seems like some win32 APIs in SQLite source code are not supported by metro, such as, LoadLibraryW, GetTempPathA.
Is there any way to compile SQLite source code or use SQLite with WinRT DLL?
Well you could always link sqlite3 statically and define new functions for accessing files etc via sqlite3_vfs.
In VS2012 there is an extension now called SQLite for Windows Runtime. You can download and install this via Visual Studio (requires a restart of the IDE). Then, go to your WinRT project, Add a Reference, under "Windows" choose "Extensions" and you should see it.
There's a winrt branch of SQLite now that only uses supported API. On top of that, we implemented SQLite3-WinRT, a WinRT component that allows using SQLite in any of the WinRT languages.
rename sqlite3.c to sqlite3.cpp
replace LoadLibrary with LoadPackagedLibrary
Fix lots of syntax errors.
From the SQLite site
SQLite version 3.7.13 adds support for WinRT and metro style applications for Microsoft Windows 8. The 3.7.13 release is coming sooner than is usual after the previous release in order to get this new capability into the hands of developers. To use SQLite in a metro style application, compile with the -DSQLITE_OS_WINRT flag. Because of the increased application security and safety requirements of WinRT, all database filenames should be full pathnames. Note that SQLite is not capable of accessing databases outside the installation directory and application data directory. This restriction is another security and safety feature of WinRT. Apart from these restrictions, SQLite should work exactly the same on WinRT as it does on every other system.
Tim Heuer provides a walk-through of building a metro app using SQLite on his blog
Let me add some remarks on using sqlite/winrt that may save you some headaches:
Winrt allows you to write only to specific folder (c:\users\<user>\My documents\<app>). You have to put your DB here. (Trivial in managed environment.)
Time from time Sqlite uses temp files. (Complex queries that need transient indices, vacuum etc.) These files also must be created in the app folder, but sqlite won't do this unless you set it with temp_store_directory pragma. If you don't do this, you may get random user bug reports.
Note that above pragma is officially deprecated. Ignore this. Native coders might be tempted to use global variable sqlite3_temp_directory instead (encouraged way), but the current binary release (dll) does not publish this variable. (You can do it yourself, but then change sqlite sources and use _declspec(dllexport) attribute; def file does not work.)
Don't rely too much on sqlite file operations. The implementation is not particularly good. For example testing of write access will succeed even if you don't have write permissions.
Apart from this there seem to be no problems with winrt. More advanced users might supply their own (better) winrt driver. It is not too difficult...

Portable C++ Component Design

I've been using COM and .NET assemblies in the past to develop component-based-systems. Now I'm going to work on a cross-plattform-C++-project and want to structure the code in components aswell…
Obviously COM and .NET are not an option, as COM is not available anywhere but Windows and Assemblies would add dependencies to the .NET framwork which may be not available at the target system.
I'm aware that due to ABI-differences I won't be able to move components between different operating systems without recompilation, but I would like to write the code in a manner, that it's compatible at source-code-level.
Is there any system/framework that enables such a architecture in C++?
I have worked with such a system in the past - we basically re-invented COM. If you are interested in that approach, check out this great article: http://msdn.microsoft.com/en-us/library/ms809983.aspx
The Mozilla suite uses a framework called XPCOM. Never used it myself, but the implication it's supposed to be like Microsoft's COM but portable. That's the only in-process component system I know of that's native code based; if you're working in Java, there's OSGi.
These days most Unix software appears to use distributed component models, where components live in different processes. The current fashionable system appears to be DBus; KDE3 used an alternative called DCOP; and of course if you want to go this route there's good old CORBA.
If you can live with a Qt dependency (only core libraries, no GUI libs), you could have a look at the CTK Plugin Framework
It is licensed under Apache 2.0 and is a dynamic C++ component system with an API which is nearly identical to OSGi.
Maybe this: http://blog.redshoelace.com/2007/09/what-is-boostextension.html