If you have experiences with linux, why not use mingw32 as compiler? DOSBox supports it, and then you have your usual ./configure && make commands back. Using ./configure --enable-static should work.

BTW, the "mac" way is multiple files in a subdirectory that is simply shown as one file by the finder.

I've managed to do the sort-of-static build by now. Just chose "lib" instead of "dll" in the SDL compilation configuration. Then add the previous external dependencies of SDL (winmm.lib and dxguid.lib) to those of DOSbox so the linking stage finds the necessary stuff. The result depends on nothing but standard windows and directx dlls, should work out of the box on any win32 system that has DirectX installed.

Why I'm not using Mingw? I've heard a lot of not-so-good things about its stability. Plus, does Mingw do windows resources stuff?

Why I'm not using Mingw? I've heard a lot of not-so-good things about its stability.

I fear for the next version of dosbox then.

Qbix, if you mean I shouldn't listen to hearsay you're right of course. But things did work out just fine with VC++, so I don't really see a need to switch compilers for the moment. I'm certainly not against open source as such and I wouldn't be using VC++ if it wasnt downloadable for free. And I have to learn my way around VC++ anyway, so why not use dosbox as the white rabbit for some experiments, I promise I won't dissect it while alive. 😉

I haven't had any problems with MinGW over the past year or so that I've been using it to compile DOSBox, SDL and other stuff. I'd like to hear some of the not-so-good-things.

mingw is stable and fast, and it supports everything the microsoft compiler supports (as long as we are talking about c/c++, not dotnet stuff). Including resources, arbitrary external DLLs and so on. Moreover, it has less bugs/a more complete c++ implementation than msvc.

HunterZ wrote:

I'd like to hear some of the not-so-good-things.

See this discussion I had a short time ago concerning an Apple II emulator:

http://groups.google.com/group/comp.emulators … fc1cf3fa78b1819

Well, in my four years experience with Exult (Ultima 7 engine), more things broke with the msvc version than with mingw.
This link doesn't really say much. Overall in my limited experience Mingw proved better than cygwin and not the other way round.

Well good to know. I may have put too much weight on Andy's statement simply because I like his software.

He may be perfectly right, but from the context I guess his concerns seem to revolve around console mode apps. It's not a problem of mingw per se, but a limitation of their goals: cygwin wants to be a tool for porting unix apps (which makes it heavy), while mingw just wants to be a decent and slim compiler with a lot less portability aid. As DOSBox uses SDL for portability, it uses mingw the way it is meant.

Yeah as far as Cygwin versus MinGW, the latter makes more sense for DOSBox because DOSBox was designed from the ground up to be cross-platform. Cygwin is full of crutches for porting Unix apps to Windows, which add extra baggage (DLLs etc.).

The original question was VC++ versus MinGW though, I think. My guess (and it's just a guess) is that MSVC++ will optimize a little better, but MinGW is likely to have less problems due to the fact that it is gcc-based (like most of the other platforms DOSBox is supported on).

I really doubt MSVC optimizes better... gcc is already quite close to intel, and if anyone then intel knows how to optimize for their CPUs. GCC has a lot of high-level optimizations, sponsored by IBM and other noteworthy organizations. That's why I always recommend the latest possible gcc: It's progressing quite fast.

By latest do you mean gcc 4.x? Is that even working with MinGW yet?

No idea. By "latest" I mean "the latest that doesn't break" which usually rules out X.0 versions 😉