I am getting support issues over the Max DLL issue on Windows each and every week !
If Xojo does not want to change the silly system of loading the entire world instead of users adding reference to what they want to use per project then why…not fix it by Loading plugin, scanning its interfaces, then unloading it, flagging where each item is of course. Then if during work in the IDE instance is created (control dropped on window, or control instance creates instance of a class with REALGetClassRef & REALNewInstanceWithClassRef), then look up in the tables and load that DLL again and keep that one loaded. => Windows max DLL limit gone.
Most plugins are such in nature that they will never need to persist alive while in the IDE. So 99% of the loaded DLL’s would no longer be loaded.
Well they still need to be able to load what is actually used though by the IDE, so that would not work from other process. Since Plugin controls are actually used running by the IDE once their put on a window. (And classes that plugin controls might need)
I dont think this should be really seen as Windows only thing anyhow, should be just load, see what plugin has, unload. (On ALL platforms to save memory and resources !!!). Then just reload whatever is needed when user drops controls on a Window.
Or if they would not want the work of detecting when needing to reload a DLL, then they could let us flag DLL’s that need to persist at IDE time -> REALPersistDLL(); Even if not as nice and not as effective then you would probably still have 80-90% less loaded DLLs even if you still would have some you don’t use loaded. Since such big majority of plugins do nothing at all in IDE design time.
I’m one of the users who just got smacked by this limit. Since Remote Debugging from Mac to Win isn’t working on my major project, I’m trying to run it within Xojo on Windows, but despite removing every plugin I don’t need, I’m still over the limit. The only solution is to remove functionality while testing on Windows, which is very difficult to do when working on cross-platform code.
With this limitation, I can’t imagine how Windows users manage to develop any significant application…
[quote=274558:@John McKernon]I’m one of the users who just got smacked by this limit. Since Remote Debugging from Mac to Win isn’t working on my major project, I’m trying to run it within Xojo on Windows, but despite removing every plugin I don’t need, I’m still over the limit. The only solution is to remove functionality while testing on Windows, which is very difficult to do when working on cross-platform code.
With this limitation, I can’t imagine how Windows users manage to develop any significant application…:([/quote]
Have you considered switching out some plugins for Xojo code? I know there is a lot of cross-over on features where plugins are simply a shortcut for code that can be created with Xojo. I don’t hate plugins, they are great and can extend the functionality of Xojo - allowing more powerful apps. But sometimes it’s just not necessary to use one.
What Max DLL issue, if that isnt a silly question?
Since those terms are only 3 characters long each, a search of the forum hasnt turned up anything but this post.
I use plugins for things like rotating pictures, time control, calendar control, encryption, SQL plugins, search control, .xml parsing, etc. - all cross-platform, and difficult or slow to implement in pure Xojo code. I’m using a total of 26 plugins (which seems like a very reasonable number), but the way they’re packaged, each plugin can contain lots of DLL’s that I don’t use.
I have no idea what the actual limit is, but I sure hit it today. The clue was that plugins higher in the alphabet weren’t loaded, since Xojo apparently loads in alphabetical order.
Xojo just has to fix it its not really complicated. There is no reason to keep plugins loaded in the IDE that are not used by the IDE once their interface been scanned. The sittuation as is makes plugin authors look bad and in the end when the customers understand it makes Xojo look really bad. Its not needed and can be easily solved.
There is no valid reason for keeping everything loaded.
Image rotation, encryption, and XML parsing can be done with Xojo code though. To get around the DLL limit you may have to sit down and do the implementation which is unfortunate.
[quote=274584:@Björn Eiríksson]Xojo just has to fix it its not really complicated.
[/quote]
Yes - we do
Please stop saying “it’s easy” as you have no idea how easy or hard it is
Its not “easy” as in “hey we’ll fix this today”
It’s a significant refactoring effort in both our C++ and Xojo code
Not “easy”
Actually Norman I do have idea about it. So please don’t give me that.
I have offered cheap solutions to problem that should not be there in the first place had things been done right. I suggest you look at them, since this really ticks of your customers, my customers, Christian customers. So coming like this telling me I dont have idea about it is not going to help the issue. I do know quite a bit about runtime architectures as well as how Xojo is glued together.
Its all our goals to get Xojo to succeed so please dont brake that down. When we are offering to flag what IDE does not need to use in the plugins.
This is not productive and Norman’s right. It’s rare that things are as easy to implement as they might sound.
[h]Avoid the Static CRT[/h]
The simplest approach is for plugin authors to link the CRT dynamically, as Microsoft recommends. In addition avoiding the TLS slot limit, this would save memory and resources in the user’s programs at runtime.
[h]Unloading Shared Libraries[/h]
Unloading shared libraries after the IDE has invoked their REALPluginMain is theoretically possible. At least, theoretically possible on Windows and Linux. Unloading shared libraries on OS X can cause dangling pointers if there’s Objective-C classes or constant CFStrings and Apple generally recommends against it.
At a minimum:
The IDE’s plugin loader code would need to be updated so that deep copies are made of all the plugin data structures.
The plugins SDK would need to be audited more generally to ensure that nothing at all from the shared library is kept around. For example, it’s possible that a string could end up in a cache somewhere.
A new SDK function would need to be added to allow plugins to indicate they are safe to unload. This would be a suggestion to the IDE and be overridden if the plugin exposes a control or a database engine.
A significant amount of testing would need to be done. Unloading shared libraries invokes a lot of code in an environment that has to be tread in carefully. The docs on DllMain cover it fairly well.
[h]Out of Process Plugins[/h]
The real, long term solution is for the IDE to run all plugins out of process and in a tight sandbox. It avoids limits like this and improves the IDE’s stability when plugins crash (or try to manipulate the IDE process).
The Max DLL problem has been around for a long time. The solution is to pare your plugins down to only what you need. This solves the max DLL issue and makes the IDE startup a ton faster and has the advantage of helping keep autocomplete from choking on many needless methods.
I run with a very narrow set of MBS and Einhugur plugins. It’s not hard to do if you’re working on the same project all the time. I occasionally have to do go find a plugin for a project but it’s not a horrible burden.
I remember talking to Aaron about this many moons ago. He had an idea, on paper at least, on how to accomplish better plugin management. Alas, he was let go from RS before he could implement it.
Does remote debugging not work for you? Or do you mean 64 bit remote debugging?
Regular remote debugging has worked for me for years, but recently stopped working. Ken Tekinay and I spent an hour and couldn’t find anything obviously wrong in my setup or code. So I’ll be filing a tech support request for it later today.
Huh
I just ran the IDE as a remote debug session to one of my windows vm
lots of stuff to make sure is copied in a post build step to make this work but it just worked
