From: "Matthias Paul" Organization: Rechenzentrum RWTH Aachen To: opendos AT delorie DOT com Date: Thu, 13 Jul 2000 18:20:33 +0100 Subject: Re: Again about NTFSDOS X-Confirm-Reading-To: Matthias DOT Paul AT post DOT rwth-aachen DOT de X-pmrqc: 1 X-mailer: Pegasus Mail v3.22 Message-ID: Reply-To: opendos AT delorie DOT com On Sun 9 Jul 2000 Pavel V. Ozerski wrote: > One author answered that this utility is developed only for MS-DOS, > the second also took this information into consideration but did > nothing to fix problem Hm, the NTFSDOS documentation states that DOS 5.0+ is needed, no word of MS-DOS, no hint that it won't work on DR-DOS. So this seems to be a rather cheap excuse, especially since DR-DOS is not a loose DOS-wannabe like some embedded OSes, but has reached a degree of compatiblity that is of the same level as several issues of MS-DOS are compatible with each other. As we see there may be problems, but there are also problem, when someone writes an application or driver and only tests it on one issue of MS-DOS and then wonders why it may not work properly with previous or later issues of MS-DOS. Applications change, operating systems change, and they must have some means to adapt to each other. That's why there are version numbers. ;-) I ran a few tests with NTFSDOS 0.9, 2.01, 2.02 and some more comprehensive tests with NTFSDOS 3.0R (as of autumn 1999) under DR-DOS 7.03. At least with 3.0R I was partially able to CD and DIR on NTFS 4.0 partitions, however, I encountered a number of problems, e.g. sometimes endless garbadge is showing at the end of larger dir listings, only absolute paths are working e.g. CD M:\TEMP, DIR M:\TEMP\*.*, not CD TEMP, or DIR *.*, and the behaviour seems to depend on which other drivers I loaded in the test configuration, the load position of the NTFSDOS driver???, and the shell I was using (I tried COMMAND.COM and 4DOS 6.02B). I have not run actual debug sessions as I think this is much easier to achieve for those who have the NTFSDOS sources. However, there seems to be a pattern and I assume that the problem is either with relative/absolute paths or with findfirst/findnext wildcard handling through the redirector interface, which is fully supported by DR-DOS (networks work, MSCDEX works, NWCDEX works, Corel CDEX works, DRFAT32 works...). >May be, I must try to contact again? I could to try to do it, >but I think, it would be better if this letter was from Caldera >or even if from another DR-DOS user? I would suggest to try it again. Feel free to forward this letter to them. Obviously I cannot speak for Caldera or Lineo, but if they want to go into it, they can get my (limited) personal support regarding how to properly setup up DR-DOS for testing (they can also have ready-to-go prepared boot floppy images from me), and if questions arise, they can also address questions regarding kernel implementation details to me (I think know it quite well as I have worked on it for a few years). If there's something to improve in DR-DOS, I want to know about it, although - let's be realistic - regarding the past and currently shipping issues of DR-DOS, the only way to fix the problem is to address the problem in NTFSDOS, not in the DR-DOS kernel. I'm sure, it will not be much effort for them to adapt NTFSDOS to work with DR DOS 5.0 (when the redirector interface became fully functional in the kernel) - 7.03. >but if someone (who knows good the DR-DOS kernel) will discuss my >results while this "research" and help to find cause. May be, the >good values (parameters) of FILES, FASTOPEN, SHARE etc could help >to force NTFSDOS to work correctly on DR-DOS. I will try to help, but I don't think FILES, FASTOPEN, SHARE and the like are causing this, because they have nothing to do with the redirector interface. >But generally, if one utility has problem with DR-DOS, that points to >possibility of similar problems by using of other system utilities. >Therefore it could be very important, to find the cause of this >problem. 100% agreed. But this holds true for both, the operating system *AND* the applications/drivers. It is a general rule of professional software development to test it on as many different configurations as possible. If the test bed is various applications/drivers running on the operating system or various operating system implementations serving an application/driver etc. is just a matter of the point of view (and if you're the developer of the application or the OS ;-) In either case, it makes your product more robust. BTW. This reminds me of a discussion I once had with a support guy from SymBIOS (now LSI) regarding a problem I encountered in their SDMS 4.xx. I clearly pointed them to the bug I had isolated in their software (and a 3 line fix in assembler), but they didn't believed me, because I was running my tests on DR-DOS not MS-DOS... In fact, it worked on MS-DOS, but as could be clearly seen, only because they had luck, that something like an uninitialized variable (actually it was a bit more complicated) happend to "randomly" have "good" values on MS-DOS and also "randomly" unexpected values on DR-DOS. He said, they would only support MS-DOS and "other DOSes would not be DOS", and since I was not using MS-DOS, the bug must per se be on my side. For what reasons ever, if this is a company's support philosophy you're stuck... ;-) Matthias ------------------------------------------------------------------- Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany eMail: Web : http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html -------------------------------------------------------------------