![Photo](http://www.gravatar.com/avatar/8334a1db73ada0451c8fcbd78d0a207a?s=100&d=http%3A%2F%2Freboot.pro%2Fpublic%2Fstyle_images%2Fmetro%2Fprofile%2Fdefault_large.png)
#1
Posted 05 July 2022 - 12:00 AM
#2
Posted 05 July 2022 - 04:50 AM
#3
Posted 06 July 2022 - 03:07 PM
@ memoarfaa
Have you tested your suggested aproach in Win10 based PEs? Please confirm this.
I'm asking because that article is from March 2011 and seems focused on Win7, and I also saw this comment in your linked page:
Kevin says:I’m assuming this doesn’t work any more in Windows 10 because… I have some items set to run as admin and they are not listed. If I add something in either Current User or Local Machine it does not run as an admin
And it seems to me if that *.reg file doesn't work on 10 to set an item to run as admin, also very possible Compatibility Mode may not work too.
@ All
For now I don't have available any program that needs to run in Compatibility Mode to test this myself.
So it will be good if any member can confirm this *.reg is still able to work on a 10 based PE. As if it works fine, it could be very useful for all users that want to run some old program that may require Compatibility Mode.
alacran
#4
Posted 06 July 2022 - 04:01 PM
This is 2016 and includes (some releases of) Windows 10:
https://qtechbabble....m-command-line/
Since in a PE the user is System, I presume that the key to test is the HKLM one
Wonko
#5
Posted 06 July 2022 - 09:03 PM
Thanks Wonko, IAW that article the Reg Key is the same, and it was tested to work fine also on 10 upto v2004.
So I decided to test it myself using the same program (from memoarfaa link) IconsExtract for my test on WinPE:
I found on my backups an old copy of IconsExtract v1.41
IconsExtract v1.41
Copyright © 2003 - 2006 Nir Sofer
Web Site: http://www.nirsoft.net
System Requirements
===================
Windows operating system: Windows 95/98/ME, Windows NT, Windows 2000 or
Windows XP.
IconsExtract can only extract icons from 32-bit executable files. It
cannot extract icons from 16-bit files.
Copied it to Y:\Portables and created iconsext.bat, booted from my Win10XPE_x64.wim, and ran iconsext.bat:
REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /v "Y:\Portables\iconsext\iconsext.exe" /t REG_SZ /d "WINXPSP3 RUNASADMIN" /f
The REG Key was created fine, and all seemed to work fine, iconsext.exe ran without issues.
But this resulted to be a waste of time, and at the end I probed nothing, because after rebooting to Win10XPE_x64.wim, this time without adding that Key to the Registry, iconsext.exe ran also this way without any issue.
So to truly test this without any doubt, we have to use a program (portable preferable), that is known it's not capable to run under Win10, and really requires to run in at least Win7 Compatibility Mode (WIN7RTM).
Any suggestion (and link) of a Portable program that runs fine on a Win7 based PE but not on a Win10 based PE is welcome.
alacran
#6
Posted 08 July 2022 - 12:14 AM
I don't think there is a "Compatibility Mode" on WinPE 10 (and I mean the official WinPE, not those kinds of "Windows Live").
To test whether the "Compatibility Mode" is applied, I wrote this very simple native C/C++ application:
#include <windows.h> #include <stdio.h> void Show_GetVersion() { DWORD dwVersion = 0; DWORD dwMajorVersion = 0; DWORD dwMinorVersion = 0; DWORD dwBuild = 0; dwVersion = GetVersion(); dwMajorVersion = (DWORD)(LOBYTE(LOWORD(dwVersion))); dwMinorVersion = (DWORD)(HIBYTE(LOWORD(dwVersion))); if (dwVersion < 0x80000000) dwBuild = (DWORD)(HIWORD(dwVersion)); char msg[1024]; sprintf(msg, "Windows Version is: %d.%d (Build: %d)", dwMajorVersion, dwMinorVersion, dwBuild); MessageBoxA(NULL, msg, "GetVersion", MB_OK); } void Show_GetVersionEx() { OSVERSIONINFO osvi; BOOL bIsWindowsXPorLater; ZeroMemory(&osvi, sizeof(OSVERSIONINFO)); osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO); GetVersionEx(&osvi); char msg[1024]; sprintf(msg, "Windows Version is: %d.%d (Build: %d)\n%s", osvi.dwMajorVersion, osvi.dwMinorVersion, osvi.dwBuildNumber, osvi.szCSDVersion); MessageBoxA(NULL, msg, "GetVersionEx", MB_OK); } INT WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR lpCmdLine, INT nCmdShow) { Show_GetVersion(); Show_GetVersionEx(); }
When this application is run in a Compatibility Mode it shows the Windows Version (Major.Minor) of that Compatibility Mode.
For example:
Windows 7: 6.1
Windows XP: 5.1
...
For those wanting to compile/build this application, please follow these steps:
- Write the code above to a text file named "version.cpp"
- Run the Microsoft Visual Studio Command Prompt
- CD to where "version.cpp" is located
- Run this command: cl.exe version.cpp Kernel32.Lib User32.Lib /link /subsystem:WINDOWS /OUT:version.exe
#7
Posted 08 July 2022 - 09:12 AM
As said before a PE is a "strange" sort of OS where the user is System.
It is entirely possible that the Registry key(s) are simply ignored in it, particularly in a "basic" PE, it is entirely possible that the subsystem (or whatever) that triggers the interrogation of those kwys is missing altogether.
If this is the case, there must be *somehow* a way to replicate the *whatever* is done on the full OS when those keys are read (it should be some sort of parameter/flag set at execution time), but really no idea on where to look for how to implement that (if possible at all).
You can still try via batch setting __COMPAT_LAYER variable
https://ss64.org/viewtopic.php?t=18
YMMV
Wonko
#8
Posted 08 July 2022 - 01:31 PM
Thank you all for your replies...
Both of the solutions of using the registry Keys:
#9
Posted 08 July 2022 - 02:48 PM
I believe the "System Compatibility Database" is not connected to the "compatibility mode" that is part of the properties of a program (and that goes into the Registry) or with environment variable, though it may contain some of those same settings.
AFAIK it is mainly used for hot-patching and more complex changes to executables, via shims:
https://tzworks.com/...php?proto_id=33
https://www.geoffcha...p/sdb/index.htm
I am not surprised that is completely missing in a PE (but that again doesn't necessarily mean that if you create the path and needed .sdb files the settings won't be respected even in the PE, or - on the opposite - that whatever settings in such shims will be read/parsed in a PE).
Wonko
#10
Posted 09 July 2022 - 09:08 AM
Hi abigt,
After some minor modifications, I managed to compile your code with PellesC v8 :
- Comment out this line as the variable is not referenced :
// BOOL bIsWindowsXPorLater;
- Add return 0 to terminate properly the function main :
Show_GetVersion(); Show_GetVersionEx(); return 0;
Attached Files
#11
Posted 10 July 2022 - 07:44 AM
JFYI
If using Vortex GetVer32.exe in a full Win7x64 OS and following GetVer32.bat:
REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /v "Y:\Portables\GetVer32\GetVer32.exe" /t REG_SZ /d "WINXPSP3 RUNASADMIN" /f
Following Key is added to the Registry, I exported it as Win7_Layers.reg
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"Y:\\Portables\\GetVer32\\GetVer32.exe"="WINXPSP3 RUNASADMIN"
All worked as expected and GetVer32.exe got Windows Version is 5.1 (Build 2600) and 5.1 (Build 2600) Service Pack 3, that means it ran in WinXP Service Pack 3 compatibility mode.
But following GetVer32.bat doesn't work in full Win10 2004 OS:
REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /v "Y:\Portables\GetVer32\GetVer32.exe" /t REG_SZ /d "WIN7RTM RUNASADMIN" /f
The key is created in the Registry, (exported as HKLM_Layers_bat.reg), but when running GetVer32.exe, it doesn't give us Win7 OS data, it gives Win10 OS data.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"Y:\\Portables\\GetVer32\\GetVer32.exe"="WIN7RTM RUNASADMIN"
After deleting that key I created manually the Key in the Registry (right click in GetVer32.exe >>> Properties >>> Compatibility >>> Win7 + Run as Admin).
And the following Key (exported as HKCU_Layers.reg) was created:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"Y:\\Portables\\GetVer32\\GetVer32.exe"="~ RUNASADMIN WIN7RTM"
Doing it this way GetVer32.exe, gives Win7 OS info as expected, please notice there is an additional ~ in the Key.
After deleting that Key I created and tested the following HKLM_Layers.reg
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"Y:\\Portables\\GetVer32\\GetVer32.exe"="~ RUNASADMIN WIN7RTM
The Key was created fine, but it seems it's not used, as when running GetVer32.exe, it gets Win10 OS info, so only valid key in full Win10 OS is HKCU_Layers.reg
My Win10XPE_x64.wim has \Windows\AppPatch\sysmain.sdb, but it lacks the option to manually select Compatibility mode.
I tested HKCU_Layers.reg and HKLM_Layers.reg, one by one deleting the previous before testing the second, but none of them worked fine as when running GetVer32.exe, it got Win10 OS info in both cases.
My Mini-10x64-LZX.vhd also has \Windows\AppPatch\sysmain.sdb, I tested HKCU_Layers.reg and HKLM_Layers.reg, one by one deleting the previous before testing the second, and same thing none of them worked fine as when running GetVer32.exe, it got Win10 OS info in both cases.
But Mini-10x64-LZX.vhd has the option to manually select Compatibility mode, I tested this too, and the Key was created fine in HKCU but GetVer32.exe got Win10 OS info, so something else was removed during the reducing process used to build this Mini-10 VHD.
I thought it was the lack of \Windows\WinSxS\amd64_microsoft-windows-a..ence-mitigations-c1_31bf3856ad364e35_10.0.19041.173_none_e9f806f05136c976, where there are 3 instances of sysmain.sdb, and added it to the VHD, but this didn't solve the problem.
Anyway at least now we know per sure the following:
In Win10 OS:
- Same or similar commands used for Win7 don't work.
- There is an additional ~ in the Key, when appling Compatibility manually.
- Only the Key in HKCU works in full 10 OS.
- EDIT: set __COMPAT_LAYER=Win7RTM also works fine, more info in post 16 and 18
In Mini-10 VHD and Win10XPE_x64.wim:
- Even if \Windows\AppPatch\sysmain.sdb is present, that's not enought.
Unsolved yet:
- What else is required to make Compatibility mode work fine in Mini-10 VHD.
- What else is required to make Compatibility mode work fine in Win10XPE_x64.wim.
Unfortunately the pending to solve items are not as easy to solve as when we are looking for a required DLL file or a Registry Key, and in this case the info available is very limited.
NOTE: Our fellow Vortex compiled a new GetVer64.exe version, the new info related to testing it is available starting on post No. 23 and following, and on post No. 29 there is Summary of our findings.
alacran
Edited by alacran, 12 July 2022 - 11:29 AM.
Added new info.
#12
Posted 10 July 2022 - 09:00 AM
@alacran
Since you are into testing, can you try the __COMPAT_LAYER environmental variable?
Wonko
#13
Posted 10 July 2022 - 09:17 AM
Sure, I will try following COMPAT_LAYER.bat and report back:
set __COMPAT_LAYER=Win7RTM
"Y:\Portables\GetVer32\GetVer32.exe"
And also COMPAT_LAYER-2.bat (just in case).
set __COMPAT_LAYER="~ RUNASADMIN WIN7RTM"
"Y:\Portables\GetVer32\GetVer32.exe"
alacran
#14
Posted 10 July 2022 - 09:52 AM
Tested in Mini-10x64-WB.vhd and Win10XPE_x64.wim, both *.bat files don't work in any of them.
Please see attached photos.
alacran
Attached Files
#15
Posted 10 July 2022 - 11:34 AM
Yep, good, but does it work in a "full" Windows 10?
Wonko
#16
Posted 10 July 2022 - 11:42 AM
JFYI
From: https://stackoverflo...yer-actually-do
Quote
__COMPAT_LAYER, and How To Use It
__COMPAT_LAYER is a system environment variable that allows you to set compatibility layers, which are the settings you can adjust when you right-click on an executable, select Properties, and go to the Compatibility tab.
So if the manual setting for Compatibility doesn't work in certain environment, it is logical to assume that set __COMPAT_LAYER will not work too.
And also if the manual setting for Compatibility works in certain environment, it is logical to assume that set __COMPAT_LAYER will work too.
Only thing set __COMPAT_LAYER does is temporary set (for limited time [until we close the *.bat file]) our desired setting.
alacran
#17
Posted 10 July 2022 - 12:58 PM
Hello,
abigt's same source code built as 64-bit application. Compiler : PellesC v8
Attached Files
- alacran likes this
#18
Posted 10 July 2022 - 03:50 PM
JFYI
After changing to another PC where I have full 10x64 2004 OS installed, I ran first COMPAT_LAYER.bat:
set __COMPAT_LAYER=Win7RTM
"Y:\Portables\GetVer32\GetVer32.exe"
And as expected GetVer32.exe got Windows Version is 6.1 (Build 7600) that is Win7, please see photo No.6
Also tested the alternative command, (more similar to the respective Key in the Registry, [that worked fine], and was also tested only just in case, in my previous post), it was named as COMPAT_LAYER-2.bat :
set __COMPAT_LAYER="~ RUNASADMIN WIN7RTM"
"Y:\Portables\GetVer32\GetVer32.exe
It didn't work fine, GetVer32.exe got Windows 6.2 (Build 9200), that is Win 10, meaning this is not the right syntax for the command, please see attached picture No. 7
So this confirms that as long as the OS used is capable to manually boot an *.exe file in Win7RTM Compatibility mode, the command set __COMPAT_LAYER=Win7RTM also works fine, and vice versa.
NOTE: set __COMPAT_LAYER command temporary sets the selected Compatibility mode, but without writing any Key to the Registry.
alacran
Attached Files
#19
Posted 10 July 2022 - 05:30 PM
Hello,
abigt's same source code built as 64-bit application. Compiler : PellesC v8
Just downloaded and tested your 64 bits version running following *.bat files in Win7x64 SP-1:
set __COMPAT_LAYER=WINXPSP3
"Y:\Portables\GetVer64\GetVer64.exe"
It didn't work fine. Anyway I will test it latter on full 10x64 OS and comment back.
set __COMPAT_LAYER=WINXPSP3
"Y:\Portables\GetVer32\GetVer32.exe"
This works fine, please see attached photo.
alacran
Attached Files
#20
Posted 10 July 2022 - 05:58 PM
NOTE: set __COMPAT_LAYER command temporary sets the selected Compatibility mode, but without writing any Key to the Registry.
Sure , that's the whole point of attempting to use it instead of the Registry mod.
I think we can say that the "mechanism" that makes __COMPAT_LAYER work (whatever it is) is not the same one as the one that makes the Registry mod working (whatever this other mechanism is).
The fact that in a "tested" (even if not the plain one made with MS tools) PE neither work may be a coincidence (i.e. both mechanism invalid/missing some files/whatever) or it could be a "common feature". i.e. the PE not having an actual user (or the user being SYSTEM) prevents the working of compatibility mode.
Probably a counter-test would be to test run in a full 7 system with runassystem (or runassystem works also on 10?):
http://reboot.pro/in...showtopic=17501
or possibly psexec.
Wonko
#21
Posted 10 July 2022 - 07:50 PM
Wonko the Sane, on 10 Jul 2022 - 12:58 PM, said:
I think we can say that the "mechanism" that makes __COMPAT_LAYER work (whatever it is) is not the same one as the one that makes the Registry mod working (whatever this other mechanism is).
I disagree with your idea my friend, on my Mini-10x64-LZX.vhd and my Mini-10x64-WB.vhd, where the Registry Key can be created manually selecting Compatibility mode, but it doesn't work, the same happends with the set __COMPAT_LAYER command, so opposite to your idea I assume both use the same mechanism.
To me it seems very clear that when manually selecting Compatibility mode doesn't works fine also set __COMPAT_LAYER command doesn't work fine, but when manually selecting Compatibility mode works fine also set __COMPAT_LAYER command works fine, so this implies both use same mechanism (IMHO a single command line program).
Wonko the Sane, on 10 Jul 2022 - 12:58 PM, said:
The fact that in a "tested" (even if not the plain one made with MS tools) PE neither work may be a coincidence (i.e. both mechanism invalid/missing some files/whatever) or it could be a "common feature". i.e. the PE not having an actual user (or the user being SYSTEM) prevents the working of compatibility mode.
No, I also disagree here, I just booted from my Win10PE x64.wim but this time as ADMIN, not as SYSTEM, and this doesn't make any difference.
But as it is also a fact that this PE lacks the option to manually select Compatibility mode, then in my opinion the single mechanism required for the manual task or the set __COMPAT_LAYER command is not present in the PE, so booting as SYSTEM or ADMIN doesn't matter.
So I'm totally convinced there is only a single command line program to set Compatibility mode, manually or by the set __COMPAT_LAYER command, in fact the GUI to manually select Compatibility mode options (and write permanent Keys in the Registry) looks to me a very poor and limited in options front end of the more powerful command line real tool, that we have not identified yet. But it seems to me \Windows\System32\Sdbinst.exe and its x86 version \Windows\SysWOW64\Sdbinst.exe could be good candidates, more info about Sdbinst.exe is available here and here
I don't see any case in making tests running in Win7 as SYSTEM, as it was already probed since post No. 11 that:
Quote
REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /v "Y:\Portables\GetVer32\GetVer32.exe" /t REG_SZ /d "WINXPSP3 RUNASADMIN" /f
Wich will apply if booting as SYSTEM works fine on full Win7 OS (but not in full Win10 OS, where only a HKCU Key (that includes the additional ~ works fine).
alacran
#22
Posted 10 July 2022 - 08:59 PM
Forgot to comment more extensively that when using the option to manually select Compatibility mode the Registry Key is created in HKCU (NOT in HKLM).
And as it has being probed in post No. 11 Full Win10 OS only accepts the Key in HKCU, (and ignores a Key in HKLM), also set __COMPAT_LAYER command necessarily emulates the behaviour of a Key created in HKCU, and that's why it works fine in full Win10 OS.
And knowing this, and also that if booting as SYSTEM we need to have the Key in HKLM, we can infer that set __COMPAT_LAYER command will never work in a PE booted as SYSTEM, even if we were able to add all required to try this.
alacran
#23
Posted 10 July 2022 - 11:50 PM
@ Vortex
Tested on Full 10x64 OS your GetVer64, using following commands:
set __COMPAT_LAYER=Win7RTM
"Y:\Portables\GetVer64\GetVer64.exe"
All working fine, GetVer64.exe got the info related to Win7 OS as you can see in attached photo.
alacran
Attached Files
#24
Posted 11 July 2022 - 07:45 AM
I don't see any case in making tests running in Win7 as SYSTEM, as it was already probed since post No. 11 that:
Wich will apply if booting as SYSTEM works fine on full Win7 OS (but not in full Win10 OS, where only a HKCU Key (that includes the additional ~ works fine).
alacran
Well, then don't try the suggested experiment, though I cannot see where/when/how you ran 7 as SYSTEM.
HKCU is a on-the-fly generated link to the structure that is really-really in HKEY_USERS, some (loosely related reference) pointing to a SID:
https://batchpatch.c...-hkey_users-hku
So (in my perverted mind) it is possible that in a PE something changes as essentially there is not a logon process, I don't have available/handy a 7 based PE (let alone a 10 based PE) but it would be interesting to check what happens in a PE:
And knowing this, and also that if booting as SYSTEM we need to have the Key in HKLM, we can infer that set __COMPAT_LAYER command will never work in a PE booted as SYSTEM, even if we were able to add all required to try this.
Well that was my initial guess:
Since in a PE the user is System, I presume that the key to test is the HKLM one
Still since the __COMPAT_LAYER doesn't write (maybe) to the Registry it may rely on a different mechanism (which is anyway missing in the tested PE's, possibly for other reasons).
Wonko
#25
Posted 11 July 2022 - 06:49 PM
When I said: I don't see any case in making tests running in Win7 as SYSTEM, as it was already probed since post No. 11 that:
What I mean is the Key in HKLM in Win7 already works in full Win7 OS, so it also should work in a full Win7 OS if booting it as SYSTEM.
But forgot to mention before my last post it was tested in Win7PE and it doesn't work, as the PE lacks all required to make it work, also set __COMPAT_LAYER doesn't work in the Win7PE.
alacran
Also tagged with one or more of these keywords: compatibility mode, winpe
Boot methods & tools →
Boot from USB / Boot anywhere →
WinPe 2024 LazesoftStarted by fi-zilal , 3 weeks ago ![]() |
|
![]()
|
||
Groups →
Windows Extreme →
Windows PE →
Windows 11 PE AudioStarted by MetallicWheat , 05 Mar 2023 ![]() |
|
![]()
|
||
Groups →
Windows Extreme →
Windows PE →
Windows 11 PE AudioStarted by MetallicWheat , 05 Mar 2023 ![]() |
|
![]()
|
||
Groups →
Windows Extreme →
Windows PE →
Windows PE 11 - 22621.1 WOW64 SupportStarted by MetallicWheat , 17 Feb 2023 ![]() |
|
![]()
|
||
Groups →
Windows Extreme →
Windows PE →
TeamViewer (TV 15.35.9.0) in a Winpe System sessionStarted by noel , 22 Nov 2022 ![]() |
|
![]()
|
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users