Date: Tue, 10 Oct 2000 19:54:26 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: jbfraleigh AT hotmail DOT com Message-Id: <9003-Tue10Oct2000195426+0300-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.5h CC: djgpp AT delorie DOT com In-reply-to: <8rv8tg$3mm$1@nnrp1.deja.com> (jbfraleigh@hotmail.com) Subject: Re: DJGPP, FreeDOS and file access References: <8rkmnt$8sq$1 AT nnrp1 DOT deja DOT com> <8rsftf$rsr$1 AT nnrp1 DOT deja DOT com> <2950-Mon09Oct2000175009+0300-eliz AT is DOT elta DOT co DOT il> <8rv8tg$3mm$1 AT nnrp1 DOT deja DOT com> Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > 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 #include 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.