error 14001 and Manifests for Imbecels?
in [Win32 API]
|
From: Larry Lindstrom on 5 Apr 2008 17:05 Hello Folks: I replaced Visual C 6.0 with Visual Studio 2008 last week and I've been busy replacing _itoa with _itoa_s, and other similar tasks, in order to get my 100k line application to work with the new development system. I finally got things working, and ran a few tests of the applicaiton. It seems to work fine. It was with great anticipation than I sent my partner a shiny new executable yesterday. He called to tell me that nothing ran. When launched from inno it just blew up with a complaint that CreateProcess() failed with an error of 14001, and the following text: This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. A search of the newsgroups pointed at a manifest problem. Manifest? I never needed a manifest when developing code in VC6. I've found some documentation about manifests, but I'm having trouble connecting the dots for my situation. This is the disk layout visual C++ created for the application's solution: app_name Debug Release Lots of .lib files app_name.exe app_name.pdb app_name Debug Release app_name.exe.intermediate.manifest I gather that in addition to the .exe file, a manifest must also be included with my distribution. The libraries I've built for my application are static. Have they been statically linked into app_name.exe? Why are there copies of all of those .lib files in app_name\Release? The application also uses the following "additional" DLLs gdiplus.lib comctl32.lib Version.lib. The manifest is a little thing. Do I just add that to the client's \Program Files\app_name? Do I need to copy each of the .lib files to the client's \Program Files\app_name? How about the additional DLL? Do I need to hunt for those and add them to the distribution? Does the manifest make programmer's lives easier somehow? What advantage do they offer? Thanks Larry
From: Sebastian G. on 5 Apr 2008 17:40 Larry Lindstrom wrote: > He called to tell me that nothing ran. When launched > from inno it just blew up with a complaint that CreateProcess() > failed with an error of 14001, and the following text: > > This application has failed to start because the application > configuration is incorrect. Reinstalling the application may > fix this problem. You have been linking the C runtime dynamically, and the client is missing the Visual C++ 2008 Runtime Libraries. Either let them download via Microsoft Download Center, or ship them with the installer, or use a merge module, or (least preferably) include the Microsoft.VC90.CRT.manifest and the DLLs in the application folder. > Manifest? I never needed a manifest when developing code > in VC6. Aside from the side-by-side versioning, manifests are a big POS.
From: PeterD on 5 Apr 2008 17:49 On Sat, 05 Apr 2008 14:05:16 -0700, Larry Lindstrom <nobody(a)aracnet.com> wrote: >Hello Folks: > > I replaced Visual C 6.0 with Visual Studio 2008 last week >and I've been busy replacing _itoa with _itoa_s, and other >similar tasks, in order to get my 100k line application to >work with the new development system. > > I finally got things working, and ran a few tests of the >applicaiton. It seems to work fine. It was with great >anticipation than I sent my partner a shiny new executable >yesterday. > > He called to tell me that nothing ran. When launched >from inno it just blew up with a complaint that CreateProcess() >failed with an error of 14001, and the following text: > > This application has failed to start because the application > configuration is incorrect. Reinstalling the application may > fix this problem. > > A search of the newsgroups pointed at a manifest problem. > > Manifest? I never needed a manifest when developing code >in VC6. > > I've found some documentation about manifests, but I'm >having trouble connecting the dots for my situation. > > This is the disk layout visual C++ created for the >application's solution: > > app_name > Debug > Release > Lots of .lib files > app_name.exe > app_name.pdb > app_name > Debug > Release > app_name.exe.intermediate.manifest > > I gather that in addition to the .exe file, a manifest >must also be included with my distribution. > > The libraries I've built for my application are static. >Have they been statically linked into app_name.exe? Why are >there copies of all of those .lib files in app_name\Release? > > The application also uses the following "additional" DLLs >gdiplus.lib comctl32.lib Version.lib. > > The manifest is a little thing. Do I just add that to >the client's \Program Files\app_name? > > Do I need to copy each of the .lib files to the client's >\Program Files\app_name? > > How about the additional DLL? Do I need to hunt for those >and add them to the distribution? > > Does the manifest make programmer's lives easier somehow? >What advantage do they offer? > > Thanks > Larry Have your user check the event log, there will be a logged entry for this error, post that event log item and possibly someone can answer the question. A manifest can either be included as a resource, or as a seperate file. Using a file allows easier updating, but creates issues with users who try (or accidently) modify it.
From: Larry Lindstrom on 6 Apr 2008 13:55 Sebastian G. wrote: > Larry Lindstrom wrote: > > >> He called to tell me that nothing ran. When launched >> from inno it just blew up with a complaint that CreateProcess() >> failed with an error of 14001, and the following text: >> >> This application has failed to start because the application >> configuration is incorrect. Reinstalling the application may >> fix this problem. > > > You have been linking the C runtime dynamically, and the client is > missing the Visual C++ 2008 Runtime Libraries. Either let them download > via Microsoft Download Center, Thanks Sebastian: This will be a product for use by non technical people. Any solution that beginse with "let them download" is a non-starter. This must be transparent. > or ship them with the installer, This sounds doable. No burden on the customer, right? I looked through \Program File\Microsoft Visual studio 9.0 and found a directory called "Microsoft.VC90.CRT". It has a manifest and 3 dlls, msvcm90.dll, msvcp90.dll and msvcr90.dll. Are these the runtime libs you are talking about? Are they legally redistributable? If these are the files, do I put them in \Program Files\app_name on the customer's PC? What of my static library? Has it been statically linked into app_name.exe? What are all of those .lib files doing in the app's Release directory? > or use a > merge module, or (least preferably) include the > Microsoft.VC90.CRT.manifest and the DLLs in the application folder. > >> Manifest? I never needed a manifest when developing code >> in VC6. > > > Aside from the side-by-side versioning, manifests are a big POS. Is there some way to tell Visual Studio 2008 to build the same executable VC6 does? Something that just runs? Sebastian, I do appreciate your attempts to assist me. Thanks Larry
From: Nathan Mates on 6 Apr 2008 16:17
In article <Xe6dnVGtsqUCk2TanZ2dnUVZ_g-dnZ2d(a)comcast.com>, Larry Lindstrom <nobody(a)aracnet.com> wrote: > I looked through \Program File\Microsoft Visual studio 9.0 and found >a directory called "Microsoft.VC90.CRT". It has a manifest and 3 dlls, >msvcm90.dll, msvcp90.dll and msvcr90.dll. Are these the runtime libs >you are talking about? Are they legally redistributable? If these are >the files, do I put them in \Program Files\app_name on the customer's >PC? Close, but not quite. What you want to do is look for vcredist_x86.exe, which should be installed in the DevStudio folder under C:\Program Files\ . (There's also a vcredist_x64.exe, for 64-bit software and OSs, but that's probably not what you're building for). What you want to do is include that vcredist exe with your installer, and run it as part of the install. Then, it'll be present for your app and every other app that wants to use it on their system. Alternatively, if your app is a single exe, no DLLs, you can set it up for static linking, *and* disable manifests for it. Right click on your project, get properties, and go to C/C++ -> Code Generation. For Runtime library, pick Multithreaded (for your release builds), and Multithreaded Debug for your debug builds. Then, go to linker -> Manifest file, and set 'Generate Manifest' to no. Then go to Manifest Tool -> Input & Output, and set 'Embed Manifest' to no. This does bloat up your exe by at least a few hundred KB. > Is there some way to tell Visual Studio 2008 to build the same >executable VC6 does? Something that just runs? No, because "just runs" is apparently a dirty word to some folks at Microsoft. I've said this before that the deploy instructions for HelloWorld.exe should be *no* longer than the source code for said project (5 lines). However, MS has some fantasy that everyone will (1) memorize their instructions about manifests buried deep in the bowels of MSDN, and (2) use their obtuse installer technology and manage every last little bit. Manifests are clearly a technology that slipped into the world a few years too early -- the error handling for them is useless at best. An app missing a DLL will clearly state that it's looking for msfoobar32.dll. An app missing things in the manifest will die with a "the application parameter is incorrect" in the messagebox, which tells people nothing useful. Microsoft has a reputation for getting things right, eventually. It's been years and two compiler versions (2005, 2008) using them. It's not gotten a lick easier. Whomever is in charge of the manifest technology at MS seems to be on a power trip of trying to make sure people jump thru lots of weird hoops. I don't appreciate it. Nathan Mates -- <*> Nathan Mates - personal webpage http://www.visi.com/~nathan/ # Programmer at Pandemic Studios -- http://www.pandemicstudios.com/ # NOT speaking for Pandemic Studios. "Care not what the neighbors # think. What are the facts, and to how many decimal places?" -R.A. Heinlein |