Details of Wine's Low-level Implementation... There are three differently sized accelerator structures exposed to the user: Accelerators in NE resources. This is also the internal layout of the global handle HACCEL (16 and 32) in Windows 95 and Wine. Exposed to the user as Win16 global handles HACCEL16 and HACCEL32 by the Win16/Win32 API. These are 5 bytes long, with no padding: BYTE fVirt; WORD key; WORD cmd; Accelerators in PE resources. They are exposed to the user only by direct accessing PE resources. These have a size of 8 bytes: BYTE fVirt; BYTE pad0; WORD key; WORD cmd; WORD pad1; Accelerators in the Win32 API. These are exposed to the user by the CopyAcceleratorTable and CreateAcceleratorTable functions in the Win32 API. These have a size of 6 bytes: BYTE fVirt; BYTE pad0; WORD key; WORD cmd; Why two types of accelerators in the Win32 API? We can only guess, but my best bet is that the Win32 resource compiler can/does not handle struct packing. Win32 ACCEL is defined using #pragma(2) for the compiler but without any packing for RC, so it will assume #pragma(4). The primary reason to do this is to reverse engineer a hardware device for which you don't have documentation, but can get to work under Wine. This lot is aimed at parallel port devices, and in particular parallel port scanners which are now so cheap they are virtually being given away. The problem is that few manufactures will release any programming information which prevents drivers being written for Sane, and the traditional technique of using DOSemu to produce the traces does not work as the scanners invariably only have drivers for Windows. Presuming that you have compiled and installed wine the first thing to do is is to enable direct hardware access to your parallel port. To do this edit config (usually in ~/.wine/) and in the ports section add the following two lines read=0x378,0x379,0x37a,0x37c,0x77a write=0x378,x379,0x37a,0x37c,0x77a This adds the necessary access required for SPP/PS2/EPP/ECP parallel port on LPT1. You will need to adjust these number accordingly if your parallel port is on LPT2 or LPT0. When starting wine use the following command line, where XXXX is the program you need to run in order to access your scanner, and YYYY is the file your trace will be stored in: wine -debugmsg +io XXXX 2> >(sed 's/^[^:]*:io:[^ ]* //' > YYYY) You will need large amounts of hard disk space (read hundreds of megabytes if you do a full page scan), and for reasonable performance a really fast processor and lots of RAM. You will need to postprocess the output into a more manageable format, using the shrink program. First you need to compile the source (which is located at the end of this section): cc shrink.c -o shrink Use the shrink program to reduce the physical size of the raw log as follows: cat log | shrink > log2 The trace has the basic form of XXXX > YY @ ZZZZ:ZZZZ where XXXX is the port in hexidecimal being accessed, YY is the data written (or read) from the port, and ZZZZ:ZZZZ is the address in memory of the instruction that accessed the port. The direction of the arrow indicates whether the data was written or read from the port. > data was written to the port < data was read from the port My basic tip for interpreting these logs is to pay close attention to the addresses of the IO instructions. Their grouping and sometimes proximity should reveal the presence of subroutines in the driver. By studying the different versions you should be able to work them out. For example consider the following section of trace from my UMAX Astra 600P 0x378 > 55 @ 0297:01ec 0x37a > 05 @ 0297:01f5 0x379 < 8f @ 0297:01fa 0x37a > 04 @ 0297:0211 0x378 > aa @ 0297:01ec 0x37a > 05 @ 0297:01f5 0x379 < 8f @ 0297:01fa 0x37a > 04 @ 0297:0211 0x378 > 00 @ 0297:01ec 0x37a > 05 @ 0297:01f5 0x379 < 8f @ 0297:01fa 0x37a > 04 @ 0297:0211 0x378 > 00 @ 0297:01ec 0x37a > 05 @ 0297:01f5 0x379 < 8f @ 0297:01fa 0x37a > 04 @ 0297:0211 0x378 > 00 @ 0297:01ec 0x37a > 05 @ 0297:01f5 0x379 < 8f @ 0297:01fa 0x37a > 04 @ 0297:0211 0x378 > 00 @ 0297:01ec 0x37a > 05 @ 0297:01f5 0x379 < 8f @ 0297:01fa 0x37a > 04 @ 0297:0211 As you can see there is a repeating structure starting at address 0297:01ec that consists of four io accesses on the parallel port. Looking at it the first io access writes a changing byte to the data port the second always writes the byte 0x05 to the control port, then a value which always seems to 0x8f is read from the status port at which point a byte 0x04 is written to the control port. By studying this and other sections of the trace we can write a C routine that emulates this, shown below with some macros to make reading/writing on the parallel port easier to read. #define r_dtr(x) inb(x) #define r_str(x) inb(x+1) #define r_ctr(x) inb(x+2) #define w_dtr(x,y) outb(y, x) #define w_str(x,y) outb(y, x+1) #define w_ctr(x,y) outb(y, x+2) /* Seems to be sending a command byte to the scanner */ int udpp_put(int udpp_base, unsigned char command) { int loop, value; w_dtr(udpp_base, command); w_ctr(udpp_base, 0x05); for (loop=0; loop < 10; loop++) if ((value = r_str(udpp_base)) & 0x80) { w_ctr(udpp_base, 0x04); return value & 0xf8; } return (value & 0xf8) | 0x01; } For the UMAX Astra 600P only seven such routines exist (well 14 really, seven for SPP and seven for EPP). Whether you choose to disassemble the driver at this point to verify the routines is your own choice. If you do, the address from the trace should help in locating them in the disassembly. You will probably then find it useful to write a script/perl/C program to analyse the logfile and decode them futher as this can reveal higher level grouping of the low level routines. For example from the logs from my UMAX Astra 600P when decoded further reveal (this is a small snippet) start: put: 55 8f put: aa 8f put: 00 8f put: 00 8f put: 00 8f put: c2 8f wait: ff get: af,87 wait: ff get: af,87 end: cc start: put: 55 8f put: aa 8f put: 00 8f put: 03 8f put: 05 8f put: 84 8f wait: ff From this it is easy to see that put routine is often grouped together in five successive calls sending information to the scanner. Once these are understood it should be possible to process the logs further to show the higher level routines in an easy to see format. Once the highest level format that you can derive from this process is understood, you then need to produce a series of scans varying only one parameter between them, so you can discover how to set the various parameters for the scanner. The following is the shrink.c program: /* Copyright David Campbell <campbell@torque.net> */ #include <stdio.h> #include <string.h> void main (void) { char buff[256], lastline[256]; int count; count = 0; lastline[0] = 0; while (!feof (stdin)) { fgets (buff, sizeof (buff), stdin); if (strcmp (buff, lastline) == 0) { count++; } else { if (count > 1) fprintf (stdout, "# Last line repeated %i times #\n", count); fprintf (stdout, "%s", buff); strcpy (lastline, buff); count = 1; } } }