* Implementation of MXIOINFO. Not a 100% match, but we are very close. I don't wanna wrangle with this one any more, so I figured I would open it up for review in case anyone else has ideas.
**Known problems:**
- The Open function uses a `movzx` instruction on the value of parameter `fdwOpen` before pushing to OpenFile from the kernel. You can force this to appear by casting to `unsigned short`, but this disturbs the instructions for the rest of the file. To get the "best" overall match I decided to leave this out.
- Flush, Advance, and Descend differ only in the order of operands on a `cmp` instruction.
- This entire file is honestly pretty ugly. The main reason is all the nested ifs; we are constrained by returning a result value from each function, but only at the very end instead of bailing out with a `return`. By far the worst offender is the do/while loop in the Descend function.
**Design considerations:**
- We are casting the file handle from MMIOINFO to `HFILE` everywhere it is used, so I decided to just change the type. While doing that, I figured I might as well just pull out the members from the struct so we don't have `m_info` all over the place.
- Without using a struct member, we have the issue of the obvious `memset` used to zero out the values in the constructor. I changed this to work on the object itself, which would not be valid in most cases, but seems fine here since we have no virtual methods.
There is a lot of repeated code here, namely the call to `_llseek` to reset `m_lDiskOffset` based on the current file position. You could move this to an inline function, but maybe that's not appropriate.
There are probably strides to be made on code clarity and comments (if needed or wanted) here. I'm open to any suggestions.
* remove casts on read, add size assert
* Use more Mx* types and param style convention
* Fixing up MXIOINFO to prepare for merge.
* Following feedback from @stravant and @itsmattkc, reverted back to using `MMIOINFO` struct as the class member instead of adding its values directly. (We actually gained a little on accuracy with this change.)
* The memset to zero out the values in the constructor now acts on `m_info` instead of `this`. Strictly speaking we don't need the size assert any more but I decided to keep it in case we change the members later for some reason.
* Casting the `hmmio` member to `HFILE` (int) or `HMMIO` (WORD) typedefs where needed.
* Squelch a signed/unsigned type comparison warning
* define MxLong/MxULong
The "long" type has different sizes on different platforms, and this may cause issues.
* use DWORD to match RegQueryValueExA arg
* 100% Match of MxDSFile
* ...almost, MxDSFile::Open is still not quite matching but all of the
other methods are 100% matching.
* Turns out that most of the virtual methods and some of the members are
actually on the MxDSSource base class, which I've pulled out as part
of this.
* In order to implement the methods I added the MXIOINFO class, which
seems to be a thin wrapper around the MMIOINFO windows structure. We
can tell this because MMIOINFO::~MMIOINFO was included in the DLL
exports, and calls down to a function which deconstructs something
looking exactly like MMIOINFO.
* Add mxdssource.cpp
* mattkc feedback
* some accuracy improvements
* Use FOURCC macro
* Tirival solve in mxioinfo.cpp
* Update mxdsfile.cpp
0xFFFFFFFF -> -1
---------
Co-authored-by: Christian Semmler <mail@csemmler.com>
