On Fri, Sep 10, 2010 at 4:37 PM, Kai Tietz <[email protected]> wrote: >>>> Hrmph, I guess the only way here is to bite the bullet and >>>> really add a -lmingwex after all other libs. However it would >>>> have been really nice if we provided them as always_inlines >>>> >>>> >>> Hmm, always inline is bad too. As gcc allows in debugging build to >>> omit inlines, which allows debugging even of those. >>> I think it would be a better solution to provide an additional >>> intrinsic library for making gcc compatible to VS. I don't like to see >>> this force-inline in headers as it has the tendency to hide stuff and >>> makes function pointer passing of those functions not correct working, >>> as each module gets an new version of this intrinsic. >>> >> That's a good idea. At least for driver builds like these especially >> if they are debug builds. However, we can also add _CRT_INLINE versions >> of them to wdm.h just like we do in winnt.h, any bad side effects you can >> think of? How does r/os deal with this? >> > > Well, providing some of those __CRT_INLINE to ddk wouldn't hurt, but > well Amine can for sure enlight us here a bit how r/os is handling > things here. >
I will carry out more tests but it seems there are performance issues when using the MinGW-w64 build of libusb0.sys compared to the WDK build, especially when using as a filter driver. I am wondering if this can be the consequences of linking to libmingwex. And linking to libmingwex is anyway a hack right now. Any suggestions for a better solution? -- Xiaofan ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
