Skip to content

v0.3.0 - Beta 1

Pre-release
Pre-release
Compare
Choose a tag to compare
@MolotovCherry MolotovCherry released this 15 Oct 21:05
v0.3.0b1
1c3d198
This commit was signed with the committer’s verified signature.
MolotovCherry Cherry
GPG key ID: 8B5DD74E59C6C5AB
Learn about vigilant mode.

Notes

This comes with a file loader.dll. No special setup is required. Just keep loader.dll in the same folder as the 2 exe's and everything will work. I have added notes on this in a text file in the zip for the next release to avoid confusion.

Changes

Did a massive refactoring of most of the codebase1. Plugin loading logic was separated out into a separate loader dll to allow for more complicated logic which was not possible (or very very difficult) using the previous method.

  • Faster plugin loading. Once the loader is injected, it does the work of the actual plugin loading at full speed from within the actual process.
  • Also multi-threaded plugin loading to load plugins in parallel. Before this, they only loaded sequentially, so technically it could be slower.
  • The loader now calls any exported Init fn so that any plugin developers can properly program their plugin.2 (P.S. as a plugin dev, your init function can take as long as you want. Though at that point it's probably more recommended to just spawn your own thread so Init can finish in a timely manner)
  • Additionally to the above, developer plugins can also detect when yabg3ml is running vs other mod loaders. This allows you to do things like not run Init code in DllMain, and instead let my mod loader call Init. Otherwise, if it's not mine, you can Init from DllMain to keep compatibility with other mod loaders. See the plugin template for how to do this.
  • Note to plugin devs / mod loader makers: If you were using an old commit of native plugin lib, please update asap. There has been dev work on it and the previous metadata macro is incompatible with this version.
  • native plugin template for plugin devs has been updated and improved. Check it out if you used a previous version.
  • More robust dirty module check, which is accurate cause it checks windows file identifier.
  • Improved process watching code.
  • Use default config values if config is malformed. This will allow it to load if entries are missing, though note if you're doing default values it may load the wrong one since you haven't configured it. Also added popup if loading config failed so it's clearer what happened.
  • Grant SE_DEBUG_NAME if running as admin just to ensure we get extra permissions. This will ensure the program succeeds if it didn't work in non-admin mode
  • General stability improvements due to the refactor and testing.
  • Various ux improvements to not crash but rather display a popup with better information
  • Updated visual style of popups to look more modern.
  • Many many many dependency updates and other misc fixes

Full Changelog: v0.2.6...v0.3.0

  1. There were 49 changed files, 139 commits, and 3,479 additions and 1,242 deletions. ↩

  2. Why? Because actually doing anything non-basic inside DllMain is a very bad idea. Deadlocks, UB (even silent UB), and a whole host of other nasty things can happen if you use DllMain for anything except simple tasks. An Init function is the proper way to do it, so now we support it! This is also reflected in some updates to the plugin template. Also, if you're a dev, the Rust signature is extern "C" fn Init(); if you use C, it is void __cdecl Init(void). See articles below.
    https://devblogs.microsoft.com/oldnewthing/20070904-00/?p=25283
    https://devblogs.microsoft.com/oldnewthing/20040128-00/?p=40853
    https://devblogs.microsoft.com/oldnewthing/20040127-00/?p=40873
    https://devblogs.microsoft.com/oldnewthing/20100115-00/?p=15253
    https://blog.barthe.ph/2009/07/30/no-stdlib-in-dllmai/
    https://learn.microsoft.com/en-us/windows/win32/dlls/dllmain?redirectedfrom=MSDN (see warning section)
    https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-best-practices ↩

Assets 3
Loading