Category Archives: Cool Tools

PC Manager Browser Space Is Mostly Volatile

I just ran PC Manager’s Deep Cleanup on my Flo6 desktop. As usual, it cleaned a lot of what it found: 11.4 of 14.6 GB wound up gone. Also, as usual it shows around 3GB remaining for my three browsers — namely, Firefox, Chrome and Edge. So I asked Copilot: why do these programs show up in their numbers? It opines (and I concur) that PC Manager Browser space is mostly volatile. Indeed the figure is kind of illusory. It’s worth understanding before treating browser cache cleanup as a valid way to recover disk space.

Take a look at the final results from my Deep Cleanup just now from the lead-in screencap. Notice that it shows 1 GB for Firefox, 1.6 GB for Chrome and ~277 MB for Edge. Keep those numbers in mind.

Why Say: PC Manager Browser Space Is Mostly Volatile?

Here’s the core issue: browser cache is engineered to be ephemeral. It’s written, read, and purged in a continuous cycle governed by cache-expiry headers, per-origin storage quotas, and the browser’s own self-management routines. The moment you fire up your browser after a cleanup and start clicking around, the cache begins refilling. Within 30 to 60 minutes of ordinary browsing, most browsers will have rebuilt several hundred megabytes of cached content — sometimes more, depending on how media-heavy the sites you visit are.

Chrome and Edge both enforce internal storage quotas and will self-evict stale or low-priority cache entries automatically when those quotas are approached. In other words, the browser is already managing this space on your behalf, without you lifting a finger. Firefox operates similarly under its own quota management framework.

In short: you didn’t “save” 2 GB when you cleared browser cache. You borrowed 2 GB temporarily — until your next browsing session rebuilt most of it. Sort of like the storage equivalent of pushing water uphill.

Check out these numbers: they represent the memory footprint for my three browsers.

Note that those numbers fall near the potential savings that PC Manager reports for each one. That’s no coincidence, it simply represents reclaiming space that the browsers will suck back up as soon as you turn them back on, and open some tabs.

What Real, Valid Savings Look Like

Contrast browser cache with the categories that represent genuinely permanent space recovery. Windows Update cleanup files — the old installer packages and superseded component stores left behind after updates — can run anywhere from 500 MB to 2 GB, and once deleted, they do not return. Windows Error Reporting logs are similarly non-regenerating under normal conditions. The Recycle Bin is obvious. Orphaned app data left behind by software you’ve already uninstalled is another solid target. Thumbnail cache does rebuild, but far more slowly than browser cache, so it offers a more durable short-term gain.

A typical monthly cleanup on a moderately used Windows 10 or 11 machine might yield up to a 5 GB of truly permanent, non-regenerating space. That’s a lot less dramatic than the headline figure PC Manager flashes at you — but it’s real. And it stays real.

Do You Need to Clean Browser Cache?

Maybe, but go into that effort with adjusted expectations. Clearing browser cache could deliver a brief responsiveness improvement. Thus, if the cache has grown bloated with stale or corrupt entries, or to make room in storage-intense scenarios, such as recording a long screen capture session, installing a large application, or freeing up breathing room on a drive that’s genuinely running tight. Otherwise, don’t expect much either in the short or long term.

If you’re truly short on disk space, PC Manager’s Large Files finder and the Windows Update Files cleanup row are far more useful targets. The browser cache, left alone, will look after itself. That’s the point!

Here in Windows-World keeping things clean does have its reward. But some things are more worth cleaning up than others. Browser cache is near the end of that list, and best left alone.

Facebooklinkedin
Facebooklinkedin

Understanding Occasional dllhost.exe Crashes

Every now and then, I drop into Reliability Monitor on my primary desktop PC (Flo6). Aka Relimon, this built-in tool provides rough and ready summaries of recent system events. Placement puts emphasis on errors and warnings. In looking over recent stuff, I observed that dllhost.exe has “stopped responding” 4 times in the period from July1 thru 18. I turned to Copilot to aid in understanding such dllhost.exe crashes. Though that frequency may sound ominous or concerning, seems like it’s pretty typical. You can see the latest report for July 1-20 in the lead-in graphic.

Why Bother Understanding Occasional dllhost.exe Crashes?

In examining the critical errors shown in ReliMon’s three-week time window, I saw that dllhost.exe “stopped responding” item on July 1, 8, 17,  and 18. So I shared that info with Copilot and asked “Should I be concerned?” It responded as follows:

Four dllhost.exe crashes over an 18‑day span is well within the “normal Windows background noise” range. It’s not a sign of system instability, corruption, or anything you need to lose sleep over. Let me break down what that frequency actually means in practical terms.

dllhost.exe (COM Surrogate) is invoked constantly—every time Explorer generates thumbnails, previews, metadata, or runs certain shell extensions. On a typical Windows system, dllhost.exe may spin up hundreds of times per day.

So:

  • 4 crashes / 18 days ≈ 1 crash every 4–5 days
  • That’s extremely low for COM Surrogate failures
  • It suggests occasional thumbnail/preview hiccups, not systemic trouble

Driving the Bus Means Wear and Tear

Given that running dllhost.exe during file access can easily cause error events to protect Explorer itself, I’m comforted to know that this occurs by deliberate design. I’ve run into a variety of .com related error events over the years that can be safely ignored (e.g. 1601, 1603, etc.). With information from Copilot in hand, and references to back it up, I’m OK with seeing this in my reliability monitor output.

Here are some useful and interesting supporting materials:

Here in Windows-World, Copilot can be a valuable source of information and insight. But I’ve learned through experience that you must check its sources to separate fact from fiction. If you use it for the same purposes, be sure to check its work (and assertions). In this case, I’m comfortable with the information it’s drawing upon and inclined to trust its veracity. Good stuff!

Facebooklinkedin
Facebooklinkedin

Cloud Rebuild Requires Registry Access

When I read about the incorporation of a Cloud Rebuild feature in Windows 11, Experimental Build 26300.8772 on July 6, I had to have it. First, of course, I had to upgrade a machine to that release. Alas, I hit a few snags on the way (see my July 15 post for deets) but eventually I got there. Then I used the “Create a recovery drive” facility to build a brand-new bootable WinRE for that PC (a honkin’ ThinkStation P3 Ultra Gen 2). But when I booted to that media, WinRE did not appear amidst its menus. The only way to see it is to use Settings > System > Recovery > Restart Now, and then to select that option under the Troubleshoot menu when on-disk WinRE boots instead. Why? Because getting to Cloud Rebuild requires registry access. I’ll explain…

Accessed via on-disk WinRE, there it is!

Why Cloud Rebuild Requires Registry Access

Cloud Rebuild is a new WinRE recovery option that downloads a fresh Windows installation directly from Windows Update and reinstalls it onto the machine. It preserves nothing — no apps, no settings, no user data. Think of it as the “nuclear but automatic” option: positioned for situations where Reset This PC fails or the local recovery image is corrupted beyond use. It does, however, require an active internet connection and relies on Windows Update to supply appropriate NIC drivers. In short, the cloud does the heavy lifting so you don’t have to carry a USB installer everywhere.

So where does the registry come into play? When you create a recovery UFD from a machine running build 26300.8772, Windows faithfully copies the host’s WinRE.wim to the drive — byte for byte. The Cloud Rebuild code is therefore physically present on that UFD. So why doesn’t the tile appear?

When you boot from the UFD, WinRE runs as a fully isolated, self-contained instance. It has no path to the host machine’s registry — that OS partition might not even be mounted. The enablement check silently fails, and the Cloud Rebuild tile simply doesn’t appear. No error, no explanation, no tile. Additionally, Cloud Rebuild is riding a Controlled Feature Rollout in this build, which means not every enrolled Insider machine receives it simultaneously. That adds yet another variable into an already narrow set of conditions.

Here’s the Catch!

The following insight matters, when it comes to planning how to make best and proper use of Cloud Rebuild. Its registry dependency means this feature is available in a narrower slice of real-world failure scenarios than one might hope. Walk through this landscape:

  • Scenario 1 — OS corrupted, disk intact: Native WinRE auto-triggers after two or three consecutive failed boots. The registry is still readable. Cloud Rebuild appears and does its job. This is the sweet spot the feature was designed for.
  • Scenario 2 — Recovery partition (or files) deleted or corrupted: Native WinRE is unavailable, so you reach for the UFD. However, Cloud Rebuild won’t appear on the UFD because the isolated WinRE instance can’t reach the host registry. You’re on your own with whatever tools that generic WinRE environment provides.
  • Scenario 3 — SSD or NVMe failed or dead: Nothing works. Not Cloud Rebuild, not native WinRE, not the UFD for anything disk-related. At that point, the conversation is about replacement hardware, not recovery software.
  • Scenario 4 — BCD or boot files corrupted: Startup Repair may intervene and restore enough of the environment for native WinRE to launch. Cloud Rebuild visibility in that scenario is uncertain and depends on how much of the OS partition structure survived intact.

Microsoft’s own documentation quietly confirms this scope by requiring that the device have “a healthy Windows Recovery Environment” for Cloud Rebuild to function. The architectural intent is clearly to cover soft OS failures — driver corruption, bad cumulative updates, damaged system files — where the underlying disk is intact and the recovery partition is alive. That’s a real and valuable use case. It does not, however, cover every use case.

Cloud Rebuild’s Place in the Recovery Toolkit

For Cloud Rebuild to be a genuine lifeline, your recovery partition must survive whatever broke Windows in the first place. That’s a reasonable bet against driver corruption, a bad update, or OS file damage. But it’s not a bet you should make against disk failure or deliberate partition cleanup.

Additionally, you should test Cloud Rebuild from within a running Windows session before you need it for real. The path is simple: Shift+Restart → Troubleshoot → Recovery and uninstall → Cloud Rebuild. If the tile appears during a deliberate test, you know the feature is enabled on your specific machine. On Insider builds especially, confirm this for yourself. That’s because Controlled Feature Rollout means the tile may simply not be there yet on your hardware, regardless of build number.

If you want to test Cloud Rebuild without committing to a full reinstall, entering WinRE via Shift+Restart lets you verify tile visibility and back out safely. Do this now, on a good day, so you know exactly what you’re working with when a bad day happens.

Closing Thoughts

Cloud Rebuild is not vaporware, and it’s not a gimmick. Within its intended scope — soft OS failure on a machine with a healthy disk and a live recovery partition — it’s a useful automatic recovery mechanism.

The trouble is, “within scope” is doing a lot of work in that sentence. Knowing where that scope ends is the difference between a recovery plan and a recovery hope. The best time to discover that Cloud Rebuild registry access doesn’t extend to your UFD is during a Friday afternoon test with a cup of coffee in hand — not at 2 a.m. during an real recovery. Test deliberately, kit accordingly, and you’ll be fine.

Here in Windows-World, it not only pays to be prepared. It’s also essential to know what you’re doing, and to understand what the tools in your kit can (and can’t) do. ‘Nuff said.

Facebooklinkedin
Facebooklinkedin

GnuGB Properties Window Explains WinGet Pin

The old saying goes “There’s one in every crowd.” One of what? In this case, an app for which WinGet handles packages that doesn’t play by the rules. That’s OK in this case: the app is Gnu Backgammon (aka GnuBG, runs as “gnubg.exe”). I’m willing to forgive these foibles because it’s the  best-ever digital version of Backgammon around. It’s so good, in fact, I have to turn down its capabilities or it will beat me 9 games out of 10. That said, a quick look at the Gnubg Properties windows explains winget pin on this executable.

How GnuGB Properties Window Explains WinGet Pin

WinGet handles GNU Backgammon under the ID GNU.gnubg, But as a quick look at the properties window for gnugb.exe shows, it doesn’t self-report file version, product name or product version info (see lead-in graphic up top). That last item is an important part of what WinGet uses to figure out if updates apply to one of the packages in its custody. Indeed, this appears at the head of the next screencap, which shows output from two WinGet commands: pin list and show GNU.gnubg.

In particular, it’s noteworthy that Version info for GNU.gnubg shows up as “Unknown.” That reports the missing properties info obliquely, and explains why WinGet always attempts to upgrade that program unless I pin it up out of the way.

Indeed, that’s one of the main points of the WinGet pin command. And it works to prevent the package manager from trying to update something for which no update is available. It’s only because the app doesn’t self-report a version number that an issue presents. Pin provides the fix, and I’m glad.

Here in Windows-World, one must take one’s jollies when one can. I choose to be amused and entertained in this case. But I’m glad the WinGet team had the forethought to anticipate and fend off this kind of thing. ‘Nuff said.

Facebooklinkedin
Facebooklinkedin

WinGet Upgrade Knows More Than It Says

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

MCIO Ups the Ante on OCuLink

For most of computing history, the connectors with the fastest, most reliable PCIe signal paths lived in rack servers. They did not sit on your desk inside a palm-sized box. That divide is eroding quickly. MCIO, short for Mini Cool Edge IO, is a connector standard that Amphenol Communications Solutions developed. Better yet, the PCI-SIG formally adopted it for PCIe CopprLink internal cabling. Standardized as SFF-TA-1016, it packs PCIe Gen 5 performance, and soon Gen 7, into a slim 0.60 mm-pitch form factor. Until recently, you would only find it in a data center. In 2026, it is showing up in mini PCs you can buy on Indiegogo, as I learned reading news at TechPowerUp this morning.

How MCIO Ups the Ante on OCuLink

You can see how the MCIO receptacle compares with USB-C, which Thunderbolt 4/5 and USB 2/3/4/5 use. It’s a little bigger but not much. Indeed, MCIO deserves a closer look. It is a next-generation internal interconnect under the OverPass platform. Its defining characteristic is density without compromise. The connector’s 0.60 mm pitch keeps it compact while supporting data rates from 16 Gbps up to 64 Gbps per lane at PCIe Gen 5. Developers are also working on PCIe Gen 7 variants that run at 128 GT/s using PAM4.

Lane configurations span 4x, 8x, 16x, and 20x. The same connector body handles both cable-to-card and card-edge applications. That versatility reduces BOM complexity. It also supports PCIe, NVMe, and SAS, and the connector is rated for cable runs up to one meter. Designers originally created it to enable modular, scalable, easy-to-service data center architectures. As it turns out, those same traits also fit compact, high-performance personal computing.

Bandwidth Showdown: MCIO vs. the Field

To appreciate what MCIO brings to the table, it helps to line it up against the standards it competes against (and leapfrogs). Thunderbolt 4 tops out at 40 Gbps total bandwidth. But it tunnels PCIe thru an Intel controller, adding overhead at every step.

USB4 v2.0 is where things get faster: up to 80 Gbps, or asymmetric 120 Gbps when video bandwidth gets priority. It is the current mainstream performance sweet spot, and it appears in more mini PCs and laptops. Thunderbolt 5 pushes the ceiling higher, delivering roughly 63 Gbps of effective compute bandwidth, or up to 120 Gbps asymmetric for display workloads, with PAM-3 signaling. In real-world eGPU tests, Try Some Tech measured roughly 5.6-5.8 GB/s of host-to-device throughput.

OCuLink is an enthusiast’s current favorite for eGPU use (see my June 8 post on this topic). It’s a native PCIe external connection that sidesteps tunneling overhead entirely. In the same real-world testing, OCuLink hit roughly 6.6 GB/s host-to-device—beating Thunderbolt 5 by approximately 16% in sustained throughput. USB6 is still on the horizon as of mid-2026, not yet officially released, with predictions pointing toward roughly 160 Gbps using PAM-4 modulation.

Then there’s MCIO 8i running PCIe 5.0 x8: approximately 256 Gbps bidirectional at PCIe 4.0 speeds, and up to 512 Gbps bidirectional at full PCIe 5.0. That’s not an incremental improvement over the competition: it’s a category jump. GPD’s G2 eGPU enclosure, which launched in 2026 using MCIO 8i, claims just 2% performance loss when running an RTX 4090 externally. No Thunderbolt or OCuLink setup has come close to that. OCuLink typically imposes a 4–25% performance penalty depending on the workload; Thunderbolt 5 can push past 25% in bandwidth-intensive scenarios.

Data Center Roots, Professional Credibility

MCIO didn’t earn its reputation in hobbyist labs. It earned it in RAID controllers, host bus adapters, JBOD enclosures, NVMe storage arrays, AI inference servers, and high-density compute racks. In those environments, signal integrity and sustained throughput are vital. PCI-SIG adopted MCIO in its CopprLink cable spec in 2021, and Amphenol announced the PCIe Gen 7 variant for CopprLink internal cabling in 2025. It targets AI inference clusters and next-generation high-bandwidth networking.

Molex also manufactures MCIO connectors under the Mini Cool Edge brand, and the pricing reflects the standard’s enterprise practicality: raw surface-mount 8x PCIe Gen 5 connectors can be found for around $2.41 per unit, while a pre-assembled 16x cable assembly runs closer to $66. In enterprise bill-of-materials terms, that’s modest. For context, a Thunderbolt 5 controller chip alone can cost more than an entire MCIO cable assembly—one reason system designers are increasingly drawn to MCIO for cost-sensitive high-performance designs.

MCIO Shows Up in Mini PCs and eGPUs

GPD is best known for its gaming handhelds. But it made a significant statement in April 2026 by announcing two MCIO-equipped products at the same time. First came the GPD BOX mini PC, powered by Intel’s Core Ultra 300 “Panther Lake” processors. Second came the GPD G2 eGPU enclosure. The G2 launched on Indiegogo at $385 early-backer pricing ($459 MSRP) and is designed to pair directly with the GPD BOX over MCIO 8i. Beyond the headline MCIO port, the G2 is a capable dock in its own right. It includes a 16-pin GPU power connector (12VHPWR), an M.2 storage slot, USB 3.2 ports, dual connectivity via USB4 v2.0, and 100W USB Power Delivery output.

TOPC, another Chinese mini PC maker, also entered the MCIO space in 2026 with the TA255—an AMD Ryzen 7 H 255-powered system priced at approximately $394 (16 GB) to $438 (24 GB). The TA255’s MCIO port runs at PCIe 4.0 x8, delivering 128 Gbps—double the bandwidth of a standard OCuLink PCIe 4.0 x4 connection. That said, its current CPU generation stops it from reaching full PCIe 5.0 speeds.

One important caveat worth calling out: unlike OCuLink or Thunderbolt, MCIO is not hot-swappable and was not designed for casual cable-swap scenarios. It requires a deliberate, secure connection. For users building a modular compact workstation or eGPU setup intended to stay put, that’s a perfectly acceptable tradeoff. For users who want to plug and unplug an external GPU the way they’d swap a USB drive, MCIO is not the it—at least, not yet.

Should You Care About MCIO?

Let’s be honest: MCIO isn’t mainstream. As of mid-2026, device support is limited to a handful of mini PCs and eGPU docks. Most of them are Chinese OEMs with uncertain global reach. If you need broad compatibility today, USB4 v2.0 remains a safe, widely supported choice. If you own a capable mini PC or handheld and want the best eGPU performance, OCuLink is a good choice.

But if you’re thinking a few years out—or building a compact computing setup around modular, high-performance components—MCIO deserves serious consideration. PCI-SIG’s formal adoption of MCIO in its CopprLink cable spec for PCIe Gen 7 signals real institutional backing. It’s not just a niche vendor experiment. I expect to see MCIO appear in more PCs, edge boxes, and workstations in 2026/2027 as the ecosystem matures.

In connector technology, the server rack and the desktop have always eventually converged. On that trail, MCIO looks like the next proving ground. Stay tuned: this story is moving faster than most. Ultimately, it should mean that external NVMes work and run the same as internal NVMes. That’s HUGE.

Facebooklinkedin
Facebooklinkedin

OCuLink Offers A Viable TB4/5 Alternative

Before we dig in, let me define the terms in the title so nobody gets left behind. OCuLink — short for “Optical-Copper Link” — uses the SFF-8611 and SFF-8612 cable specs, originally bred in the enterprise SAS and NVMe world, and now showing up on consumer PCIe expansion cards, eGPU docks, and mini-PC expansion modules. The reason OCuLink offers a viable TB4/5 aleternative is: it carries native PCIe lanes over a compact four-lane connector. Zero protocol translation is involved.

TB4 is Thunderbolt 4 — Intel’s certified 40 Gbps interconnect standard. It runs the Goshen Ridge controller and dominates today’s laptops and docks. TB5 is Thunderbolt 5, Intel’s 80 Gbps follow-up, running the Barlow Ridge controller. It started appearing on premium Copilot+ laptops and high-end docks in late 2024.

Intel has owned the high-speed external storage conversation for nearly a decade. I must ask: “Is there a credible alternative path for builders and prosumers who’d rather not pay the Thunderbolt toll?” Table 1 above says yes, emphatically. The rest of this post explains why the math works out that way.

Why OCuLink Offers a Viable TB4/5 Alternative

Start with the Intel moat, because it’s real and it matters. Thunderbolt certification ties nominally to the USB4 spec. In practice, Intel controls the gate through its mandatory certified controller requirement — Goshen Ridge for TB4, Barlow Ridge for TB5. Each controller adds $15–$25 to a device’s BOM. That cost tags along through the supply chain straight to your invoice. The certification program itself isn’t free either, which is why you see so many USB4 ports on budget laptops and mini-PCs that carry the USB4 badge but quietly skip PCIe tunneling entirely — because PCIe passthrough is optional in the USB4 specification. A port can wear the USB4 label, deliver USB 3.2 storage speeds, and be perfectly compliant. Go figure! Intel doubled the bandwidth ceiling with Thunderbolt 5. But the same certification architecture stayed intact. That structural dependency hasn’t gone anywhere.

The Tunneling Tax

Then there’s what tunneling costs you, and this part tends to get glossed over in spec-sheet marketing. Both TB4 and TB5 move PCIe data over a tunneled protocol stack built primarily for display connectivity. The protocol treats NVMe storage as a secondary concern. That overhead carries a measurable real-world cost. TB5’s 80 Gbps headline pipe delivers only around 6–7 GB/s to an NVMe enclosure in independent benchmarks

Alas, this lands below the sequential read ceiling for a single Samsung 990 Pro or WD Black SN850X. The bandwidth also gets split in ways the spec sheet doesn’t advertise. Run a TB5 dock with a 4K display and a storage enclosure at the same time. The NVMe gets whatever lanes aren’t already committed to display output. No firmware update can fix that. It’s simply how the tunneling protocol divides resources between display and storage traffic.

OCuLink sidesteps all of it, and the reason is almost embarrassingly simple: it carries native PCIe — no tunneling, no overhead, no protocol translation between the cable and the drive controller. The SSD on the far end of an SFF-8611 cable sees the host’s PCIe bus directly. It behaves exactly as if it were seated in a motherboard M.2 slot.

You need no Intel controller, no certification fee in the BOM, and no spec-version negotiation between host and peripheral. Any PCIe host with an SFF-8611 port talks to any OCuLink enclosure. The connector standard is generation-agnostic. OCuLink scales to PCIe Gen5 today, with a theoretical ceiling over 15 GB/s. Thunderbolt 5 can’t get close within its tunneling architecture. Intel spent a decade building a toll road. OCuLink is the county road that goes to the same place, faster, for free.

What Are OCuLink’s Trade-Offs?

I’d be doing you a disservice if I left it there. That’s because OCuLink’s edge comes with genuine limitations you need to price into a buy-in. Cable length is the hard ceiling for which there’s no current engineering workaround. Passive copper OCuLink tops out at 0.5 to 1 meter depending on implementation. TB5 copper passive reaches 2 meters. TB5 optical reaches 40 meters or more. For a storage enclosure sitting six inches from your PC, cable length is a non-issue. For anything across a room or mounted in a rack, it’s disqualifying. Know your use case before you order anything.

Hot-plug behavior is the next honest caveat. PCIe never supported hot-swapping natively. OCuLink inherits that reality. Some enclosure implementations handle safe removal gracefully through driver-level coordination. Others expect a full shutdown first. At minimum, eject the device properly from Windows before pulling the connector. TB4 and TB5 hot-plug is standardized, reliable, and boring in the best possible way. You unplug, Windows notices, the drive disappears from Explorer. No drama.

Ecosystem and Power: The Remaining Gaps

The OCuLink consumer ecosystem is thin compared to Thunder-bolt’s. The OCuLink ecosystem embraces dozens of enclosures from small-batch vendors. Thunderbolt counts hundreds of certified peripherals from Belkin, CalDigit, OWC, and others. Support responsiveness, documentation quality, and return policies reflect that gap. Also, OCuLink carries no power delivery over the connector itself — any drive or enclosure needs its own power source. TB4 and TB5 deliver up to 100W over the same cable that carries data. None of those are dealbreakers for a desktop prosumer. They could be for a road warrior expecting plug-and-play.

For desktop and prosumer builders, or anybody running a PCIe expansion card that exposes an SFF-8611 OCuLink port, you get a legit, lower-cost, higher-throughput alternative to Intel’s certified Thunderbolt ecosystem. The bandwidth math in Table 1 speaks for itself. OCuLink over PCIe 4.0 x4 already beats TB5’s real-world NVMe ceiling. PCIe Gen5 doubles that figure again with no new Intel controller, no certification program, and no tunneling tax required. Those are the deets. Intel built the tollbooth. OCuLink is the on-ramp they forgot to close.

It’s worth considering, and maybe buying into. I’m doing just that myself. You may want to do likewise, if you like the numbers as much as I do.

 

Facebooklinkedin
Facebooklinkedin

GNUBG Shows WinGet Pin Rationale

Since Monday, I’ve noticed that WinGet is updating GNU Backgammon every day, aka GNUBG. You can see in the lead-in graphic this happens because the app reports its version number as unknown. Of course, that means WinGet wants to update it, even though that’s unnecessary. How to avoid this unwanted repetition: the WinGet Pin command. Thus, GNUBG shows WinGet Pin rationale, and lets me turn down the noise.

How GNUBG Shows WinGet Pin Rationale

The lead-in graphic also shows that the current installed GNU Backgammon version matches the one that WinGet wants to install. That proves it’s a reporting error from the app itself, not the typical “current version is less than winget database version” that supplies a usually valid reason to run the update process.

Obviously, this will go on until (or if) the developers fix the game, or until a real, new version comes out. So here’s what I did to stop the madness: I ran winget pin –id GNU.gnubg

Once pinned, WinGet stops its repeated GNUBG updates. Good!
[Click image for full-sized, more readable view.]

I’ve seldom had to use WinGet Pin on the PC fleet here at Chez Tittel. But every now and then — as with GNUBG here — something pops up that calls for a timeout. Now, I just have to remember to keep an eye on the app so I can unpin or force-update when a REAL one shows up. That’s just one of the small things that keeps me on my toes, here in Windows-World.

Facebooklinkedin
Facebooklinkedin

NVIDIA Extends ARM on Windows’ Reach

Just a couple of weeks ago, Lenovo sent me the Qualcomm X2-based Yoga Slim 7X Gen 11 laptop. Over the weekend, NVIDIA upped the ante with a Computex announcement of its RTX Spark CPU, also ARM-based. Developer in collaboration with MediaTek, this new CPU family, aka N1 and N1X, shows that NVIDIA extends ARM on Windows’ reach. Indeed Microsoft has announced a “Surface Laptop Ultra” build around this silicon, and ASUS, Dell, HP, Lenovo and MSI are also on the bandwagon. Acer and Gigabyte will follow shortly after that, and we’ll have both laptops and desktops running RTX Spark to choose among. Big news!

What NVIDIA Extends ARM on Windows’ Reach Means

Let me be clear about what’s going on with this upcoming architecture and systems that will use it. It’s aimed squarely at the top end of the market. I’m guessing such systems could easily cost upwards of US$5K, because they are aiming at high-end creators and AI developers.

Here’s a list of noteworthy features that NVIDIA and the OEMs are touting as relevant to potential buyers of such top-flight PCs:

  • Up to 6,144‑core Blackwell RTX GPU for high‑performance graphics, AI acceleration, and workstation‑class compute in thin‑and‑light designs.
  • 20‑core Arm‑based Grace CPU (co‑developed with MediaTek) delivering strong performance‑per‑watt for mobile and small‑form‑factor desktops.
  • Up to 1 petaFLOP FP4 AI compute enabling local execution of large AI models, agentic workflows, and advanced inference without cloud dependency.
  • Unified memory architecture (16–128GB LPDDR5X) shared between CPU and GPU, reducing bottlenecks and enabling massive 3D scenes, large‑context LLMs, and high‑resolution media workflows.
  • Ultra‑low power envelope (single‑digit watts to ~80W) allowing OEMs to build ultra‑slim laptops with all‑day battery life while retaining workstation‑class performance.
  • Full RTX software stack support (CUDA, TensorRT, DLSS 4.5, OptiX, Reflex, G‑SYNC) for creators, developers, and gamers on Windows.
  • Native support for on‑device AI agents via NVIDIA OpenShell and Windows 11 optimizations, positioning PCs as proactive “teammates” rather than passive tools.
  • High‑bandwidth NVLink‑C2C interconnect (600 GB/s) between CPU and GPU for low‑latency, high‑throughput compute.
  • Advanced media engines including 4:2:2 hardware encode/decode, AV1 encoders, and Blackwell‑class video pipelines for 12K editing and pro‑grade content creation.

A LOT to Take In, MORE Left to Understand

Whoa! That’s a lot of capability with a pretty rarified set of target buyers. Given current RAM and storage pricing, and rising costs for PC hardware in general, it’s clearly a small sliver of the market. But it’s got huge potential, and could ultimately redefine how Windows works — for a certain subset of users/consumers.

I think it’s pretty cool. I hope I’ll get  a chance to check one out later this year. In the long run, though, what will make the difference is how and when such special capabilities trickle down to garden-variety PC users. I’m intensely curious to watch this unfold, and see how it all plays out. Stay tuned: I’ll keep you posted!

Facebooklinkedin
Facebooklinkedin

WinRE Ignores Inactive HDMI Output

I guess it figures. If you examine yesterday’s blog post carefully, you’ll see it includes an obvious iPhone shot of a Windows boot screen. I’d hoped to replace it with a real screencap. Instead, I learned something interesting: my AGPTEK HD Video Capture device works fine with Windows OS running; not so with WinRE/WinPE at the helm. That’s because WinRE ignores inactive HDMI output ports thanks to its slimmed-down minimal graphics. Let me explain…

Why Say: WinRE Ignores Inactive HDMI Output

Simply put, if the runtime environment doesn’t require HDMI graphics, WinRE doesn’t use them. Given that the ASUS Zen14 has a perfectly good built-in display, with its own video channel, WinRE doesn’t feed any signals to the external HDMI port when it’s running.

My AGPTEK HD Video Capture box will cheerfully record any signals sent its way, once its “Record” button is pushed. It writes output to a UFD, from whence it may be copied and edited. I could have used it to capture a frame from said video showing the boot screens I wanted, but the box couldn’t grab them.

What WOULD Work?

It turns out I need an active frame-grabbing device not a passive, pass-through capture device if I want to grab WinRE and other WinPE-based screens through the HDMI port on the A14. Most of them cost between US$240 and 450, whereas the AGPTEK cost me US$65. Here in Windows-World, once must make sure to pay for what one needs. Otherwise, when one gets what one has paid for, it may not suffice to meet them! Live and learn, I always say…so obviously, I’ve learned that I need to buy another box!

 

Facebooklinkedin
Facebooklinkedin