Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
10 check-ins using file ssh.c version 828ecdc8a8
|
2006-08-29
| ||
| 13:50 | Explicitly closing logctx on various kinds of error exit means that the log file gets fclosed properly and the critical last few messages might be recoverable from the log file more often... check-in: b802bd4ac5 user: simon tags: trunk | |
| 13:32 | The Windows HANDLE type, despite being a `void *', does not actually behave like a pointer. In particular, the right thing to set a HANDLE to to indicate that it's invalid is INVALID_HANDLE_VALUE, not NULL. Crack down on sloppy use of NULL HANDLEs across all Windows code. (There is one oddity, which is that {Create,Open}FileMapping are documented to return a NULL HANDLE instead of INVALID_HANDLE_VALUE on failure. Shrug. If MS want to be inconsistent, I suppose I have to live with it.) check-in: 8c6438590b user: simon tags: trunk | |
| 13:20 | Support for sending serial breaks, in both the Windows and Unix serial backends. check-in: 92fba70907 user: simon tags: trunk | |
| 04:18 | Inhibit the Serial configuration panel in mid-session if the session isn't a serial one. In particular, this causes pterm not to fail an assertion if you select `Change Settings'. Ahem. check-in: 0f9a8f4bb2 user: simon tags: trunk | |
|
2006-08-28
| ||
| 14:09 | Apparently MsgWaitForMultipleObjects doesn't always return the values one might expect, which means that GetMessage() was occasionally blocking the process. That appears to be the last of the annoying data loss issues, so I think the Windows serial back end actually looks vaguely reliable now. Phew. check-in: b83e5fdf72 user: simon tags: trunk | |
| 13:36 | That OVERLAPPED fix seems to have made flow control useful as well (presumably Windows's serial buffer is actually _filling up_, causing an XOFF to be sent, now that my dodgy I/O code isn't causing it to leak). So I think I'll switch the default flow control to XON/XOFF, since it actually seems to do something now. check-in: eca76f8423 user: simon tags: trunk | |
| 13:27 | Eep! Next bit flag after 1 and 2 is _4_, not 3. Perhaps it's time I stopped coding and went and sat down quietly and tried not to touch anything for a while. check-in: 8e09b64fa5 user: simon tags: trunk | |
| 13:26 | Reading 4K at a time from a serial port turns out to be a bit unfriendly in an interactive session, because at 19200 baud it takes nearly two seconds to receive that much data, and as long as the data is flowing continuously Windows waits until it has a full buffer. So here's another annoying flag in the winhandl API, which restricts reads to length 1 so that serial output shows up as it appears. (I tried this yesterday, but without the OVERLAPPED fix in r6826 it behaved very erratically. It now seems solid.) check-in: da46d6cd48 user: simon tags: trunk | |
| 13:16 | Apparently it helps for an OVERLAPPED structure to contain a valid event handle. This seems to have fixed _some_, but not all, of the curious data loss issues in the Windows serial backend. check-in: 51fdd5e6b1 user: simon tags: trunk | |
| 12:47 | Minor tweaks to -nc: - log host:port in event log - add -nc to Plink usage message check-in: 6310d3d2a4 user: jacob tags: trunk | |