|
Hi,
I have a VB server application (driven from a set of ASP classic pages). To improve throughput of the VB app we have written a small component in c++ that runs multiple instances of the server app, and when it receives the requests from the ASP page it redirects them to which ever instance is free.
We've always been careful to maintain the base addresses of all our .dlls & .exes so they don't clash with each other, but my question is, that if I am running multiple instances of the VB .exe will it clash with itself and get rebased in memory and is there any way to prevent this? Or, will the .exe only be loaded once into memory and all instances access the same memory locations? And what about .dlls used by the .exe, will each only be loaded once, or per instance of the .exe?
Also, are there any good tools (preferably free) that I can use to look at what's actually happening when the exe/dlls get loaded?
Any advice would be really appreciated.
Simon
|
|
|
|
|
Simon Stevens wrote: running multiple instances of the VB .exe will it clash with itself and get rebased in memory and is there any way to prevent this?
It's handled automatically. Even though making sure your base addresses don't stomp each other is kind of important, it's not necessary in most cases. Most DLL's don't need to be loaded at a specific address.
The default base address for .EXE's is 0x400000, DLL's is 0x100000000, IIRC.
If an EXE or DLL absolutely has to be loaded at a specific address (which is rarely ever required) and that space isn't available, it's just not loaded. If it can be loaded anywhere (the default Link configuration), and the base address isn't available, it'll be rebased automatically.
Though, there are performance benefits to specifying your own default base addresses. If there is a collision, the DLL that is being loaded is moved to a free block in the address space. Moving code around is an expensive operation. So if a DLL gets used by multiple processes, the base address that's good for one process might not be so good for another!
As for loading multiple copies of your .EXE. Since each process gets it's own virtual address space (about 4GB worth), it thinks it is the only process loaded in Windows. So even though you have lots of processes running, each one thinks it's the only process running.
When the .EXE is launched, it's loaded, by default, at 0x400000. Launch another .EXE and it gets loaded at the same address, but in another virtual address space. If you launch the same .EXE again, it also gets it's own virtual address space, but another copy of the code is NOT loaded. The code for each process is mapped into each virtual address space, as needed. So, if you launch 16 copies of Notepad, only one copy of the code stays in memory and that code gets mapped into the virtual address space of each process.
The same is also true for DLL's.
This "mapping" is why you can load the same .EXE or .DLL multiple times, but only keep a single copy of the code in memory. Though, say you have a .DLL being used by two different process and each has to load the .DLL at a different address?? Easy. Each address space maintains its own map of code in the .DLL. Each map does any rebasing of the code required to get it to fit where the address space allows.
You can read more about it here[^].
|
|
|
|
|
Cheers Dave, that clears things up a bit. I hadn't realised that each .exe was getting it's own address space, that does make more sense now I think about it.
So all I need to worry about is my .dll's clashing with other .dll's that are loaded by my .exe into it's own virtual address space.
Brilliant, Cheers.
Simon
|
|
|
|
|
Not really. Any rebasing happens automagically. The biggest performance hit is going to come when the DLL is loaded for the first time. After that, where the DLL lands in the address space is usually where it stays for the lifetime of the process its loaded into.
|
|
|
|
|
Right, so for example, I've got a.exe which loads b.dll, c.dll. For optimum performance, I just need to change the base addresses of b.dll and c.dll so they don't clash with each other, which will prevent any rebasing and any performance loss.
Simon
|
|
|
|
|
|
Thank you. 
Simon
|
|
|
|
|
Class Class1<br />
Public Field1 as Integer<br />
End Class
I'm sure that many coders want browse Class1.Field1 in designer property grid , why Microsoft doesn't support it ?
|
|
|
|
|
I think the clue is in the word "Property"
Steve Jowett
-------------------------
Sometimes a man who deserves to be looked down upon because he is a fool, is only despised only because he is an 'I.T. Consultant'
|
|
|
|
|
Ky Nam wrote: I'm sure that many coders want browse Class1.Field1 in designer property grid
Speak for yourself. I don't want it to.
Ky Nam wrote: why Microsoft doesn't support it ?
Because exposing fields as public is bad practice...? You're supposed to be exposing PRIVATE fields through nice little public Property accessors.
|
|
|
|
|
hey guy
if u r in ur home u follow ur home,s rule not to other,s same
like when u work in microsoft it has also there rule
ok don,t ask this type of question.
read it private, public, partial property to set the class
byeeeee
hope u understand
lucky
|
|
|
|
|
Speaking of rules...
Do NOT use SMS Speak in the fourms. It makes your posts quite difficult to read. You've got a 101+ key keyboard in front on your, use it!
Lucky Sheikh wrote: hope u understand:
Barely, just barely.
|
|
|
|
|
I am having a problem with changing an image using the "Image.FromFile(Path)" method. On startup, everything works fine, but as soon as I use the "openFileDialog" box, the system won't open the selected image any longer.
Every time the mouse hovers over a button, I want it to change the image of the button. This works even after opening another form and closing it again. But as soon as I select an image using the "openFileDialog" box then the system crashes out every time I hover over one of the buttons that I want the image changed.
After using the "OpenFileDialog" box, I dispose of it, in an attempt for it not to clash with Hover methods.
What can I do to avoid this problem?
  
Evan Saunders
|
|
|
|
|
i think after ur code, try the picturebox.load before anything
phatkin
|
|
|
|
|
after which code, the "OpenFileDialog" or the "image.fromfile()" for the hover?
|
|
|
|
|
after image.from file,
my VS got corrupted on ma vista so cant check for u today but i hope it works or sam1 else helps u
phatkin
|
|
|
|
|
EvanSaunders wrote: then the system crashes out every time I hover over one of the buttons
What buttons?? In the OpenFileDialog??
EvanSaunders wrote: that I want the image changed.
The OpenFileDialog doesnt' fire off any events, so I don't know where you're changing whatever image.
What's the exception that's thrown?? Does your entire system crash (Windows), or just your app??
|
|
|
|
|
I have the buttons in my main menu...(the openfiledialog box is in a form opened by the main menu)
I choose an imagefile from the opendialog box to load an image on another form for another task, but as soon as I do this, and go back to the main menu, my main menu hover buttons won't change images any longer.
The exception thrown is that my created system crashes with the exception that the image path doesn't exist. Strange exception seeing that it loaded before...
|
|
|
|
|
I still don't know exactly what your code is doing, nor if the button in your main menu (which are not buttons BTW) are the same as your "hover buttons" (whatever those are...), but...
If you loaded the file with Image.FromFile(), or anything else like that, the file get's locked for the lifetime of the object that loaded it.
You might want to take a look at this[^] for a way around that lock.
|
|
|
|
|
Hover Buttons are, as explained, normal buttons. The reason I call them that is because I have a method for changing their image when the mouse hovers over a particular button. Thanks anyway for trying to help...;P
|
|
|
|
|
The situation is not clear, and you did not show any code. So the following is a wild guess,
i.e. the facts are correct, whether they apply to your situation is uncertain:
Image.FromFile() keeps the file open for as long as the image lives (the reason is
some image files, such as JPEG, contain additional information, which remains available
to GetPropertyItem() but is not loaded into memory permanently).
There are two ways to resolve this:
1. don't use FromFile(), use FromStream() instead.
2. immediately make an image copy for use inside your app, and Dispose of the original image,
freeing the file.
Hope this helps.
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
I get what you are saying...I figured out an easier way to keep the information, using your logic...
I loaded the images into the resources folder, and then when I change the image of a button when hovered over by the mouse, I can just call it from the resources directly.
Apperantly, when loading the project/system, the default directory is set to the ../bin/debug/ folder. When using the OpenFileDialog, the default directory is then changed, which doesn't allow me to select an image implicitly the way I was doing it.
Thanks for the trouble
|
|
|
|
|
EvanSaunders wrote: the default directory is set to the ../bin/debug/ folder
Sometimes. If you create a desktop shortcut, you can choose the initial "current directory"
to be any existing directory.
When using the OpenFileDialog, the default directory is then changed
Sometimes. The File Dialogs have a property that controls whether the current directory
gets changed permanently or not.
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
Thanx, I'll check if setting property to "false", in regards to the current directory.
|
|
|
|
|
EvanSaunders wrote: I loaded the images into the resources folder, and then when I change the image of a button when hovered over by the mouse, I can just call it from the resources directly.
I had no idea you were changing the images on the buttons using Image.FromFile().
This is definitely the proper way to go when dealing with the images on controls like you are. Loading from resources is quicker than loading from files as the mouse passes over them.
EvanSaunders wrote: Apperantly, when loading the project/system, the default directory is set to the ../bin/debug/ folder.
The CurrentDirectory is set to whatever folder the .EXE was launched from. The problem you, apparently, ran into is that you used relative paths (actually, NO path) in your code to load the image files. When the CurrentDirectory changed, so did the path that your code assumed was the correct path to find those image files.
It's good practice to always build and use fully qualified paths to any files that your app uses. An example of such:
Dim imageFilepath As String = Path.Combine(Application.StartupPath, "image.bmp")
This code doesn't rely on the current directory at all. It relys on a known path that cannot change during the lifetime of the applications session and just appends the filename to this known path. The CurrentDirectory can change all it wants and it won't affect this code.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
