Differences between the static linked and DLL version?
Fernando Pereira -- morgan@cardume.com
Wednesday, January 29, 1997
Environment: VC++ 4.2b ; Windows95
Hello, does anyone has a clue why a program I compile and link =
statically with MFC fails to execute, while if I use the DLL version it =
runs OK on my Win95 PC? (everything runs OK in NT).
And yesterday I tested my software in a beta site that has a Compaq =
Deskpro 2000 with just Win95 + some Oracle installed and even the DLL =
version couldn't start correctly (the release version: I tried =
successfully to run the debug version using MFC - DLL version).=20
Thanks,
Fernando
/////////////////////////////////////////////////////////////////////////=
//////////////////////////////////////
// Fernando Pereira
// morgan@cardume.com
//
// www.cardume.com
//
Hans Wedemeyer -- hansw@sprintmail.com
Friday, January 31, 1997
[Mini-digest: 4 responses]
Environment: VC++ 4.2b ; Windows95
Fernando,
I had a similar problem, never was able to use 4.2b, and had to go back
and remove and strip all files from the old installation, and reinstall
from the CD and forget about the patch.
I was then able to link statically and it all worked.
For my system the patch never worked.
regards
Hans Wedemeyer
hansw@sprintmail.com
Fernando Pereira wrote:
>
> Environment: VC++ 4.2b ; Windows95
>
> Hello, does anyone has a clue why a program I compile and link statically with MFC fails to execute, while if I use the DLL version it runs OK on my Win95 PC? (everything runs OK in NT).
>
> And yesterday I tested my software in a beta site that has a Compaq Deskpro 2000 with just Win95 + some Oracle installed and even the DLL version couldn't start correctly (the release version: I tried successfully to run the debug version using MFC - DLL version).
>
> Thanks,
> Fernando
>
> ///////////////////////////////////////////////////////////////////////////////////////////////////////////////
> // Fernando Pereira
> // morgan@cardume.com
> //
> // www.cardume.com
> //
-----From: Mike Blaszczak
At 09:02 1/29/97 -0000, Fernando Pereira wrote:
>Environment: VC++ 4.2b ; Windows95
> Hello, does anyone has a clue why a program I compile and
> link statically with MFC fails to execute, while if I use
> the DLL version it runs OK on my Win95 PC? (everything runs OK in NT).
We have only the clues you gave us, which are absolutely none.
What does "fail to execute" mean? Does it fail to start? Does it fail
to run? Does it start and die immediately? Does it print trace messages?
Which messages does it print? Does it reformat your hard drive? What
volume label does it lay down on the drive? Does it post any message
boxes? What do they say?
When you debug your app, and you put a breakpoint on your InitInstance()
override, is it hit? How far does execution get? Do you create your
main window? Does the view that's created with your application's
default empty file create correctly? What sort of controls does it use?
Or is it not a CFormView-derived view?
Or are you writing a dialog-based application? You didn't even bother
to tell us about the most fundamental aspects of your application's
architecture.
How can we possibly make a diagnosis when you've provided absolutely
no description of your problem, whatsoever?
> even the DLL version couldn't start correctly
It sounds like you'd better get started debugging. Take notes, and tell
us about somet of the things that you find.
.B ekiM
http://www.nwlink.com/~mikeblas/
These words are my own. I do not speak on behalf of Microsoft.
This performance was not lip-synched.
-----From: kenn@owl.co.uk (Ken Nicolson)
On Wed, 29 Jan 1997 09:02:13 -0000, Fernando Pereira
wrote:
>Environment: VC++ 4.2b ; Windows95
>
>Hello, does anyone has a clue why a program I compile and link =
statically
>with MFC fails to execute, while if I use the DLL version it runs OK on
>my Win95 PC? (everything runs OK in NT).
There's a memory overwrite or bad pointer somewhere in your code, no =
doubt.
Buy BoundsChecker and it will help locate your problem. While you're
waiting for the software to arrive, recompile the code for Release Build
with warning level 4 and check *every* warning you get from there.
Ken
--=20
Ken Nicolson, Panasonic OWL: mailto:kenn@owl.co.uk - =
http://www.owl.co.uk
At Home: mailto:ken@ride.demon.co.uk - =
http://www.ride.demon.co.uk
#include
-----From: Ehab Bassilli
At 09:02 AM 1/29/97 -0000, you wrote:
>Environment: VC++ 4.2b ; Windows95
>
>Hello, does anyone has a clue why a program I compile and link statically
with MFC fails to execute, while if I use the DLL version it runs OK on my
Win95 PC? (everything runs OK in NT).
Possibilities are as follows :
1.- This is a win95 problem.. not your software.
its actually a strange problem.. but wait a sec. what version are you usin
of VCPP? the professional or the standard?... its seems 2 me u r using the
professional as it gives you the option of statically linking..
If you find out why please email me back!
Thanks
Ehab.
>
>And yesterday I tested my software in a beta site that has a Compaq Deskpro
2000 with just Win95 + some Oracle installed and even the DLL version
couldn't start correctly (the release version: I tried successfully to run
the debug version using MFC - DLL version).
>
>Thanks,
>Fernando
>
>///////////////////////////////////////////////////////////////////////////
////////////////////////////////////
>// Fernando Pereira
>// morgan@cardume.com
>//
>// www.cardume.com
>//
>
>
>
>
Fernando Pereira -- morgan@cardume.com
Monday, February 03, 1997
[Mini-digest: 2 responses]
Environment: VC++ 4.2b ; Windows95
>I had a similar problem, never was able to use 4.2b, and had to go back
>and remove and strip all files from the old installation, and reinstall
>from the CD and forget about the patch.
>I was then able to link statically and it all worked.=20
>For my system the patch never worked.
I am using the 4.2b as there is a bug in 4.2 with the CArray::Copy =
function that I use. I am using the warning level at 4 (with no warning =
messages) and I use BoundsChecker 4.2Pro.
But as my problems in Win95 only show in the release code, it is a =
little harder.
>From Mike B.:
>We have only the clues you gave us, which are absolutely none.
Yes, that's true, but I haven't asked to solve my problem; if you had =
read the message more carefully, you will find that I only needed some =
more info on differences between the dll and the static version; =
pointers problems is a good reason, but it's a little too general, as =
you all know.=20
>What does "fail to execute" mean? Does it fail to start? Does it fail
> to run? Does it start and die immediately? Does it print trace =
messages?
> Which messages does it print? Does it reformat your hard drive? What
> volume label does it lay down on the drive? Does it post any message
* boxes? What do they say?
As I had said, I didn't describe the problem in detail as I didn't ask =
to anyone solve my problem; but the program just stops after displaying =
a splash screen; the app is an SDI application=20
>When you debug your app, and you put a breakpoint on your =
InitInstance()
>override, is it hit? How far does execution get? Do you create your
>main window? Does the view that's created with your application's
>default empty file create correctly? What sort of controls does it =
use?
>Or is it not a CFormView-derived view?
If you had read my mail you would discover it is a problem only in the =
release version (no trace, no breakpoints).
>Or are you writing a dialog-based application? You didn't even bother
>to tell us about the most fundamental aspects of your application's
* architecture.=20
For that I am at fault! It is a SDI application and it uses Oracle; it =
also uses 2 working threads
>How can we possibly make a diagnosis when you've provided absolutely
>no description of your problem, whatsoever?
Just by answsering directly the question.
>It sounds like you'd better get started debugging. Take notes, and =
tell
>us about somet of the things that you find.
Yes, I am doing that. One thing that sometimes puzzles me is a message =
"INTERNAL COMPILER ERROR"; this shows up when I sometimes do a rebuild =
all.
Fernando
.B ekiM
http://www.nwlink.com/~mikeblas/
These words are my own. I do not speak on behalf of Microsoft.
This performance was not lip-synched.
-----From: kenn@owl.co.uk (Ken Nicolson)
On Wed, 29 Jan 1997 09:02:13 -0000, Fernando Pereira =
wrote:
>Environment: VC++ 4.2b ; Windows95
>
>Hello, does anyone has a clue why a program I compile and link =3D
statically
>with MFC fails to execute, while if I use the DLL version it runs OK on
>my Win95 PC? (everything runs OK in NT).
There's a memory overwrite or bad pointer somewhere in your code, no =3D
doubt.
Buy BoundsChecker and it will help locate your problem. While you're
waiting for the software to arrive, recompile the code for Release Build
with warning level 4 and check *every* warning you get from there.
Ken
--=3D20
Ken Nicolson, Panasonic OWL: mailto:kenn@owl.co.uk - =3D
http://www.owl.co.uk
At Home: mailto:ken@ride.demon.co.uk - =3D
http://www.ride.demon.co.uk
#include
-----From: Ehab Bassilli
At 09:02 AM 1/29/97 -0000, you wrote:
>Environment: VC++ 4.2b ; Windows95
>
>Hello, does anyone has a clue why a program I compile and link =
statically
with MFC fails to execute, while if I use the DLL version it runs OK on =
my
Win95 PC? (everything runs OK in NT).
Possibilities are as follows :
1.- This is a win95 problem.. not your software.=20
its actually a strange problem.. but wait a sec. what version are you =
usin
of VCPP? the professional or the standard?... its seems 2 me u r using =
the
professional as it gives you the option of statically linking..=20
If you find out why please email me back!=20
Thanks=20
Ehab.
>
>And yesterday I tested my software in a beta site that has a Compaq =
Deskpro
2000 with just Win95 + some Oracle installed and even the DLL version
couldn't start correctly (the release version: I tried successfully to =
run
the debug version using MFC - DLL version).=20
>
>Thanks,
>Fernando
>
>////////////////////////////////////////////////////////////////////////=
///
////////////////////////////////////
>// Fernando Pereira
>// morgan@cardume.com
>//
>// www.cardume.com
>//
>
>
>
>
-----From: Fernando Pereira
Environment: VC++ 4.2b ; Windows95
To all that this may have any interest: this is a problem with =
stacksize. I remembered already having this problem with VC 1.5 and =
Oracle; it seems that Oracle DLLs use a lot of stack space. The debug =
version of VC++ has normally a bigger stack size default than the =
release version.
Only after I remembered this old problem I managed to solve this. I know =
have increased the stacksize and everything is OK.
Thanks to all that answered my question,
Fernando Pereira
Mike Blaszczak -- mikeblas@nwlink.com
Tuesday, February 04, 1997
[Mini-digest: 2 responses]
At 09:43 2/3/97 -0000, Fernando Pereira wrote:
> If you had read my mail you would discover it is a problem only in the
> release version (no trace, no breakpoints).
It's a trivial matter to add debugging information to a release build.
If I found a problem that happened only in release builds, it would be
the _first_ thing to do.
>Environment: VC++ 4.2b ; Windows95
>To all that this may have any interest: this is a problem with =
>stacksize. I remembered already having this problem with VC 1.5 and =
>Oracle; it seems that Oracle DLLs use a lot of stack space. The debug =
>version of VC++ has normally a bigger stack size default than the =
>release version.
That's a curious diagnosis. In Win32, the stack size specified by the
linker (or by the module definition file, or by whatever tool you might
use to edit the EXE) is only an initial size. If the stack grows
beyond that size, the application causes a page fault and the operating
system reacts by growing the space allocated for the stack. It happens
transparently.
.B ekiM
http://www.nwlink.com/~mikeblas/
These words are my own. I do not speak on behalf of Microsoft.
This performance was not lip-synched.
-----From: Mario Contestabile
>Environment: VC++ 4.2b ; Windows95
>If you had read my mail you would discover it is a problem only in the =
>release version (no trace, no breakpoints).
>
>Yes, I am doing that. One thing that sometimes puzzles me is a message =
>"INTERNAL COMPILER ERROR"; this shows up when I sometimes do a rebuild =
>all.
>
>Fernando
>
>
>Hello, does anyone has a clue why a program I compile and link =3D
>statically
>with MFC fails to execute, while if I use the DLL version it runs OK on
>my Win95 PC? (everything runs OK in NT).
When these two things happen concurrently:
1->"INTERNAL COMPILER ERROR"
2->while if I use the DLL version it runs OK
there is a _very_ good chance that what is happening is the following:
you are using a .lib file which uses MFC dynamically, yet you are building
your app using MFC statically. Synchronize the two projects in their MFC
library usage.
mcontest@universal.com
Dave Kolb -- sasdxk@wnt.sas.com
Thursday, February 06, 1997
...
> >Environment: VC++ 4.2b ; Windows95
>
>>To all that this may have any interest: this is a problem with =
>>stacksize. I remembered already having this problem with VC 1.5 and =
>>Oracle; it seems that Oracle DLLs use a lot of stack space. The debug =
>>version of VC++ has normally a bigger stack size default than the =
>>release version.
>
>That's a curious diagnosis. In Win32, the stack size specified by the
>linker (or by the module definition file, or by whatever tool you might
>use to edit the EXE) is only an initial size. If the stack grows
>beyond that size, the application causes a page fault and the operating
>system reacts by growing the space allocated for the stack. It happens
>transparently.
>
>[>Dave Kolb] 16 bit Oracle ODBC drivers (VC 1.5 is 16 bit) did use a lot of
>stack size and had some problems but that should not be relevant to 32 bit
>stacks. 16 bit stacks of course worked a lot differently than 32 bit stacks.
>
This is a bit off topic but thought I'd share some info I found on NT
and 95 32 bit stack management...
For 32 bit stacks, the linker and def files have both reserved and
committed stacksize values. Default reserved size is 1M (+64K for 95).
In my experience (the last time I checked was 1 year ago using
VirtualQuery API on the NT and 95 stacks) the committed size is not
honored and the OS commits only two pages - one stack plus one guard
page (95 was more for thunking purposes). And like Mike B. said, the
committed portion grows via stack page faults as long as you touch stack
pages sequentially and don't jump the guard page. For CreateThread
dwStackSize is the initially committed stack space and NOT the total
reserved stack space but is ignored and so is totally worthless. The new
thread's reserved stack space is the same as the main thread. IMHO,
CreateThread (or a CreateThreadEx please!!!) should really have TWO
arguments for stacks: reserved size and committed size, and they should
both be honored. One reason I suspect dwStackSize on CreateThread is
ignored is that it was misunderstood by many apps to be the total
reserved stacksize and so was overcommitting memory and causing poor NT
performance. At best, CreateThread's dwStackSize is a performance
related parameter (if it were actually honored) and what's really needed
is some way to specify the total reserved stacksize when creating a
thread (which affects capability rather than performance). To my
knowledge there is NO way to do this without overallocated the total
reserved stacksize of the main thread thereby causing ALL threads to
have the same larger total reserved size which can be very wasteful of
virtual address space (and paging tables in real memory) for an app that
merely needs one large thread in addition to many smaller threads (e.g.
>one thread wants a high level of recursive logic and 1M is not enough).
>
>Dave Kolb
>...
>
Become an MFC-L member
| Вернуться в корень Архива
|