Problems, problems problems 
Author Message
 Problems, problems problems

Hi all,

Well, i posted few times before, but i'm experiencing a very weird
problem. I build an MFC app (MDI + DLLs) which runs perfectly on NT 4
etc. but i'll not run on 2k, once i installed VC6 on top of a clean 2k
the app worked. Depends shows that all versions of dlls used are equal,
can somebody please enlighten me?

thanks

daniel
PS correct MFC, oleaut etc. dll's were provided to the application by
installshield, so it appears to be something else then a dll problem -
anyhow it's hell (dll-hell?)

--

-------------------------------------------
  D.J. Vis
  BioMedia Amsterdam
-------------------------------------------



Fri, 03 Jan 2003 03:00:00 GMT  
 Problems, problems problems

Quote:
> Well, i posted few times before, but i'm experiencing a very weird
> problem. I build an MFC app (MDI + DLLs) which runs perfectly on NT 4
> etc. but i'll not run on 2k, once i installed VC6 on top of a clean 2k
> the app worked. Depends shows that all versions of dlls used are equal,
> can somebody please enlighten me?

What do you mean by do not work... what happen when you launch your app from
2000?

Quote:
> PS correct MFC, oleaut etc. dll's were provided to the application by
> installshield, so it appears to be something else then a dll problem -
> anyhow it's hell (dll-hell?)

 anyway with WFP, you can't modify system dll...

--
Tenebrax
http://graff.ctw.net



Fri, 03 Jan 2003 03:00:00 GMT  
 Problems, problems problems

Quote:

> > Well, i posted few times before, but i'm experiencing a very weird
> > problem. I build an MFC app (MDI + DLLs) which runs perfectly on NT 4
> > etc. but i'll not run on 2k, once i installed VC6 on top of a clean 2k
> > the app worked. Depends shows that all versions of dlls used are equal,
> > can somebody please enlighten me?

> What do you mean by do not work... what happen when you launch your app from
> 2000?

simply: process is created, no window shown - application terminates normally
(...) without showing a thing. At first, we thought of dll conflict, version
conflicts/incompatablities etc. - none of that all. Installing VC resulted in a
working system, but i can;t ship to all of my customers a copy of vc just to
make my app running. The used DLL's - shown by depends- were exactly the same as
on the installed system. So there must be a registry of env. option to set in
order to make this app run properly...

please advise

Quote:

> > PS correct MFC, oleaut etc. dll's were provided to the application by
> > installshield, so it appears to be something else then a dll problem -
> > anyhow it's hell (dll-hell?)

>  anyway with WFP, you can't modify system dll...

2k has adopted the side by side dll mechanism, you're able to provide all sys
dlls neces. to your application but you're unable to update 10 super hidden
system files (kernel, user32 etc, but mfc42.dll aswell), but you're still able
to ship your own copy of mfc42.dll an have it linked side by side...
So much for the theory...

daniel

Quote:

> --
> Tenebrax
> http://graff.ctw.net

--

-------------------------------------------
  D.J. Vis
  BioMedia Amsterdam
-------------------------------------------



Fri, 03 Jan 2003 03:00:00 GMT  
 Problems, problems problems

Quote:
> > What do you mean by do not work... what happen when you launch your app
from
> > 2000?

> simply: process is created, no window shown - application terminates
normally
> (...) without showing a thing. At first, we thought of dll conflict,
version
> conflicts/incompatablities etc. - none of that all. Installing VC resulted
in a
> working system, but i can;t ship to all of my customers a copy of vc just
to
> make my app running. The used DLL's - shown by depends- were exactly the
same as
> on the installed system. So there must be a registry of env. option to set
in
> order to make this app run properly...

> please advise

I hope you don't use OCX...? (cause that's one of the things installed by
VC, other thing are database support (some parts...).

A thing that may be interresting to know is until when your app is working
properly... (cause lot of thing changed in W2K...normally it should be
compatible... but.. ;-)...

Anyway, all the app I've compiled run on all the windows version.

A last thing: I once got a strange thing with an app I compiled under Win98,
it won't run correctly, I recompile it under 2000, then it run under both 98
and 2000. So even if its against all logic, you can try to compile your app
under 2000 then look if it run on nt correctly... (and on 2000...).

Quote:
> > > PS correct MFC, oleaut etc. dll's were provided to the application by
> > > installshield, so it appears to be something else then a dll problem -
> > > anyhow it's hell (dll-hell?)

> >  anyway with WFP, you can't modify system dll...

> 2k has adopted the side by side dll mechanism, you're able to provide all
sys
> dlls neces. to your application but you're unable to update 10 super
hidden
> system files (kernel, user32 etc, but mfc42.dll aswell), but you're still
able
> to ship your own copy of mfc42.dll an have it linked side by side...
> So much for the theory...

Yes and no, I read that all the system dll (dll installed by win2k are
protected (that's why you can't get the full IE 5.5 for instance) can't be
updated, if you put the dll inside the app folder, they will be linked with
your app... but installing or not VC doesn't change anything about that...
so I don't think it's a dll problem...

--
Tenebrax
http://graff.ctw.net



Fri, 03 Jan 2003 03:00:00 GMT  
 Problems, problems problems
When you are in debug mode, and single-stepping through the MFC
source, where does it fail?
                        joe

On Mon, 17 Jul 2000 14:28:42 +0100, Dani?l J. Vis

Quote:

>Hi all,

>Well, i posted few times before, but i'm experiencing a very weird
>problem. I build an MFC app (MDI + DLLs) which runs perfectly on NT 4
>etc. but i'll not run on 2k, once i installed VC6 on top of a clean 2k
>the app worked. Depends shows that all versions of dlls used are equal,
>can somebody please enlighten me?

>thanks

>daniel
>PS correct MFC, oleaut etc. dll's were provided to the application by
>installshield, so it appears to be something else then a dll problem -
>anyhow it's hell (dll-hell?)

Joseph M. Newcomer [MVP]

Web: http://www3.pgh.net/~newcomer
MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm


Fri, 03 Jan 2003 03:00:00 GMT  
 Problems, problems problems

Quote:

> When you are in debug mode, and single-stepping through the MFC
> source, where does it fail?
>                         joe

nowhere! that's the beauty...

daniel

Quote:

> On Mon, 17 Jul 2000 14:28:42 +0100, Dani?l J. Vis

> >Hi all,

> >Well, i posted few times before, but i'm experiencing a very weird
> >problem. I build an MFC app (MDI + DLLs) which runs perfectly on NT 4
> >etc. but i'll not run on 2k, once i installed VC6 on top of a clean 2k
> >the app worked. Depends shows that all versions of dlls used are equal,
> >can somebody please enlighten me?

> >thanks

> >daniel
> >PS correct MFC, oleaut etc. dll's were provided to the application by
> >installshield, so it appears to be something else then a dll problem -
> >anyhow it's hell (dll-hell?)

> Joseph M. Newcomer [MVP]

> Web: http://www3.pgh.net/~newcomer
> MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm

--

-------------------------------------------
  D.J. Vis
  BioMedia Amsterdam

-------------------------------------------



Sat, 04 Jan 2003 03:00:00 GMT  
 Problems, problems problems
If that is so, then you may have an uninitialized variable problem.
The de{*filter*} can change the stack contents, which causes something
that used to fail innocuously to fail catastrophically.
                        joe

On Tue, 18 Jul 2000 07:46:08 +0100, Dani?l J. Vis

Quote:


>> When you are in debug mode, and single-stepping through the MFC
>> source, where does it fail?
>>                         joe

>nowhere! that's the beauty...

>daniel

>> On Mon, 17 Jul 2000 14:28:42 +0100, Dani?l J. Vis

>> >Hi all,

>> >Well, i posted few times before, but i'm experiencing a very weird
>> >problem. I build an MFC app (MDI + DLLs) which runs perfectly on NT 4
>> >etc. but i'll not run on 2k, once i installed VC6 on top of a clean 2k
>> >the app worked. Depends shows that all versions of dlls used are equal,
>> >can somebody please enlighten me?

>> >thanks

>> >daniel
>> >PS correct MFC, oleaut etc. dll's were provided to the application by
>> >installshield, so it appears to be something else then a dll problem -
>> >anyhow it's hell (dll-hell?)

>> Joseph M. Newcomer [MVP]

>> Web: http://www.*-*-*.com/ ~newcomer
>> MVP Tips: http://www.*-*-*.com/ ~newcomer/mvp_tips.htm

Joseph M. Newcomer [MVP]

Web: http://www.*-*-*.com/ ~newcomer
MVP Tips: http://www.*-*-*.com/ ~newcomer/mvp_tips.htm


Sat, 04 Jan 2003 03:00:00 GMT  
 Problems, problems problems

Quote:

> If that is so, then you may have an uninitialized variable problem.
> The de{*filter*} can change the stack contents, which causes something
> that used to fail innocuously to fail catastrophically.
>                         joe

hi joe
no - can't be, none of my own code is executed at all - so initializing or not
initializing a variable will not make a difference at all. BTW the de{*filter*}
does not change the stack cont, or does not place guard bits around your memory
when working with release builds.
I really can't figure out what i'm doing wrong, the de{*filter*} is only installed
on top of the system - the de{*filter*} was not attached to the running process at
all. So it must be a companion shittie from MSVC6 enableing my app, depends
shows no clues at all - all version numbers are equal. What did i miss?

daniel

Quote:

> On Tue, 18 Jul 2000 07:46:08 +0100, Dani?l J. Vis


> >> When you are in debug mode, and single-stepping through the MFC
> >> source, where does it fail?
> >>                         joe

> >nowhere! that's the beauty...

> >daniel

> >> On Mon, 17 Jul 2000 14:28:42 +0100, Dani?l J. Vis

> >> >Hi all,

> >> >Well, i posted few times before, but i'm experiencing a very weird
> >> >problem. I build an MFC app (MDI + DLLs) which runs perfectly on NT 4
> >> >etc. but i'll not run on 2k, once i installed VC6 on top of a clean 2k
> >> >the app worked. Depends shows that all versions of dlls used are equal,
> >> >can somebody please enlighten me?

> >> >thanks

> >> >daniel
> >> >PS correct MFC, oleaut etc. dll's were provided to the application by
> >> >installshield, so it appears to be something else then a dll problem -
> >> >anyhow it's hell (dll-hell?)

> >> Joseph M. Newcomer [MVP]

> >> Web: http://www.*-*-*.com/ ~newcomer
> >> MVP Tips: http://www.*-*-*.com/ ~newcomer/mvp_tips.htm

> Joseph M. Newcomer [MVP]

> Web: http://www.*-*-*.com/ ~newcomer
> MVP Tips: http://www.*-*-*.com/ ~newcomer/mvp_tips.htm

--

-------------------------------------------
  D.J. Vis
  BioMedia Amsterdam
-------------------------------------------



Sun, 05 Jan 2003 03:00:00 GMT  
 Problems, problems problems
But, in fact, if you have any static constructors, there is code
executed long before your WinMain. Since you can't control the order
of static constructors, it is possible (I've done it!) to get one
class to try to initialize before a class it depends on has
initialized. This can lead to interesting failure modes.
                        joe

On Wed, 19 Jul 2000 12:07:18 +0100, Dani?l J. Vis

Quote:


>> If that is so, then you may have an uninitialized variable problem.
>> The de{*filter*} can change the stack contents, which causes something
>> that used to fail innocuously to fail catastrophically.
>>                         joe

>hi joe
>no - can't be, none of my own code is executed at all - so initializing or not
>initializing a variable will not make a difference at all. BTW the de{*filter*}
>does not change the stack cont, or does not place guard bits around your memory
>when working with release builds.
>I really can't figure out what i'm doing wrong, the de{*filter*} is only installed
>on top of the system - the de{*filter*} was not attached to the running process at
>all. So it must be a companion shittie from MSVC6 enableing my app, depends
>shows no clues at all - all version numbers are equal. What did i miss?

>daniel

>> On Tue, 18 Jul 2000 07:46:08 +0100, Dani?l J. Vis


>> >> When you are in debug mode, and single-stepping through the MFC
>> >> source, where does it fail?
>> >>                         joe

>> >nowhere! that's the beauty...

>> >daniel

>> >> On Mon, 17 Jul 2000 14:28:42 +0100, Dani?l J. Vis

>> >> >Hi all,

>> >> >Well, i posted few times before, but i'm experiencing a very weird
>> >> >problem. I build an MFC app (MDI + DLLs) which runs perfectly on NT 4
>> >> >etc. but i'll not run on 2k, once i installed VC6 on top of a clean 2k
>> >> >the app worked. Depends shows that all versions of dlls used are equal,
>> >> >can somebody please enlighten me?

>> >> >thanks

>> >> >daniel
>> >> >PS correct MFC, oleaut etc. dll's were provided to the application by
>> >> >installshield, so it appears to be something else then a dll problem -
>> >> >anyhow it's hell (dll-hell?)

>> >> Joseph M. Newcomer [MVP]

>> >> Web: http://www.*-*-*.com/ ~newcomer
>> >> MVP Tips: http://www.*-*-*.com/ ~newcomer/mvp_tips.htm

>> Joseph M. Newcomer [MVP]

>> Web: http://www.*-*-*.com/ ~newcomer
>> MVP Tips: http://www.*-*-*.com/ ~newcomer/mvp_tips.htm

Joseph M. Newcomer [MVP]

Web: http://www.*-*-*.com/ ~newcomer
MVP Tips: http://www.*-*-*.com/ ~newcomer/mvp_tips.htm


Sun, 05 Jan 2003 03:00:00 GMT  
 Problems, problems problems
This is truly wierd.

I hate to sound like I'm beating the same drum over and over, but... what
happens if you link statically?

Also - is it possible that some OCX you are using is not registered?



Quote:
> Hi all,

> Well, i posted few times before, but i'm experiencing a very weird
> problem. I build an MFC app (MDI + DLLs) which runs perfectly on NT 4
> etc. but i'll not run on 2k, once i installed VC6 on top of a clean 2k
> the app worked. Depends shows that all versions of dlls used are equal,
> can somebody please enlighten me?

> thanks

> daniel
> PS correct MFC, oleaut etc. dll's were provided to the application by
> installshield, so it appears to be something else then a dll problem -
> anyhow it's hell (dll-hell?)

> --

> -------------------------------------------
>   D.J. Vis
>   BioMedia Amsterdam
> -------------------------------------------



Sun, 05 Jan 2003 03:00:00 GMT  
 Problems, problems problems

Quote:

> But, in fact, if you have any static constructors, there is code
> executed long before your WinMain. Since you can't control the order
> of static constructors, it is possible (I've done it!) to get one
> class to try to initialize before a class it depends on has
> initialized. This can lead to interesting failure modes.
>                         joe

yeah - you're right, some part of the initialization can't be (easily) controlled by
the programmer - and weird things happen debugging those 'bugs'. But this can't be
what's causing the problem, because i'm running a binary copy of my release build,
run it on w2k with the vc installed on top of a clean install - and my app is as
happy as a clamp. For clarety: de{*filter*} is NOT running, let along attached to the
process. Apart from that, i'm not using static constructors.
but thanks again for the input.

regards

daniel
--

-------------------------------------------
  D.J. Vis
  BioMedia Amsterdam

-------------------------------------------



Mon, 06 Jan 2003 03:00:00 GMT  
 Problems, problems problems

Quote:

> This is truly wierd.

> I hate to sound like I'm beating the same drum over and over, but... what
> happens if you link statically?

> Also - is it possible that some OCX you are using is not registered?

well, the rhythm of the drums still ain't right - problem is not fixed yet -
so - any input is very much appreciated. Did not try to link statically to
the MFC support libs, would be an tremendous performance loss though, linking
7 DLL's plus exe statically... but it's worth the try, isn't it?
To the best of my knowledge i'm not using any ocx'es, doesn't the OS warn you
if it's missing it's OCX?
IMHO the key to solve this problem is to figure out what VC install does
include to the system i'm not including... The worst part is i'm not
receiving any error code AT ALL. startup and termination is 'normal'...
Will try to link dll's statically an run on a naive w2k system - need to
format my test computer again - what a hobby... grmmm, once i did that i'll
get back to you!

thanks, regards

daniel

Quote:



> > Hi all,

> > Well, i posted few times before, but i'm experiencing a very weird
> > problem. I build an MFC app (MDI + DLLs) which runs perfectly on NT 4
> > etc. but i'll not run on 2k, once i installed VC6 on top of a clean 2k
> > the app worked. Depends shows that all versions of dlls used are equal,
> > can somebody please enlighten me?

> > thanks

> > daniel
> > PS correct MFC, oleaut etc. dll's were provided to the application by
> > installshield, so it appears to be something else then a dll problem -
> > anyhow it's hell (dll-hell?)

--

-------------------------------------------
  D.J. Vis
  BioMedia Amsterdam
 -------------------------------------------



Mon, 06 Jan 2003 03:00:00 GMT  
 Problems, problems problems
Dani?l!

My 2 ?res worth:
If an app will not work on a machine until VC is installed, it would be
difficult to convince me that it is not a matter of installed components.

I'm not sure depends.exe is up to scratch, perhaps a tool showing *all*
loaded DLLs etc would be of help? www.sysinternals.com has such an app
(DLLShow, if memory serves). A tedious comparision of the DLLs loaded on a
working machine with the ones on a non-working one *must* give a result.

Johan Rosengren
Responsable Informatique
PACTA S.A.



Quote:


> > This is truly wierd.

> > I hate to sound like I'm beating the same drum over and over, but...
what
> > happens if you link statically?

> > Also - is it possible that some OCX you are using is not registered?

> well, the rhythm of the drums still ain't right - problem is not fixed
yet -
> so - any input is very much appreciated. Did not try to link statically to
> the MFC support libs, would be an tremendous performance loss though,
linking
> 7 DLL's plus exe statically... but it's worth the try, isn't it?
> To the best of my knowledge i'm not using any ocx'es, doesn't the OS warn
you
> if it's missing it's OCX?
> IMHO the key to solve this problem is to figure out what VC install does
> include to the system i'm not including... The worst part is i'm not
> receiving any error code AT ALL. startup and termination is 'normal'...
> Will try to link dll's statically an run on a naive w2k system - need to
> format my test computer again - what a hobby... grmmm, once i did that
i'll
> get back to you!

> thanks, regards

> daniel



> > > Hi all,

> > > Well, i posted few times before, but i'm experiencing a very weird
> > > problem. I build an MFC app (MDI + DLLs) which runs perfectly on NT 4
> > > etc. but i'll not run on 2k, once i installed VC6 on top of a clean 2k
> > > the app worked. Depends shows that all versions of dlls used are
equal,
> > > can somebody please enlighten me?

> > > thanks

> > > daniel
> > > PS correct MFC, oleaut etc. dll's were provided to the application by
> > > installshield, so it appears to be something else then a dll problem -
> > > anyhow it's hell (dll-hell?)

> --

> -------------------------------------------
>   D.J. Vis
>   BioMedia Amsterdam
>  -------------------------------------------



Tue, 07 Jan 2003 03:00:00 GMT  
 Problems, problems problems

Quote:

> Dani?l!

> My 2 ?res worth:
> If an app will not work on a machine until VC is installed, it would be
> difficult to convince me that it is not a matter of installed components.

> I'm not sure depends.exe is up to scratch, perhaps a tool showing *all*
> loaded DLLs etc would be of help? www.sysinternals.com has such an app
> (DLLShow, if memory serves). A tedious comparision of the DLLs loaded on a
> working machine with the ones on a non-working one *must* give a result.

you were right, depends was not showing all dlls used by the process, it turned
out to be dao350.dll, which i did distribute, but accidentally marked as
'autoregistring' which was not the correct setting for this dll, regsvr32 was
the sollution.

Thank you all for helping me out!

daniel

Quote:

> Johan Rosengren
> Responsable Informatique
> PACTA S.A.




> > > This is truly wierd.

> > > I hate to sound like I'm beating the same drum over and over, but...
> what
> > > happens if you link statically?

> > > Also - is it possible that some OCX you are using is not registered?

> > well, the rhythm of the drums still ain't right - problem is not fixed
> yet -
> > so - any input is very much appreciated. Did not try to link statically to
> > the MFC support libs, would be an tremendous performance loss though,
> linking
> > 7 DLL's plus exe statically... but it's worth the try, isn't it?
> > To the best of my knowledge i'm not using any ocx'es, doesn't the OS warn
> you
> > if it's missing it's OCX?
> > IMHO the key to solve this problem is to figure out what VC install does
> > include to the system i'm not including... The worst part is i'm not
> > receiving any error code AT ALL. startup and termination is 'normal'...
> > Will try to link dll's statically an run on a naive w2k system - need to
> > format my test computer again - what a hobby... grmmm, once i did that
> i'll
> > get back to you!

> > thanks, regards

> > daniel



> > > > Hi all,

> > > > Well, i posted few times before, but i'm experiencing a very weird
> > > > problem. I build an MFC app (MDI + DLLs) which runs perfectly on NT 4
> > > > etc. but i'll not run on 2k, once i installed VC6 on top of a clean 2k
> > > > the app worked. Depends shows that all versions of dlls used are
> equal,
> > > > can somebody please enlighten me?

> > > > thanks

> > > > daniel
> > > > PS correct MFC, oleaut etc. dll's were provided to the application by
> > > > installshield, so it appears to be something else then a dll problem -
> > > > anyhow it's hell (dll-hell?)

> > --

> > -------------------------------------------
> >   D.J. Vis
> >   BioMedia Amsterdam
> >  -------------------------------------------

--

-------------------------------------------
  D.J. Vis
  BioMedia Amsterdam
-------------------------------------------



Mon, 13 Jan 2003 03:00:00 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. problems problems problems

2. Problems, problems, problems!

3. Problems, Problems, Problems

4. VC6 to VC7 migration problem (problem with ATL and MFC)

5. Problem #30 on http://cs.nmu.edu/programming/c/problems.htm

6. Problem...Problem!

7. Problem with problem

8. Problem with Problem

9. Array size problems (memory problem)

10. binary problem - beginner problem

 

 
Powered by phpBB® Forum Software