Open questions:

1. Does IrXfer send anything in ANSI, forcing NT to detect whether the other guy is Unicode or ANSI?

    OBEX is natively Unicode, so only private header types would be ANSI.

2. How do I register a service DLL, as opposed to a service that is an EXE?

    There is a flag for this: SERVICE_WIN32_SHARE_PROCESS

3. What is the best way to fix the TerminateThread() logic used for timeouts?

    Use async reads and writes.

4. How should the client and server share files, since BUILD.EXE generates only a single executable file per directory?

5. What is the structure of the receive-file service?

    - it must handle IR devices coming and going

    - one thread would block in AcceptEx(), listening for connections
      ...unless we can set up an async accept() with a c/b

    - it would launch another thread to read the incoming data

    - it should show a progress bar for the user

6. What are the possibilities for sending?

    Here are the modules to be divided between shell extension, the service, and perhaps another program:

    - getting the file name  (definitely part of the shell)

    - getting the file handle

    - getting the file data

    - sending the data

    - displaying the progress bar

    possible solutions:

    1. the shell reads and sends the data itself
        - protocol code is in two places
        - two copies of progress code
        + the send path is simple

    2. the shell opens the file, displays progress, sends data to service for transmission
        + a single copy of protocol code
        + all send UI is in the shell extension
        - shell <-> service communication is complex
        - two copies of progress code

    3. the shell opens the file, displays progress; the service reads and sends data
        + a single copy of protocol code
        + all UI is in the shell extension
        - shell <-> service communication is complex
        - two copies of progress code

  * 4. the shell opens the file; the service reads data, sends it, and displays progress
        + a single copy of protocol code
        + a single copy of progress code
        + shell <-> service communication is modest
        - not as simple as 1.

        request sends an array of file names and a destination directory
                receives a transfer cookie

        checkup sends a transfer cookie and an XFER_DATA pointer
                receives data in the XFER_DATA

        close   sends a transfer cookie
                xfer is aborted if still in progress

        E_ADDRINUSE at connect() means the port is bound to another device

tasks:

- convert to Unicode
- create RPC interface
- allow 64-bit file sizes