DLLs as subprojects

[moncef]

Which is best the solution from point of view memory used by a project MDI calling a large number of DLLs:

1: creating DLLs as subproject

2: creating Dlls independently of the project.

Thanks in advance for your help

[Greg_T_]

Hello Moncef,

I would think that separate DLL projects would reduce the potentially needed run-time memory since some of the many DLLs may not need to be loaded, depending on what features get used by the program. I think that if all the code is in one project (a primary DLL plus the subprojects) then the compiled result is a single large DLL. Then when the program runs it will have to load the large DLL every time, which would use the full amount of RAM during run-time. In comparison, if there are many separate DLL projects which compile as many separate DLL files, then only the DLLs being used would get loaded. If all the DLLs are used everytime the program is run (depends on what the program does), then I would think the memory required would be the same either way.

In our analysis software we have many separate DLLs and have observed that if only a few of the program features are used then the RAM use is lower, so my comments are based on this experience. I also think that the separate DLLs help with the software maintenance: it is easier to make updates to the separate DLLs, and to share development with others.

Regards,
Greg

[Jugoslav_Dujic]

Quoting - moncef

Which is best the solution from point of view memory used by a project MDI calling a large number of DLLs:

1: creating DLLs as subproject

2: creating Dlls independently of the project.

Thanks in advance for your help

As stated, the question does not make sense. What do you mean by "subproject"?

If by "project" you mean "a Visual Studio project" made for the development purpose: it is certainly more convenient to have one solution (.sln) containing multiple projects (.vfproj): you can easily access them all from the Visual Studio, build them together, etc. But it doesn't have absolutely anything to do with memory -- it's just how you organize your work.

What does affect memory usage is whether you load the dll's dynamically (LoadLibrary/GetProcAddress/FreeLibrary) or statically (link with dll's import library). The first method is more flexible but more complicated. If you have multiple dlls and load them all at once through import library, the process will consume somewhat more memory. However, that memory will typically be occupied only by code (rather than data) so your memory gain will probably be negligible, i.e. probably not worth the effort of doing everything dynamically. Memory -- unless you start hitting gigabyte marks -- is not an issue with modern computers. But there is no universal answer.

[Jugoslav_Dujic]

Quoting - moncef

Which is best the solution from point of view memory used by a project MDI calling a large number of DLLs:

Moncef, um, just now something crossed my mind: I saw your project where you put a dialog definition and a dialog procedure within a dll, linked to the main MDI program. Now, is there a particular reason why you put that in a dll?

I mean, it's possible to do that way, but it's much simpler to write, debug and maintain to simply put all your dialogs and other resources within one main exe. It is a nice style indeed to put all the code related with one window/dialog within one .f90 file, but you don't have to go as far as moving them to dlls. When you make a dozen, it would become a hell of a maintenance job.

There are reasons to put resources into dlls (for localization -- google "satellite dll"), but it's uncommon to put the related source code there (unless you're developing e.g. a highly customizable GUI aplication).

[moncef]

Quoting - Jugoslav Dujic

Moncef, um, just now something crossed my mind: I saw your project where you put a dialog definition and a dialog procedure within a dll, linked to the main MDI program. Now, is there a particular reason why you put that in a dll?

I mean, it's possible to do that way, but it's much simpler to write, debug and maintain to simply put all your dialogs and other resources within one main exe. It is a nice style indeed to put all the code related with one window/dialog within one .f90 file, but you don't have to go as far as moving them to dlls. When you make a dozen, it would become a hell of a maintenance job.

There are reasons to put resources into dlls (for localization -- google "satellite dll"), but it's uncommon to put the related source code there (unless you're developing e.g. a highly customizable GUI aplication).

Excuse my late reply because I was on mission abroad.
As you mentioned in your reply it is indeed my project where I put a dialog definition procedure within a dll and linked it to the main MDI program.

Theresea particular reason to put resources into dlls : I develloped a code to simulate thermal system ( furnaces, boilers...) by using an object approach. To built a thermal system the user selects components from a library of thermal components: burners, thermal walls , heat exhangers an so on. Each component selected is inserted in a graphical editor . The user can select a components in this editor and dfine its caractteristics. In the beginning I developed my code as you said: I simply put all dialogs and other resources within the main program. It is a nice style to put all the code related with one window / dialog within one. F90 file as yo said. But it works when you have large number af dialogs, bitmaps, menus. At the beginning it worked, I had a limited number of components, I receive this message: 1233641472 total image size exceeds max (268435456); image may not run. Despite that I got to run my program. As I increased the number of components and I have added other modules can no longer compile the main program.
It is for this reason that I associated with each component a DLL to allocate resources and reduce the size of memory allocated to main program.

Thanks for your reply

[Jugoslav_Dujic]

Quoting - moncef

At the beginning it worked, I had a limited number of components, I receive this message: 1233641472 total image size exceeds max (268435456); image may not run. Despite that I got to run my program. As I increased the number of components and I have added other modules can no longer compile the main program.
It is for this reason that I associated with each component a DLL to allocate resources and reduce the size of memory allocated to main program.

The message "total image size exceeds max (268435456); image may not run." was issued with older versions of MS Linker. The resulting .exe will not run on Windows 95/98 indeed, but will in Windows NT/2000/XP/Vista. The warning should be ignored on most systems; I think that newer linker versions do not generate it.

The "total image size" is the sum of object code + resources + static data. Typically, it was these static data which caused these problems -- many older programs would use big COMMON arrays, (and CVF and older compilers used even other static arrays by default). If you compile with /Qauto (IVF default), and make large arrays ALLOCATABLE, there's no static data size issue.

In your case, it might be the number and/or size of resources that became problematic. I can't find an information of its limits though, but apparently it's hard to hit. Do you remember the size of the exe? Object code (.obj) and resources (.res) are put into the exe file as-is (while static data are not, i.e. declaring a 20 MB array will not make your exe 20 MB bigger).

If your current setup with dlls works fine for you, please do keep it. I was just pointing out that it might not be the best scheme.

[moncef]

Quoting - Jugoslav Dujic

The message "total image size exceeds max (268435456); image may not run." was issued with older versions of MS Linker. The resulting .exe will not run on Windows 95/98 indeed, but will in Windows NT/2000/XP/Vista. The warning should be ignored on most systems; I think that newer linker versions do not generate it.

The "total image size" is the sum of object code + resources + static data. Typically, it was these static data which caused these problems -- many older programs would use big COMMON arrays, (and CVF and older compilers used even other static arrays by default). If you compile with /Qauto (IVF default), and make large arrays ALLOCATABLE, there's no static data size issue.

In your case, it might be the number and/or size of resources that became problematic. I can't find an information of its limits though, but apparently it's hard to hit. Do you remember the size of the exe? Object code (.obj) and resources (.res) are put into the exe file as-is (while static data are not, i.e. declaring a 20 MB array will not make your exe 20 MB bigger).

If your current setup with dlls works fine for you, please do keep it. I was just pointing out that it might not be the best scheme.

This is the only alternative that I found that using Dlls to solve my problem. At the moment I have not finished rewriting my code using DLLs, so I can not confirm whether it running or not. About the size of the executable, when I could compile my code, it was of 9 MB.

If you have another proposal to avoid the use of Dlls in my case I listened with interest.

Thanks four your reply.

[Jugoslav_Dujic]

Quoting - moncef

This is the only alternative that I found that using Dlls to solve my problem. At the moment I have not finished rewriting my code using DLLs, so I can not confirm whether it running or not. About the size of the executable, when I could compile my code, it was of 9 MB.

If you have another proposal to avoid the use of Dlls in my case I listened with interest.

Thanks four your reply.

9MB is really not too much. It's a fairly routine size of an exe nowadays.

It's hard to me to offer an advice if I don't know what exactly went wrong in the original -- i.e. what were the error messages, were they during compiling, linking or executing, etc. Also, I forgot which compiler vendor and version you use?

Windows allows for quite huge sizes of executables and (as far as I can tell) number and size of resources, so it's hard to me to imagine that you broke some limit there. On the other hand, it's fairly easy to enter into memory problems by declaring or allocating huge arrays, but it doesn't seem to be your case.

[moncef]

Quoting - Jugoslav Dujic

Quoting - moncef

This is the only alternative that I found that using Dlls to solve my problem. At the moment I have not finished rewriting my code using DLLs, so I can not confirm whether it running or not. About the size of the executable, when I could compile my code, it was of 9 MB.

If you have another proposal to avoid the use of Dlls in my case I listened with interest.

Thanks four your reply.

9MB is really not too much. It's a fairly routine size of an exe nowadays.

It's hard to me to offer an advice if I don't know what exactly went wrong in the original -- i.e. what were the error messages, were they during compiling, linking or executing, etc. Also, I forgot which compiler vendor and version you use?

Windows allows for quite huge sizes of executables and (as far as I can tell) number and size of resources, so it's hard to me to imagine that you broke some limit there. On the other hand, it's fairly easy to enter into memory problems by declaring or allocating huge arrays, but it doesn't seem to be your case.

I use CVF6.6 and when i compile my code without using DLLand with a large number of components the operation sucesses with the warning Message : total image size exceeds max (268435456); image may not run.

In the Forum and a bout this message Steve lionel said,like you, that linker warning is telling that the static code and data size of your application is greater than 2GB (that's why the number is negative.) 2GB is the absolute maximum limit for static code and data size on Windows (even Windows x64).

he saidalso thatone solution to this problemis to reduce the size of arrays used in the code. Wich is with
concordance with my case : When I reduce the number of components my code works. But in my case , this
redution limits the use of the code to simple thermal systems which is notthe intention.

For the moment I see twodirections :

*Solutions proposed by Steve Lione : Ifone needs more array space,he have to :
1- move to Windows x64 using an Intel EM64T processor : Frankly I do not know how
2 - use ALLOCATABLE arrays (to get around the static size limit.).Iuse allocatable arrays. But
the problem is that the maximun number of my arrays are definedwithin a Records or types
wichexclued using Allocatable arrays.

* Using Dlls: what I'm to do now. In this case, whait is the best way, if exists,to use DLLs tosolve this problem.

Iwant to immigrate to the CVF compiler 10.10.014( I have a version) but the my Visual studio.8 versiondoes not have a resource editor which is not practical for the development of menus and dialogs of the program. My question is how to acquire and ad the resource editor to my visual studio.8 version ? andif this migrationcan help.

Thanks

[moncef]

use CVF6.6 and when i compile my code without using DLLand with a large number of components the operation sucesses with the warning Message : total image size exceeds max (268435456); image may not run.
but when i execute my code I receive this message : Could not execute : Bad executable format( win32 error 193)

In the Forum and a bout the warning message, Steve lionel said,like you,that linker warning is telling that the static code and data size of your application is greater than 2GB (that's why the number is negative.) 2GB is the absolute maximum limit for static code and data size on Windows (even Windows x64).

About the win32 error 193, he saidalso thatone solution to theproblemis to reduce the size of arrays used in the code. Wich is with concordance with my case : When I reduce the number of components my code works. But in my case , this redution limits the use of the code to simple thermal systems which is notthe intention.

For the moment I see twodirections :

*Solutions proposed by Steve Lione : Ifone needs more array space,he have to :
1- move to Windows x64 using an Intel EM64T processor : Frankly I do not know how
2 - use ALLOCATABLE arrays (to get around the static size limit.).Iuse allocatable arrays. But
the problem is that the maximun number of my arrays are definedwithin a Records or types
wichexclued using Allocatable arrays.

* Using Dlls: what I'm to do now. In this case, whait is the best way, if exists,to use DLLs tosolve this problem.

Iwant to immigrate to the CVF compiler 10.10.014( I have a version) but the my Visual studio.8 versiondoes not have a resource editor which is not practical for the development of menus and dialogs of the program. My question is how to acquire and ad the resource editor to my visual studio.8 version ? andif this migrationcan help.

Thanks

[Jugoslav_Dujic]

Quoting - moncef

use CVF6.6 and when i compile my code without using DLLand with a large number of components the operation sucesses with the warning Message : total image size exceeds max (268435456); image may not run.
but when i execute my code I receive this message : Could not execute : Bad executable format( win32 error 193)

In the Forum and a bout the warning message, Steve lionel said,like you,that linker warning is telling that the static code and data size of your application is greater than 2GB (that's why the number is negative.) 2GB is the absolute maximum limit for static code and data size on Windows (even Windows x64).

About the win32 error 193, he saidalso thatone solution to theproblemis to reduce the size of arrays used in the code. Wich is with concordance with my case : When I reduce the number of components my code works. But in my case , this redution limits the use of the code to simple thermal systems which is notthe intention.

For the moment I see twodirections :

*Solutions proposed by Steve Lione : Ifone needs more array space,he have to :
1- move to Windows x64 using an Intel EM64T processor : Frankly I do not know how
2 - use ALLOCATABLE arrays (to get around the static size limit.).Iuse allocatable arrays. But
the problem is that the maximun number of my arrays are definedwithin a Records or types
wichexclued using Allocatable arrays.

* Using Dlls: what I'm to do now. In this case, whait is the best way, if exists,to use DLLs tosolve this problem.

Iwant to immigrate to the CVF compiler 10.10.014( I have a version) but the my Visual studio.8 versiondoes not have a resource editor which is not practical for the development of menus and dialogs of the program. My question is how to acquire and ad the resource editor to my visual studio.8 version ? andif this migrationcan help.

Thanks

I see: wherever you turn, there's a limit you hit. Here are your other options:

• ALLOCATABLE arrays within TYPES are allowed since CVF 6.5. They work reasonably well since CVF6.6C. You should really use allocatables (in or out of structures) wherever you can, because they're much more flexible.
• Visual Studio which goes with Intel Fortran does not have a resource editor indeed. Instead, you can use a free alternative such as www.resedit.net. It's fairly powerful, but I didn't use it extensively to comment on possible drawbacks.
• Buy and install a Visual Studio 2005 full edition, then reinstall IVF. (If I recall correctly, 10.1.024 works with VS 2005, but not with VS 2008; Steve would know better).

Personally, I would try the option 2) or 3). And move everything to allocatable anyway.

[Steven_L_Intel1]

ALLOCATABLE components of derived types were introduced in CVF 6.6, but even in CVF 6.6C they have many bugs. I would recommend avoiding them unless you are using a 10.0 or newer version of IVF.

IVF 10.1.019 and later works with VS2008