Specifically, this creates a call osd_get_command_line() that returns UTF-8 command line arguments as std::vector<std::string>. On non-Windows platforms, this does nothing more than build the vector. On Windows, this invokes GetCommandLineW() and CommandLineToArgvW(). This also attempts to unwind usage of wmain()/_tmain() on Windows, which is not standard.
Related to this, this fixes a bug in Imgtool; specifically, non-7 bit ASCII was not being handled correctly in Windows.
This is really an admission that the way that Windows handles Unicode and command line arguments sucks, and it is my belief that having a wmain() or _tmain() declaration specific for Windows is a worse solution. C'est la vie.
I'm very open to the idea that src/osd/osdcore.[cpp|h] is not the best place to do this. Let me know if I should move it.
Make avi_file a class that's held with smart pointers, encapsulate various AVI I/O structures
Make zip_file and _7z_file classes rather than having free functions everywhere
Hide zip/7z class implementation behind an interface, no longer need to call close() to send back to the cache
Don't dump as much crap in global namespace
Add solaris PTY implementation
Improve variable expansion for SDL OSD - supports ~/$FOO/${BAR} syntax
Rearrange stuff so the same things are in file module for all OSDs
Move file stuff into its own module
7z/zip open and destruct are still not thread-safe due to lack of interlocks around cache access
Directory functions still need to be moved to file module
SDL OSD may not initialise WinSock on Windows
Put SHLIB=1 in the main makefile, or on the command line.
The idea is to get a *way* faster link with symbols. It works at
least on linux, with one annoying caveat: you have to be in the
build/projects/sdl/mame/gmake-linux directory to start mame
afterwards. We're going to move some things around to be able to use
LD_LIBRARY_PATH or have it start as-is from the root.
