📄 log.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=Windows-1252">
<TITLE>Development log</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
<OBJECT TYPE="application/x-oleobject" CLASSID="clsid:1e2a7bd0-dab9-11d0-b93a-00c04fc99f9e">
<PARAM NAME="Keyword" VALUE="Log, development">
<PARAM NAME="Keyword" VALUE="Development log">
<PARAM NAME="Keyword" VALUE="bugs">
</OBJECT>
<h2><A NAME="log"></A>Development Log</h2>
<h3>A Brief History of Speak Freely</h3>
When I moved to Europe in May of 1991 to help organise
<a href="http://www.fourmilab.ch/autofile/">Autodesk</a>'s
<a href="http://www.fourmilab.ch/autofile/www/chapter2_97.html">European Software Centre</a>,
I realised that one
thing I'd miss is being able to listen in on design
meetings and talk with individual developers without
running up huge phone bills. Autodesk had a dedicated
56 Kb leased line between headquarters in California and
the European Software Centre which was used primarily
for transmitting software updates but which was nearly
idle in the overlap hours between Europe and California.
Since all of our software developers had
<a href="http://www.sun.com/">Sun</a> workstations
which came with audio hardware, I decided to see if I
could put the pieces together so we could talk and/or
broadcast meetings over the leased line. Since raw
Sun mu-law audio requires 64 Kb and I only had 56 Kb
to work with, I hammered in a decimation/expansion scheme
to reduce the bandwidth to 32 Kb. (It remains today, in
a more refined form, as "Simple compression".) I knew
very little about audio encoding at the time--obviously
ADPCM would have been a far better choice, but I was
ignorant of it and I'm not sure a public domain implementation
of it existed in 1991. I first experimented with an RPC
implementation which worked fine over a LAN but was
hopeless over the leased line, which was routed over a
satellite link and had high latency; I finally settled
on UDP as the only viable protocol, a decision
independently reached by the designers of RTP years
later.
<p>
Anyway, the first release of what was then called
NetFone was posted on July 11, 1991. Release 2 was
posted on September 12, 1991 and consisted of cleanups
and bug fixes.
<p>
That's where things stood until Release 3 on December
13, 1994, which corrected some compiler warnings on
the Sun ANSI compiler which replaced Sun's original K&R
cc.
<p>
I didn't really get back into development mode until
the summer of 1995, when I discovered the public
domain implementation of GSM which is still used in
Speak Freely. This, along with Phil Karn's DES (which
I had used in a number of other programs over the
years), and the
<a href="http://www.sgi.com/">Silicon Graphics</a>
audio drivers supplied
by Paul Schurman made up NetFone release 4, posted on
August 2, 1995. This was the first version able to
run on a typical Internet connection as opposed to a
leased line, albeit still limited to Sun and Silicon
Graphics workstations.
<p>
NetFone release 5 followed on August 28, 1995 and added
IDEA encryption as well as fixes to features in release 4.
<p>
Netfone 5.1 was released on September 2, 1995, and
was the first to include a development log file. The program
was renamed <cite>Speak Freely</cite> as of release 5.2 on
September 21, 1995 and all subsequent development is
documented in the Unix development log.
<p>
The Windows version began as a port of NetFone 5 (aka 5.0)
and all development following its initial release on
August 23, 1995 is described in the following Windows development
log. "Features" which were added and later removed after
having been deemed ill-considered are described
in <font color="#808080">grey type</font>.
<h3>Speak Freely for Windows Development Log</h3>
<P><B>23 August 1995</B>
<P>Initial announcement of Speak Freely Release 5.0.
<P><B>24 August 1995</B>
<P>Peter Claus Gutman, developer of a very nice encryption
library, wrote to suggest his library might prove useful. In
the source code for the library, I found a clever 80x86
assembly-language implementation of IDEA, made freely available
by its author, who is identified in the source code only as
"Bryan". Whoever you are, Bryan, great piece of work! If you,
or somebody who knows who you are, happens to read this, let me
know so I can give complete attribution.
<P>I integrated the assembly language loop into IDEA\IDEA.C,
modifying it slightly to work with Microsoft Visual C's inline
assembler, so you don't need a separate assembler to take
advantage of the optimised code. Whether the assembler or
original C code is used depends upon whether USE_ASM is
defined, so you can use the original loop for reference or if,
for example, your compiler doesn't support inline assembly code
or is incompatible with the way Microsoft do it.
<P>Enabling the assembly language code increased the speed of
IDEA encryption and decryption on my 486/50 machine from
152,000 bytes per second to 242,000 bytes per second--well
worth the trouble of integrating the code.
<P><B>30 August 1995</B>
<P>Completed a massive revision to avoid all packet
fragmentation and thus work with WINSOCK drivers such as
Trumpet WINSOCK. The changes were so great and ubiquitous
there's no point in trying to describe them. In debugging the
changes, one of the mysteries that has been dogging me was
finally solved--the random hangs, loss of synchronism, failure
to release resources, etc. etc. etc. were the result of Windows
discarding messages to the main window as a result of overflows
of the default 8 message queue. Speak Freely juggles a lot of
balls in the air at once, and it's very easy to hit this
limit. At initialisation time, we now try to expand the queue
to its maximum size of 120 messages or whatever lower maximum
the system we're running on supports.
<P>Added the "Extended Status" (Propeller Head) dialogue.
<P>Made compression modes global rather than per-connection.
This means compression only has to be done once, which speeds
up party line transmissions. The change is necessary in any
case so that packet size can be optimised.
<P><B>1 September 1995</B>
<P>Update release 5.1.
<P><B>8 September 1995</B>
<P>CreateSocket() in UTILITY.C contained a "defensive bind()" to
address zero as a work-around for some defective WINSOCK implementations.
Unfortunately, this work-around causes other TCP/IP stacks, including
that built into Windows NT to fail. I made the nugatory bind conditional
on a new Options/Workarounds/Always Bind Socket menu item which is, of
course, saved in the .INI file.
<P>Update release 5.1a.
<P><B>9 September 1995</B>
<P>Discovered that the reason the socket write was failing on
Windows NT and Windows 95 is that Microsoft's built-in WINSOCK,
entirely incompatible with Unix and every other WINSOCK I have
encountered, refuses sendto() once a datagram socket has been
connect()ed. The sole function of connect() on a datagram
socket is to specify a default address so subsequent writes can
be done with send() (or, on Unix, write()), and there is no
prohibition of overriding this default address with a
subsequent sendto(). The WINSOCK specification nowhere
mentions such a restriction as a Windows-specific change. I
modified the socket write code in CONNECT.C and the loop-back
socket write in FRAME.C to first try sendto(). If it fails,
send() is then tried and if that works all subsequent socket
writes for the rest of the session are done using send(). This
code has been verified to work on both Windows NT and Windows
95 (first customer shipment edition). Special thanks to John
Deters who both identified the source of this problem on
Windows NT and tested innumerable versions slowly converging
toward the actual fix.
<P>Added an item to the Propeller Head dialogue to indicate
whether sendto() or send() is being used to write to outbound
sockets; it's "Sending with" in the "Network" box.
<P>Tested with the WINSOCK implementation included with Sun
PC-NFS 5.1. Works fine.
<P>Update release 5.1b.
<P><B>10 September 1995</B>
<P>After last week's experience I decided to indulge in some
preemptive workarounds for crummy network and sound card
drivers which fail in obvious ways which haven't bitten me
yet. I expanded the Options/Workarounds menu to include:
<blockquote>
<dl>
<dt>Audio
<dl>
<dt>Assume Half-duplex
<dd>Assumes the sound card is half-duplex without
requiring it to fail an output open while input is open.
Accommodates cards which are actually half-duplex but don't
indicate this by failing a simultaneous input and output open.
Also handles cards which crash the system or application when
you try to open them in full-duplex mode.
<dt>Assume 11025 Samples/sec
<dd>Assumes the card is capable only of 11025 samples
per second mode, not our preferred 8000 samples per second.
Permits correct operation on cards which don't fail when opened
with a sample rate of 8000 samples per second but which can't
actually run at that rate.
</dl>
<p>
<dt>Network
<dl>
<dt>Always Bind Socket
<dd>As before; bind outbound sockets, even though
there's no need to do so.
<dt>Never Connect Outbound Socket
<dd>Don't connect() the output sockets. This implies
we'll always use sendto() to write to those sockets. Clears
"Use send(), Not sendto()" mode if set.
<dt>Use send(), Not sendto()
<dd>Always use send() to write to outbound sockets;
don't wait for a sendto() to fail first. Accommodates drivers
where a sendto() on a connected socket crashes the application
or system. Clears "Never Connect Outbound Socket" mode if
set.
<dt>Multicast TTL Argument Is char
<dd>Certain Winsock implementations by a
<I>soi-disant</I> "setter of standards" headquartered east of
Seattle, Washington in the United States flagrantly ignore the
long-established convention that Boolean arguments to multicast
setsockopt() calls are of type int. Their code errors such
requests with a "bad address" fault, and accept them only if
the argument is passed as a character (incompatible with
Unix). This workaround is set if we empirically discover this
to be the case on the system on which we're running, and can be
set by the user to preempt dastardly behaviour by systems that
don't have the courtesy to inform us of their incompatibilities
with contemporary community standards.
</dl>
</dl>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -