Programmatically switch between direct and extended mode

Personally I would not like it if some software on my computer suddenly decided to shut off or active one of my external monitors sliding around my windows. Going from extended to direct or vice versa would do that. I think you are looking at a short term problem which will be solved by CV1. Lack of support for both modes in some software will get fixed!

Well, I'm not planning to implement that feature in a game or something whwre you wouldn't expect it. It's specifically meant for a launcher that can be configured to auto switch modes. If this isn't useful to you, then you just don't download it. ;)
But I'm sure lots of people would greatly appreciate something like that.

Waiting 1 year+ is not really what I am looking for. I want to write the tool now.

No one? :(

*Bump*

I'm definately interested in such a launcher, because I want to set up a VR demo station at work where people can launch demos without having to know anything about VR.

Looks like ConfigUtil doesn't use typical windows forms controls, so we can't use WinAPI functions to reliably and precisely interact with the UI. We could only emulate mouse clicks or keyboard input, which would be very unreliable.

So, I'm currently trying to learn how inject some code into the ConfigUtil to tell it to switch between the modes.
What I found out so far, we will need
-SeDebugPrivilege and admin privileges
-OpenProcess to get a handle to the process
-VirtualAllocEx to make some space for code that we have to inject
-WriteProcessMemory to write a function of type LPTHREAD_START_ROUTINE to our target process; this function will have to call the actual Oculus function that changes the mode
-CreateRemoteThread to call the LPTHREAD_START_ROUTINE function that we injected

The really tricky thing will be to trace down where the ConfigUtil function is located and where it will be located the next time.
As I understand there are multiple approaches to do this:
-Use ollyDbg or similar, find a unique string that is likely in the same location as the function, use breakpoints to trace the function call
-Use Cheat Engines DBVM and UltiMap to automatically log in realtime which functions are called, filter it down until you are left with one function (DBVM only runs on Intel CPUs and not on the newer gen ones (haswell/haswell-e/broadwell), only ivy and below.. and some AntiVirus programs cause bluescreens the enabling DBVM)

Then you can do one of these things:
-write down the address of the function manually look for static (multilevel)pointers that point to that function, restart the ConfigUtil a couple of times and make sure the pointer is aalways pointing to the function
-write down the address of the function and use Cheat Engine's automatic pointer scanner, restart the ConfigUtil, search the function address again, rescan.... repeat until the results don't decrease a lot anymore, pick any (multilevel) pointer from the list you want
-write down the bytes around the ConfigUtil function, restart the ConfigUtil, search for the function again, write down the bytes around the function again.... check which bytes are always the same, create a dynamic pattern like F8 ?? 39 66 ?? 9A D4, questionmarks meaning the bytes changed every time.

You can then programmatically scan for the pattern around the function or use the static (multilevel) pointer to get the functions address.

Then you need to find out how to actually call the function. We probably have to push certain values onto the stack and then "call" (E8) the address of the function.

In the end we then need to call
-WaitForSingleObject to wait for the remote thread to finish
-GetExitCodeThread to see if we were successful
-CloseHandle for the remote thread and process handles
-VirtualFreeEx to clean up the mess we left in our target process

But OMG.. this will be soo much work... I really hope I'll be able to do it, but I honestly kinda doubt it.


SeDebugPrivilege: http://msdn.microsoft.com/en-us/library/windows/desktop/bb530716(v=vs.85%29.aspx#SE_DEBUG_NAME
OpenProcess: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684320%28v=vs.85%29.aspx
VirtualAllocEx: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366890%28v=vs.85%29.aspx
WriteProcessMemory: http://msdn.microsoft.com/en-us/library/windows/desktop/ms681674%28v=vs.85%29.aspx
CreateRemoteThread: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682437%28v=vs.85%29.aspx

WaitForSingleObject: http://msdn.microsoft.com/en-us/library/windows/desktop/ms687032%28v=vs.85%29.aspx
GetExitCodeThread: http://msdn.microsoft.com/en-us/library/windows/desktop/ms683190%28v=vs.85%29.aspx
CloseHandle: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724211%28v=vs.85%29.aspx
VirtualFreeEx: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366894%28v=vs.85%29.aspx