Bug fix in task start/finish lines
A pilot using xcsoar software a few days ago reported a problem with the task startline not being accurate at the borders.
It seems that the error depends on the fact that, as the pilot explains, the start line is not 90 degrees exactly to the target point.
We assume the same can happen with the finish line.

In case the start/finish lines are very big, like 20km long, and the first target point is far away, over 50km, then the error can be measured in some dozens meters.
With shorter start/finish lines, the error is relatively smaller, and become unnoticable.
This problem in fact has been in both softwares for 8 years, and nobody could discover.

The condition to discover the problem, in fact, is to cross the line at the borders, which is a "borderline" condition intrinsecally.
It is risky in any case, because the GPS on LK (or xcsoar) cannot be hold valid in case the position fix is wrong by a few meters, resulting in a no-start or a no-finish.

Anyway, we now reduce a bit the length of these lines, depending on their sizes and distance to next turnpoint.
This is now fixing the calculation problem, but it is nevertheless granting 4 times more marging than a calculation fix, assuming that the pilot that wants to cross the lines at their borders can have a gps which can be even a dozen meters wrong, while turning for example.

Here are some examples computed automatically by LK to make some margins on the borders, depending on the line size and distance to next turnpoint:

LINE LEN  DISTANCE TO NEXT         CORRECTION ON LINE LEN
2 km        25km		      8 m
10 km       20km                     33 m
10 km       60km                     99 m

Which means that if you have a 20km start line (10km on each side of the start point), in that case it will be shortened by 99m on each border for your safety. A glider flying at 120kmh will make 33 meters every second, and the gps is always 1 second late.
For this reason LK will be conservative on the borders, for those that need to cross start of finish risking in any case a false start/arrive.
Update changes, and fix the previous commit typo in the comment> "this is now fixing" should read "this is not fixing..".
Revert "Bug fix in task start/finish lines"

This reverts commit 8a866e0d945f631e1d68b53f108caa631ea38d4b.  This
commit was harmful, because it kludges around with observation zone
sizes, but the bug is not about the size, but about the
orientation/angle.  Not only does this not fix the problem, it also
introduces a new bug.
LKUtils, InputEvents: close the handles returned from CreateProcess()

MSDN says: "Handles in PROCESS_INFORMATION must be closed with
CloseHandle when they are no longer needed."

Fix for a memory leak.
CommandLine: remove unused parameter
lk8000.rc: remove obsolete ACCELERATORS section
wcecompat/ts_string: add missing stdlib.h include

For malloc().
Common/Data/Bitmaps: shrink brush pattern to 8x8

GDI is optimised for 8x8 patterns.  This reduces the time needed for
DrawAirSpace() by 40% on a Dell Axim x51v.  Other graphics
chips/drivers may result in different speedups, however it is safe to
say that 8x8 is the best bitmap size for patterns.
Calc/TaskUtils: fix rounding error in sector angle calculation

A great circle is the shortest path on earth's surface from one point
to another.  A big problem with great circles is that while flying on
one, your bearing will change over time.

Simple example: fly from Canada north (360 degrees) until you pass the
north pole, continue flying straight until you hit Russia.  You are
now heading south (180 degrees), even though you have not turned, and
you are still flying on the very same great circle in the same
direction.

The problem that is addressed by this patch is not so drastic, however
it must be addressed or LK8000 task calculations are wrong.  I fixed
the same bug in XCSoar yesterday, and LK8000 being derived from XCSoar
has been sharing the same bug for quite a few years.

The calculation of symmetric sectors was using the wrong reference,
and therefore was using the wrong angle!

Imagine a task consisting of just one start point and a finish line.
LK8000 determines the orientation of the finish line by calculating
the angle from start to finish .... WRONG!  Wrong because it looks at
the task from the eyes of the start point, but we really want to
calculate the finish line.  Therefore, the reference must the the
finish line.

The error is small (sometimes 0.1% or less for common tasks), but
still it is significant if you miss the finish line by a few hundred
meters.

Thanks to Peter Scholz for noticing the problem and providing sample
data (http://bugs.xcsoar.org/ticket/2209).