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/
