I prefer all folders to open by default in the compact List view; some other people prefer the Detailed view by default. Either way, only morons need a folder to automatically switch to the Large icons view as soon as File Explorer detects videos or images inside!

Normally, Apply to all folders should have set the current folder’s view as the default view for all folders, but for some reason this just didn’t happen in my case! At least, not while I was checking my external backups with the File Explorer of the most retarded version of Microsoft Windows ever!

So I just asked Gemini:

Ludditus: How to make the file explorer in Win11 default to the compact list view for ALL folders, even those with videos or images?

Gemini: To force Windows 11 File Explorer to use the same view everywhere, you have to defeat a built-in feature called “Automatic Folder Type Discovery.” By default, Windows scans the contents of a folder and automatically switches the template to “Pictures” or “Videos” (which defaults to Large Icons), ignoring your global preferences.

You can stop this behavior permanently by clearing your saved folder views and forcing a single “General Items” template across the registry.

① Disable automatic folder sniffing:
Run in PowerShell.

Open PowerShell and paste the following block of code. This wipes the existing folder view memory (which is likely cluttered anyway) and creates a registry key that forces all folders to use the generic template, preventing them from automatically switching when they detect media.

# 1. Delete existing saved folder views
Remove-Item -Path "HKCU:\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\BagMRU" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item -Path "HKCU:\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags" -Recurse -Force -ErrorAction SilentlyContinue

# 2. Force the 'NotSpecified' (General Items) template globally
New-Item -Path "HKCU:\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags\AllFolders\Shell" -Force | Out-Null
New-ItemProperty -Path "HKCU:\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags\AllFolders\Shell" -Name "FolderType" -Value "NotSpecified" -PropertyType String -Force | Out-Null

# 3. Restart Explorer to apply changes
Stop-Process -Name explorer -Force

② Set the master view in File Explorer:

When your taskbar reappears, open File Explorer. Because of the script, Explorer now treats every folder identically, meaning we only have to set the view once.

  1. Navigate to your C:\ drive (or any standard folder).
  2. Click View > List (or Details, depending on your preference).
  3. Click View > Compact view (to tighten the padding between items).

③ Apply to all folders:

Now push this configuration to the rest of the system:

  1. Click the three dots (…) at the top of the File Explorer window and select Options.
  2. Go to the View tab.
  3. Click the Apply to Folders button.
  4. Click Yes on the confirmation prompt, then OK.

From now on, regardless of how many MP4s or JPEGs are dumped into a new directory, File Explorer will strictly adhere to the compact list layout. If you ever need to see thumbnails in a specific folder, you can still manually switch it to Large Icons from the View menu, and Windows will remember that specific exception.

It worked.

Fucking stupid Microsoft, with its automatic shit.

Windows 11 File Explorer is still the worst of all!

I still had to ask Gemini:

Ludditus: Is it only my feeling, or is Win11’s File Explorer much slower than Win7’s File Explorer was on CPUs that were 10 years older and 5-10 times slower by PassMark?

Gemini: It is definitely not just your feeling. It is a documented, measurable fact. Despite running on hardware that crushes decade-old CPUs in PassMark scores, Windows 11’s File Explorer is objectively slower and less responsive than the version in Windows 7 (and Windows 10).

The problem isn’t your hardware; it’s a fundamental architectural shift in how Microsoft handles the user interface.

The Architectural Shift: Native vs. Hybrid

Windows 7’s File Explorer was a pure, native Win32 application written in C/C++. It was highly optimized, deterministic, and ran directly on the OS without layers of virtualization. This meant instantaneous execution.

Windows 11’s File Explorer is essentially a “Frankenstein” application. Microsoft wanted a modern look but couldn’t easily rewrite the decades-old Win32 file browsing core from scratch. Instead, they used the Windows App SDK to wrap the legacy Win32 core in a modern WinUI 3 / XAML interface for elements like tabs, toolbars, and context menus.

This hybrid approach creates severe performance bottlenecks:

  • The Bridging Tax: When you right-click a file, the system must translate the old legacy shell command into a modern XAML visual element. This communication lag between the Win32 legacy code and the modern UI framework causes the infamous split-second delay when opening context menus.
  • The Lifted Compositor: Unlike older Windows versions, WinUI 3 uses a “lifted compositor.” UI elements are processed within the app, drawn to off-screen buffers, and then sent to the Desktop Window Manager (DWM). This adds a rendering tax to every single frame, making navigation feel sluggish and “stepped” rather than instant.

Additional Modern Bloat

Beyond the rendering engine, Windows 11 introduces background behaviors that actively work against responsiveness:

  • Cloud Integration: The default “Home” view actively queries OneDrive and Office.com for “Recent” and “Recommended” files, introducing network latency into a local file browser.
  • Automatic Folder Discovery: Explorer constantly runs a “sniff test” on folders to guess their content type (pictures, music, documents) and adjusts the view accordingly, consuming CPU cycles and disk I/O in the background.
FeatureWindows 7 File ExplorerWindows 11 File Explorer
ArchitectureNative Win32 (C/C++)Hybrid Win32 wrapped in WinUI 3 / XAML
RenderingDirect OS drawingLifted compositor (off-screen buffers to DWM)
Cloud IntegrationNoneQueries OneDrive and Office.com by default
PerformanceInstant, hardware-directBogged down by UI translation overhead

Microsoft’s Band-Aid Fix

Microsoft is aware of the sluggishness. In recent updates (such as version 24H2), their primary solution was to pre-load File Explorer into memory in the background at startup. While this masks the initial launch delay (at the cost of consuming more RAM), independent benchmarks show that even the pre-loaded Windows 11 Explorer is still measurably slower to open and navigate than the standard Windows 10 (and Windows 7) Explorer.

You aren’t imagining things. You are simply throwing massive computing power at layers of compositing overhead, legacy code translation, and background web queries that simply didn’t exist a decade ago.

Ludditus: The slowness to open is not the issue. The slowness to navigate is what’s absurd. Any Linux file manager is much more responsive!

Gemini: You are spot on. The initial launch time is a minor annoyance; the real killer is the active navigation lag—changing directories, scrolling through large folders, selecting files, and waiting for the UI to update. It feels like moving through wet cement.

And you are entirely right about Linux. If you fire up Thunar (XFCE) or Dolphin (KDE), directory switching is instantaneous, even on folders with thousands of items.

The reason Windows 11 feels so absurdly sluggish during navigation comes down to how the UI handles data rendering compared to native Linux widget toolkits.

1. The XAML Visual Tree Nightmare (Measure & Arrange)

In Windows 7 (and classic Win32), a file list was rendered using heavily optimized, native OS controls (like SysListView32). When you changed directories, the system didn’t create new objects for every file. It simply dumped text strings and icon pointers into a pre-existing grid canvas. It was incredibly lightweight.

Windows 11 uses WinUI 3 / XAML. In this architecture, every single file row or grid icon is not just data drawn on a screen—it is a distinct, heavy UI object node in a massive Visual Tree.

  • Every file item contains sub-objects: a Grid, a Border, an Image control for the icon, a TextBlock for the name, another TextBlock for the date, etc.
  • When you open a folder with 500 files, Explorer instantiates thousands of these nested UI elements.
  • The Layout Pass: Every time you scroll or change folders, the XAML layout engine must run a two-pass calculation (Measure and Arrange) to determine the exact pixel boundaries of every single element. The CPU gets hammered just calculating UI padding, margins, and alignment.

2. Linux Does Not Treat UI Elements Like DOM Nodes

Linux file managers feel incredibly responsive because GTK and Qt handle large lists completely differently.

  • Dolphin (KDE / Qt): Uses a highly optimized Model/View/Delegate architecture. When you browse a folder with 10,000 files in Dolphin, it does not create 10,000 UI row objects. The view widget is a single canvas. It calculates what is currently visible on your screen and uses a lightweight “Delegate” to paint the text and icons directly onto that canvas. The UI tree remains completely flat and minimal.
  • Thunar / PCManFM (GTK): Built on pure, low-overhead C code mapping directly to basic X11/Wayland drawing surfaces. It bypasses heavy abstraction layers entirely.

Because Linux file managers treat data as data to be painted rather than a tree of objects to be instantiated, directory navigation scales linearly, keeping CPU overhead near zero.

3. Synchronous Shell Extensions & Property Handlers

When you navigate to a new folder in Windows 11, Explorer doesn’t just read the filenames. It runs a barrage of background checks via the shell wrapper:

  • It queries cloud state providers (even if you aren’t actively using OneDrive).
  • It invokes Property Handlers to read metadata (like extracting dimensions from images or bitrates from media files) so it can figure out what columns to display.
  • In the old Win32 days, this data pipeline was tightly coupled and fast. In Windows 11, this metadata has to be marshaled across the Win32-to-XAML bridge. If a single shell extension stutters or the bridging layer delays the data callback, the entire UI thread locks up for a fraction of a second, causing that distinct visual hitch when entering a folder.

Throwing a 16-core modern CPU at Windows 11 doesn’t fix it because the bottleneck is single-threaded UI layout calculation and object-marshalling overhead. It’s a classic case of modern software design prioritizing a certain visual aesthetic and developer convenience over deterministic, low-latency execution.