Announcement

Collapse
No announcement yet.

Fedora Moves Ahead With Plans To Drop Packages Having Bad Security Practices

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by Weasel View Post
    Bad design? That's exactly what plugins are. They rely on the VST SDK for example, which defines an audio interface. That's it.

    Plugins obviously need a GUI and a toolkit, which is totally separate from the VST spec (they can do what they want you know).
    If your (in-process) plugins need a GUI, it might be a good idea to provide or mandate an API for that, so that they look and work somewhat the same as your application. Providing a GUI abstraction layer would also make it a lot easier to port plugins between various platforms (no need to write a new GUI for each of them).

    But of course nobody ever said the VST spec/SDK is sane in that regard (it was never designed to be cross-platform, I suppose).

    Originally posted by Weasel View Post
    Cause DLLs have no issues whatsoever loading 100 different versions of the same toolkit, since each symbol is local to the module.

    Using ELF is like using short-named global variables in your code with no prefix and no namespaces whatsoever. Retarded crap.
    You don't seem to understand the difference between binary formats and what (dynamic) linkers do with them.

    ELF ≠ libc

    ELF supports versioned symbols and such, but the default shared library loader does not use them, and by default most linkers don't create them. In any case, it's up to the application loading them to ask for it; I'm pretty sure neither Reaper nor the plugins do that. It's up to the library provider to support it. And I suppose the VST spec and/or SDK don't have provisions for this.

    There is also another issue: I'm not sure Gtk itself would like that, because of the way it implements its main loop etc., so sharing Gtk 2 & 3 in one application might fail even on Windows (but I didn't test that, so it's just a guess, and it might depend on what features you try to use, as Gtk is more than just a GUI library).

    Another solution might be to use out-of-process plugins, of course, but those might come with their own issues (especially on Windows?).

    Comment


    • #22
      Originally posted by JanC View Post
      If your (in-process) plugins need a GUI, it might be a good idea to provide or mandate an API for that, so that they look and work somewhat the same as your application. Providing a GUI abstraction layer would also make it a lot easier to port plugins between various platforms (no need to write a new GUI for each of them).

      But of course nobody ever said the VST spec/SDK is sane in that regard (it was never designed to be cross-platform, I suppose).
      It works on Mac and Windows so it's pretty cross platform I guess. (it even works on Linux, albeit with those problems due to ELF)

      Also you seem to be missing the point here. Plugins are not always tied to an application. In the VST case, you don't write plugins for REAPER, you write plugins for the VST interface. An application, such as REAPER, can be a VST host and implement the hosting interface. There are a LOT of VST hosts out there.

      People need to stop this mentality that plugins need to be written only for a specific application. No, plugins need to be written for a specific interface and then they work for ALL applications that implement such interface.

      On a sidenote: VST is a garbage interface, but there are other interfaces out there which exhibit the same problems only on ELF. VST2 is however, for some reason, the most popular by far and wide, so I used it as an example.

      Originally posted by JanC View Post
      ELF supports versioned symbols and such, but the default shared library loader does not use them, and by default most linkers don't create them. In any case, it's up to the application loading them to ask for it; I'm pretty sure neither Reaper nor the plugins do that. It's up to the library provider to support it. And I suppose the VST spec and/or SDK don't have provisions for this.

      There is also another issue: I'm not sure Gtk itself would like that, because of the way it implements its main loop etc., so sharing Gtk 2 & 3 in one application might fail even on Windows (but I didn't test that, so it's just a guess, and it might depend on what features you try to use, as Gtk is more than just a GUI library).
      But symbol versioning should be *enforced* by the loader, or by the format itself. For example, with DLLs, it is literally impossible to import a symbol without specifying the module for it. As in, impossible from a format standpoint (which is really what this is about). I think it's similar with Mach-O. That's why ELF sucks.

      Originally posted by JanC View Post
      Another solution might be to use out-of-process plugins, of course, but those might come with their own issues (especially on Windows?).
      Out-of-process actually sounds like there should be no problems neither on Linux/ELF and Windows. It's a known hack around shitty plugins coded with global variables that can't run in more than one thread.


      Note that it's not Linux's fault per se. Reaper in Wine works just fine. It's not a problem in Linux itself. It's a problem with the ELF format and the loader. I never said you can't have a sane environment on Linux. That sane environment is called Wine. ;-)

      Comment


      • #23
        I explained why there is no problem with the ELF format, and where the problem(s) likely are, but if you want to ignore people trying to help you, feel free…

        Comment

        Working...
        X