Has anyone here had any experience resolving the win32 error 8: "Not enough storage is available to process this command"?? Some background... some people may recall past threads where I discuss some incredibly bizarre scenarios that I am trying to deal with due to the obnoxious nature of the project I'm working on. Basically, we (me and a couple coworkers) are trying to take some old C simulator type code--written for Linux--and get it working within a component-based simulation framework on Win32... this typically involves writing an "interface layer" which serves as the middle man. If the framework wants to do something, it calls the interface, which calls down into the guts of the simulation code and makes it do what it has to do by whatever means necessary. A major problem that is beginning to come up is that the old C sim code is VERY heavily reliant upon static data. A single huge static data structure--which contains member structures for all of the subsystem data--maintains almost all of the data for the entire aircraft and all of its subsystems... this really sucks. Furthermore, there are tons of local static variables (things like "int tf_firstpass" to check for the need to initialize things). One of the things we want to do eventually is allow for multiple instances of the aircraft to fly at the same time, which is not possible with the static data. So I rewrote the interface to be very component based and loaded from DLLs. Now, at runtime, for each instance of the aircraft I am actually making a copy of the DLLs that is named for the aircraft instance and loading the DLL into a new address space per aircraft. Surprisingly, this works. (If anyone has better ideas, I'm all ears... I know that this solution is hideous). But after loading, unloading, loading, unloading, etc., a few times, the LoadLibrary call will fail for one particular DLL and GetLastError() gives me the error... Error 8 "Not enough storage is available to process this command". There isn't a ton of info online for this error, it seems, and I was wondering if anyone knew how to go about resolving it?

Thanks for the links. I'll check them out.

I should note that the reason that I am actually having to reload them occasionally is that I need for the static data to be reset to its initial state. Unfortunately, the underlying sim code doesn't expose any clean interface for doing that sort of thing... in fact, most of the subsystems are actually initialized the first time you run them. The initialization and update logic are coupled together (using one of those static boolean flags to indicate first_pass). The horrible design of the sim code is causing all sorts of awkward situations.

Also, I currently have 15 or 20 components running, and it usually happens after the 3rd or 4th reload. So, in total I am only doing about 80 to 100 LoadLibrary calls. But I am calling FreeLibrary() to unload each component before reloading them, so they should be properly released... er, shouldn't they?

I'll go check out your links now. r++

I've thought of a lot of things. The problem with the data copying is... prepare yourself for this, it's almost embarrasing, :-)... that the core data--the stuff that holds the sim state--is in one giganormous 20+MB structure, containing lord-knows-how-many smaller structures. Most subsystems have a structure for their actual "current state", as well as a "buffer in" and a "buffer out" structure. The problem is that this design is not entirely consistent, and--worst of all--most of the structure isn't used... but we can't really say with any certainty which parts will never be used, which makes selectively copying pieces a bit more difficult.

We've written some code that analyzes changes, and the typical frame results in maybe 3k of actual modified data in the whole mess. There are some enormous sections that appear to NEVER change, but there may be some unique cases where this isn't true. Furthermore, the codebase we use comes to us from a team that may have reserved some of that space for particular "vehicular features" (I've gotta be somewhat vague so I don't get in trouble) that may not yet be incorporated into the simulation. Since different versions of the vehicle--which we integrate every few months--may radically alter the composition of the underlying static data structure, we can't build to many assumptions about that into our approach.

In other words, is an absolute nightmare. The sim code works fine for what it was intended to do, which is to run a standalone testbed simulation in a *nix environment, so I don't want to be too hard on those guys. But we are coercing it to do something it wasn't meant to do. The guts of it are so thorough and so accurate that it is very much worth making it work.

Another problem with the copying of static data is the fact that we would like to have multiple instances running in the same environment and process at some point. So if we can let them each have their own version of the data it would be ideal. Making an adhoc copy of the dll and renaming it seems to be working great for the average use case. It's just when we're doing particular things that require a restart more than a few times that I'm having problems.

Cool, I'll look all that over. Thx for the help, again.

It's almost a million lines of code with hundreds or thousands of functions--each of which accesses multiple datastructures--in a codebase which we do not maintain and which is updated every few months by those who do.

By the time we finished refactoring one version, several more would have already come out.