> It espouses the philosophy of 'POSIX is the portable interface'; systems that don't > support POSIX calls (i.e. Windows) have crutches and shims in place in the code to > make them look like they do, at least as much as is necessary to support the POSIX > calls used. Surely this must rub some MAME developers the wrong way.
I'm the Mac/Linux/BSD porter guy and *I* think that's wrong.
1) POSIX translation layers on Windows have a long and storied history of failure. Bloat, bad performance, and general bugginess are the usual suspects (Cygwin embodies the trifecta). Even osd/sdl on Windows uses primarily native Windows APIs aside from the SDL audio/video stuff.
2) MAME's existing OSD layer has primitives for anything you should ever need to do in the existing OSD layers (file I/O, graphics, audio, threading, synchronization, and soon sockets), so why ignore them? This is the thing about libmame that I find technically most off-putting; you can get very good portability for free if you simply use the existing OSD layer instead of trying to bolt on your own.
|