"Gary Mount" <gary_mount@xxxxxx> wrote in message
news:O8hezyiYIHA.5900@xxxxxx
Quote:
> 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.
>
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.