Ittr
Freshman Member
Posts: 25 
OS: Windows 10 v1903
Theme: aero8400
CPU: Intel Core i3-1005G1
RAM: 8GB
|
Post by Ittr on Jun 2, 2023 7:05:34 GMT -8
Since Windows 11 released in October 2021, people have been struggling to accommodate for the permanent increase in size of both the navigation (back/forward) buttons and the address bar, which under ordinary circumstances can no longer be restored to their former sizes (seen in Vista through to Windows 10 version 1903). This can be annoying if you're trying to replicate how File Explorer looked prior to Windows 11, increasingly so with the forced tab interface by default. Today, I would like to present a discovery to this forum which may make the behaviour of File Explorer in Windows 11 (both 21H2 and 22H2) more desirable. Use of ExplorerFrame and its associated MUI file from build 21332 (early Windows 11 21H2 beta, the last to have the old proportions/extents) appears to restore the previous behaviour of the navigation buttons and Explorer address bar to how it is in Windows 10 version 2004 onwards - large (but smaller than in 11) by default, but able to be fully restored to its previous smaller size. Below is a screenshot of this in effect using a work-in-progress Windows 7-style visual style, the basic theme (with the WindHawk mod to fix extended client area) and the "Shrink Address Bar Height" WindHawk mod (as well as OldNewExplorer). The result is something which is on-par with what can be achieved in Windows 10, but ordinarily cannot be in 11 due to the differences in proportions. I have also attached the ExplorerFrame DLL and its MUI from 21332 below for other users to experiment with. There are a few bugs or side-effects so please read below for those. Known side-effects or bugs: -Tabs will be permanently disabled in 22H2 Windows 11, as will the fluent/modern command bar -Explorer will default to the Ribbon UI used in Windows 8.x and Windows 10, but this can be switched by ordinary means to the Windows 7 command bar -In 22H2, the behaviour of "Home" will more or less replicate the "Quick Access" area in Windows 10 and will be collapsible in the navigation pane (meaning it won't have the separators nor will it be permanently shown) -Closing Explorer windows which use the Ribbon UI may cause the Explorer shell to crash and restart. It is advised to use the Windows 7 command bar UI through either OldNewExplorer or ExplorerPatcher. Attachments:
21332ExplorerFrame.zip (1.12 MB)
|
|
Windows 10-7
Sophomore Member
Posts: 218 
OS: Windows 11 22H2
Theme: Aero7 - WindowsBlinds 11
RAM: 16gbs
|
Post by Windows 10-7 on Jun 2, 2023 9:18:12 GMT -8
That's amazing! Thank you so much!
|
|
|
|
Post by R.O.B. on Jun 2, 2023 19:16:30 GMT -8
Very nice discovery! Definitely going to have to try this out when I get the chance. Hoping one day we'll eventually be able to restore the actual old address bar height.
|
|
AnyKey
Sophomore Member
Posts: 229
OS: Windows 10 Pro 22H2
Theme: XP Classic Theme
CPU: AMD Ryzen 7 3700X
RAM: 16 GB 1333 MHz DDR4
GPU: Nvidia Geforce RTX 2070 Super
Member is Online
|
Post by AnyKey on Jun 2, 2023 20:46:27 GMT -8
Did anyone try replace files with Win10 1903 one?
Edit: I tried but it just threw the procedure error.
|
|
Windows 10-7
Sophomore Member
Posts: 218
OS: Windows 11 22H2
Theme: Aero7 - WindowsBlinds 11
RAM: 16gbs
|
Post by Windows 10-7 on Jun 2, 2023 20:59:18 GMT -8
To fix the Quick Access, before replacing explorerframe, run ViveTool with these commands vivetool /disable /id:37634385 vivetool /disable /id:39145991 vivetool /disable /id:36354489 restart then replace explorerframe and itll look like this! (WindHawk + Text replacing the word home with quick access) Attachments:
|
|
Ittr
Freshman Member
Posts: 25
OS: Windows 10 v1903
Theme: aero8400
CPU: Intel Core i3-1005G1
RAM: 8GB
|
Post by Ittr on Jun 2, 2023 22:46:06 GMT -8
Did anyone try replace files with Win10 1903 one?
Edit: I tried but it just threw the procedure error.
I did previously attempt to use the 22H2 Windows 10 ExplorerFrame, but it resulted in Explorer refusing to open.
In terms of how I came to the conclusion of using 21332's ExplorerFrame: after reading up that Windows 11 21H2's version still worked (see here...), eventually I thought about the proximity of the build range - build 22000 is 21H2, but taking away the jump in build numbers late in development from 21390 to 21990, 22000 would be classed as being within 100 Windows builds of 21332. Upon investigation, build 21332 was the very last build released that still didn't have the enormous Windows 11 Explorer dimensions. Why is this relevant? Because it led me to think - if 21H2's ExplorerFrame with the new giant proportions but no tabs stuff still works in 22H2 (which afaik is going to be the final major feature update for Windows 11) then why wouldn't one from a few dozen builds earlier?
As to why versions from production Windows 10 builds don't work, it probably has something to do with the fact that there is a rather drastic gap in development between what is now referred to as Windows 10 22H2 (which is still using version 2004's codebase but with some label changes via cumulative updates, same goes for 20H2, 21H1 and 21H2) and Windows 11 (all releases). Why did this happen? This huge gap mainly stems from the fact that in 2020, Microsoft decided to stop releasing "full" feature updates for Windows 10, largely abandoning what had become known as the "Manganese" (finishing at build 19645) and "Iron" development semesters (finishing at build 20348, released only as Server 2022). Since the start of 2019, the development of Windows has taken place under an "Azure development scheme", leading each codebase or semester to have a codename, usually from the periodic table. Windows 11 21H2 was based on the "Cobalt" development semester for Windows, whereas Windows 10 2004+ remains based on the "Vibranium" codebase (ending in the 1904x range). Essentially, there are over two-thousand builds between where public Windows 10 releases ended and Windows 11's started. As such, it is likely that more problems will occur with components from "Vibranium" than those from early "Cobalt" builds. |
|
|
|
Post by OrthodoxWin32 on Jun 3, 2023 0:16:46 GMT -8
Excellent discovery indeed, well done Ittr ! However, I am seriously worried about the future, because nothing says that Windows 11 build 21332 explorerframe, or even Windows 11 21H2, will not be compatible with Windows 12. The only "good" element (but which can also be a bad element) is that Microsoft seems to be developing a new UWP explorer in parallel. So maybe it no longer made any changes to explorer in Windows 12. |
|
AnyKey
Sophomore Member
Posts: 229
OS: Windows 10 Pro 22H2
Theme: XP Classic Theme
CPU: AMD Ryzen 7 3700X
RAM: 16 GB 1333 MHz DDR4
GPU: Nvidia Geforce RTX 2070 Super
Member is Online
|
Post by AnyKey on Jun 3, 2023 10:33:11 GMT -8
Is build 21332 provided now? I need to get files by myself for my system locale.
|
|
Ittr
Freshman Member
Posts: 25
OS: Windows 10 v1903
Theme: aero8400
CPU: Intel Core i3-1005G1
RAM: 8GB
|
Post by Ittr on Jun 3, 2023 11:52:44 GMT -8
Is build 21332 provided now? I need to get files by myself for my system locale.
Unfortunately, I only have the en-US MUI file in the attached download in the original post, and in the version of Cobalt build 21332 I have saved on my PC. It is likely since it was an Insider build that there are other language releases of the build, although I'm not aware of how well they have been archived and I only know the link to en-US 21332 on archive.org. Sorry. On the other hand, I have had reports of the DLL being usable without replacing the associated MUI file, however this may potentially cause other issues as it's not a use case I have tested for. It may not be needed to replace the MUI file if you are using a different locale however please let me know if this causes issues. |
|
AnyKey
Sophomore Member
Posts: 229
OS: Windows 10 Pro 22H2
Theme: XP Classic Theme
CPU: AMD Ryzen 7 3700X
RAM: 16 GB 1333 MHz DDR4
GPU: Nvidia Geforce RTX 2070 Super
Member is Online
|
Post by AnyKey on Jun 4, 2023 10:12:17 GMT -8
Is build 21332 provided now? I need to get files by myself for my system locale.
Unfortunately, I only have the en-US MUI file in the attached download in the original post, and in the version of Cobalt build 21332 I have saved on my PC. It is likely since it was an Insider build that there are other language releases of the build, although I'm not aware of how well they have been archived and I only know the link to en-US 21332 on archive.org. Sorry. On the other hand, I have had reports of the DLL being usable without replacing the associated MUI file, however this may potentially cause other issues as it's not a use case I have tested for. It may not be needed to replace the MUI file if you are using a different locale however please let me know if this causes issues. I looked some places but build 21332 is no longer provided by Microsoft. The only thing I can stick is find someone's archive on the Internet.
Well, I tested to replace only the dll on virtual machine. Looks like working well. Though I'm not sure how it goes on my real machine, it will probably work well.
|
|
friendshiping94
Freshman Member
Posts: 42
OS: Windows 10 Home 22H2
Theme: Windows 7 M1 Unredpilled
CPU: Intel(R) Core(R) i5-2400S 2.50 GHz
RAM: 12 GB of RAM
GPU: Nvidia GeForce GT 710
|
Post by friendshiping94 on Jun 4, 2023 23:35:14 GMT -8
Unfortunately, I only have the en-US MUI file in the attached download in the original post, and in the version of Cobalt build 21332 I have saved on my PC. It is likely since it was an Insider build that there are other language releases of the build, although I'm not aware of how well they have been archived and I only know the link to en-US 21332 on archive.org. Sorry. On the other hand, I have had reports of the DLL being usable without replacing the associated MUI file, however this may potentially cause other issues as it's not a use case I have tested for. It may not be needed to replace the MUI file if you are using a different locale however please let me know if this causes issues. I looked some places but build 21332 is no longer provided by Microsoft. The only thing I can stick is find someone's archive on the Internet.
Well, I tested to replace only the dll on virtual machine. Looks like working well. Though I'm not sure how it goes on my real machine, it will probably work well.
Well, the build is still available in UUPDump.
|
|
AnyKey
Sophomore Member
Posts: 229
OS: Windows 10 Pro 22H2
Theme: XP Classic Theme
CPU: AMD Ryzen 7 3700X
RAM: 16 GB 1333 MHz DDR4
GPU: Nvidia Geforce RTX 2070 Super
Member is Online
|
Post by AnyKey on Jun 5, 2023 10:55:15 GMT -8
I looked some places but build 21332 is no longer provided by Microsoft. The only thing I can stick is find someone's archive on the Internet.
Well, I tested to replace only the dll on virtual machine. Looks like working well. Though I'm not sure how it goes on my real machine, it will probably work well.
Well, the build is still available in UUPDump.
No, it doesn't go well even if you use that because required files have already been deleted from Microsoft's server. |
|
|
|
Post by justaduckinacostume on Jul 9, 2023 22:52:20 GMT -8
Since Windows 11 released in October 2021, people have been struggling to accommodate for the permanent increase in size of both the navigation (back/forward) buttons and the address bar, which under ordinary circumstances can no longer be restored to their former sizes (seen in Vista through to Windows 10 version 1903). This can be annoying if you're trying to replicate how File Explorer looked prior to Windows 11, increasingly so with the forced tab interface by default. Today, I would like to present a discovery to this forum which may make the behaviour of File Explorer in Windows 11 (both 21H2 and 22H2) more desirable. Use of ExplorerFrame and its associated MUI file from build 21332 (early Windows 11 21H2 beta, the last to have the old proportions/extents) appears to restore the previous behaviour of the navigation buttons and Explorer address bar to how it is in Windows 10 version 2004 onwards - large (but smaller than in 11) by default, but able to be fully restored to its previous smaller size. Below is a screenshot of this in effect using a work-in-progress Windows 7-style visual style, the basic theme (with the WindHawk mod to fix extended client area) and the "Shrink Address Bar Height" WindHawk mod (as well as OldNewExplorer). The result is something which is on-par with what can be achieved in Windows 10, but ordinarily cannot be in 11 due to the differences in proportions. I have also attached the ExplorerFrame DLL and its MUI from 21332 below for other users to experiment with. There are a few bugs or side-effects so please read below for those. Known side-effects or bugs: -Tabs will be permanently disabled in 22H2 Windows 11, as will the fluent/modern command bar -Explorer will default to the Ribbon UI used in Windows 8.x and Windows 10, but this can be switched by ordinary means to the Windows 7 command bar -In 22H2, the behaviour of "Home" will more or less replicate the "Quick Access" area in Windows 10 and will be collapsible in the navigation pane (meaning it won't have the separators nor will it be permanently shown) -Closing Explorer windows which use the Ribbon UI may cause the Explorer shell to crash and restart. It is advised to use the Windows 7 command bar UI through either OldNewExplorer or ExplorerPatcher.  |
|
|
|
Post by justaduckinacostume on Jul 19, 2023 12:53:55 GMT -8
Anybody know how to fix that?
|
|
Ittr
Freshman Member
Posts: 25
OS: Windows 10 v1903
Theme: aero8400
CPU: Intel Core i3-1005G1
RAM: 8GB
|
Post by Ittr on Jul 19, 2023 13:33:02 GMT -8
Anybody know how to fix that? This has only been tested for 100% DPI configurations. AFAIK OldNewExplorer is also designed for 100% DPI. This isn't something I can easily mitigate as I've been focusing on restoring other aspects and visuals of Windows Explorer to closely match their respective Windows 7 counterparts (on Windows 10 version 1903), something I'll be posting separately about if the project reaches completion. |
|
|
|
Post by justaduckinacostume on Jul 19, 2023 14:28:24 GMT -8
Anybody know how to fix that? This has only been tested for 100% DPI configurations. AFAIK OldNewExplorer is also designed for 100% DPI. This isn't something I can easily mitigate as I've been focusing on restoring other aspects and visuals of Windows Explorer to closely match their respective Windows 7 counterparts (on Windows 10 version 1903), something I'll be posting separately about if the project reaches completion. Just tried it on 1920x1080 and 100% scaling, restarted my pc too just to be sure. Sadly, it's still displaying the same way. Something else must be causing it. |
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Mar 1, 2024 21:26:21 GMT -8
Since Windows 11 released in October 2021, people have been struggling to accommodate for the permanent increase in size of both the navigation (back/forward) buttons and the address bar, which under ordinary circumstances can no longer be restored to their former sizes (seen in Vista through to Windows 10 version 1903). This can be annoying if you're trying to replicate how File Explorer looked prior to Windows 11, increasingly so with the forced tab interface by default. Today, I would like to present a discovery to this forum which may make the behaviour of File Explorer in Windows 11 (both 21H2 and 22H2) more desirable. Use of ExplorerFrame and its associated MUI file from build 21332 (early Windows 11 21H2 beta, the last to have the old proportions/extents) appears to restore the previous behaviour of the navigation buttons and Explorer address bar to how it is in Windows 10 version 2004 onwards - large (but smaller than in 11) by default, but able to be fully restored to its previous smaller size. Below is a screenshot of this in effect using a work-in-progress Windows 7-style visual style, the basic theme (with the WindHawk mod to fix extended client area) and the "Shrink Address Bar Height" WindHawk mod (as well as OldNewExplorer). The result is something which is on-par with what can be achieved in Windows 10, but ordinarily cannot be in 11 due to the differences in proportions. I have also attached the ExplorerFrame DLL and its MUI from 21332 below for other users to experiment with. There are a few bugs or side-effects so please read below for those. Known side-effects or bugs: -Tabs will be permanently disabled in 22H2 Windows 11, as will the fluent/modern command bar -Explorer will default to the Ribbon UI used in Windows 8.x and Windows 10, but this can be switched by ordinary means to the Windows 7 command bar -In 22H2, the behaviour of "Home" will more or less replicate the "Quick Access" area in Windows 10 and will be collapsible in the navigation pane (meaning it won't have the separators nor will it be permanently shown) -Closing Explorer windows which use the Ribbon UI may cause the Explorer shell to crash and restart. It is advised to use the Windows 7 command bar UI through either OldNewExplorer or ExplorerPatcher. That's WindowBlinds' fault. Use DWMBlurGlass and SecureUXPatcher with a Windows 7 style theme instead, it will be a lot better than using WindowBlinds. |
|
