MAMEWorld Forums - Programming - Re: libmame patch discussion please

> > 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.

As it turns out there are very, very few POSIX APIs needed by most non-GUI software, and by MAME In particular, that are not available on Windows. The major one is POSIX threads; but pthreads is available for Windows with the pthreads-win32 library (that works on 64 bit systems now too), and it's even included "for free" with the MAME version of the MingW compiler. I'll admit that I haven't performance tested pthreads-win32 but I had assumed it was pretty good.

Aside from that, the only differences between windows and non-windows in the "posix" OSD is:

- Windows needs to call mkdir(dir) instead of mkdir(dir, 0777)

- Windows needs to call VirtualAlloc/VirtualFree instead of mmap/munmap (and this functionality is only needed by the dynamic recompiler cache and I don't know if that is actually used by MAME proper, I think it might be a MESS thing)

- I use GetCurrentThreadId() as a convenience in the osd_work_queue.c implementation because pthreads-win32 doesn't have integer thread ids; but I don't really even need to do that

So since 99.99% of the code can be identical between all systems, it seems to make sense to me to have it be so instead of having duplicate OSD implementations.

The parts of the OSD that truly cannot be implemented portably is the stuff relating to graphics, sound, and input. But libmame doesn't even want the OSD to provide those; it expects code external to the library to provide those.

And, for what it's worth, I have benchmarked my osd_work_queue implementation fairly thoroughly and it is approximately 3x faster (and uses considerably less code) than the SDL OSD implementation (at least on Linux - maybe it's worse on Windows, I should investigate that).

> 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.

I just like the conciseness of an OSD implementation that isn't duplicated across platforms unnecessarily. With about 5 lines of #ifdef WINDOWS code across the entire POSIX OSD, it is completely portable between Linux and Windows. I haven't tried Mac OS X but since it's even closer to true POSIX than Windows, I would expect to have to make *zero* modifications to the posix OSD.

Also, the sockets API is already very, very portable across platforms so I expect that when MAME supports sockets, the "posix" OSD implementation will not need anything windows specific.

And - the phrase "bolt on your own" is a little bit unfair. It was carefully constructed, and you could replace BOTH of the sdl and windows OSD implementations (except for the graphics, sound, and input part of course!) with the posix implementation and have 1/2 of the code and have it run faster (at least for anything threaded) AND not have to maintain and debug/test two separate OSD implementations.

But if you are saying that in order to have libmame accepted by the MAME team I'd have to back out my OSD implementation and re-use the existing ones, then I would do that. The patch would have to include changes to windows and sdl OSD code instead of adding the posix OSD, but I can do it. Just give the word and it will be done.