jp9000
/
obs-studio
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
obs-studio/plugins/win-capture/hook-helpers.h

66 lines
1.4 KiB
C
Raw Normal View History

win-capture: Add hook helper functions for IPC These inline functions simplify the process of using windows IPC objects, such as mutexes and events.
2014-11-10 01:48:16 -08:00
#pragma once
#if !defined(__cplusplus) && !defined(inline)
#define inline __inline
#endif
win-capture: Always use minimal access rights within hook This prevents issues with opening handles to objects within UWP programs, which have increased security limitations.
2016-10-31 01:41:01 -07:00
#define GC_EVENT_FLAGS (EVENT_MODIFY_STATE | SYNCHRONIZE)
#define GC_MUTEX_FLAGS (SYNCHRONIZE)
win-capture: Create all named objects within hook All named objects (including file mapped shared memory) need to be created within the hook itself due to the fact that UWP programs cannot access named objects outside of the UWP process. Because shared memory needs to be created within the hook, the capture loop cannot start until the shared memory has been filled with valid data. Creating an additional "initialize" event fixes this issue. Additionally, changed the way that named kernel objects are opened/created. Before, there were functions that would first try to open named objects and then implicitly create them if opening failed (assuming that if the hook didn't create it first, game capture would), now it's been changed so that you can only either explicitly open or create.
2016-11-01 00:21:42 -07:00
static inline HANDLE create_event(const char *name)
win-capture: Add hook helper functions for IPC These inline functions simplify the process of using windows IPC objects, such as mutexes and events.
2014-11-10 01:48:16 -08:00
{
win-capture: Create all named objects within hook All named objects (including file mapped shared memory) need to be created within the hook itself due to the fact that UWP programs cannot access named objects outside of the UWP process. Because shared memory needs to be created within the hook, the capture loop cannot start until the shared memory has been filled with valid data. Creating an additional "initialize" event fixes this issue. Additionally, changed the way that named kernel objects are opened/created. Before, there were functions that would first try to open named objects and then implicitly create them if opening failed (assuming that if the hook didn't create it first, game capture would), now it's been changed so that you can only either explicitly open or create.
2016-11-01 00:21:42 -07:00
return CreateEventA(NULL, false, false, name);
}
win-capture: Add hook helper functions for IPC These inline functions simplify the process of using windows IPC objects, such as mutexes and events.
2014-11-10 01:48:16 -08:00
win-capture: Create all named objects within hook All named objects (including file mapped shared memory) need to be created within the hook itself due to the fact that UWP programs cannot access named objects outside of the UWP process. Because shared memory needs to be created within the hook, the capture loop cannot start until the shared memory has been filled with valid data. Creating an additional "initialize" event fixes this issue. Additionally, changed the way that named kernel objects are opened/created. Before, there were functions that would first try to open named objects and then implicitly create them if opening failed (assuming that if the hook didn't create it first, game capture would), now it's been changed so that you can only either explicitly open or create.
2016-11-01 00:21:42 -07:00
static inline HANDLE open_event(const char *name)
{
return OpenEventA(GC_EVENT_FLAGS, false, name);
win-capture: Add hook helper functions for IPC These inline functions simplify the process of using windows IPC objects, such as mutexes and events.
2014-11-10 01:48:16 -08:00
}
win-capture: Create all named objects within hook All named objects (including file mapped shared memory) need to be created within the hook itself due to the fact that UWP programs cannot access named objects outside of the UWP process. Because shared memory needs to be created within the hook, the capture loop cannot start until the shared memory has been filled with valid data. Creating an additional "initialize" event fixes this issue. Additionally, changed the way that named kernel objects are opened/created. Before, there were functions that would first try to open named objects and then implicitly create them if opening failed (assuming that if the hook didn't create it first, game capture would), now it's been changed so that you can only either explicitly open or create.
2016-11-01 00:21:42 -07:00
static inline HANDLE create_mutex(const char *name)
win-capture: Add hook helper functions for IPC These inline functions simplify the process of using windows IPC objects, such as mutexes and events.
2014-11-10 01:48:16 -08:00
{
win-capture: Create all named objects within hook All named objects (including file mapped shared memory) need to be created within the hook itself due to the fact that UWP programs cannot access named objects outside of the UWP process. Because shared memory needs to be created within the hook, the capture loop cannot start until the shared memory has been filled with valid data. Creating an additional "initialize" event fixes this issue. Additionally, changed the way that named kernel objects are opened/created. Before, there were functions that would first try to open named objects and then implicitly create them if opening failed (assuming that if the hook didn't create it first, game capture would), now it's been changed so that you can only either explicitly open or create.
2016-11-01 00:21:42 -07:00
return CreateMutexA(NULL, false, name);
}
static inline HANDLE open_mutex(const char *name)
{
return OpenMutexA(GC_MUTEX_FLAGS, false, name);
}
win-capture: Add hook helper functions for IPC These inline functions simplify the process of using windows IPC objects, such as mutexes and events.
2014-11-10 01:48:16 -08:00
win-capture: Create all named objects within hook All named objects (including file mapped shared memory) need to be created within the hook itself due to the fact that UWP programs cannot access named objects outside of the UWP process. Because shared memory needs to be created within the hook, the capture loop cannot start until the shared memory has been filled with valid data. Creating an additional "initialize" event fixes this issue. Additionally, changed the way that named kernel objects are opened/created. Before, there were functions that would first try to open named objects and then implicitly create them if opening failed (assuming that if the hook didn't create it first, game capture would), now it's been changed so that you can only either explicitly open or create.
2016-11-01 00:21:42 -07:00
static inline HANDLE create_event_plus_id(const char *name, DWORD id)
{
char new_name[64];
sprintf(new_name, "%s%lu", name, id);
return create_event(new_name);
}
static inline HANDLE open_event_plus_id(const char *name, DWORD id)
{
char new_name[64];
sprintf(new_name, "%s%lu", name, id);
return open_event(new_name);
win-capture: Add hook helper functions for IPC These inline functions simplify the process of using windows IPC objects, such as mutexes and events.
2014-11-10 01:48:16 -08:00
}
win-capture: Create all named objects within hook All named objects (including file mapped shared memory) need to be created within the hook itself due to the fact that UWP programs cannot access named objects outside of the UWP process. Because shared memory needs to be created within the hook, the capture loop cannot start until the shared memory has been filled with valid data. Creating an additional "initialize" event fixes this issue. Additionally, changed the way that named kernel objects are opened/created. Before, there were functions that would first try to open named objects and then implicitly create them if opening failed (assuming that if the hook didn't create it first, game capture would), now it's been changed so that you can only either explicitly open or create.
2016-11-01 00:21:42 -07:00
static inline HANDLE create_mutex_plus_id(const char *name, DWORD id)
win-capture: Add hook helper functions for IPC These inline functions simplify the process of using windows IPC objects, such as mutexes and events.
2014-11-10 01:48:16 -08:00
{
char new_name[64];
Fix windows printf format warnings (from mingw)
2015-02-08 15:40:51 -08:00
sprintf(new_name, "%s%lu", name, id);
win-capture: Create all named objects within hook All named objects (including file mapped shared memory) need to be created within the hook itself due to the fact that UWP programs cannot access named objects outside of the UWP process. Because shared memory needs to be created within the hook, the capture loop cannot start until the shared memory has been filled with valid data. Creating an additional "initialize" event fixes this issue. Additionally, changed the way that named kernel objects are opened/created. Before, there were functions that would first try to open named objects and then implicitly create them if opening failed (assuming that if the hook didn't create it first, game capture would), now it's been changed so that you can only either explicitly open or create.
2016-11-01 00:21:42 -07:00
return create_mutex(new_name);
win-capture: Add hook helper functions for IPC These inline functions simplify the process of using windows IPC objects, such as mutexes and events.
2014-11-10 01:48:16 -08:00
}
win-capture: Create all named objects within hook All named objects (including file mapped shared memory) need to be created within the hook itself due to the fact that UWP programs cannot access named objects outside of the UWP process. Because shared memory needs to be created within the hook, the capture loop cannot start until the shared memory has been filled with valid data. Creating an additional "initialize" event fixes this issue. Additionally, changed the way that named kernel objects are opened/created. Before, there were functions that would first try to open named objects and then implicitly create them if opening failed (assuming that if the hook didn't create it first, game capture would), now it's been changed so that you can only either explicitly open or create.
2016-11-01 00:21:42 -07:00
static inline HANDLE open_mutex_plus_id(const char *name, DWORD id)
win-capture: Add hook helper functions for IPC These inline functions simplify the process of using windows IPC objects, such as mutexes and events.
2014-11-10 01:48:16 -08:00
{
char new_name[64];
Fix windows printf format warnings (from mingw)
2015-02-08 15:40:51 -08:00
sprintf(new_name, "%s%lu", name, id);
win-capture: Create all named objects within hook All named objects (including file mapped shared memory) need to be created within the hook itself due to the fact that UWP programs cannot access named objects outside of the UWP process. Because shared memory needs to be created within the hook, the capture loop cannot start until the shared memory has been filled with valid data. Creating an additional "initialize" event fixes this issue. Additionally, changed the way that named kernel objects are opened/created. Before, there were functions that would first try to open named objects and then implicitly create them if opening failed (assuming that if the hook didn't create it first, game capture would), now it's been changed so that you can only either explicitly open or create.
2016-11-01 00:21:42 -07:00
return open_mutex(new_name);
win-capture: Add hook helper functions for IPC These inline functions simplify the process of using windows IPC objects, such as mutexes and events.
2014-11-10 01:48:16 -08:00
}
static inline bool object_signalled(HANDLE event)
{
if (!event)
return false;
return WaitForSingleObject(event, 0) == WAIT_OBJECT_0;
}