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.