From: Max T. W. <ma...@mt...> - 2005-06-27 01:41:09
|
Earnie Boyd wrote: > > On 12:20:04 am 2005-06-27 "Max T. Woodbury" <ma...@mt...> wrote: > > Earnie Boyd wrote: > > > > > > I don't mind that you review any of these but the SUSv3 > > > specifications is what you need to use for comparison. > > > > Fine. I'll google it. > > > > > IIRC, you are using win98 with FAT32. Changes you would make need > > > to keep that in consideration. > > > > Yes. I will not be able to do this alone. At a minimum, I'll need > > to have someone else test things. I'm going to have to learn a lot > > more about SourceForge as well I think. They have a 'compiler farm'. > > Does it include MicroS* thingies? > > > > There are flag bits to test for which system you're coding for. You'll > need to filter the code based on the system type you're executing on. Yep. I've seen those. Are there ones for file system type or is the assumption NT == NTFS and !NT == FATxx. > > If I really have to, I can scrape up a spare drive for my laptop and > > put NT on it. I believe XT needs 128MB of memory or more and this > > poor beast only has 80. > > > > NT 4 or Windows 2000 would be sufficient if they had NTFS file systems. I have NT 4 and XP in hand, just not used, but I do not have a 2K at hand. If I'm going to play with 'em I'll try to put XP up under VMWare. > > > You'll need to explain this better. I'm not sure what you mean. > > > > The document mentioned adding bits and support functions. These have > > to go in before they can be used. However they should not cause > > problems for anything that doesn't use them. Still, once they are > > added, a review should be done to make sure that that assumption is > > correct. > > > > For example, adding a 'directory' bit to the 'fd' structure (I'm > > guessing at the name here - just lazy - I think you can figure out > > what I mean) and adding code that tests for it will have no effect > > until there is some piece of code that sets that bit. Put that one > > piece in the test branch where it can't be picked up by someone by > > accident. The rest can be in HEAD where it will be picked up and > > compiled. That makes sure that the new code at least compiles on > > various systems even if it is never executed. > > > > It sounds as if you expect it to not be coded already which would be a > wrong assumption. MSYS has more than a few lines of code. You'll have to > determine what is missing. A good place to start is looking at the > winsup/cygwin/cygwin.din file which contains the list of exported functions. From the djgpp document outlines quite a few changes to existing routines. I searched for a few of the more important ones to see if they fit the pattern described. All the external interfaces I checked for were there but the quick look at the code showed no awareness of directories in the key places. So I expect that there will be more than a little code to add to stuff that is already there and that it can be safely added in HEAD as long as the piece that would activate the sequence was sequestered in a testing branch, simply not checked in or isolated with a #if ... #endif pair until all the testing is done. (Argh - run on sentence - apology.) And yes MSys has a magnificent amount of code. Much more than I'd care to try to write by myself. However, I read other peoples code fairly quickly. That was the first thing I learned when I started programming. (And it wasn't nice, clean, well formatted and well structured code like yours either. It was a bastard version of 1960s style FORTRAN with rampant GOTOs written by an 'old hand' who learned 'real programming' as a mathematician in the early 50s that I started on!) |