Thanks for bringing this up. I have no clue of this Win32 stuff, so if you know how to fix it properly I would welcome a pull request on that.
Tom 2017-11-04 12:26 GMT+01:00 Carlo Bramini <carlo.bra...@libero.it>: > Hello, > > my primary platforms are Windows 7 and XP. > I'm sorry, but I wouldn't say "this works fine on XP". > It may work for luck, or it could work but with some malfunctions that you > cannot see at user level. > Perhaps it could also depend on the application using libfluidsynth: > maybe, with the console mode program included with the library, you won't > see troubles at least apparently, but it could not be true that we will be > always lucky. > > Sincerely. > > > > Il 4 novembre 2017 alle 0.54 Ceresa Jean-Jacques < > jean-jacques.cer...@orange.fr> ha scritto: > > > > Hello Carlo, > > > > > I think that the best thing to do is to revert this change and restore > original code, with the little addition of keeping the window handle > private into each fluid_dsound_audio_driver_t structure. > > > > You are right, this is a more straigtforward solution. > > > > Despite the fact you are right, even if window creation inside DllMain() > is a very bad practice, this works fine on XP. So, which Windows OS do you > usualy use ? > > > > Regards > > > > > > Message du 01/11/17 15:00 > > > > De : "Carlo Bramini" <carlo.bra...@libero.it> > > > > A : fluid-dev@nongnu.org > > > > Copie à : > > > > Objet : [fluid-dev] Error in DllMain. > > > > > > > > Hello, > > > > I had noticed that Fluidsynth for Windows is doing a very dangerous > thing. > > > > Actually, when I tried to run my test program with double click but > incidentally nothing happened, I got quite immediately this suspect. > > > > Into fluid_dll.c there is an implementation of DllMain with some > code. > > > > In this code, it creates an handle to a window to be used for > setting the cooperative level in the directsound driver. This is wrong. > > > > DllMain should never call some functions, because during the lock > applied by the loader these functions may not be resolved, may not work > correctly, could crash or can cause some strange behaviors. On Windows > 9x/ME, this could even hang the entire OS. The NT kernel is more robust and > protected, so the effects are tipically limited to the current local > thread. It seems to me that it was implemented in a different manner in the > past, because fluid_win32_create_window() is also called into > fluid_dsound.c. Perhaps, somebody did this change without knowing the > drawbacks, by thinking that in this way one window handle could be created > just once, when the DLL is loaded, instead of creating and destroying it > for each directsound object created. > > > > More details could be found here: > > > > > > > > https://msdn.microsoft.com/en-us/library/windows/desktop/ > dn633971(v=vs.85).aspx > > > > > > > > I think that the best thing to do is to revert this change and > restore original code, with the little addition of keeping the window > handle private into each fluid_dsound_audio_driver_t structure. > > > > > > > > Sincerely. > > > > > > > > _______________________________________________ > > > > fluid-dev mailing list > > > > fluid-dev@nongnu.org > > > > https://lists.nongnu.org/mailman/listinfo/fluid-dev > > > > > > _______________________________________________ > > fluid-dev mailing list > > fluid-dev@nongnu.org > > https://lists.nongnu.org/mailman/listinfo/fluid-dev > > _______________________________________________ > fluid-dev mailing list > fluid-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/fluid-dev >
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
