To: simon AT tesla DOT ee DOT mcgill DOT ca ( Simon Chamlian tlf 340-1590) Cc: djgpp AT sun DOT soe DOT clarkson DOT edu Subject: Re: quite confusing Date: Sun, 20 Nov 94 14:25:07 +0200 From: "Eli Zaretskii" > Well you got me REAL confused now! > I downloaded the latest version of DJGPP (i.e djdev112; dif26; > bnu24 gas23; gcc260; gpp260 etc)! > > Than I received e-mails stating that > > > 1) Somebody uploaded a corrected version of stat() and fstat() > library functions for DJGPP. The first version had several bugs > which would crash your machine in DPMI mode. > > 2) Somebody else ported GNU Diffutils 2.6 to DJGPP. > > [snip] > > What is going on????? > > If there are bugs in version 112 of djgpp, how come there is no > maintenance files for this version or is there one that has not > been announced? Last question first: yes, there are maintenance releases for 1.12, two of them--1.12m1 and 1.12m2, they can be found on any SimTel mirror, probably the same one you've got 1.12 in the first place. But they have nothing to do with the uploads which confused you. Those uploads are add-ons to the standard package made by volunteers (I am one of them) to improve on the ``official'' distribution. Things which are broken in the ``official'' distribution indeed get fixed in the maintenance releases, but what about adding functionality? If you see some functionality which is absent in the distribution, and is sometimes required or useful, do you necessarily call it a bug? The new versions of f?stat() make these functions much more compatible with their Unix namesakes, even though in DOS world this is *very* hard to do. The original versions distributed with libc.a aren't broken, they just don't return some fields of struct stat as Unix-born programs expect them (e.g., inode is returned 0). Anybody who ever had to port a Unix program to DOS bumped on the fragment like this: if (stbuf1.st_dev == stbuf2.st_dev && stbuf1.st_ino == stbuf2.st_ino) assume the files are the same; Under DOS this is a bug: the program will think all files on any drive are the same file. These and many other portability-related problems are corrected in that version. DJGPP is not broken here, you will see the same problems in any DOS-based C library. Work is under way to incorporate the improved versions in DJGPP v2.0, but I thought DJGPP community would benefit from these even before that, and so uploaded them to omnigate. The note about bug under DPMI related to the previous version of those same improved functions, not the ones in the current DJGPP library. Diffutils 2.6 on omnigate are a complete port of this GNU package. It includes Diff, Diff3, Cmp and Sdiff, all of them work on both text and binary files. DJGPP 1.12 only includes Diff and Cmp; its Diff loses on binary files, and Cmp thinks all files are the same in the above spirit. The version on omnigate doesn't have these problems. Diffutils 2.7 (released by GNU about a month ago) have a PC/ subdirectory which is still in beta, and so wasn't included in the official 2.7 distribution on GNU ftp site, but anybody who wants to build a full DJGPP version of Diffutils 2.7 right out of the box can ask me and I will mail him the contents of that directory. Hopefully, the next version of Diffutils will have it officially included. Other uploads you've mentioned were done for similar reasons: they try to bring to you things which either aren't included in the standard distribution (like imake) or which improve on them. With all due respect, I don't see how a wealth of free software can be a nuisance, or even a cause of confuse. Every such upload has a README file which explains its rationale and is usually included in the announcement so you don't have to download the package just to see if you need it.