Flurry of Activity

Hey Aaron.. Both these projects got me thinking about a problem I have: where can you hide DLLs? RB hides it's own plugin DLLs inside the resources section of the executable, does it not? Could we put our own 3rd party DLLs in our plugins folder and expect them to get sucked in by the linker?

We jump thru some amazing hoops to get plugins to work, but we don't expose those hoops to the user. There's really no easy way to "hide" DLLs.

One thing that you can do (I think), is drag the DLL into your project as a project item. Then, write it out to the user's temp directory when the app launches (make sure to append the .dll back onto it!), and then use Soft declares with an absolute path to the dll file. That might work.

Great idea - thanks.

How is the memory footprint when you do that? I mean does REALbasic load the resource into memory only the first time it is accessed for each program run or is it always loaded into memory on every launch used or not?

We cache plugins, so once we've already loaded one, we don't load it a second time. However, that's specific to the plugin, not to the memory loader. We load the plugins on app launch since any plugin which was linked into the application must be used (the linker dead-strips unused plugins).

Ultimately, the memory footprint is essentially the same as if the DLL is loaded from disk. All DLLs used by an application are loaded in the application's memory space (only once) when they're on disk. Since we cache plugin loading so that it's only loaded once, it's a wash on the footprint.

Sorry that I wasn't clear with my question... what I meant to ask was when you drag something (in this case a DLL) into the project, isn't it treated like a String Constant except in a few cases like Pictures? I am just wondering if these Project Items get loaded on every launch or only when they are first requested.

Oh, you're not talking about how we deal with plugins, but how we deal with project item resources?

Well, a project item is part of your application (it's linked into it, no magic there), which means it takes up space when your application is mapped into memory by the system loader. So yes, technically it's taking up memory as soon as the application is launched. Again, things that aren't used are stripped out at link time. And yes, it's just a string constant when you reference it. When you reference the "string", you're really just obtaining a pointer to something that's already loaded into your application's memory space.