Mail Archives: djgpp-workers/2001/09/12/19:05:35
> A patched 2.03 should be tested as well as a 2.04, so either should
> take as much time. Besides, we can always patch (or refresh) 2.04
> after the release, or do a 2.05 with only bugfixes from 2.04.
Proposal:
Create djupd203.zip as update (specific fixes)
Refresh djdev203.zip (replace modules in current libc, new crt0.o)
Rationale:
I want to to the minimum work, solve some problems, create a bridge
solution until the full one is available.
One of the key things in my mind is DJ's point that our libc and
applications are separate (we potententially link the bugs into
every binary - or into no binaries for rarely used modules...).
This means lots of testing on a new release. It can mean little
testing needed for a current build/executable port re-linked with
an updated libc (1-2 modules with 1-2 lines of changes).
I'm sitting on the fence here. Why? I've had lots of good luck with
2.03 on NT 4.0. I've actually had fairly good luck with 2.03 on
Windows 2K once I understood the problems/workarounds. 2.03 is
smaller and faster than 2.04. It's had a lot of field proven testing
in the last 2 years. There are a small handful of 2.03 bugs that
are not W2K specific that I think would be useful as an update
kit for 2.03 users. (Try not to link the known bugs into new images
people are building today). With a 2.03 refresh you could build
W2K/XP ready images today - just like the GCC 3.0.1 binaries in testing.
If we don't provide at least an update for 2.03, we are pulling a
Microsoft - you have to take all my new features (and bugs) to get fixes
for your old bugs. But I don't want to do full testing twice - and
I certainly think it's in the best interest to spend resources on getting
2.04 tested/fixed/released instead of re-releasing 2.03
I would say that the target for a 2.03 update is to make sure new
images for the next 3 months are less buggy/more compatible (not
necessarily to make W2K a good development environment). If you need
a tool chain for W2K you download the test versions (these are
new installs anyway).
There are 4 groups of W2K bugs:
Address wrap (crt0.o)
NTVDM nesting bug (dpmiexcp.c)
Hardware breakpoints (dbgcom.c)
LFN bugs
The first can be seen on NT 4.0 also, and is fixable with a binary patch.
The second can be fixed with an NTVDM patch (W2K only, not XP) new gcc/make.
The third group is only important to debuggers.
The final group can be fixed loading the LFN TSR.
Maybe I'll go back to pretending the problem doesn't exist instead of
pondering what to do about it :-)
- Raw text -