84 lines
2.6 KiB
Plaintext
84 lines
2.6 KiB
Plaintext
|
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
|
||
|
|
|