"forexmgr" <forexmgr.33xckz@no-mx.forums.net> wrote in message
news:forexmgr.33xckz@no-mx.forums.net...[color=blue]
>
> 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[/color]


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. [email]Arnold@Arnold.com[/email]> wrote in message
news:e6cD3whYIHA.3964@TK2MSFTNGP03.phx.gbl...[color=blue]
>
> "forexmgr" <forexmgr.33xckz@no-mx.forums.net> wrote in message
> news:forexmgr.33xckz@no-mx.forums.net...[color=green]
>>
>> 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[/color]
>
>
> 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.[/color]

"Gary Mount" <gary_mount@telus.net> wrote in message
news:O8hezyiYIHA.5900@TK2MSFTNGP02.phx.gbl...[color=blue]
> 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.
>[/color]

No, 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.