| << Newer | Article #187 | Older >> |
Building MAME under Windows Vista
As several folks have pointed out, yes I'm running Vista on my laptop. Overall, I have to say it runs pretty well, but then again, I have a decent machine (2GHz Pentium-M, 2GB RAM, ATI Mobility Radeon 9600).
There are a few definite improvements that have been nice to have. For example, the video driver now properly detects when I plug/unplug my second monitor, and adds/removes the second half of the display automatically now. You can also now shift-right click on any file or folder in Explorer and there is a new "Copy as Path" option, which is very useful when you are switching between GUI navigation and command-line windows. Most everything I've run on it seems to work fine, even the stuff it warns you about. The newly redone games are quite nice (yes, even Minesweeper got a nice rewrite ;)) And MAME itself runs as well as it did under XP, no problems there (whew!)
On the flip side, I have run into some issues, especially with regards to building MAME. Mingw and Vista don't get along very well, which is unfortunate. The handling of built-in paths (i.e., includes pointing to gcc libraries, paths, etc) is completely broken, meaning you have to explicitly specify them when you build. I've already done some workarounds in the windows.mak file to sort of get things limping. If you set the environment variable VISTA_MINGW_ROOT to point to your mingw folder, it triggers some of the additional paths to be explicitly added to the command line. It's a pretty ugly hack, however, and doesn't work 100% unless you're using the MSVC tools (which is good enough for my development, at least :)). I've brought this up with the mingw-developer group, and it appears that the Vista version of the standard C library is much stricter about proper parameters, and will return errors in many cases that used to "work" due to invalid parameters.
A somewhat more annoying problem is that the mingw make utility will randomly fail with a "Cannot fork" error during a build. This error is completely random; if you re-run the make it will often succeed on the files that failed. My suspicion is that there is some sort of objection to the fork process, which is a little unnatural under Windows, and requires creating an empty process and poking data into memory -- which looks a lot like a malicious program trying to modify another application. I've taken to using the -i parameter with make, which ignores errors and keeps making. Then I run make several times in a row. By about the 5th time, all the files tend to be built. I haven't found a good workaround to this one yet, unfortunately. It's been reported, but I haven't heard any reported solutions from the mingw folks at this time.
Both of these issues are annoying, so if you wish to develop with MAME, I would recommend holding off on a Vista upgrade until they are fixed. Or (shameless plug) you can install a beta version of Virtual PC 2007, install Windows XP, and run your development environment in there. It's kind of a heavyweight approach, though, and requires a copy of XP to play with.
And finally, there is one issue I have run into that just really gets my goat. With the new user access control, some bright bulb decided that any .EXE file with the phrase "setup" or "patch" in its name required authorization to run. Sadly, this means that patch.exe, which you might recall is pretty commonly used in MAME development, pops up an authorization dialog every time you try to use it. The workaround is easy enough: rename patch.exe to undiff.exe and it works fine. Or just turn off the user access control. But still, it's pretty awful.
You might think with all the problems I would give up, but for the most part, it works pretty well. Heck, I even kind of like the aero glass theme and the animations. It's also pretty cool to run MAME in a window and then use flip-3D to switch apps and watch MAME run live in that mode. :) And well, somebody has to be the squeaky wheel that points out the issues. There's still a few weeks left before broad availability, so who knows, maybe these things will get solved before most people will really be affected.