Source file: /~heha/hs/sht11.zip/src/inpout32.h

/**********************************************************************************\
 * Defines InpOut32.dll and InpOutX64.dll for direct and GetProcAddress() linking *
\**********************************************************************************/

#pragma once

#include <windows.h>
#ifdef INPOUT_EXPORTS
# define FUNC(ret,name,args) EXTERN_C ret WINAPI name args
  typedef struct QUEUE *HQUEUE;		// virtual class pointer
#else
/* FUNC() will generate import function prototypes AND function pointer types
 * for the application programmer.
 * Function prototypes are useful for importing this library using inpout32.lib.
 * Drawback: The inpout32.dll is required, otherwise, the application will not start.
 *
 * Function pointer types are suffixed with "_t". These are useful for defining
 * pointers to funtions and to cast the result of GetProcAddress().
 * Drawback: This requires more coding effort for the application programmer.
 *
 * I have never used the "delayed import" feature (available since Visual C++ 2005).
 */
# define FUNC(ret,name,args) EXTERN_C _declspec(dllimport) ret WINAPI name args;\
   typedef ret(WINAPI*name##_t)args
  DECLARE_HANDLE(HQUEUE);		// opaque to user of inpout.h
#endif

/*****************\
 ** General I/O **
\*****************/

/* Basic BYTE input/output
 * Access to old-style LPT addresses 0x378 (LPT1), 0x278 (LPT2), and 0x3BC (LPT3)
 * are automatically redirected to PCI and PCIexpress cards.
 * If no true parallel port available for those addresses, redirection applies
 * to USB2LPT (native or HID API) and USB->ParallelPrinter adapter
 * You can use space-saving numerical imports like GetProcAddress(h,MAKEINTRESOURCE(1))
 * safely, as these numbers will never change
 */
FUNC(BYTE, Inp32, (WORD addr));				// @1
FUNC(void, Out32, (WORD addr, BYTE value));		// @2
FUNC(BOOL, IsInpOutDriverOpen, (void));			// @3

/* DlPortIo.dll compatible entries.
 * BYTE access is redirected too (as above), but WORD/DWORD not.
 * Not recommended for new software.
 * Import by number is not recommended from here and below.
 */
FUNC(BYTE, DlPortReadPortUchar, (WORD addr));					// @4
FUNC(void, DlPortWritePortUchar, (WORD addr, BYTE value));			// @5
FUNC(WORD, DlPortReadPortUshort, (WORD addr));					// @6
FUNC(void, DlPortWritePortUshort, (WORD addr, WORD value));			// @7
FUNC(DWORD, DlPortReadPortUlong, (WORD addr));					// @8
FUNC(void, DlPortWritePortUlong, (WORD addr, DWORD value));			// @9

FUNC(PBYTE, MapPhysToLin, (void*PhysAddr, DWORD PhysSize, HANDLE*MemoryHandle));// @11
FUNC(BOOL, UnmapPhysicalMemory, (HANDLE MemoryHandle, void*LinAddr));		// @12
FUNC(BOOL, GetPhysLong, (void*PhysAddr, DWORD*PhysVal));			// @13
FUNC(BOOL, SetPhysLong, (void*PhysAddr, DWORD PhysVal));			// @14

/* System query and some useful file system fiddling, only useful for X86 executeables
 */
FUNC(BOOL, IsXP64Bit, (void));			// @10
FUNC(BOOL, DisableWOW64, (PVOID* oldValue));	// @15
FUNC(BOOL, RevertWOW64, (PVOID oldValue));	// @16

/**********************\
 ** LPT-specific I/O **
\**********************/

/* Because inpout32.dll most-used purpose is to access the parallel port,
 * routines are added 2013 to accomodate the fading but still useful port.
 * Most important are the built-in redirection features.
 * But it's much better do avoid direct access to ports either, and to move
 * time-critical code to a USB (or Ethernet, etc.) microcontroller.
 * As a good intermediate step, sufficient for a bunch of applications,
 * my so-called USB2LPT device is able to process microcode (ucode)
 * as a concatenation of OUT and IN instruction into one USB packet.
 * This requires rewriting of applications due to logical restructuring
 * but will help making any redirection much faster than ever before.
 * (Because it's not possible to concatenate IN instructions automatically;
 *  a random application relies to get the return value immediately.)
 * Good candidates for a rewrite are applications accessing synchron-serial
 * connected devices, as SPI, JTAG, and IIC, mostly, chip programmers.
 */

/* This function is for debugging and possibly for some interactive setup.
 * It's called by invoking "rundll32 inpout32.dll,Info"
 * and pops up a MessageBox showing computer's hardware and redirection features
 * concerning parallel ports. Arguments, except HWND, are currently not used.
 * The LPTSTR is the command line, possibly used later.
 */
FUNC(void, Info,  (HWND, HINSTANCE, PCSTR, int));	// @18
FUNC(void, InfoW, (HWND, HINSTANCE, PCWSTR, int));	// @19

/* This new function returns the address of parallel port(s), via PnP service.
 * 1. Mode <a> is zero: Returns
 * LOWORD = SPP base address, you can assume 8 contiguous addresses: 4 SPP, 4 EPP
 * HIWORD = ECP base address, you can assume 3 contiguous addresses
 * Returns zero when no address was found (no or no true parallel port).
 * <n> is the zero-based(!) number of parallel port, as for
 * \devices\parallelX (NT kernel namespace) or /dev/lpX (Linux)
 * 2. Mode <a> is nonzero:
 * This function will find all LPT port addresses to array <a>,
 * whereas n is the size of the array.
 * Unused table entries are left unchanged, so the caller should zero-out
 * this array on entry. The return value is the count of found ports,
 * include those that wouldn't fit into the table (i.e. LPT21 when n==10).
 */
FUNC(DWORD, LptGetAddr, (DWORD a[], int n));		// @20

/* These functions work similar to Inp32() and Out32(), but with one difference:
 * LptQueueIn() doesn't return a useful value!
 * As a result, all I/O can be collected and executed in one transaction
 * and can be much faster than single transfers, especially for USB devices.
 * You get the result for all IN transactions on QueueFlush().
 * These routines go to standard LPT ports if available (i.e. don't enqueue),
 * and to USB devices, like USB2LPT, USBLotIo or USB->ParallelPrinter etc.
 * For USB devices, no administrative privileges are necessary.
 * For new software, programmers should use this interface.
 * For USB->ParallelPrinter adapters, a latch and some connections are necessary!
 * Read http://www.tu-chemnitz.de/~heha/usb2lpt/faq#DIY
 *
 * <n> is zero-based (LPT1 = 0), the current working maximum is 8 (for LPT9)
 * <flags> is currently unused and should be zero
 * LptOpen() returns NULL on failure.
 * <offset> is 0..7 for SPP and EPP port range, and 8..11 for ECP port range
 *		Example: QueueOut(10,0x20) enqueues a switch to BiDi mode
 * <us> is a delay in microseconds. Maximum value is 10 ms, i.e. 10000 us
 * <buf> is a buffer for the results of all enqueued IN instructions.
 * <buflen> is the size of that buffer, for a sanity check.
 *		Must be >= count of enqueued IN instructions.
 * LptQueueFlush() returns the number of IN results made, and -1 on failure.
 *		For OUT-only programs, you SHOULD call QueueFlush() regularly,
 *		as this DLL doesn't create a time-out thread for you.
 * All other functions return TRUE on success and FALSE otherwise.
 * LptInOut() is a real workhorse, processes microcode containing IN and OUT
 *		instructions and returns the IN results in another buffer.
 *		The microcode is the same as for USB2LPT device, see below.
 *		This is an alternate access method, possibly bypassing the queue.
 *		New applications are strongly encouraged to use that function!
 *		You should not intermix LptInOut() and LptQueueXxx() functions,
 *		except you have ensured LptQueueFlush() before LptInOut().
 * Don't use CloseHandle() to close the handle returned by LptOpen().
 */
 
FUNC(HQUEUE,LptOpen,    (int n, DWORD flags));			// @21
FUNC(int, LptInOut,     (HQUEUE, const BYTE ucode[], int ulen, BYTE result[], int rlen)); // @22
FUNC(BOOL,LptQueueOut,  (HQUEUE, BYTE offset, BYTE value));	// @23
FUNC(BOOL,LptQueueIn,   (HQUEUE, BYTE offset));			// @24
FUNC(BOOL,LptQueueDelay,(HQUEUE, DWORD us));			// @25
FUNC(int, LptQueueFlush,(HQUEUE, BYTE result[], int rlen));	// @26
FUNC(BOOL,LptClose,     (HQUEUE));				// @27

/* Short-form description of microcode (ucode)
 * 1 BYTE opcode = (mostly) LPT port address offset + IN bit (bit 4), e.g.
 *   0x00 = write to data port
 *   0x11 = read from status port
 *   0x0A = write to ECP control register (ECR)
 *   0x20 = delay for n x 4 us
 * For OUT and DELAY opcode, the data byte follows the opcode.
 * For each IN instruction, no byte follows, but one byte space in result buffer is needed.
 * Multiple opcodes and data bytes are contiguous and not aligned somehow.
 * General USB implementations allow maximum ucode length (as EP0 transfer) of 4096 bytes.
 * Further limits may apply to specific USB2LPT devices.
 * Opcodes > 0x20 are currently disallowed.
 */

#undef FUNC
Detected encoding: ASCII (7 bit)2