title: Using 64-bits driver from 32-bits application
body: <p>I have a Windows application that HAS to run as 32-bits (because of other limitations out of my control). However, my application has to call and access a driver which may be 32-bits or 64-bits depending on the system where it is installed.</p>
  
  <p>I access the driver through DeviceIoControl() calls, exchanging data structures declared in an include file. Data structures contains fields declared as "DWORD_PTR" (the include file I don't control either).</p>
  
  <p>My problem is that on a 64-bits system, the driver expects the structures to contain 64-bits integer (because of DWORD_PTR declaration). However, my 32-bits program sees those DWORD_PTR as 32-bits integers. I then have a data mismatch between my program version of the data structures and the driver understanding of those structures.</p>
  
  <p>DeviceIoControl() ends-up failing with ERROR_INSUFFICIENT_BUFFER (The data area passed to a system call is too small). I confirmed that I don't get this error if I pass a 64-bits version of the structs to the driver.</p>
  
  <p>I have a few ugly options out of this mess. But I wonder if anyone has some nicer suggestions?</p>
  
  <hr>
  
  <p>Solution:</p>
  
  <ul>
  <li>Declare a new copy of the shared structures with REAL 64-bits data fields (__int64)</li>
  <li>Dynamically check the OS architecture (32/64)</li>
  <li>Use the 32-bits or 64-bits version of the structures for the DeviceIoControl() calls.</li>
  </ul>
  
  <p>Drawbacks:</p>
  
  <ul>
  <li>I have to maintain an explicit 64-bits copy of the structures declaration manually. It can be a pain over time.</li>
  </ul>
  
  <hr>
  
  <p>My other solutions are variation of this one, but they <strong>ALWAYS</strong> involve maintaining some copy of the structures definition (for example in an IDL for COM servers option).</p>
  
  <p>Edit: This is a Microsoft driver and it seems it does not use IoIs32bitsProcess(irp)!</p>