Mail Archives: djgpp/2000/10/10/14:16:44
> From: jbfraleigh AT hotmail DOT com
> Newsgroups: comp.os.msdos.djgpp
> Date: Tue, 10 Oct 2000 14:26:00 GMT
>
> Borland is doing something different that works. What is it? I
> don't know.
Exactly! The difference between DJGPP and Borland is that Borland's
sources are not freely available. So we can only guess what does
Borland's library do internally.
But we do know what DJGPP's library does, and most people who wrote
the library are available here, in case the docs and the comments
don't explain enough.
So digging into DJGPP's library functions is a much more efficient way
of investigating problems than reporting what the other compilers do.
Especially since sometimes compilation with other compilers requires
subtle changes to the sources, which might make the problem go away
for reasons which have nothing to do with the differences between
the implementations of the offending functions.
The above observations are based on several years of experience in
solving problems like this one over the Internet.
> > People have been asking you all kinds of questions in this thread, but
> > for some reason you preferred not to answer them. Could you please go
> > back and answer those questions?
>
> I like to avoid restating the obvious or throwing out information
> that might lead someone down the wrong path.
Sorry, this is IMHO not the best way to solve such problems. What is
obvious for you is not at all obvious for me and others. We are
asking the questions which seem obvious to avoid the situation where
trivial problems generate long threads which consume valuable time, as
it happened more than once before. Please understand that the obvious
questions are not meant to question your knowledge or abilities. We
simply prefer to put those trivial issues to rest before exploring the
more complicated possibilities. Please bear with us.
> The question "Does the
> file exist?" has come up a few times and I haven't answered it because
> the answer seems obvious (to me, at least). I've stated that it works
> under one environment but not another. To me, this is a good
> indication that the file does exist.
Not necessarily: it is possible that Borland's fopen doesn't fail when
the file does not exist.
> We had discussed possible differences between _dos_findfirst and
> findfirst. I felt that this discussion was leading away from my actual
> problem with "fopen."
Sorry, I don't understand what led you to this conclusion. The
initial report was about both findfirst and fopen; it is quite
possible that the reason(s) for their misbehavior are connected. If
so, solving one of them will solve the other.
The difference between findfirst and _dos_findfirst, when incorporated
in the same program, are IMHO an important lead, a key that could
unlock the problem. We have full sources for both of these functions,
so we can investigate the reason for the different behavior. As
someone who knows something about the library internals, I think that
pursuing this difference might lead quite quickly to the solution of
your problem. I assume that you want the problem to be resolved;
please help me help you do it as best as I can, by trusting my
instincts and experience.
> They may be related, but I think by keeping
> things simple (less variables to deal with), it's often easier to find
> a solution.
We have two functions whose code is quite simple, and which boils down
to calling the same DOS function via Int 21h. It looks like a trivial
debugging session to step through each one of these functions with a
debugger or by adding printf statements, and see where does findfirst
fails, and why. I fail to see any complications and/or multitude of
variables here. It is certainly easier to compare two DJGPP functions
than a DJGPP function with a Borland function: the similarities
between the last two end with their names.
> > IIRC, one of the questions was about possible long file-name support
> > in the version of FreeDOS you are using--if there is such a support,
> > please try to turn it off and see if that works.
>
> I already answered this question in a previous post.. There is no
> LFN support in the version of FreeDOS that I'm using (AFAIK)
What does the following program print on FreeDOS?
#include <fcntl.h>
#include <stdio.h>
int main (void)
{
printf ("LFN is %ssupported\n", _USE_LFN ? "" : "not ");
return 0;
}
Please compile and run this exactly as you compile and run the
offending program, that is, with the same compiler switches (as far as
possible) and in the same drive/directory. If you invoked the
original program from somewhere other than a vanilla DOS prompt,
please invoke the above test program in the same way.
As another thing to try, please set LFN=n in the environment and see
whether findfirst succeeds where it previously failed, and whether the
program with fopen succeeds as well.
> I skipped two questions. One, more of a comment than a question,
> was a link to the FAQ regarding the findfirst not working with kernel
> v2017. As you stated in your last post, this wouldn't seem to be
> related to the fopen problem (unless a call is made to the "findfirst"
> function from the fopen function). It is possible that this has not
> been corrected in kernel v2021 and is the cause of my problem.
I don't think this can explain your problem, since both _dos_findfirst
and findfirst call the same function of Int 21h (unless the library
thinks that long file names are supported, in which case findfirst
calls the LFN-aware function whereas _dos_findfirst does not).
> > Failing all that, please post a complete short test program which
> > exhibits the problem on your machine, so others could try to compile
> > and run it on theirs.
>
> I think the 3 or 4 lines of posted is enough to show what I'm
> doing. I could understand a complete program if what I was doing were
> a little more complex..
Nevertheless, a complete short test program will help. Please
consider making this small effort.
- Raw text -