Compiling SVN versions of Eternity under Vista/VC++2008E

Hello all. As some of you may know, I have started hosting SVN versions of ZDoom/GZDoom on DRD Team.

Someone added in the idea of hosting Eternity builds. I am willing to do this, and have already added it to my auto-update batch.

There is only one problem... it doesn't compile too well under Microsoft Visual C++ 2008. I have a successful compile, and it runs perfectly well under Windows Vista. However, testing it on a Windows XP machine with IE7 installed causes issues. It has not yet been tested under any other configuration.

Dependancy walker says that the problem is, because it links to "shlwapi.dll", it also wants to link to "dwmapi.dll", which does not exist on XP machines.

My question is, has anyone ever found a solution to this, and have they ever gotten a successful compile under VC++ 2008? (Or even 2005?)

This is the executable in question, if anyone wants to perform any tests on it.

I've gotten it to compile fine in VC2005 on my Windows 2k machine, however it involved some.... "hacking up" of the project file... For instance, I imported the file into Code::Blocks, switched the compiler to VC2005's, and made some changes so that snes_spc.lib was linked properly...

I know that sounds rather... ewe.. and you need to set up Code::Blocks to read your include folders and such, but it was the only way I could get it to work for me.

Perhaps I could use that batch file to upload SVN builds up to your site? They work quite well :)

EDIT: Looking back on this post, I was thinking you would want a build from me as an example rather than just taking my word for it...
http://www.mediafire.com/?xjebzzsx4f1
Here's the latest SVN

I removed the dependency on shlwapi; you should be able to avoid it by removing the shlwapi.lib file from the list of libraries to link against. The code segment that was previously using the PathRemoveFileSpec function has been rewritten to use an internal routine for the same purpose.

If the dependency is still getting dragged in even after you remove the library from the link options, then it must be getting linked through the SDLmain library. IF this is determined to be the case, then I'll see about eliminating EE's dependency on SDLmain.lib as well; that library frequently has to be copied into programs to avoid some weird linking problems in newer versions of MSVC. It's only a single source file containing a WinMain function to register and create the application's main window and run its message pump.

Quasar said:
If the dependency is still getting dragged in even after you remove the library from the link options, then it must be getting linked through the SDLmain library. IF this is determined to be the case, then I'll see about eliminating EE's dependency on SDLmain.lib as well; that library frequently has to be copied into programs to avoid some weird linking problems in newer versions of MSVC. It's only a single source file containing a WinMain function to register and create the application's main window and run its message pump. [/B]

I am afraid this is the case. I saw some clues pointing to this, but never thought anything of it. I am rather new to VC++ at all, I used Borland and compiled DOS programs. All this Windows crap is new to me.

In any case, would possibly linking to an old SDL build fix the problem?

I can't really say with any certainty; I'll just go ahead and integrate the SDLmain code into EE's Win32 build and we'll see what happens from there :)

I almost forgot about this thread. I've eliminated SDLmain from EE's linking process; it turns out it isn't needed at all for Win32 console applications. All it's doing is redefining our main and then calling it from its own. This may improve things by not dragging in a certain version of the C runtime library and anything else that SDLmain.lib may have been linked with.

I hate to say it, but it's still loading those bogus DLL's in XP. I can't say with any bit of certainty at all what's causing it. I do know, however, it worked in Windows 2000 using Virtual PC.