sha - Dave's Blog


Win10 PWA Terminology

2018 May 31, 8:26

Folks familiar with JavaScript UWP apps in Win10 have often been confused by what PWAs in Win10 actually are. TLDR: PWAs in Win10 are simply JavaScript UWP apps. The main difference between these JS UWP Apps and our non-PWA JS UWP apps are our target end developer audience, and how we get Win10 PWAs into the Microsoft Store. See this Win10 blog post on PWAs on Win10 for related info.

Web App

On the web a subset of web sites are web apps. These are web sites that have app like behavior - that is a user might call it an app like Outlook, Maps or Gmail. And they may also have a W3C app manifest.

A subset of web apps are progressive web apps. Progressive web apps are web apps that have a W3C app manifest and a service worker. Various OSes are beginning to support PWAs as first class apps on their platform. This is true for Win10 as well in which PWAs are run as a WWA.

Windows Web App

In Win10 a WWA (Windows Web App) is an unofficial term for a JavaScript UWP app. These are UWP apps so they have an AppxManifest.xml, they are packaged in an Appx package, they run in an App Container, they use WinRT APIs, and are installed via the Microsoft Store. Specific to WWAs though, is that the AppxManifest.xml specifies a StartPage attribute identifying some HTML content to be used as the app. When the app is activated the OS will create a WWAHost.exe process that hosts the HTML content using the EdgeHtml rendering engine.

Packaged vs Hosted Web App

Within that we have a notion of a packaged web app and an HWA (hosted web app). There's no real technical distinction for the end developer between these two. The only real difference is whether the StartPage identifies remote HTML content on the web (HWA), or packaged HTML content from the app's appx package (packaged web app). An end developer may create an app that is a mix of these as well, with HTML content in the package and HTML content from the web. These terms are more like ends on a continuum and identifying two different developer scenarios since the underlying technical aspect is pretty much identical.

Win10 PWA

Win10 PWAs are simply HWAs that specify a StartPage of a URI for a PWA on the web. These are still JavaScript UWP apps with all the same behavior and abilities as other UWP apps. We have two ways of getting PWAs into the Microsoft Store as Win10 PWAs. The first is PWA Builder which is a tool that helps PWA end developers create and submit to the Microsoft Store a Win10 PWA appx package. The second is a crawler that runs over the web looking for PWAs which we convert and submit to the Store using an automated PWA Builder-like tool to create a Win10 PWA from PWAs on the web (see Welcoming PWAs to Win10 for more info). In both cases the conversion involves examining the PWAs W3C app manifest and producing a corresponding AppxManifest.xml. Not all features supported by AppxManifest.xml are also available in the W3c app manifest. But the result of PWA Builder can be a working starting point for end developers who can then update the AppxManifest.xml as they like to support features like share targets or others not available in W3C app manifests.

PermalinkCommentsJS pwa uwp web

Tweet from David Risney

2016 Dec 10, 10:07
Seems like @pushalotapp isn't on the Microsoft Store anymore? Will it come back?

Tweet from shauna

2016 Dec 7, 10:10
I see Melania's fight against cyberbullying is going well.

Parsing WinMD with .NET reflection APIs

2016 Nov 2, 6:13

Parsing WinMD files, the containers of WinRT API metadata, is relatively simple using the appropriate .NET reflection APIs. However, figuring out which reflection APIs to use is not obvious. I've got a completed C sharp class parsing WinMD files that you can check out for reference.

Use System.Reflection.Assembly.ReflectionOnlyLoad to load the WinMD file. Don't use the normal load methods because the WinMD files contain only metadata. This will load up info about APIs defined in that WinMD, but any references to types outside of that WinMD including types found in the normal OS system WinMD files must be resolved by the app code via the System.Reflection.InteropServices.WindowsRuntimeMetadata.ReflectionOnlyNamespaceResolve event.

In this event handler you must resolve the unknown namespace reference by adding an assembly to the NamespaceResolveEventArgs's ResolvedAssemblies property. If you're only interested in OS system WinMD files you can use System.Reflection.InteropServices.WindowsRuntimeMetadata.ResolveNamespace to turn a namespace into the expected OS system WinMD path and turn that path into an assembly with ReflectionOnlyLoad. code programming winmd winrt

Tweet from Casey Kolderup

2016 Oct 19, 5:18
Github is down, which gave me the opportunity to share this incredible moment with all of you

Tweet from SwiftOnSecurity

2016 Oct 13, 11:02
Give flair to users with 2FA turned on. Make it a status symbol, then public shaming takes over. "U don't have 2FA what if you get hacked?"

Tweet from Pwn All The Things

2016 Sep 6, 10:47
Oh My God. This report is such a troll. Hackers cleverly hid their searching of network shares using "SMB protocol"

WinRT Toast from PowerShell

2016 Jun 15, 3:54

I've made a PowerShell script to show system toast notifications with WinRT and PowerShell. Along the way I learned several interesting things.

First off calling WinRT from PowerShell involves a strange syntax. If you want to use a class you write [-Class-,-Namespace-,ContentType=WindowsRuntime] first to tell PowerShell about the type. For example here I create a ToastNotification object:

$toast = New-Object Windows.UI.Notifications.ToastNotification -ArgumentList $xml;
And here I call the static method CreateToastNotifier on the ToastNotificationManager class:
$notifier = [Windows.UI.Notifications.ToastNotificationManager]::CreateToastNotifier($AppUserModelId);
With this I can call WinRT methods and this is enough to show a toast but to handle the click requires a little more work.

To handle the user clicking on the toast I need to listen to the Activated event on the Toast object. However Register-ObjectEvent doesn't handle WinRT events. To work around this I created a .NET event wrapper class to turn the WinRT event into a .NET event that Register-ObjectEvent can handle. This is based on Keith Hill's blog post on calling WinRT async methods in PowerShell. With the event wrapper class I can run the following to subscribe to the event:

function WrapToastEvent {
param($target, $eventName);

Add-Type -Path (Join-Path $myPath "PoshWinRT.dll")
$wrapper = new-object "PoshWinRT.EventWrapper[Windows.UI.Notifications.ToastNotification,System.Object]";
$wrapper.Register($target, $eventName);

[void](Register-ObjectEvent -InputObject (WrapToastEvent $toast "Activated") -EventName FireEvent -Action {

To handle the Activated event I want to put focus back on the PowerShell window that created the toast. To do this I need to call the Win32 function SetForegroundWindow. Doing so from PowerShell is surprisingly easy. First you must tell PowerShell about the function:

Add-Type @"
using System;
using System.Runtime.InteropServices;
public class PInvoke {
[DllImport("user32.dll")] [return: MarshalAs(UnmanagedType.Bool)]
public static extern bool SetForegroundWindow(IntPtr hwnd);
Then to call:
[PInvoke]::SetForegroundWindow((Get-Process -id $myWindowPid).MainWindowHandle);

But figuring out the HWND to give to SetForegroundWindow isn't totally straight forward. Get-Process exposes a MainWindowHandle property but if you start a cmd.exe prompt and then run PowerShell inside of that, the PowerShell process has 0 for its MainWindowHandle property. We must follow up process parents until we find one with a MainWindowHandle:

$myWindowPid = $pid;
while ($myWindowPid -gt 0 -and (Get-Process -id $myWindowPid).MainWindowHandle -eq 0) {
$myWindowPid = (gwmi Win32_Process -filter "processid = $($myWindowPid)" | select ParentProcessId).ParentProcessId;
} c# powershell toast winrt

Retweet of doctorow

2016 Feb 8, 5:08
A digital, 3D printed sundial whose precise holes cast a shadow displaying the current time …

Retweet of rcallimachi

2016 Jan 7, 2:51
Wow: When is the last time a sitting American president penned an OpEd in the New York Times? Barack Obama just did …

Retweet of KyloR3n

2016 Jan 3, 9:46
*writes "search your feelings. you know it to be true" on his Converse in black sharpie*

Retweet of soaj1664ashar

2015 Dec 5, 12:52
[Blogged]: The Dark Side of Comments: … #XSS #comments

Retweet of creativecommons

2015 Nov 24, 12:13
Why is a museum suing Wikipedia for sharing? … via @communia_eu

Retweet of sharonodea

2015 Sep 30, 5:53
Founder of #Peeple, an app designed to collect unsolicited feedback doesn't appear to like unsolicited feedback.

Tweet from David_Risney

2015 Aug 17, 9:08
Watching ST VOY. Cool to foreshadow Year of Hell in Before and After, but why don't they recognize the Krenim from Kes' report?

Eminem meets Beatles:

2015 Apr 14, 8:08

Eminem meets Beatles:


Eminem meets Beatles:

2015 Apr 14, 8:08

Eminem meets Beatles:


Retweet of stshank

2015 Apr 13, 9:23
UIforETW: New open-source tool from Google to make it easier to use Microsoft Event Tracing for Windows (aka xperf): 

laughingsquid:‘Find a Fish’, The Classic Surreal Intermission...

2015 Apr 8, 5:02


‘Find a Fish’, The Classic Surreal Intermission Sketch From Monty Python’s 1983 Film ‘The Meaning of Life’

Surprisingly often quoted ‘a fish fish fishy, oh!’ with my roommates in college.


laughingsquid:‘Find a Fish’, The Classic Surreal Intermission...

2015 Apr 8, 5:02


‘Find a Fish’, The Classic Surreal Intermission Sketch From Monty Python’s 1983 Film ‘The Meaning of Life’

Surprisingly often quoted ‘a fish fish fishy, oh!’ with my roommates in college.

Older Entries Creative Commons License Some rights reserved.