OAuth scopes in Azure DevOps 2020

Here's another OAuth scope dump from the latest on-prem instance of Azure DevOps.

The same caveat applies: some of those might be cloud only.

It's AzDevOps all the way down

Oy vey. Some posts ago, I've mentioned that all TFS Azure DevOps collection databases had the same schema, haven't I? Well, not quite.

Full circle

Following up from my last post about generating a CSR, I went through the motions of testing the full cycle for said CSR. I'd sign it with a bogus (but locally trusted) authority certificate, install the signed cert locally, export the PFX, install it on a Web server, select the cert for TLS on an IIS website, and hit it with a bunch of desktop browsers. The certificate works as expected.

CSR with PowerShell

Following up from a past post, I've decided to put together a PowerShell script for generating a certificate signing request for a certificate authority to sign. Here's the script, but some commentary is in order.

c:\>TFS

Today, we're going to take a look at another wonderfully disjoint area of TFS Azure DevOps administration - command line clients. There are four Microsoft provided ones (that I know), and another that's probably the best of them all.

One core, two cores...

I mentioned before that Windows 10 came with two flavors of SAPI, 5.4 proper and OneCore, internally also marked as v.5.4. The System.Speech.Synthesis classes of the .NET library employ the classic SAPI, while the Windows.Media.SpeechSynthesis classes of the UWP library run on top of OneCore. You can see that by the contents of the voice Id values. Native applications that target SAPI directly, via COM, have the option of using either. Why was SAPI forked like that - I'm not sure.

More TTS

Continuing with the Windows speech synthesis (SAPI) theme. The situation with Sayaka is a crying shame, no question there. As for Ayumi and Ichiro, they are perfectly compatible with SAPI 5.4 proper. Move their tokens to HKLM\..\Speech, and they are perfectly willing to talk, too.

Writing to HKLM requires elevation, though. Maybe those apps that would like to register extra voices on startup can do so in HKCU. SAPI has a key there, too.

Who wants to meet Sayaka-san?

And now, for something completely different - speech synthesis in Windows (AKA SAPI).

Windows 10 comes with a built-in speech engine. In fact, it comes with two - SAPI 5.4 proper, and SAPI 5.4 OneCore (four on a 64-bit OS). They all coexist side by side. The data files are largely shared.

My specific interest comes from a desire for spoken Japanese language. One can install the Japanese text-to-speech (TTS) voices in Settings, under Time and Language/Speech. Once you do, there are three Japanese voices in the list - Ayumi, Haruka, and Ichiro. Together with the three English voices, six total.

That's the Windows settings, but what about SAPI applications? Turns out, SAPI 5.4 gets only Haruka, while OneCore get all three. So going forward, my interest was limited to OneCore. The more voices, the merrier.

SAPI stores its voice list in the registry - different keys for SAPI 5.4 proper and 5.4 OneCore. Yet if you look at the registry key HKLM\SOFTWARE\Microsoft\Speech_OneCore\Voices\Tokens, you will see seven subkeys. The seventh one is Microsoft Sayaka. Why isn't she present in the list and why can't applications find her?

A dwarf is sitting under a tree...

I've published a package on PyPI! That's a first for me.

DWARF Explorer (dwex for short) is a cross platform GUI utility in Python for visualizing the debug information in DWARF format. It was initially meant for iOS dSYM bundles and Android unstripped native binaries, but runs under Windows, MacOS, and Linux. For completeness' sake, it takes Windows' PE files, too, with the caveat that the primary format of debug symbols on Windows isn't DWARF, it's PDB.