StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Is emulated device access a stopgap solution for until you get hardware? If so, I recommend finding some other way to be productive: work on something else, write unit tests, etc. </p> <p>Is emulated device access a permanent requirement? If so, here are a few approaches you could take:</p> <ol> <li><p><strong>If the other vendor's SDK has a "simulation" or "emulation" mode, use it.</strong> You might be surprised. You're probably not the only client that needs to be able to test/run their application without the other vendor's hardware installed. </p></li> <li><p><strong>Take the other vendor's code out of the picture.</strong> Emulate only the functionality that your application needs, and base it on your program's requirements. Everything is under your control.</p> <p>a. <strong>Add an indirection layer.</strong> Use polymorphism to switch between two implementations: one that calls into the other vendor's DLL, and one that emulates its behavior. Having your code call into an abstract base class instead of directly calling into the other vendor's DLL also will make it easier to write unit tests for your code.</p> <p>b. <strong>Write a mock DLL (as Adam Rosenfield suggested).</strong> You need to match the function names and calling conventions exactly. As you upgrade to new versions of the other vendor's DLL, you will need to extend the mock DLL to support any new entrypoints that your application uses.</p> <p>If you need to choose which DLL to use at runtime, this may require converting your code to load the DLL dynamically (but it sounds like you might already be doing this, given that you said something about function pointers). You may be able to decide at install time whether to install the other vendor's DLL or the mock DLL. And if this is purely for testing purposes, you may be able to choose which DLL to use at compile time, and just build two versions of your application.</p></li> <li><p><strong>Write a mock device driver (as others have suggested).</strong> </p> <p>If you have the spec for the interface between the other vendor's user mode DLL and their device driver, this may be doable. It will probably take longer than any of the other approaches, even if you're an experienced device driver developer, and especially if you don't have the source to the other vendor's DLL. UMDF (User Mode Driver Framework) might make this slightly easier or less time consuming.</p> <p>If the spec you mentioned does not describe the user/kernel interface, you will need to reverse engineer that interface. This is probably not going to be an effective use of your time compared with the other options, particularly if the driver interface is complex (e.g. it passes a lot of complex data structures to <code>DeviceIoControl()</code>). </p> <p>In both cases, you will need to revisit this every time you upgrade to a new version of the other vendor's SDK. The same exported DLL functions may require using new <code>DeviceIoControl()</code> codes and structures. </p></li> </ol>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload