Ive noticed an increase in the number of plugins that exist as DLLs in my windows build over the last few years.
In 2010, there were about 5 or 6. Now there’s about 41 including AVcodecs even though I don’t play any video or music files.
I know Christian revised the content of the plugins a while back, but my understanding is that the DLL should only get installed if the app uses one of the function calls.
So Im confused about why a Windows build includes
MBS_MacOSX_LaunchServices.dll
Why would a windows app need a MACOSX function?
Because you reference the plugin part.
You can of course make sure your Mac only code is in
#if targetMacOS
...
#endif
How can the Windows app be calling a Mac OS call?
Great.
What call/s should I #if around?
I don’t know your app.
But look for things with MBS in name.
Thats fairly obvious. It didnt help, however.
None of them say Launch, but I still dont know why a MacOSX DLL even exists.
Well, you could send me a copy of project to review.
Or check all usages of MBS classes.
see
https://www.mbsplugins.de/archive/2013-10-21/Using_dash_if_to_reduce_app_si
If you’re building a macOS app on Windows, the DLL has to exist so the compiler knows what functions are available from that plugin on macOS.
Any time you target a platform different than the one you’re on the plugins have to contain definitions of the functions for that other target so the compiler knows they’ll exist on the other target.
They may just be stubs - but they have to exist for the compiler.
Thats the point really.
Im building a windows app on a windows machine, and a DLL called MacOSX Launch services appears in the Libs folder.
It cannot be calling any Mac OSX Launch services on a Windows machine.
Maybe there is a function called MBSDoNothingVeryImportant which happens to be in that plugin for some reason.
Assuming so, I cant work out which function it is.
As said, check all entries with MBS in name.
[quote=396810:@Jason Parsley]If you’re building a macOS app on Windows, the DLL has to exist so the compiler knows what functions are available from that plugin on macOS.
Any time you target a platform different than the one you’re on the plugins have to contain definitions of the functions for that other target so the compiler knows they’ll exist on the other target.
They may just be stubs - but they have to exist for the compiler.[/quote]
Im not [quote]’ building a macOS app on Windows’[/quote]
Clearly I’m missing something here.
Never mind. Life’s too short.
The way it was explained, the compiler needs to know for both platforms what plugin functions are available, even if it’s not on the platform you’re using. I wouldn’t get caught up on the one phrase.
That is right, so the plugin includes DLLs for all platforms.
Just when you build, you can use #if to avoid a Mac plugin ending in a Windows app.
@Jeff Tullin
What happens if you remove all of the MBS plugins that specifically say Mac in the name from your plugins directory? If your project still compiles, that would be the easiest solution… and your IDE should be faster too.
If it doesnt compile, youve found the culprits.
Tried that.
It compiled AND still added the DLLs.
Clearly caching at work.
But I can never remember how to clear the cache on a Windows machine (why isn’t there a menu item for this??)
I deleted the DLL from the built app Libs folder and the app didn’t start.
No messages, just nothing…
I’ll get back to it eventually.
I just don’t understand why such a DLL even exists in the first place.
It’s like bundling an aqualung with a bicycle. 
Cache is in hidden AppData folder in your user folder.
See also http://www.monkeybreadsoftware.de/xojo/plugincache.shtml
And after removing plugins, clearing cache and building fresh copy you should have an error or no DLL there.