Mail Archives: djgpp-workers/2001/09/13/02:40:34
On Wed, 12 Sep 2001, Charles Sandmann wrote:
> 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.
I agree.
> 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.
Right.
> 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
Unlike DJ, I don't think a patched v2.03 needs testing. The only
changes introduced there are (or should be) specific work-arounds for
W2K problems and a small number of specific localized bugs, such as
the one with d0301_s.S. I think we already done all the testing that
these need, since each change was tested on W2K and elsewhere and
proven to work reliably.
So we could simply release a patched v2.03 as soon as the zips are
ready.
> 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).
Even if we start the release cycle of v2.04 today, it won't be ready
in 3 months. It will take more.
> 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.
This is an alternative solution, but I don't think we should recommend
it to newbies. Binary patches are not for the faint of the heart. I
do agree, though, that it will be useful to have this as well in some
separate archive, since this solution is much faster if someone
decides to go that way (no need to rebuild many apps).
- Raw text -