Re: [fluid-dev] Error in DllMain.

[Tom M.]

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 <address@hidden>:

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

_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev