Mail Archives: djgpp/2011/02/09/23:30:13
> Only with patchlevel 2 (backported from 2.04?) did 2.03 (circa 2000)
> become "stable" on Win2k/XP
The refresh was released in December 2001, over 9 years ago,
and included fixes for many modules to work around NTVDM bugs
in Windows 5. Windows 2000 and Windows XP are very similar and
bug compatible (and claim windows versions NT5.0 and NT5.1).
I haven't used a DOS or Win 9x OS since January 2000, with
the release of Windows 2000. But I still use many DJGPP and
personal applications built with DJGPP daily. v2.03 has been
my preferred djgpp version since the 2001 update. I also use
many apps built with VisualC from VS6 (circa 1997) as native
Win32 console apps. But the RTL support is very poor, so requires
either hacking source or some support routines to port to
the Win32 native environment.
I prefer small, fast images, so avoid tools that contain bloat
(personal definition: always getting features I don't want or need).
So I prefer to use Juan's libsupp with v2.03 when needed to
add the required RTL functional requirements for many
apps written / enhanced since the 1990s. v2.04 just isn't
ready in my opinion for my use - and my djgpp use is now
minimal enough to make it not worth while to be the release
manager to move it from beta to release.
That's been the one and only reason that v2.04 has never
been released - no one has wanted it bad enough to be the
release manager, create a plan, clear the required bugs,
schedule a final release candidate.
But new versions of windows (Vista, 7) are less NTVDM
compatible. 64-bit versions do not support 16-bit
applications (a hardware limitation) - so there is no DOS
to load the stub or to handle DOS interrupts. It's clear to
me that Win32 console apps are the fix for this problem.
Since there are are other compilers that address that area,
I might borrow some of the well debugged, tight DJGPP
code for RTL improvements, but that's it.
I still think djgpp apps are good for embedded systems,
close to the metal diagnosis apps, etc. And until I have to
deal with 64-bit windows every day ... it's still good
enough for the big pile of already built apps.
>P.S. The changes in 2.04 were pretty much CWS' work (right??).
Not at all. The v2.03 refresh was my idea, and I acted as
the release manager on the update. I had several Win 2000
systems used on a daily basis, and the bugs personally bugged
me enough to make sure it worked. I helped work on v2.04
until Andrew quit as release manager.
> (v2.04...) Better support for 4 GB files, better
> memory management (??), symlinks, etc.
There are problems with the APIs for files over 2GB; I'm not
sure this is fixable (maybe it should be pulled out).
free() has a performance bug - which could be fixable
by not trying so hard to merge blocks. The alternate
malloc() is missing functionality and was not stable last time
I saw it tested.
- Raw text -