|
Previously I had always installed them into Windows\System32 but with VC7 the merge modules for MFC and CRT by default install the DLL's into the application directory.
Have Microsoft changed the policy on this? do all DLL's go into app directory now?
|
|
|
|
|
Yes, in theory Microsoft want to keep System32 uncluttered. This keeps with the whole 'have everything you need to run the app in the one directory' approach that will be a boon to software pirates in coming years.
There is, of course, no reason not to put them in System32 if you want to.
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
|
I like it, too. I have a big hard drive, I don't care. I'm just pointing out that it will aid piracy.
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
Do it like the pro's and save yourself a lot of grief: link statically.
|
|
|
|
|
For many years now, I've always copied the DLL's into the application directory. I got so fed up with some other application overwriting the system DLL's with older versions and breaking my app.
However, where possible I avoid linking to the MFC DLL's and use static linking instead. Helps a lot when distributing applications over the internet and also makes updating users systems easier.
Michael
Life’s not a song.
Life isn’t bliss.
Life is just this.
It’s living. -- Buffy the Vampire Slayer: Once more, with feeling
|
|
|
|
|
I am having a brain freeze (happens with no sleep . . .) Anyway, I have a third party ActiveX control (single OCX file with several controls in it) and I want to get the IID, CLSID, and LIBID for one of the controls. Can anyone refresh my memory on how to do this?
In desparate need of sleep . . .
Zac
"If I create everything new, why would I want to delete anything?"
|
|
|
|
|
If you have the typelib (or if it is embedded in the .ocx) you can view it using OLE/COM Object viewer - View TypeLib from there. All these GUIDs should be in there.
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!
|
|
|
|
|
I'm completely new to programming, so this question will probably provide some laughs for you experienced people. What is the difference between the Heap and the Stack? And is this difference addressed by any code techniques? In other words, is this important, or does Windows manage memory without having to make the distinction? Another question; When you guys refer to a memory leak, is this exclusively 'heap leak' or 'stack leak', or does it even matter? And, are these locations assignable?
|
|
|
|
|
Well... I guess you've already written some programs in C or C++, right? If so, unless you have used malloc or new, all the variables declared and used in your program live on the stack. They're automatically added and removed on a stack-like manner as the flow of execution progress. For instance:
int a=0;
int b=10;
for(a=0;<b;++a){
int i=2*a;
}
Get the idea? The lifespan of stack variables is automatically taken care of by the compiler.
Sometimes, however, you need to have a variable that lives longer that the context it is declared in. These can be seen as "floating" variables whose birth and death is under control of the programmer, not the compiler --you decide when the variable is created, and when it is destroyed. The space these variables live in is called the heap. In C/C++, heap variables are handled though pointers:
int * a;
...
void f()
{
a=new int;
}
...
delete a; This is a very shallow introduction to the concepts, any basic C++ tutorial will explain these things better and in more detail.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
You know, this is the one thing I never remember. I know the concepts fine, but which is the stack and which is the heap is something I can never recall. I think you've cracked it for me. A stack is more orderly than a heap, and the heap is disorderly unless the programmer cleans it up. Well done, thank you.
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
Maybe it helps me that English isn't my native language but since the word "heap" does not correlate directly to an object in the real world in my mind then it's only a matter of connecting the stack to one such thing. And visualizing a stack of plates in a cafeteria usually does it for me.
Then there are the HeapXXX( ) functions which should also be a hint 
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!
|
|
|
|
|
|
Joaquín M López Muñoz and Thomas George,
Thanks much, this is just what I was looking for. I'll pursue those clues. And, T. George, thanks for the article.
|
|
|
|
|
Hi people,
Could anyone point me to some code that loads any file in 10% pieces. i.e. load first 25% of file content, then the next 25% and so on till 100%?
I'm sure this has been done before......
TIA.
'My capacity for happiness', he added, 'you could fit into a matchbox without taking out the matches first'.
- Marvin, the robot.
Amit Dey
sonork: 100:18407
msn: visualcdev
|
|
|
|
|
You mean something like:
<br />
DWORD dwFileSize = ::GetFileSize( hTheFile, NULL );<br />
DWORD dw10Percent = ( dwFileSize *.10 );<br />
BYTE *pBuffer = new BYTE[ dw10Percent ];<br />
<br />
if( !pBuffer )<br />
{<br />
return( ERROR_NOT_ENOUGH_MEMORY );<br />
}<br />
DWORD dwStatus = 0;<br />
DWORD dwRead = 0;<br />
<br />
dwStatus = ::ReadFile( hTheFile, pBuffer, dw10Percent, &dwRead, NULL );<br />
if( dwStatus != ERROR_SUCCESS )<br />
Peace!
-=- James (Sonork:100.21837)
"There is nothing worse than being oblivious to the fact that you do not know what you are doing."
[Get Check Favorites 1.5 Now!]
|
|
|
|
|
Thanks,James.
But for large files, what if enough memory cannot be allocated? Can a smaller buffer(say 5000 chars) be reused?
'My capacity for happiness', he added, 'you could fit into a matchbox without taking out the matches first'.
- Marvin, the robot.
Amit Dey
sonork: 100:18407
msn: visualcdev
|
|
|
|
|
|
Thanks.
'My capacity for happiness', he added, 'you could fit into a matchbox without taking out the matches first'.
- Marvin, the robot.
Amit Dey
sonork: 100:18407
msn: visualcdev
|
|
|
|
|
Thomas George wrote:
If you do not want the whole file in emeory at one time, then you can go to any small size you want. But, if you actually want the whole file in memory and you are trying to limit memory usage, so that you do not get an 'out of memory' error, try using memory mapped files.
A small note: using memory mapped files alone does not guarantee that the entire file will (or will not) be mapped into your address space: the amount of the file mapped in can be specified by the user, so that you can map 10KB chunks into your address space as needed, if desired.
If you try to map a large enough file (or part of a file), you can still encounter a out-of-memory-type situation, because you need a contigous range of addresses large enough for the size of the mapping. Paging, however, will still occur as-needed.
Peace!
-=- James (Sonork:100.21837)
"There is nothing worse than being oblivious to the fact that you do not know what you are doing."
[Get Check Favorites 1.5 Now!]
|
|
|
|
|
As I understand it, if the mapping is unnamed, it is mapped into the local address space of the application and is not in the global space. So, the chances of running out of memory is remote - unless you have a 2 GB file. In that case, you are not in a place where generic solutions work.
I am not sure whether I am 100% correct on this. Please feel free to correct me if I am wrong.
My article on a reference-counted smart pointer that supports polymorphic objects and raw pointers
modified 29-Aug-18 21:01pm.
|
|
|
|
|
[Edit: this had an undesired aggressive tone] I do not believe so: specifying a name only makes the name of the file mapping object (a kernel object) available for others processes to open. Regardless of it bring named or unnamed, it is always mapped into the address space of the calling process.
However, in the case of a named object, the two (or more) different processes share the same physical memory (pages), and physical disk space (the file).
You are correct in saying that (in general) you need a pretty large file to fail, unless your physical address range is fragmented, or you specified a starting address that does not have the contigous range available. BTW: a process' address space is normally 2GB (unless you booted with /3GB).
Peace!
-=- James (Sonork:100.21837)
"There is nothing worse than being oblivious to the fact that you do not know what you are doing."
[Get Check Favorites 1.5 Now!]
|
|
|
|
|
you are right.
The file is always mapped into the process address space, which is 2 GB. But since the mapping is to a logical process address space, i do not think that there will be a failure to map a view, if the physical address space is fragmented. AFAIK, It will just cause more page faults, because each logical page can be mapped to a different physical page.
I am saying this because I have mapped 512 MB on a machine with 512 MB RAM, obviously, there was not enough physical memory to do that. In any case, the idea is to be able to use more memory than available physically.
Thomas
My article on a reference-counted smart pointer that supports polymorphic objects and raw pointers
modified 29-Aug-18 21:01pm.
|
|
|
|
|
Thomas George wrote:
[...] if the physical address space is fragmented. AFAIK, It will just cause more page faults, because each logical page can be mapped to a different physical page
Correct. I said "physical address", when I should have said "virtual address", because you need a contigious range of addresses in your virtual address range to satisfy the size of the view.
Peace!
-=- James (Sonork:100.21837)
[Tip for SUV winter driving survival: "Professional Driver on Closed Course" does not mean "your Dumb Ass on a Public Road"!]
[Get Check Favorites 1.5 Now!]
|
|
|
|
|
Supposing our discussion was only limited to text files, moderately large to small text files, would such buffer allocation at one shot be of some advantage? what are the general rules for handling text files?
'My capacity for happiness', he added, 'you could fit into a matchbox without taking out the matches first'.
- Marvin, the robot.
Amit Dey
sonork: 100:18407
msn: visualcdev
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
