I posted a program in my GIST you can compile and view its DEP Policy then try to change it. If you do turn on DEP in the Project Compile settings in 11.13622 it will be enabled for the Process Permanently so trying to Enable or Disable will error 5.
If you want to be cautious implementing DEP (IMO a good idea because a violation will GPF your program) I suggest in 13622 turning it OFF in EXE Project, then add SetProcessDEPPolicy(1) in code to turn it on for selected users or installs e.g. Back Door user or Developer machine installs. You can do this in any version of Clarion.
The DLL setting does not matter. Some use it as an FYI that the DLL works fine with DEP so you might check if your DLLs have the DEP flag. I’m not sure what Process viewer shows DEP for DLLs, my coming Rebase tools do. PEview will show it http://wjradburn.com/
DEP has been around since XP SP 3. It started defaulting to ON in Visual Studio 2005. Its been 15 years so it is very likely every DLL shipping today works. I guess I’m saying don’t take the time to check individual DLLs dated after maybe 2010. One known issue is older versions of the Microsoft ATL. DEP is mandatory in 64-bit so will always be ON in the future software.
Do you have any insight what the DEP column in ProcessViewer is trying to show?
I think ProcessViewer is showing the Out parameters from GetSystemDEPPolicy(*long,*long) of (DEP Flags , Permanent) so “disabled (permanent)” means Flags=0 and Permanent=True. Permanent means it can’t be changed, if you try you get Error 5. You only get to change it once, or not at all if set in the Project.
On a C6 app where GetSystemDEPPolicy() returns 2, calling SetProcessDEPPolicy(1)
returns 0 but the DEP column in ProcessViewer shows “disabled (permanent)”
IF SetProcessDEPPolicy() returned 0 that’s False and it failed. You could check GetLastError(). Its probably error 5 because “(permanent)” shows.
Reading more I see passing (3) to SetProcessDEPPolicy() is a better test because it is exactly the same the Compiler DEP flag which turns off the ATL fixes. Those would be needed in pre 2005 MFC DLLs. So probably not an issue for a Clarion developer nor 15 year old DLLs.
The DEP flag in the DLL is used for more than an FYI based on the quote from the below page on C# and DEP it will be good to have it turned on in your DLL projects.
If the image is a DLL and the flag is set, the OS skips checking the DLL against a compatibility database which results in a small performance improvement.
The System DEP Policy page for “Always On” mentions “System compatibility fixes are ignored” which is what I think that is talking about. The default “Opt In” must get those fixes for some specific DLLs.