Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 170
  • Last Modified:

running code from a dll as a new process

I have two apps:
 - VideoServer - a standalone video survailance app
 - ServerGuard - manages the servers and runs them

the server is always in one location, only the settings for it change for every new instance
the guard also provides a crash-recover mechanism for the server
if the server freezes or terminates unexpectedly the guard has an option to rerun the server
if the server freezes then the guard terminates the servers process !

for now I have the server as an exe
the guard can run as many servers as it 'wants'
so every server takes it's memory toll

I've already built all of the projects in the group with RT packages
that reduced memory consumption of the server from 38 to 22 mb :)
but still if you have 4 cameras running that's almost 100 mb !!!

I'd like to create a dll from it so the core functions would be shared

that's not really a problem
the problem is that I need a process handle for the guard !!
so how could I run some dll code as a separate process ??
if it turns out difficult I'll increase the points
I have about 2000 to spare :)
0
Lee_Nover
Asked:
Lee_Nover
  • 5
  • 3
1 Solution
 
333Commented:
why you need to run some dll code as separate process?
you can put all shared server's code to dll, then make server as small exe that only calls funtions from dll (and maybe handles local variables). so, your guard process still runs and terminates exe and it will have a handle.
0
 
kretzschmarCommented:
listening . . .
0
 
Lee_NoverAuthor Commented:
333 good idea :)
I never thought of it :)
I'll wait a while for other ideas if anyone has any
I'll also try your method for now
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
Lee_NoverAuthor Commented:
oh .. a typo
that was from 28 to 22 mb memory usage ! :)

hum ... about running such an application where the actuall app stuff is in a dll

should I use:

with Application do
begin
  Initialize;
  CreateMainFormFromDll;
  MainForm.ShowModal;
  Run;
end;


actually I don't even need the application object here
simply:


begin
  CreateMainFormFromDll;
  MainForm.ShowModal;  
end.


or any other method ?
0
 
333Commented:
question about your app (maybe you won't be able to reduce memory with dll): those 22mb are your exe's size :) or memory allocated to for example video buffers etc.?
if you can share the same buffers along different server instances, then you can reduce memory usage, otherwise you can't. also, if you create the same component (form or whatever) for each instance, this won't reduce memory usage, if you can create component once and it will work with different server instances, then your memory will be reduced.

sometimes you won't get any benefit from using dlls vs exes. the point is, that when you run your exe first time, windows loads exe's code and data segments into memory, when you run second instance of the same exe, code segment isn't loaded into memory, only pointer will be returned to first instance's code. however, any variables and buffers will be created. so the code part of your app is acctualy shared and it's similar to dlls. exeption to this is compressed exes, for example with upx. in this case, each instance's code will be loaded into memory and it will not be shared and this will increase memory usage.
you may benefit from dll if you're able to use shared memory. when you have separate exes, your code is shared, but data - not. using dll is posible to create objects and allocate buffers once and then share them among instances.

so, if the biggest part of memory is allocated to for example video buffers and you can read or write from different instances to the same buffer, go for dll.
0
 
Lee_NoverAuthor Commented:
tnx for the info :)
didn't know exes code was shared !
I don't compress the server exactly because of that non-sharing thingie (I knew about that :)
with using RT packages there is also no need to compress them :)

I have some buffers but they can't be shared

I also have lots of helper functions and I was thinking of moving those to a dll
so if I understood you correctly that code would be shared in memory with an exe as well .. or am I wrong ?

the biggest memory eater are the resources I think
using ks theme for 'leet' xp looks :) (the boss wanted that)
which reminds me .. gotta move that into a RT package also :)
0
 
333Commented:
about code sharing you may read this
http://www.jrsoftware.org/striprlc.php#execomp
not much info but....

well, most of your functions code should be shared (at least i don't know why the should not :)
i don't know what your server does and how it looks, but AFAIK most servers are running as services or console apps or programs with simple hidden windows, to decrease resource consumption. if you're using gui for some administrative tasks (like setting up parameters etc), then you may consider to make this gui as separate exe, with ability to connect to different servers and talk to them using named pipes for example. in this case, your form with lots of funky bitmaps and other resource eaters will be launched only once.
0
 
Lee_NoverAuthor Commented:
yes I already separated all of the settings gui and info guis from the main app
they're created dinamically but still in the same app
that should be enough I guess :)

my server is a complete standalone VideoSurvailance app
but I'll split it into parts as needed
0
 
Lee_NoverAuthor Commented:
uh .. forgot to say that other forms have to be in the app because they're bound to some datasets in the main form
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 5
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now