Thanks for the report! Well, I am truly shocked. Hijacking a program's main function just because I included the SDL.h header is totally unacceptable! Also, the reason for this drastic measure isn't properly documented by SDL. Their reason to "run code before other code runs" is just the way most backdoors work. And IMO, it is a reason for completely removing SDL support, if we cannot prevent it from doing so. Esp. this is why any app is supposed to call SDL_Init() to handle the startup stuff.

I quickly looked through the SDL code. It seems that this part has undergone a few changes between SDL2 and SDL3. I will try to reproduce your finding, then I'll see if defining SDL_MAIN_HANDLED solves this problem appropriately.

Thanks for looking into this. I was surprised by the "main" replacement business as well. I assume the previous version of fluidsynth worked with SDL2 because it didn't use "UNICODE" (and I am using UCRT so I assume I don't need UNICODE, so I am happy disabling that in my builds).

SDL3 was just released yesterday, which no longer automatically includes SDL_main.h. Moving to SDL3 would be my preferable solution, but it requires a few code changes in fluid_sdl2.c. I'm not sure when I'll find time to do so, hence I'd welcome a PR. Until this is done, I will disable SDL2 support by default for the next fluidsynth release.