DRD Team

This might be a big no-no, if it is, please just obliterate this topic.

I have successfully compiled a build of the latest source of GZDoom (and it runs fine), but when I sent it along to a friend who's not-so techie related, she got an error:

"This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix the problem."

Long story short... how would I get the build to run for her, without having her go through installing Visual Studio or whatever? I read it's something to do with debug DLLs of some kind, but I have no idea what they are.

First, what Windows version does your friend have?
Second, what's the hardware specs she got?
Third, what precisely did you send her?

Does an official download work?

First, what Windows version does your friend have?
Second, what's the hardware specs she got?
Third, what precisely did you send her?

Does an official download work?

1) She has Windows XP Home SP2. I have Windows XP Pro SP2.
2) She has an AMD Sempron 3000+, 2 GB of RAM, and a Radeon 9550. It runs the latest public build completely normally.
3) I built the latest SVN trunk of GZDoom (r100) and sent her the four files it produced - gzdoomd.exe, brightmaps.pk3, lights.pk3, gzdoom.pk3, and added in fmodex.dll. (Without that it didn't work for me, either.) It worked for another person I sent it to after sending it to her, so either he has some DLLs she doesn't have to let it run, or else my system (Which is a lot better than hers - Core 2 Duo E6750, GeForce 8800 GTS 640, 4 GB RAM) used some optimizations she wouldn't have, like SSE2 or SSE3 perhaps.
4) Yes, an official download build of 1.1.02 works for her 100% fine.

Download my build of r100 from http://nash.wanzafran.com/doomstuff/svn/gzdoom-svn.zip and see if that works for her?

(BTW, I maintain the latest SVN builds for ZDoom and GZDoom at the above address)

She said that one works... so what did you do that I didn't? I noticed it was lacking a few files... and that the EXE was named different.

I'm guessing I'd have to compile it in a normal mode as opposed to debug mode... but I'd have to find where that's supposed to be done, unless you'd like to tell me.

You can change that in the toolbar of MSVC. Look for a field that says 'Win32 Debug'. I don't know if there is an issue with debug builds because I never tried to make them work on another computer but they are certainly not for distribution. They contain unoptimized code that is considerably slower (and larger) than the release build.

I tried switching that to release and I got lots of real fun errors.

1>mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "..\..\release\fixrtext.exe". Access is denied.
2>mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file ".\release\makewad.exe". Access is denied.
6>.\trustinfo.txt : manifest authoring warning 81010002: Unrecognized Element "requestedPrivileges" in namespace "urn:schemas-microsoft-com:asm.v3".
6>mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "..\..\release\updaterevision.exe". Access is denied.
7>mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "..\gzdoom.exe". Access is denied.

It attempts to start up normally but crashes before it gets to the menus. Is there a reason why this build fails, but not a debug build?

Nash wrote:Download my build of r100 ...

Nash, thank you for doing this.
Just one request though, could you specify the svn number in your builds, ie gzdoom-svn100.zip

And also a big Thank You to Graf Zahl for the tireless effort to give us those updates.

NeoHippo wrote:Just one request though, could you specify the svn number in your builds, ie gzdoom-svn100.zip

That's pretty pointless; with SVN you can go back and get any version of any file if you wanted it.

Also, I'm still trying to figure out why it's giving me those errors... I have a feeling once I resolve it, it will build completely successfully and errorless.

Dark Pulse wrote:That's pretty pointless; with SVN you can go back and get any version of any file if you wanted it.

Maybe, DP, you are endowed with powers of clairvoyance. If that is the case, then I can understand you stating that.

For my part, if I click on either link in http://forum.zdoom.org/viewtopic.php?f=3&t=17088 , I get zdoom-svn.zip or gzdoom-svn.zip.
This does not tell me which version I would be downloading until I had downloaded, installed and ran the program.

So, yes, for my part it would be nice if the SVN version were reflected in the filename, therefore my request for gzdoom-svn###.zip.

Well, using TortoiseSVN will tell you what revision the files are at. :p

Nash's link doesn't, but that might be useful.

Still looking for a solution to my issue on compiling them... >_<

EDIT: Nevermind. Turns out the Firewall is being really, really dumb and is denying the access to those files when I try to modify them. I gotta work around it and tell it to take a hike when VC++ wants to modify the files.

I have already explained in that thread why my files aren't named with the revision number appended, but I'll go through it again here really quick:

I have no idea how to retrieve the current revision number. Basically, my computer (which is left on 24 hours) is scheduled to run an automated process that checks for any SVN updates and compiles the latest version if there's one, and finally upload. This is all done using basic commands through .BAT files. The BAT file does a lot of things - among others, zipping up the files and renaming them, before upload.

The problem comes because I don't know how to retrieve the SVN revision that I could pass to the rename command.

BTW, you can check which revision my executables are at without running them - just hover your mouse over the EXE and the tooltip that appears should tell you the file version - for example, 2.2.0.951 means it's at revision 951.