* Created a more flexible imgtool::datetime structure for use within Imgtool
This is intended to replace most usage of time_t
* Changing the granularity of imgtool_clock from 1ms to 100ns, as per Vas' suggestion
* Created arbitrary_datetime in timeconv.h to facilitate interpretation of datetime info
I concluded that invoking std::mktime on manually assembled std::tm is bad, because it is indeterminate how the std::tm members may be "dominant". This required that I go further in imgtool, and update a number of drivers and eliminate the parameter of imgtool::datetime that takes std::tm.
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.
* [Imgtool] Fixed issue with 'listfilters' command
* [Imgtool] Extremely basic fix to the Imgtool <==> CHD HD bridge
This really needs _much_ more work
* Introduced an 'util::arbitrary_clock' template class, to represent a clock that "knows" when the epoch starts
Also:
- Converted the NTFS filetime code to use util::arbitrary_clock
- Converted the Mac datetime code to use util::atribrary_clock
This is in preparation for a bigger change to Imgtool where I eliminate usage of time_t
1. Changed the Win32 code to use _O_U8TEXT()
2. Reordered system #includes
3. Changed a number of 'std::wcout << ...' to use util::stream_format()
I'm getting massive code compilation issues, and it isn't clear to me what the problem is. I'm committing my WIP right now, with the intention of reviewing the specifics soon.
I really don't like the prevalence of '#ifdef WIN32' in this change, both the _setmode() and bypassing codecvt. I strongly suspect that the latter is the consequence of some mistake that in practice doesn't cause problems in MSVC. I welcome all eyes.
