Hi,
Each Visual Studio uses a run time file that is called visual c runtime with a
name something like msvcrt(verion).dll. An older VS program will install the
older version so look for this in your dependancy walker watching for the
msvcrt type file. These are freely distributable installation files. You will
need to obtain older version through Microsoft.
Kevin
--- In [email protected], Thomas Hruska <thru...@...> wrote:
>
> Mike Unger wrote:
> > Hi,
> >
> > I am working at modifying some C++ code from the vendor of a data
> > acquisition board we use. All I had was the c code and the header files, no
> > project file of any kind (so I don't know what environment it was developed
> > in) I created a simple dos application with Visual Studio 2005 and pulled
> > the files in. I had to make a couple mods to get it to compile (like change
> > fopen to fopen_s).
> >
> > I should make it clear that we had been running an exectuable of this
> > program for some time and that it works fine, there are two dlls that are
> > needed with it.
> >
> > Now when I run the program I get an error "The system cannot execute the
> > specified program" That's real descriptive.
> >
> > I've done a bunch of searching on that error. I read about Manifest, I do
> > believe that is embedded in my binary because I see it when I load the .exe
> > in VS.
> >
> > I tried running Dependency Walker. It did find two dlls that are missing
> > but it says they are missing for the working executable too.
> >
> > I've read some info that points to there being a problem with running these
> > older dlls I have with an executable from VS 2005. Should I try to compile
> > in an older version of VS like VS 6.0?
> >
> > Anyone have any thoughts? I'd appreciate any advice you might have.
> >
> > I should add that I'm an amateur with Visual Studio, most of my background
> > is in embedded microcontrollers.
> >
> > Thanks in advance.
> >
> > Mike
>
> Changing fopen() to fopen_s() is unnecessary and are highly-undesired
> Microsoft extensions to ANSI C/C++. Everyone I know disables those
> extensions because using them more or less ties your application to a
> specific platform. You typically disable them by setting the
> appropriate #define directive. You were probably following the
> recommendations of the compiler output to make the change.
>
> Now onto the problem at hand. I recommend two things: First, make sure
> you are running the application under the integrated debugger. VS has
> very powerful debugging facilities. Learn how to step through the code
> line-by-line. Although you probably won't get past the loader stage
> given your current problem.
>
> The debugger will also show what DLLs your application is attempting to
> load and from where it is loading them. This is likely the stage your
> app. is failing at so breakpoints won't really help you here. Look for
> the "Output" tab/window while starting the debugger. When a startup
> ('import' is the technical term) DLL fails to load, the whole
> application will fail to load.
>
> As to the Dependency Walker issue, you have found one of the most useful
> tools in your toolkit. The two DLLs you have found are "issues" are
> probably the delay-load import DLLs that don't ship with Windows
> (probably something internal to Microsoft or some really obscure
> installer). No worries there though - delay-loaded stuff is not loaded
> until the application first uses them. Since no apps. use them that I'm
> aware of, they are never loaded and therefore don't have a chance of
> being the cause.
>
> What is more likely is the inability of the main EXE to find one or both
> of the DLLs.
>
> BTW, watch your dependencies in VS 2005 and later. VS loves to drop the
> MSVCRT80.DLL bomb (significantly bloats your install). Just be aware of
> this issue and prefer to statically link against the runtime.
>
> --
> Thomas Hruska
> CubicleSoft President
> Ph: 517-803-4197
>
> *NEW* MyTaskFocus 1.1
> Get on task. Stay on task.
>
> http://www.CubicleSoft.com/MyTaskFocus/
>
