Re: [fluid-dev] Error in DllMain.

[Carlo Bramini]

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 <address@hidden> 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" <address@hidden>
> > > A : address@hidden
> > > 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
> > > address@hidden
> > > https://lists.nongnu.org/mailman/listinfo/fluid-dev
> > >
> _______________________________________________
> fluid-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/fluid-dev