Vista Tutorial - Software Program "Has Stopped Working"

Have developed a program that has ran on Xp for 2 years, installed on Vista, and some machines will run it ,and others give me .

"Program has Stopped Running". I cannot find any reason for it. and there is no indication of an issue or error from my program.

Since this works on some machines, and not on others (vista). does anyone have a clue on what I can do to figure what is holding it up?

thanks .
Andy

"forexmgr" <forexmgr.33xckz@xxxxxx-mx.forums.net> wrote in message
news:forexmgr.33xckz@xxxxxx-mx.forums.net...
You compile/build the solution under the Vista platform. So, you got two
versions one that runs on Vista and another version that runs on XP, because
there is no guarantee that something that was compiled/built on the XP
platform is going to run on the Vista platform, no more than you can
guarantee that something compiled/built on the Win 2K platform is going to
run on the XP platform or XP to the Win 2k platform. You compile/build a
solution for the platform it's intended to run on.

Are you saying there is a compiler switch for what O/S your want to compile
for?
I don't think the compiler distinguishes on what operating system it is
running on to determine what binary it will create.


"Mr. Arnold" <MR. Arnold@xxxxxx> wrote in message
news:e6cD3whYIHA.3964@xxxxxx

If you developed it, do you still have the source code? If so, I would
suggest you build a debug version to help you out with what could be going
wrong.

"forexmgr" <forexmgr.33xckz@xxxxxx-mx.forums.net> wrote in message
news:forexmgr.33xckz@xxxxxx-mx.forums.net...

Also right-click on it's setup.exe>Properties>compatibility>install in XP
SP2 mode.

"forexmgr" wrote:

As a programmer, the compiler is set to 32bit, so it should run fine. expecially since other 32 bit programs run. also, it will run on some vista machines but not others.

I have set the compatibility on the link to start as XP but that didn't work either, I have the source ,but it seems not to get to anywhere in there also.

This is an issue with vista, or some @#$#@ setting on Vista otherwise it would not work on all machines.

Andy

"Gary Mount" <gary_mount@xxxxxx> wrote in message
news:O8hezyiYIHA.5900@xxxxxxNo, the common practice that I have been taught in deploying COM solutions
to the Windows platform from many years of experience as a software
developer whether it be a Windows desktop or server solution is you build
and deploy the solution for the O/S platform that it's indented to run on.

Yes, there is a switch out there on the Windows platform for COM solutions,
and it's called DLL Hell and the Registry . Solutions built and deployed to
the Windows platform use Common DLL(s) that are common named on all the
platforms. And that means that a solution that works on one platform may not
work on another platform, because of the possible DLL issues, There is no
guarantee that by deploying said software to a platform may work with a
given common named DLL. The code in DLL from a platform may not be the
same code for the same named DLL on another platform.

Sometimes, you can build a solution that was built on a platform, which
includes all DLL(s) in a setup package the common named DLL(s) on a O/S such
as Win XP that said application needs and deploy the solution to a Win 2K3
server, as an example, and watch the whole thing go up in smoke, because of
DLL Hell issues. The common named DLL Hell issues can cause other
application to stop working if it was working with a common named DLL that
was replaced by the install of software that was compiled, built, DLL(s)
pickup in a setup package form the platform and then deployed to a different
platform.

It's called DLL Hell and it does exist on the Windows O/S platform, which is
why one should use a dedicated *build machine* based on the O/S used and
compile and deploy the application only for the platform so that things
such as DLL(s) are kept in sync with the platform it's intended to run.

One can now get away with having different versions of DLL(s) on a machine
with .NET solutions, because .Net DLL(s) do not get registered to the
Registry. .Net DLL(s) are deployed to the area where the exe is deployed so
that .Net can find the DLL(s) that the program will use, which means that
common DLL(s) can be deployed with different versions.

If you're talking COM DLL(s), that's another story as they must be
registered, which can lead to things breaking with DLL Hell issues.

"forexmgr" <forexmgr.33y5r0@xxxxxx-mx.forums.net> wrote in message
news:forexmgr.33y5r0@xxxxxx-mx.forums.net...Have you ever done a deployment of an application that was complied/built on
one platform and deployed to another platform? Because if you have not faced
that bullet, then you don't know what you're up against.

If it's your app, you have the PDB, though, right? Should be easy enough to
debug through. What's the call stack? Heck, I'd just build it and run it
directly under the debugger if I were you, since you're expecting to fail.

--
Speaking for myself only.
See http://zachd.com/pss/pss.html for some helpful WMP info.
This posting is provided "AS IS" with no warranties, and confers no rights.
--
"forexmgr" <forexmgr.33y5r0@xxxxxx-mx.forums.net> wrote in message
news:forexmgr.33y5r0@xxxxxx-mx.forums.net...