This thread originally died because it got side-tracked into discussions
about IntPtr's and endianess, so I would encourage everyone to go back into
the ML archives, and post some well-thought-out thoughts on the subject.
Just remember: A pointer is always the size of native int. (That includes
void*) IntPtr is a struct in mscorlib that wraps a void* . Some hardware bus
specs specify endianess issues (like PCI is explicitly a certain way on
*all* architectures.) And if you are worried about endianess, we will have
be able to leverage System.BitConverter and ADC to make sure we are doing
everything the exact way it is meant to be.
So my next question for this thread is, how do we want to do API versioning?
An interface representing a functional form of a piece of hardware may
change - and we don't want to start having IVGADriver1 , IVGADriver2 , etc.
Ideas? (A decorator pattern might work, but then we still technically have
to have multiple versions of the same interface in memory, not to mention
supported by the original driver's codebase.)
Also, resource mapping. We don't have Sing# or Spec# to help us, so I was
hoping Logical_Error would like to share with us some of his thoughts on
what we can (or will eventually) do, to emulate the same robust safety net.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
SharpOS-Developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
