www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/10/10/10:45:18

From: jbfraleigh AT hotmail DOT com
Newsgroups: comp.os.msdos.djgpp
Subject: Re: DJGPP, FreeDOS and file access
Date: Tue, 10 Oct 2000 14:26:00 GMT
Organization: Deja.com - Before you buy.
Lines: 72
Message-ID: <8rv8tg$3mm$1@nnrp1.deja.com>
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>
NNTP-Posting-Host: 209.101.83.36
X-Article-Creation-Date: Tue Oct 10 14:26:00 2000 GMT
X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)
X-Http-Proxy: 1.0 PROXY, 1.0 x56.deja.com:80 (Squid/1.1.22) for client 209.101.83.36
X-MyDeja-Info: XMYDJUIDjbfraleigh
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com


> It is not really relevant to tell what other compilers do, because it
> might as well be the bug in the other compiler.

   I disagree with this statement.  You need to establish a baseline
for testing.  There are two components here - The OS and the compiler.
I should be able to write some ANSI C code and have it function the
same way on any OS and with any compiler.  If this code fails, on any
combination of OS or compiler, then there's a problem.  The fact that
it works with Borland's compiler is something that can assist in
discovering why it doesn't work with DJGPP.  It might be a bug with
Borland's compiler, but Borland is doing something different that
works.  What is it?  I don't know.

> 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.  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.  For the record, though, the file
does 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."  They may be related, but I think by keeping
things simple (less variables to deal with), it's often easier to find
a solution.

> 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)

> There were other questions, as far as I remember.  Please reread the
> thread and try to answer them.  It is very hard to help you if
> questions are ignored.

   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.

   The other was asking whether I had tested under MSDOS.  I've tested
this program under IBM DOS 5.02, RxDOS and a Windows 98 DOS boot disk.
It's worked under all environments except for FreeDOS.

> 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..


   I appreciate the help that I've received... It's either a FreeDOS
issure or a DJGPP issue, I'm not sure which.  Apparently this isn't
something that a lot of other people have run into.



Sent via Deja.com http://www.deja.com/
Before you buy.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019