Quote:
Originally Posted by ultim
I am much more concerned about some changes relating to Avs 2.6. One is that back in 2015 IanB changed the x64 binary interface in an incompatible way, ignorant of the fact that there is already a significant x64 plugin ecosystem, and he just broke it. This leaves Avs+ the following options: 1) Pull IanB's corresponding changes and recompile all x64 plugins. Or, 2) diverge from Avs2.6 when it comes to x64 plugins. IMHO it is a tough call. On one hand I'd very much prefer to stay in sync and compatible to Avs 2.6 in all aspects. On the other hand I'd prefer not to have to follow Avs2.6 and its inexplicable decisions any further, but this comes at the great price of splitting the community. The community needs to be united if anything, not further segmented. And actually there is a 3rd alternative, 3) if we'd need to break many plugins anyway just by following Avs 2.6, we could break with the old interface completely. On one hand this brings the disadvantages from both worlds (breaking plugins AND splitting the community), but would allow us break free of the very limiting old interfaces, to sanitize and upgrade them in a future-proof way. Of course this presumes the support of plugin writers for Avs+ even more than if we took option 2).
|
At one point I remember someone bringing up the idea of eliminating the C++ compiler difference in the event of MinGW builds by having a compatibility shim that wraps C++ plugins and loads them through the C interface.
Would something like that be able to also eliminate the compatibility problems with 2.6's switch to size_t to support 64-bit? Alternately, have a separate loader for size_t-based 64-bit plugins that the user can do specific overrides for if necessary (e.g.,
LoadPlugin("Plugin.dll", alt_loader=true), or
Load_New64_Plugin("Plugin.dll")). If that'd even work, that is.
On a purely philosophical level, I'd say break with the old interface completely and start fresh. On a practical level, I know that's ill-advised. I'd prefer that we have some kind of fallback so that plugin devs can migrate to the new interface organically without shocking users. But design the new interface so it doesn't collide at all with the old and is completely self-contained. This way plugins can simply add another interface for AviSynth+ alongside their interfaces for classic AviSynth (which avsplus could still load in this scenario) and VapourSynth without any real hiccups.