Category Archives: PowerShell

Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

Jumping WinGet’s Install Technology Hurdle

Leave a comment

Wow! It’s hard to believe that WinGet has been around for over 6 years now (it made its debut on 5/19/2020). Over those years I’ve seen the upgrade block shown in the lead-in graphic many times. I’ve also learned to deal with it in more roundabout ways. Let me call this jumping WinGet’s install technology hurdle, so I can explain one particular technique worth investigating.

What Jumping WinGet’s Install Technology Hurdle Means

The text at the head of the screen cap recommends “Uninstall each package, then install the newer version.” This will work if there’s no other way. But if — as you can see is the case with Oh My Posh (OMP) — there’s an internal update mechanism, this often works just fine without requiring wholesale removal (uninstall old version) and replacement (install new one).

Indeed, it just so happens that OMP will happily update itself at the command line using the built-in command

oh-my-posh upgrade --force

So that’s what I did instead of running one WinGet command to remove the old package, and another to install the new one. This situation pops up when WinGet detects that a normal upgrade is not feasible. It blocks upgrades whenever the install technology changes from one release to the next. That’s how it avoids potential problems with the package and its supporting infrastructure that might otherwise occur.

But the teams who develop such packages know their inner workings. They can (and often do) support such upgrades because they understand how to hand off from the older install technology to the newer one. When I run into this situation, I look for a built-in update mechanism in the package (or its related app) itself. It will often jump the hurdle for me, and let me keep using WinGet thereafter. Indeed, I’ve done this myself with Adobe Acrobat too. Furthermore, GitHub documents similar cases with MS Edge, PowerShell 7, Oracle VirtualBox, LocalSend, and other packages as well.

But Wait…There’s More!

Even after I got to the latest version, I found a couple of older versions of OMP also installed. Ultimately, I DID have to uninstall those to make them go away. That’s because OMP lets multiple versions run in parallel. This time, I used msiexec and the GUIDS (for the no-longer-wanted versions) for that purpose

msiexec /x "{97557535-43B6-44EF-BA97-86563C1AC80A}"
msiexec /x "{85B43182-5A11-40E5-9E09-7EF6EB1CFDF7}"

Now, I’ve got just the one (updated) version and a clean Oh-My-Posh setup. Here in Windows-World, it’s always something. Thank goodness that Copilot was able to help me steer through the wreckage, and clean up the older versions properly. Now I see only the latest version when I run winget list, and OMP is working as it should be. AND I solved a problem I didn’t know I had. Good-oh!

Facebooklinkedin
Facebooklinkedin
Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

WinGet Shows More Icons

Leave a comment

Here’s an interesting and welcome observation. Installing updates this morning, I noticed that 7 of 10 packages showed icons as Winget did its upgrade thing. (And this came from the 2018 vintage ThinkPad X380 Yoga!) Anecdotally, that’s way up from when icons first started showing up Windows Terminal in early March of this year. I’m delighted to see that WinGet shows more icons than ever before. Mostly that happens as more developers start including the necessary image references in their package metadata. In my sample screenshot (5 packages) every one has an associated icon. I’m jazzed!

Why WinGet Shows More Icons Nowadays

Lots of popular apps now include icon Url fields in their metadata (that’s where those images come from: e.g. VLC, Chrome, FireFox, NotePad++, MTPW, etc.). Microsoft has definitely upped its support for icons as well (e.g. Edge, PowerToys, Terminal, VStudio, .NET runtimes, and more). Indeed, there seems to be a growing wave of developer support as more and more packages now sport icons as WinGet interacts with them.

At the same time, says Copilot, “the WinGet backend now caches and serves icons [more] reliably.” These days icons are cached in the content delivery network (CDN), retrieval is faster and better, and broken URLs are getting fixed. The net-net is that more icons are appearing because there are more of them around, and the mechanisms to show them are working better, too.

Here in Windows-World, that counts as progress. Plus, I love the eye-candy that icons provide within the mostly monochrome Windows Terminal environment. How could you not? Good stuff!

If you’ve not yet turned icons on in your Terminal evironment just yet, never fear. I posted about this on April 10 (2026) in an item entitled How to Light Up Winget Icons. Follow its instrux if you’d like to see them for yourself.

Facebooklinkedin
Facebooklinkedin
Insider stuff, PowerShell, Recent Activity, Updates, WED Blog, Windows 11

WinGet List/Install Orders Seldom Match

Leave a comment

If you run winget upgrade --all --include-unknown regularly, you have probably noticed something odd. The packages listed in the upgrade table rarely install in the order they appear. I hit this recently on my ThinkPad X12 Hybrid Tablet, where six packages needed attention: Google Chrome, Microsoft Teams, MiniTool Partition Wizard Free, Oh My Posh, Patch My PC Home Updater, and Windows App. They were listed in one sequence but installed in a noticeably different one. The explanation stems from WinGet’s dependency resolver. It’s worth understanding, and explains why WinGet list and install orders seldom match each other.

Why Do WinGet List/Install Orders Seldom Match?

As you can see in the lead-in screencap, the upgrade table that WinGet displays before installation is sorted alphabetically by package display name — that is the first (Name) column, not the Id column. It’s purely cosmetic: WinGet queries its source index, collects available updates, and orders the results for human readability. The order in that table carries no weight when determining which package installs first. Think of it as a shopping list arranged by aisle label, not a build sequence.

Install Order Shows a Dependency Graph

Before the first installer touches the PC, WinGet’s dependency resolution engine reads every package manifest in the upgrade set. It constructs a directed acyclic graph (DAG) of declared dependencies. Next, it runs a topological sort namedGetInstallationOrder() on the winget source. That produces an install sequence where no package arrives before its pre-reqs are satisfied. This re-ordered queue need not follow name or ID order.

The X12 Hybrid Tablet Run

In the screencap, you see the raw WinGet output from a recent run on the X12 Hybrid Tablet. Six packages are available, listed in alphabetical order by display name — Chrome, Teams, MiniTool, Oh My Posh, Patch My PC, Windows App. The three declared VCLibs and Windows App Runtime dependencies follwing that list reinforce that notion that other elements than those that appear are in the mix. In the end, the actual install order was MiniTool Partition Wizard, Patch My PC…, Chrome, Teams, Windows App, and finally, Oh-My-Posh.

When List Order and Install Order Do Align

Occasionally the two sequences match — but that is coincidence, not design. It happens when none of the packages in the upgrade set declare inter-package dependencies and WinGet’s internal queue order happens to mirror alphabetical sequence. As soon as one package declares a dependency on another — or on a shared runtime — the topological sort reshuffles the queue and the coincidence evaporates.

A Practical Takeaway

No need to manage this manually. Winget’s dependency resolver handles the sequencing reliably. Indeed, fighting it with flags like --skip-dependencies is rarely worth the risk. Tyring to drive this yourself, you might end up with a package that installs against a runtime version it does not actually support. Trust the DAG, watch the dependency notice block that appears before the first installer fires, and you will get a clear picture of why the WinGet upgrade install order looks the way it does.

Next time you notice that WinGet installs packages out of listing order, check the dependency notice block at the top of the install run. That block is where WinGet “shows its work.” That’s where the topological sort result gets laid out in plain text. It is one of those quiet, well-engineered behaviors that rewards users who take a moment to read the output carefully.

Further proof of my earlier contention (see this June 27 post) that “WinGet knows more than it says.” I think so, but you can make  your own judgement. Here in Windows-World, there’s plenty of room for multiple takes on what’s REALLY going on. This is mine…and I’m sticking to it!

 

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, Recent Activity, Updates, WED Blog, Windows 11

WinGet Upgrade Knows More Than It Says

Leave a comment

In running through my usual morning Winget Upgrade drill, I noticed that it found 3 upgrades, but applied only 2. As you can see in the lead-in screencap, it concluded its efforts with a line that reads “1 package(s) have upgrades blocked because newer versions use a different install technology…” To me, this means that WinGet Upgrade knows more than it says, because process of elimination reveals that Microsoft Edge is the missing item.

Why Say: WinGet Upgrade Knows More Than It Says

Microsoft Edge is deeply embedded into the Windows 11 OS.  Indeed, Windows 11 uses WebView 2 as a system component. That also powers the Settings app, widgets, Copilot, Teams, Outlook (new), the MS Store, and more. That’s why Edge usually updates more easily from within its own UI anyway.

In this particular case, something about the install technology changed moving from Version 149.0.4022.96 to Version 149.0.4022.98. That forces WinGet to keep its mitts off, unless users uninstall the old and then install the new in two separate operations.

I elected to jump into the app, do the upgrade, then returned to Windows Terminal to run WinGet Upgrade –all –include-unknown again. As you can see in the lead-in graphic (if you right-click that image to display it in its own browser tab), with Edge manually updated already beforehand, the next check returns “No installed package found matching input criteria.” In WinGet parlance that means “no items need updating here.”

In Windows-World, what you see can sometimes tell you more than what your app or tool output tells you. This is a definite illustration, and explains why I assert that the Windows package manager (i.e. WinGet) and its upgrade facility knows more than it says. Cheers!

Facebooklinkedin
Facebooklinkedin
Insider stuff, PowerShell, Recent Activity, Updates, WED Blog, Windows 11

WinGet Copilot CLI Update Gets Interesting

Leave a comment

By design, the WinGet package manager is pretty conservative about working on apps that are running. With Copilot now active on my desktop most of the time, and even accessible in Windows Terminal (or rather, Intelligent Terminal) this goes double. Yesterday, in fact, my attempt at a WinGet Copilot CLI upgrade gets interesting when it fails with an “access denied” error message. Let’s figure this out, and apply a dead-easy fix.

What to Do When WinGet Copilot CLI Update Gets Interesting

You can see the first Winget failure, the fix, and a successful upgrade in series in the lead-in screencap. That fix provides a way to get Copilot out of the way so WinGet can do its thing without the possibility of messing anything up. Figure that Copilot is nearly always on my systems these days into your consideration and the runtime context.

That fix is:

Stop-Process -Name Copilot -Force -ErrorAction SilentlyContinue

Now, let me explain what’s going on, and this fix does the trick.

Why the First WinGet Upgrade Failed

The root cause is straightforward Windows behavior. The operating system won’t let any process overwrite a running executable. If you had an active terminal session that loaded the Copilot CLI — or any background shell or process that previously invoked it — the old copilot.exe is locked. The installer cannot swap in the new binary, so it fails, and reports explanatory error info.

This is not a WinGet bug. But WinGet could arguably handle it more gracefully. It could detect running processes before the upgrade begins and warn the user. Instead, it downloads everything, then fails at the last step. That may be disconcerting, or perhaps even frustrating, but it’s easily fixed.

The Fix: Kill All Copilot Processes, Then Retry

The fix is a two-step sequence. First, kill any running Copilot processes. Then retry the WinGet upgrade. In PowerShell, do that by running these two commands in sequence:

Stop-Process -Name copilot -Force -ErrorAction SilentlyContinue
winget upgrade GitHub.Copilot

[Note the first two lines are actually a one-liner with a spillover resulting from local formatting; run as a single command.] That’s what the screenshot at the top of this post illustrates. The first command runs cleanly even if no matching process exists. The
-ErrorAction SilentlyContinue flag does that by design and intent.

The second winget upgrade command then finds the package again, verifies the hash, extracts the archive, and this time completes successfully. You will see two confirmations appear: “Overwriting existing file” for the WinGet Links path, and “Command line alias added: ‘copilot’.” Then, finally: “Successfully installed.”

Noteworthy Postscript

A couple of additional observations from this experience deserve mention. First, note that Copilot CLI lists Microsoft.PowerShell (version 7.0.0 or later) as a required dependency. If you have not yet upgraded to PowerShell 7.x, WinGet may attempt to pull that in first. In this case, PowerShell 7.6.2.0 was already current, so that dependency check passed instantly.

Second, if you run WinGet from within VS Code’s integrated terminal, Windows Terminal, or any shell that has previously invoked gh copilot, (gh = GitHub, and is the target for copilot requests in a shell environment) you may hit this exact error. Opening a completely fresh PowerShell window before running the upgrade is often enough to sidestep the issue entirely. In that case, no Stop-Process is needed.

Third, this pattern is not unique to Copilot CLI. Any WinGet-managed package that ships as a standalone executable can run into this same locked-file problem during upgrades. Ditto for Web browsers (e.g. Chrome, Edge, Firefox, etc.) which many users, including your humble correspondent, tend to leave running all the time. For browsers the update may fail, it may not run at all, or you may need to “Relaunch” the browser so the updater applies that change file.

A Predictable Bump in the Road

WinGet is a solid package manager. It delivers smooth, hands-off upgrades nearly all the time. When it stumbles — as it did here — its error messages are descriptive enough for a quick diagnosis and fix.

One command to kill the offending process, a second WinGet command to retry, and you’re done. It is a minor contortion, but now you know that two-step. Here in Windows World, it’s good to keep tools current. To that end, don’t let a transient file lock slow you down. Fixed!

Facebooklinkedin
Facebooklinkedin
Insider stuff, PowerShell, Recent Activity, Troubleshooting, WED Blog, Windows 11

Troubleshooting Flo6 S3 Sleep Oddities

Leave a comment

Now that I’m back to a normal work pattern, I couldn’t help but notice that the power button on my Flo6/MSI B550 Tomahawk PC was blinking this morning. That means it’s sleeping and needs a touch to wake itself back  up. Indeed, that blinking power button is the unmistakable signature of S3 sleep — Suspend to RAM — where the system cuts power to everything except memory. Nobody asked it to do that. Time to find out why it thought that was a good idea. Hence, I found myself troubleshooting Flo6 S3 sleep oddities.

Troubleshooting Flo6 S3 Sleep Oddities: Step 1

My first move with any uninvited sleep behavior is to open an elevated command prompt and run powercfg /a. This dumps a plain-English summary of every sleep state the OS currently considers available — and, crucially, tells you which ones are actually enabled. The lead-in graphic shows what Flo6 reported.

That told me everything I needed to know at a glance. S3 was alive and well. Hibernate was also active. Windows had a full menu of power-down options available to it, and apparently it was helping itself. The next question was: what power plan setting was pulling the trigger?

Step 2: Drilling deeper

To see exactly what the current power scheme was telling Windows to do with sleep, I queried the sleep sub-group directly with powercfg /query SCHEME_CURRENT SUB_SLEEP. The output is verbose, so here’s the relevant section I was hunting for:

0x00004650 is 18,000 decimal — 5 hours on AC power. So Windows was faithfully sleeping Flo6 after 5 hours of perceived inactivity, exactly as I’d told it to in recovering from a recent, ill-advised troubleshooting test that reset all my sleep options. Nothing malicious, nothing mysterious. Just a setting I’d explicitly configured sitting where I’d put it, also wrong. Time to kill it.

Pulling the Plug on the Sleep/Wake Timers

I wanted three things gone: the Sleep After timer, Hybrid Sleep, and Wake Timers. Setting any timeout value to 0 disables it. I ran the following commands, covering both AC and DC (battery) power states for completeness, even though Flo6 is a desktop that will never run on battery:

As a belt-and-suspenders measure, I also went into Device Manager, expanded the Universal Serial Bus controllers node, and for each USB Root Hub, opened Properties > Power Management and unchecked Allow the computer to turn off this device to save power. USB Selective Suspend has a well-documented history of nudging systems toward sleep states in ways that aren’t immediately obvious from power plan settings alone. Worth the two minutes it takes to disable it across the board.

The EC Reset: Clearing the Firmware’s Memory

OS-level changes are necessary, but they don’t always flush stale power-state data that’s been cached at the firmware level. The MAG B550 Tomahawk MAX has an Embedded Controller that can hold onto a previous power state even after you’ve changed every relevant Windows setting. The fix is straightforward: shut Flo6 down cleanly, flip the PSU switch off, unplug the AC cord, then hold the case power button for 15 to 30 seconds. This drains the residual charge and forces the EC to reinitialize from scratch. Reconnect everything, power on, and let the board POST fresh. It’s a small step, but it closes a gap that software alone can’t address.

Verdict: Flo6 Should Stay Awake

Hopefully, Flo6 makes it through the night — and several nights after that — without a single uninvited nap. No blinking power button at 6 AM, no dead monitors, no manual wake required. For extra confidence, I’ve got a scheduled Task Scheduler job logging system uptime to a text file every hour overnight. If S3 ever comes back uninvited, I’ll have a timestamp trail to work from. IMO, one week’s worth of clean logs is good enough for me to call this one closed.

If I’ve missed anything, the blinking power button will be back. I hope not, but here in Windows-World anything is possible. If it’s not “case closed” I’ll report back with an addendum here. Fingers crossed that won’t be needed…

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

WinGet Iconification Is Ongoing

Leave a comment

Yesterday, I had the good fortune to spend an hour on the phone with WinGet team lead Demitrius Nelon. He gave me a “slice of life” view into the many and varied kinds of chicken-and-egg problems his team deals with daily. He also helped me improve my understanding of where and how icons come from inside a sixel-enabled terminal session, including those that WinGet shows. And indeed, WinGet iconification is ongoing and spreading, as I saw this morning when I ran a general upgrade command on the recently clean-installed (and properly enabled) ThinkPad X12 Gen 1 tablet.

Why Say: WinGet Iconification Is Ongoing

Take a look at the output for a winget upgrade –all …  command from the lead-in graphic. Note the first actual upgrade (for OneDrive) shows an icon in that output stream. This is the first visible evidence I’ve seen running WinGet that the tool is including icons outside of the list –details commands. Very interesting!

Doc Info on list –details

Here’s a big snippet from the release notes for WinGet production version v.1.28.190:

New Feature: ‘list –details’

The new feature enables a new option for the list command, --details. When supplied, the output is no longer a table view of the results but is instead a series of show like outputs drawing data from the installed item.

An example output for a single installed package is:

> wingetdev list Microsoft.VisualStudio.2022.Enterprise --details
Visual Studio Enterprise 2022 [Microsoft.VisualStudio.2022.Enterprise]
Version: 17.14.21 (November 2025)
Publisher: Microsoft Corporation
Local Identifier: ARP\Machine\X86\875fed29
Product Code: 875fed29
Installer Category: exe
Installed Scope: Machine
Installed Location: C:\Program Files\Microsoft Visual Studio\2022\Enterprise
Available Upgrades:
  winget [17.14.23]

If sixels are enabled and supported by the terminal, an icon for the installed package will be shown.

I’m glad to see and understand that the stuff I had to figure out more or less on my own through trial and error is now going explicitly into the public record. For the details on how to enable sixel output in your WinTerm sessions, see last Friday’s how-to blog post Light Up WinGet Icons.

Where to from Here?

I expect to see icons popping up all over WinGet in the coming months. I also expect to see more icons popping up in output streams, as the plumbing falls into place. Right now, only about 20% of WinGet’s packages show icons. But that number’s going to jump for sure. Stay tuned, and I’ll tell you all about it.

 

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

How-To: Light Up Winget Icons

Leave a comment

Thanks to numerous requests, I’m providing step-by-step instrux in this unusual second blog post for today. It’s based on something that made me unreasonably happy earlier this week. That is:  WinGet can now display colorful package icons right inside Windows Terminal, rendered via sixel graphics. It’s a small visual upgrade that makes winget list –details output dramatically more readable. You get actual application icons inline with package data instead of a wall of monochrome text. But getting there requires a few specific steps. Here’s the complete recipe so you, too, can light up WinGet icons.

Why Must You Light Up WinGet Icons?

The current production version of WinGet is v1.28.220 as I write this post. The latest Preview version is v1.29.70-preview. Production is still catching up, so preview is a must for the moment. I imagine, though, that this will change with the next production version update. As with all moving targets, this one keeps changing along with everything else!

Step 1 — Get a Preview Version of Winget

Sixel icon support requires WinGet version 1.29.50-preview or later. The current stable release doesn’t include it. Check your version with winget -v. If you’re behind, try this first:

winget upgrade Microsoft.AppInstaller –source winget

If that doesn’t pick up the preview build, head to the microsoft/winget-cli releases page on GitHub, download the latest .msixbundle. If a double-click won’t install it, you can install it manually with Add-AppxPackage. Fair warning: on some machines the Microsoft Store installer handles dependencies automatically. On others, you’ll need to sideload VCLibs and Microsoft.UI.Xaml packages yourself.

Step 2 — Enable Sixels in Winget’s Settings (Not Terminal’s!)

This is the gotcha, and it got me for a short while. I confess: I mixed it up myself. The sixel toggle goes in WinGet‘s own settings file, NOT in Windows Terminal’s settings.json. Run winget settings to open the file. Add or merge a visual block so it looks like this:

{
“$schema”: “https://aka.ms/winget-settings.schema.json”,
“visual”: {
“enableSixels”: true,
“progressBar”: “rainbow”
}
}

The enableSixels: true setting tells WinGet to emit sixel graphics in its output. The progressBar key is optional —”rainbow“, “accent”, and “retro” work well (“sixel” works, but is hard to see). Any of these gives you graphical progress bars during installs, as a nice bonus.

Step 3 — Restart Terminal and Run It

Kill Terminal completely — not just close a tab. Right-click the taskbar icon and close the window, or kill the wt process outright. Relaunch. Then run:

winget list –details

Icons should appear for Win32 packages (exe/msi installers). MSIX packages won’t show icons — that’s a known limitation of the current pipeline, not a configuration error on your part. You can filter to a single package to test things quickly (I chose 7Zip, as it’s at the top of my ASCII sort order):

winget list –details 7zip

What to Expect

Not every package gets an icon. In my testing across two ThinkPads, icon coverage ranged from 26% to 31% of total installed packages. The dividing line is 100% correlated with installer category: Win32 packages (exe/msi) get icons, MSIX packages don’t. That’s an architectural gap Microsoft hasn’t bridged yet.

But what works, works beautifully. The icons are crisp, properly sized, and render instantly. It turns a dull text dump into something you can actually scan visually — which matters when you’re staring at 150+ installed packages trying to figure out what needs updating. Once you’ve got it set up, you won’t want to go back to the plain-text version. Cheers!

Facebooklinkedin
Facebooklinkedin
Cool Tools, PowerShell, WED Blog, Windows 11

Some Have Icons, Others Don’t

Leave a comment

Now that the adrenaline rush from getting icons working in WinTerm has subsided, I’ve started looking more closely at which items actually display icons in response to winget list –details. My conclusion from this analysis? Some have icons, others don’t. Indeed, the number of qualifying items is less than I originally thought: exactly 37 of the 143 total packages that winget manages show me something pretty to look at. ‘Sup with that? Here’s my take…

Which Some Have Icons, Others Don’t?

The test machine is a Lenovo ThinkPad X12 Gen 1 Hybrid running Windows 11 — a clean-ish install with the usual factory bloatware and a handful of my own tools layered on top. Running winget list --details produces 143 packages. Of those, exactly 37 display colorful, sixel-rendered icons in the terminal output. The remaining 106 show nothing. No icon, nor placeholder. No ghostly outline. Just… text.

What’s striking is how that output is organized. All 37 icon-bearing packages appear first in the output stream, clustered together like a parade of floats. Then there’s a visual cliff — you scroll past the last colorful logo and drop straight into a desert of monospaced text. It’s like walking from a gallery opening into a DMV waiting room. Same terminal. Same command. Two completely different experiences.

Twenty-six percent. That’s the icon coverage rate. On a machine with 143 packages, barely a quarter of them get the visual treatment. The other 74%? It’s still 1985 out there.

The Installer Category Absolutely Rules

Here’s where things get interesting — and by “interesting” I mean “so clean it almost feels like a prank.” I started looking for the variable that separates the haves from the have-nots. Publisher? Nope — Microsoft shows up on both sides. Source repository? Irrelevant. Architecture? x64 and x86 packages appear in both camps. Update date? No correlation. Then I looked at the Installer Category field, and the mystery evaporated.

The Pattern

Every single package with an icon has Installer Category exe or msi. These are traditional Win32 desktop applications installed via ARP (Add/Remove Programs) entries. Every single package without an icon has Installer Category msix — modern packaged apps from the Microsoft Store or sideloaded MSIX bundles.

There’s a 100% correlation. Not 98%. Not “mostly.” One hundred percent. Win32 equals icons. MSIX equals no icons. The dividing line isn’t publisher, isn’t source, isn’t architecture, isn’t age. It’s installer category, and nothing else.

What Does This Mean?

Why does this make sense architecturally? Because the two package types get their metadata from fundamentally different places:

  • Win32 packages (exe/msi) live in the winget community repository, where their manifest files include IconUrl fields pointing to PNG images. Winget fetches those URLs, converts the images to sixel format, and Terminal renders them inline. Clean pipeline. Works beautifully.
  • MSIX packages get their metadata from the Microsoft Store catalog or from the AppxManifest.xml embedded inside the package itself. Neither of these sources exposes icon URLs in a format that winget’s sixel rendering pipeline can consume. The icons exist — the Store shows them, Dev Home shows them, the Start Menu shows them — but terminal-facing winget can’t reach them through the MSIX metadata path.

Searing Irony: MS Apps Are Holdouts

And here’s where the comedy writes itself. Of the 106 iconless MSIX packages on this PC, 96 are published by Microsoft. Let that sink in. The company that built winget. The same outfit that built Windows Terminal. The company that built the sixel rendering pipeline. The developers who invented the MSIX packaging format… can’t show its own icons in its own tool.

We’re not talking about obscure infrastructure components here. The missing-icon list reads like a “Best of Microsoft” compilation album:

  • Flagship apps: Microsoft Edge, Microsoft Teams, OneDrive, Outlook, Paint, Photos, Calculator, Camera, Notepad
  • Windows itself: Windows Terminal, Microsoft Store, Windows Security, Snipping Tool, Windows Media Player
  • Productivity & lifestyle: To Do, Sticky Notes, Phone Link, Quick Assist, Clipchamp, Power Automate
  • Entertainment & social: Xbox, Solitaire, Dev Home

Then there are the framework and runtime packages — the plumbing that nobody sees but everything depends on. .NET Native Frameworks (versions 1.3, 2.1, 2.2), VCLibs (2012, 2013, 2015), UI.Xaml (2.7, 2.8), WindowsAppRuntime (1.6, 1.7, 1.8) — many appearing twice, once for x64 and once for x86. These make up vital Windows infrastructure. You wouldn’t expect icons on a Visual C++ redistributable. But Teams? Edge? Photos? These are flagship consumer applications with instantly recognizable logos. And in the terminal, they’re anonymous.

What Else Is Missing?

The remaining ~10 non-Microsoft MSIX packages without icons are third-party apps that happen to ship as MSIX bundles, mostly OEM-related: Intel Graphics Software, Thunderbolt Control Center, Dolby Audio Premium, Lenovo Vantage, Notepad++ (there’s also an installable version, with icon showing), Realtek Audio Control, Synaptics TrackPoint and TouchPad drivers, and — somewhat poetically — Oh My Posh, a tool whose entire reason for existing is making terminals look prettier.

Why DOES MSIX Fall Behind?

To understand the gap, you have to understand the pipeline. Winget’s icon rendering isn’t magic — it’s a four-step relay race, and MSIX packages drop the baton at the starting line.

Here’s how it works for Win32 packages:

  1. Manifest lookup. Winget looks up the package in its community repository and finds the package manifest YAML file.
  2. Icon URL extraction. The manifest includes an IconUrl field pointing to a hosted PNG or SVG image.
  3. Sixel conversion. Winget fetches the image from the URL and converts it to sixel format — an inline graphics encoding standard that dates back to DEC terminals in the 1980s, now reborn in modern terminals.
  4. Terminal rendering. Windows Terminal, with enableSixels: true in its experimental settings, interprets the sixel data and renders the icon inline, right next to the package name.

For MSIX and Store packages, this pipeline breaks at steps 1 and 2. MSIX packages registered through the Store don’t necessarily have community manifests with IconUrl fields. Their metadata comes from the Store catalog API or from the AppxManifest.xml bundled inside the package. Neither of these sources feeds into winget’s sixel rendering path.

It’s not that MSIX packages don’t have icons — they absolutely do. The Microsoft Store displays them beautifully. Dev Home displays them. The Start Menu displays them. Your taskbar displays them. But the specific pipeline that converts an icon reference into sixel terminal output hasn’t been connected to the MSIX metadata source. The icons are there. The rendering engine is there. The wiring between them? Not yet.

What Comes Next? “Under Construction…”

The good news — and it’s genuinely good news — is that this is just an implementation gap, not a fundamental limitation. Every piece of the puzzle belongs to MS:

  • Winget — Microsoft’s package manager
  • Windows Terminal — Microsoft’s terminal application
  • Sixel rendering — implemented by the Terminal team
  • MSIX — Microsoft’s modern packaging format
  • The Store catalog API — Microsoft’s metadata service

There are no third-party dependencies to negotiate. No standards bodies to petition. No licensing hurdles to clear. Connecting the MSIX metadata path — where the icons already live — to the sixel rendering pipeline is a plumbing job. An important one, but a plumbing job nonetheless.

When (not if) Microsoft bridges this gap, the icon coverage on a typical Windows machine should jump dramatically. We’re talking from 26% to potentially 90% or higher, essentially overnight. On this ThinkPad, that would mean going from 37 icons to 130+. The visual cliff in the winget list output would disappear, replaced by a continuous stream of colorful, identifiable package icons.

The winget-cli GitHub repository is the place to watch. Feature requests and pull requests related to MSIX icon rendering or Store catalog icon integration would be the signal that the coverage expansion is inbound. Given that Microsoft went to the trouble of implementing sixel rendering in the first place — a non-trivial engineering effort — it seems unlikely they’d leave 74% of packages iconless.

One in Four Is a Good Start…

So here we are. The sixel icon feature in Windows Terminal works. It works beautifully, in fact — those 37 Win32 packages look fantastic, their colorful logos rendered crisply inline, transforming a wall of text into something you can actually scan visually. The three-step setup is straightforward. The technology is sound.

It’s just that only 37 apps showed up to the party in full regalia, while 96 of Microsoft’s own applications stand in the corner without name tags. Edge — the browser Microsoft preinstalls on every Windows PC on Earth — doesn’t get an icon. Teams — the collaboration hub Microsoft spent billions promoting — doesn’t get an icon. Windows Terminal itself, the application rendering the icons, doesn’t get an icon. You have to admire the irony, even if you wish you didn’t.

The feature is real. The gap is clear. The fix is feasible. And in the meantime, those 37 Win32 apps with their lovingly rendered sixel icons are living proof that the future of terminal-based package management looks a lot more colorful. Now, somebody needs to connect the rest of the plumbing.

In Windows-World, 26% is a start. A visually delightful, architecturally illuminating, slightly ironic start. But MS can do better. Hopefully, sooner rather than later. Let’s see!

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, WED Blog, Windows 11

WinGet Export/Import Aces App Handling

Leave a comment

After a fortunate accident decided me to clean install Windows 11 on the ThinkPad X12 Detachable Tablet, I had to continue the setup process. For me, that means installing a raft of apps and applications. “This time,” I thought, “Let’s try Winget’s export & import functions.” I did just that yesterday. I’m pleased to report that WinGet Export/Import aces app handling. Indeed I was able to handle 35-plus apps in under 20 minutes. Let me explain…

How WinGet Export/Import Aces App Handling

As with much else in the Windows Terminal/PowerShell environment, WinGet manages export/import operations using a .json (JavaScript Object Notation) file. It’s like XML, except more compact: human-readable, but less verbose.

Step 1 is to instruct the source PC (Flo6, in this case) to export its roster of installed packages. First I started off with a command to grab that roster, and stuff it into a .json file:

winget export -o Flo6-apps.json

Then, I opened that file in notepad to edit out stuff I didn’t want or need. In this case that includes lots of stuff that comes pre-installed on Windows anyway (e.g. Edge, PowerShell, and a bunch of other stuff). It also included apps I knew I wouldn’t want on the X12 (e.g. all the MSI motherboard stuff and utilities, Adobe Acrobat, NVIDIA software, older CrystalDiskX versions, and so forth).

Long Story Short: 58 to 36

By the time I trimmed everything, the number of entries in the .json file dropped from 58 to 36 (the export function skips apps for which WinGet packages don’t exist, so that trimmed the overall number down from 221 to 58 to start with). After that, it was just a matter of using the import function on the receiving X12 PC, like so:

winget import -i Flo6-apps.json
The whole process took about 20 minutes to run. Indeed it is much, much faster than the one-at-a-time approach. It’s even faster than using PatchMyPC Home Updater, whose 500-plus application catalog covers much of the same ground that I like to tread on my setups.

Lessons Learned

Along the way I learned a few things, hopefully worth sharing. First and foremost, I learned to read the export JSON file carefully. I confess: I did miss a couple of things (e.g. MSI version of CPU-Z). I ended up having to do a little cleanup after the import completed. You could do better, by reading — and pruning — the export list more closely than I did.

I also had to do some followup on Windows Terminal/PowerShell setup. That meant adding a nerd font, changing from PS 5.1 to 7.x, and making sure OhMyPosh was working properly. Easily done, but takes a little while.

Now, I’m ready for my next adventure. Here in Windows-World there’s always a new one right around the corner.

Facebooklinkedin
Facebooklinkedin