icex2
e61dfb3977
Remove usages of AVS threads and logging functions from the bemanitools backend. Use the bemanitools 6 API instead which propagates interfaces to call thread and log APIs. Prior design decisions for using these were: - have a single log stream through the AVS logging system for “neatness”, log output redirection options in launcher, and theoretically logging to an xrpc endpoint - IIDX 19 to IIDX 24 crash the AVS logging engine in libavs due to IO hook code running in a non AVS thread (threads in ezusb library) causing a stackoverflow when trying to acquire a mutex (see dev journal 2018-02-10-logging-breakdown-avs.md for details) With a flexible log sink architecture in the core of bemanitools, and a separate writer function that is hooked up as a log writer to AVS, log streams are still unified on a sink level. This takes care of having all log messaged sinked to the same targets no matter how many logging engines are using them. This avoids going through the AVS logging engine with the IO related hooking code in iidx, which just uses the bemanitools logging engine instead. Furthermore, this removes any needs to having to switch thread and logging implementations once AVS is booted which significantly simplifies the runtime orchestration during bootstrapping. The log-server, which was specifically implemented for iidx to solve the threading issue, can also be removed now. Unfortunately, this also caused performance issues such as stuttering due to it’s rather simplistic implementation.
35 lines
1.3 KiB
C
35 lines
1.3 KiB
C
#ifndef BT_API_HOOK_H
|
|
#define BT_API_HOOK_H
|
|
|
|
#include <windows.h>
|
|
|
|
#include <stdbool.h>
|
|
#include <stdint.h>
|
|
#include <stdlib.h>
|
|
|
|
#include "api/core/config.h"
|
|
|
|
typedef void (*bt_hook_iat_dll_name_get_t)(char *buffer, size_t size);
|
|
typedef bool (*bt_hook_pre_avs_init_t)(const bt_core_config_t *config);
|
|
// game module reference, either the exe or dll. allow for further targeted hooking/patching
|
|
// remark: you can't own the memory of the property_node config. whatever you need form that, make sure to copy the data and not just reference it.
|
|
// there is no guarantee the data is not free'd/gone after this call returns
|
|
// use the property api to iterate the data and parse it into your own custom configuration struct
|
|
// it is advised to also validate all parameters
|
|
// if no configuration was provided upon loading, the config_node contains an empty root node
|
|
typedef bool (*bt_hook_main_init_t)(HMODULE game_module, const bt_core_config_t *config);
|
|
typedef void (*bt_hook_main_fini_t)();
|
|
|
|
typedef struct bt_hook_api {
|
|
uint16_t version;
|
|
|
|
struct {
|
|
// Optional
|
|
bt_hook_iat_dll_name_get_t iat_dll_name_get;
|
|
bt_hook_pre_avs_init_t pre_avs_init;
|
|
bt_hook_main_init_t main_init;
|
|
bt_hook_main_fini_t main_fini;
|
|
} v1;
|
|
} bt_hook_api_t;
|
|
|
|
#endif |