Doesn't answer any of my questions, but yeah.

Sorry - I didn't see your message with questions until just now (I was looking at more recent messages):

When I said the resulting file was identical, I meant the SDL.DLL file that I built from downloaded source and the SDL.DLL and the one I found already built in @TeaRex's project. But I'm not trying to statically-link SDL.DLL anyway, only the Visual C++ redistributables.

I put back the FPU in config.h, as you said.

When I said that MT/t didn't work, I meant that I got around a hundred lines of error messages beginning

sdlmain.obj : error LNK2001: unresolved external symbol __environ
1>.\Release/DOSBox.exe : fatal error LNK1120: 1 unresolved externals

I suppose I'm asking for a way to build an executable that has the redistributable files baked into the EXE but leaves SDL.DLL as a separate file.

When I said the resulting file was identical, I meant the SDL.DLL file

Neither sdl.dll nor sdl.lib should be identical, possibly you linked to the wrong library.

I suppose I'm asking for a way to build an executable that has the redistributable files baked into the EXE but leaves SDL.DLL as a separate file.

Doesn't matter, still SDL has to be compiled with the same runtime library option.

Neither sdl.dll nor sdl.lib should be identical, possibly you linked to the wrong library.

You're right: there was no compiled copy of sdl.dll in @TeaRex's original project; the two identical copies were the ones built on my system, one when was building my DOSBox project, the other when I was building SDL.DLL as a separate project in a different folder.

Thanks for your patience over this, I'm trying to do somersaults when I'm still learning how to walk in the C++ world.

Well i can only say that it is pretty straightforward, first get everything to compile
out of the box (for sdl you need the directx sdk and, possibly later, some fixes
found in the dosbox source tree; for dosbox you should remove unnecessary
things and add the SDL header/library directory). If that works just switch everything
to use /MT for the non-dll runtime library.

Thank you. That's the clearest statement I've seen of what needs to be done, though I'll probably have to come back to you and ask "Exactly how do I add the DirectX SDK to SDL?" That's probably obvious to anyone with experience in this, but it's not at all obvious to a newcomer.

I've already added the folders in the SDL source distribution named lib and include to the VC++ listings for lib and include directories. Is that what you meant by adding the SDL lib/header directory?

I'm using the SVN source in @TeaRex's project - it dates back to October, if I remember correctly. (I'm at a different computer right now, and can't check this.)

Will try this tonight, if I can figure out how to add the DirectX SDK to SDL. I hope this page may be what I need:

http://forums.libsdl.org/viewtopic.php?t=4450 … 68baa51935e43cd

Thanks again for all your help.

I usually try to avoid modifying the global header/library search paths. Anyways.

Start off with clean sources, SDL-1.2.14.zip (latest sdl sources) and straight dosbox 0.74
or svn sources.

Read the visual c specific docs of sdl, extract VisualC.zip and open the project
solution in there with vs2010. Compile the whole thing, should give link errors
which you resolve by adding the dx sdk lib directory to the additional library directories
or library directories listing (program files Microsoft DirectX SDK (June 2010)\Lib\x86 folder or so).

That should compile fine in release mode now.

Thanks again. Will test and report back when I get back to my development machine.

Note that the DirectDraw .lib file is no longer there in the latest DirectX SDK. I'm not sure if SDL as used in DOSBox needs to be linked against it, but it might very well. So I'd recommend installing the February 2010 DirectX SDK instead of the newest version, if you can't link SDL.

But that should only affect dosbox itself (HAVE_DDRAW_H), not SDL.

Thanks again to everyone for your advice, which worked perfectly. I was able to build an executable with the Visual C++ 2010 redistributables included; it runs even when MSVCP100.DLL and MSVCR100.DLL (in \Windows\System32) are renamed.

Here's what I did. I followed the instructions on the wiki page about building under Visual C++ Express. I also downloaded and installed the February 2010 DirectX SDK and added its include and lib directories in the Visual C++ directories. I added MSVCRT.LIB to the excluded libraries, and built with the /MT option.

These are the warnings that I got:

1>c:\development\dosbox-0.74\src\cpu\core_dyn_x86\risc_x86.h(111): warning C4731: 'gen_runcode' : frame pointer register 'ebp' modified by inline assembly code
1>..\src\gui\sdlmain.cpp(1892): warning C4297: 'SDL_main' : function assumed not to throw an exception but does
1> __declspec(nothrow) or throw() was specified on the function
1>..\src\gui\sdlmain.cpp(1892): warning C4297: 'SDL_main' : function assumed not to throw an exception but does
1> __declspec(nothrow) or throw() was specified on the function
1>sdlmain.lib(SDL_win32_main.obj) : warning LNK4217: locally defined symbol _exit imported in function _main
1>sdlmain.lib(SDL_win32_main.obj) : warning LNK4217: locally defined symbol _strrchr imported in function _main
1>sdlmain.lib(SDL_win32_main.obj) : warning LNK4217: locally defined symbol _fprintf imported in function _ShowError
1>sdlmain.lib(SDL_win32_main.obj) : warning LNK4217: locally defined symbol __iob imported in function _ShowError
1>sdlmain.lib(SDL_win32_main.obj) : warning LNK4217: locally defined symbol _fclose imported in function _cleanup_output
1>sdlmain.lib(SDL_win32_main.obj) : warning LNK4217: locally defined symbol __pctype imported in function _ParseCommandLine
1>sdlmain.lib(SDL_win32_main.obj) : warning LNK4217: locally defined symbol ___mb_cur_max imported in function _ParseCommandLine
1>sdlmain.lib(SDL_win32_main.obj) : warning LNK4217: locally defined symbol __isctype imported in function _ParseCommandLine

Apparently they're not serious, because the executable works.

I also applied the same procedure to @TeaRex's project, and built a version of that with the redistributables included.

This was exactly what I was hoping to accomplish. Thanks again to everyone for your help.

Great that you got it to work! As for your warnings I think the one about EBP being modified is unavoidable (and spurious since EBP is in fact saved and restored by the inline ASM code), I simply turn it off in the project properties (you can selectively disable warnings by number). The others can be fixed with small changes to the source: add the missing #includes and change the throw() declarations. But this is purely cosmetic I think.

Just for your info, my source tree contains small patches vs. the official SVN in the following areas: It uses real IBM VGA fonts for keyboarlayout=none, so that you can type e.g. MMMMMM without the M's sticking together; and, it fills unused areas of the emulated ROMs with random bytes instead of zeros, to make the Ultima VII intro work correctly, which copies ROM data to the screen to create a random "snow" effect.

Thank you again for your source tree! I noticed that a build from your source produced a better-looking text screen than the distribution version, but I couldn't figure out exactly why this was so until you explained it.

Also, thanks for your suggestions about the error messages. If you ever have a few minutes with nothing better to do, I'd be grateful for step-by-step instructions for "adding the missing #includes" - this is beyond my expertise right now.

Would anything be gained by working with a more recent DirectX SDK? Thanks to your help, I have this working very well right now, and I don't want to change anything if there won't be any benefit.

And thank you again for this. I'll post one or two alternative DOSBox icons in the future, as a thank-you to this community.

Having had a similar problem with deploying a DOSBox built in VC++2010, I'm wondering whether emendelson's problem was manifest related. The one I built without re-compiling the sdl kept including VS 2008 assembly information in the manifest and I think this was because SDLmain.lib had been built with VC+2008. Turning off manifest generation is VC++2010 options (something now apparently allowed by MS) solved the problem without having to install the DirectX SDK or rebuild the SDL.