Win32 Desktop Applications Calling WinRT APIs on Windows 8: Which Contracts Cross the Boundary

Integration boundary

I am designing an application for Windows 8 where a traditional Win32 desktop process needs to consume functionality that appears to exist only in the Windows Runtime (WinRT) surface, such as the share contract or certain system settings exposed through the Charm bar. The documented model states that desktop apps may call a subset of WinRT APIs, while Store apps are restricted from direct Win32 access, but the exact subset and the activation requirements are unclear to me.

Constraints and uncertainty

The target is Windows 8 (not 8.1), so behaviors added in 8.1 such as boot-to-desktop are out of scope. I need to know whether a plain, unpackaged Win32 executable can activate WinRT components that assume an app-container identity, and whether contract-based features like Share require the calling app to participate in the Modern UI lifecycle rather than running as a background desktop process.

Given the asymmetric interop rules, I am unsure which side of the boundary should own the feature.

Questions

• Which documented categories of WinRT APIs are callable from an unpackaged Win32 desktop process on Windows 8, and which require an app identity?
• Can a desktop application act as a Share source or target through the contract system, or is that restricted to Store apps?
• Does invoking a WinRT API from the desktop trigger the documented full-screen transition to the Modern UI, and can that be avoided?