Mail Archives: opendos/2000/07/13/18:52:19
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: <Matthias DOT Paul AT post DOT rwth-aachen DOT de>
Web : http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html
-------------------------------------------------------------------
- Raw text -