I have tried to compile a simple "hello world" like program.  I have used MSDOS 6.22
together with DOSLFN 0.41 (used options  ~- t+; this means that no numeric tail
will be created).  I have used djdev204, gcc472b, bnu223b and CWSDPMI r7 without
activated swap file.  The system has 64 MB.  The program crashes with the
following stack trace:

   Stack Fault at eip=1902d; flags=3293
   eax=11000000 ebx=00000000 ecx=00000000 edx=00000000 esi=4f575c3a edi=4407712f
   ebp=415c4b52 esp=00000781 cs=e7 ds=ef es=ef fs=cf gs=0 ss=cf error=0000

It makes no difference if I use gcc471b and bnu222br4.  It crashes in the same
way.  If I try to debug the program, I get the following output:

   GNU gdb (GDB) 7.5
   [snip]
   Reading symbols from d:/work/a.exe...Dwarf Error: wrong version in compilation
   unit header (is 0, should be 2, 3, or 4) [in module d:/work/a.exe]
   (gdb) q

The program has been compiled with the following options:
   gcc -Wall -g -O0 1.c

If I remove DOSLFN from autoexec.bat, reboot and recompile the program again
then it runs flawlessly.  Removing DOSLFN and rebooting alone is not enough.
The program must be recompiled without DOSLFN installed at all.
If I use djdev203, gcc472b and bnu223b the produced program runs flawlessly.
Recompiling libc from CVS repository code will not solve the problem.  The new
library make the program crashes in the same way.  It seems to be a new problem
with DOSLFN support by DJGPP.  I have never tested with FreeDOS.

If more information is need, please contact me.

Regards,
Juan M. Guerrero

Does GDB say that even if you remove DOSLFN, reboot, and then try
debugging the program?  If so, I'd suspect file I/O functions that
somehow write corrupted data to the executable.

One way to dig into this would be to run objdump on the binary
compiled with DOSLFN, then on the same program compiled without
DOSLFN, and compare the results.

Once you've established that file I/O under DOSLFN is the problem, I'd
try disabling the LFN DOS calls in functions like _write and see if
that helps.  Or maybe diff the sources of v2.04 against v2.03, and see
which functions had changes in the LFN parts -- this could give you
ideas what functions could trigger a bug in DOSLFN.

Yes, it's a large job, sorry.

Am 11.11.2012 19:49, schrieb Eli Zaretskii:

Yes, GDB says the same even if I remove DOSLFN and reboot the system.
Also the program continues crashing if I reemove DOSLFN and reboot the
system.  The only way to get a program that does not crash and that can
be debuged with GDB is to recompile the code with DOSLFN deinstalled.

Yes, I will follow this strategy, but it make take same time until I will have fixed this

Regards,
Juan M. Guerrero

"Juan Manuel Guerrero" <juan.guerr...@gmx.de> wrote in message
news:509FE38A.9030207@gmx.de...

Why are you using those options?  I've never needed any ...  I'd try it
without them.

Doesn't the ~- option disable finding files with numeric tails also?  I'm
sure that some of the DJGPP files have LFNs largest enough to have numeric
tails for their SFNs.  I.e., it could be a DJGPP file is not being found, or
an incorrect DJGPP file is being found.

Which version of 0.41? 0.41b?  Actually, I have _two_ DOSLFN's that say they
are version 0.41b...  So, what file size too?

Next, I'd try MS-DOS v7.10, if you have it.

I don't normally use DJGPP 2.04, but I have it installed.  If you're still
having problems, can you post the simple "hello world" like program?

To me, that implies that some DJGPP file is not being found.  I'd suspect
the ~- option first, the t+ option second, and MS-DOS version third.

That's strange.

It could be ...

I thought 2.04 was primarily for a Windows XP's DOS console,
and this DJGPP version has not been officially released.

Rod Pemberton

 > > I have tried to compile a simple "hello world" like program.  I have
 > > used MSDOS 6.22 together with DOSLFN 0.41 (used options ~- t+;
 > > this means that no numeric tail will be created).
 >
 > Why are you using those options?  I've never needed any ... I'd try it
 > without them.

I have tried without any of the options but it did not help.

 > Doesn't the ~- option disable finding files with numeric tails also?  I'm
 > sure that some of the DJGPP files have LFNs largest enough to have numeric
 > tails for their SFNs.  I.e., it could be a DJGPP file is not being found, or
 > an incorrect DJGPP file is being found.

May be that it inhibits finding with numeric tails but I have installed my files
with numeric tails disabled (~-) so that all files will be found. My djgpp
installation consists of the following packages:
acnf259b.zip, amak194b.zip, bnu223b.zip, bsh205bbr3.zip, bsn241b.zip,
byacc19b.zip, bz2-106a.zip, bz2-106b.zip, csdpmi7b.zip, dif32br3.zip,
djdev204.zip, djtzn204.zip, dosck11br2.zip, ed-15b.zip, faq230b.zip,
fil41b.zip, flx254b.zip, fnd4233br4.zip, gcc472b.zip, gdb75b.zip,
gdbm110br2.zip, gprf304b.zip, grep214b.zip, gro116b.zip, gwk401b.zip,
gzip15b.zip, h2m1371b.zip, isp3301b.zip, licv112b.zip, lss444b.zip,
lsupp64a.zip, m4-1415b.zip, mak381b.zip, man13b.zip, mktmp17br2.zip,
pat261b.zip, pcre831b.zip, pdcur34a.zip, perl588b.zip, rdln62b.zip,
sed421b.zip, shl2011b.zip, spl312br4.zip, tar112ab.zip, txi413br2.zip,
txt20b.zip, xz-504b.zip, dcrw853b.zip, jas1901b.zip, jbig20b.zip,
jpeg8db.zip, lcms23b.zip, lmpg051b.zip, mgrx100b.zip, png1510b.zip,
tiff401b.zip, zlib127b.zip
The only package that cannot be extracted without having numeric tail
generation enabled is perl, but here only certain man pages collide and I
do not care about this.  I prefer having numeric tail disabled.  The same
I do on my Win98SE installation.

 > Which version of 0.41? 0.41b?  Actually, I have _two_ DOSLFN's that say they
 > are version 0.41b...  So, what file size too?

I have tried the following versions.  I do not remember from where I downloaded
them.  I have only tested using djdev204, gcc472b and bnu223b:

03.07.2004  23:31            19.521 doslfn.com   from doslfnjh-0.33.zip   OK
28.11.2004  15:13            18.705 doslfn.com   from doslfn-0.40.zip     OK
01.03.2005  21:47            18.849 doslfn.com   from doslfn-0.40a.zip    OK
02.10.2006  12:41            18.902 doslfn.com   from doslfn-0.40e.zip    KO
16.12.2011  14:08            16.256 doslfn.com   from doslfn-0.41.zip     KO
05.01.2012  13:31            16.241 doslfn.com   from doslfn-0.41a.zip    KO
07.02.2012  16:43            16.317 doslfn.com   from doslfn-0.41b.zip    KO

 > Next, I'd try MS-DOS v7.10, if you have it.

I have tried Win98SE (I assume it is MS-DOS v7.10) with doslfn-0.41b and worked.

 > I don't normally use DJGPP 2.04, but I have it installed.  If you're still
 > having problems, can you post the simple "hello world" like program?

----------------- start -----------------
#include <stdio.h>

int main(int argc, char *argv[])
{
   int i;
   for (i = 0; i < argc; i++)
     printf("argv[%d]=%s\n", i, argv[i]);
   return i;

----------------- end -----------------

 > To me, that implies that some DJGPP file is not being found. I'd suspect
 > the ~- option first, the t+ option second, and MS-DOS version third.

I have tried all option combinations but they did not work if DOSLFN did not
work with options.  Only those DOSLFN versions I have mentioned above did work
with MS-DOS 6.22.

 > I thought 2.04 was primarily for a Windows XP's DOS console,
 > and this DJGPP version has not been officially released.

2.04 should also work on plain DOS.  There is only a lack of interested
personnel to fix and implement missing features.

Regards,
Juan M. Guerrero

Hi,

That's odd, my personal setup (FreeDOS + /beta/ GCC 4.72 + BinUtils 2.22r4) seemingly works fine with or without LFNs.

But I didn't disable numeric tails, just installed (unzipped) both with and without LFN=n set.

Seems odd, but I've seen a few quirks (hidden bugs) in DOSLFN, so it's not totally surprising. (Actually, I saw some weird redirection bug due to DOSLFN the other day when using a GPC-compiled program, but that's only 2.03p2, which, from below, you say worked fine.)

It could be anything. Even if it's a DOSLFN bug, it may only show up when used in connection with various things.

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/d...

The actual homepage (redirector, goes to ee3web or whatever) of DOSLFN is below, but it never loads for me (times out):

http://doslfn.adoxa.cjb.net/

http://www.freedos.org/software/?prog=doslfn

1). native or emulated MS-DOS? (if so, which VBox version?)
2). cpu family / model / stepping
3). ver /r
4). date, size, md5sum of DJGPP .EXEs used (or quote from .mft / .ver)
5). date, size, md5sum of DOSLFN.COM
6). memory managers loaded (with date, size, version, md5sum if possible), e.g. HIMEM, EMM386
7). try unloading all non-essential TSRs first

Though you may also wish to test (or use as backup) something like StarLFN, who knows:

http://sta.c64.org/starlfn.html

"Juan Manuel Guerrero" <juan.guerr...@gmx.de> wrote in message
news:50A17014.8060106@gmx.de...
...

In the a recent thread on comp.os.msdos.programmer, "cg_chas" had an issue
with VirtualBox for every version of DOSLFN past 0.32o.  Ibiblio has a bunch
of DOSLFN versions.  I uploaded a package of some DOSLFN versions,
specifically those that "cg_chas" didn't have.  The link in the thread is no
longer valid.  Upon request, I can upload the collection again, or any of
the other versions.  You'll have to read the thread for the list of versions
I have and compare yours.  The thread also has some basic LFN test code in C
that I posted too.

https://groups.google.com/group/comp.os.msdos.programmer/msg/2d77f779...

Ibiblio's limited collection of DOSLFN:
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/d...

Rod Pemberton

On 13 Nov., 01:47, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
wrote:

I have inspected my DOSLFN collection and it is identical with that at
Ibiblio
I have only forgot to test doslfnm-0.34.zip.
I will try your test code but I need to read the thread more
carefully.

Regards,
Juan M. Guerrero

On 13 Nov., 00:27, rugx...@gmail.com wrote:

I noted the reported issue first on my Thinkpad T60.  It has
3GB of RAM, T5600 cpu and 4 OSs are installed on different
partitions: MS-DOS 6.22, Win2K SP5, WinXP Prof SP3 and
Linux.  I have cloned the DOS partition and created a
VMware DOS virtual machine on my desktop computer (a linux
only computer).  I use VMware 5.0.0 build-812388 on that
machine (no VirtualBox at all).  The MS-DOS installation is
completely standard as produced by their setup programs.
First MS-DOS 6.2 is installed and later 6.22 is installed.
The virtual machine has 64 MB and himem.sys and emm386.exe
have the following setting (from config.sys):

DEVICE=C:\DOS\HIMEM.SYS /VERBOSE /SHADOWRAM:on /TESTMEM:off
DEVICE=C:\DOS\EMM386.EXE HIGHSCAN I=A200-AFFF I=B000-B7FF I=CF00-CFFF
I=D000-DFFF I=E000-E9FF /VERBOSE /NOEMS /NOVCPI

I also load SMARTDRV.EXE and CTM-DE.EXE but I do not
think that this is of importance.  Neither MSCDEX nor
a CDROM driver is loaded.  In conclusion, this is neither
a hardware nor a VMware induced problem IMHO.  The sample
program crashes in the same way on T60 than on VMware.
The DOSLFN versions I have reported to work for me work
on T60 and on VMware and those that do not work neither
work on T60 nor on VMware.
Just for fun I installed gcc344 and bnu2161 (from /beta).
They are not capable to produce a program when DOSLFN 0.41b
is used (no mather if ~- or ~+ is used).  gcc aborts with:

Reading specs from c:/djgpp-2.04/bin/../lib/gcc/djgpp/3.44/specs
Configured with: /gnu/gcc-3.44/configure djgpp --prefix=/dev/env/DJDIR
--disable-nls --disable-libstdcxx-pch
Thread model: single
gcc version 3.4.4
 c:/djgpp-2.04/bin/../libexec/gcc/djgpp/3.44/cc1.exe -E -quiet -v -
iprefix c:/djgpp-2.04/bin/../lib/gcc/djgpp/3.44/ -remap -imacros c:/
djgpp-2.04/bin/../lib/gcc/djgpp/3.44/djgpp.ver 1.c -mtune=pentium -
Wall -fworking-directory -O0 -o 1.i
ignoring nonexistent directory "c:/djgpp-2.04/bin/../lib/gcc/djgpp/
3.44/../../../../djgpp/include"
ignoring nonexistent directory "c:/djgpp-2.04/djgpp/include/"
#include "..." search starts here:
#include <...> search starts here:
 c:/djgpp-2.04/bin/../lib/gcc/djgpp/3.44/include
 c:/djgpp-2.04/lib/gcc/djgpp/3.44/include/
 c:/djgpp-2.04/include/
End of search list.
<command line>:6885180:46796: c:/djgpp-2.04/bin/../lib/gcc/djgpp/3.44/
djgpp.ver: Value too large (EOVERFLOW)
1.c:1:19: c:/djgpp-2.04/include/stdio.h: Value too large (EOVERFLOW)

This is no surprise.  There were some 0x71NN issues in
djdev204 in those days when gcc344 was build.

The bottom line of all this is what Eli has already pointed
out some days ago: there are some I/O functions in 2.04 that
do not perform well iff LFN support is enabled _and_ the
used OS is neither WinXP nor Win2K.  Fixing this will take
some time and may not be easy.
An inspection of the sample program using objdump shows
that the working binaries are indentical to those produced
on WinXP, Win2k and Win98SE.  Those one that do not work
have only sequence of zeros written in the .text and other
sections of the file.  Neitherless some COFF headers are
written into the file.

Of course, this does not mean that there would not be any
bugs in the different versions of DOSLFN.  If the latest versions
of DOSLFN shall still be usefull on MSDOS they will need
some major fixes.  But there are also some things that need
to be fixed in 2.04.

Regards,
Juan M. Guerrero

"Juan Manuel Guerrero" <juan.guerr...@gmx.de> wrote in message
news:50A17014.8060106@gmx.de...

I didn't see any issues with this.

DJGPP 2.04
DOSLFN 0.41b (16,317 bytes)
MS-DOS v7.10

gcc -Wall -g -O0
DOSLFN ~- t+

Rod Pemberton

On 14 Nov., 10:58, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
wrote:

Yes, you are right.  I have also tested 0.41b on Win98SE
and it works flawlessly.  The problem is not with DOS 7.10
but with MS-DOS 6.22.

Regards,
Juan M. Guerrero

On 12/11/2012 3:42, Juan Manuel Guerrero wrote:

It was a combination of the old MSDOS, DOSLFN chaining and djdev204
not always setting carry before using 71A6 (get file info by handle).
I've released DOSLFN 0.41c to explicitly set carry before chaining.

http://adoxa.3eeweb.com/doslfn/
http://adoxa.110mb.com/doslfn/

--
Jason.

On 11/21/12, Jason Hood <jad...@yahoo.com.au> wrote:

Current v2.04 is supposed to always set carry flag before calling 71A6.
Is the djdev204 in question an old version?

--
O.S.

On 21 Nov., 16:02, Ozkan Sezer <seze...@gmail.com> wrote:

Yes, I tested with the original djdev204 from the /beta directory.
A year ago I committed changes to the repository that explicitly
set the carry flag before every  0x71A6 and 0x7100 call but I must
to have missed something, because even a newly compiled library
did not work with the DOSLFN 0.4[0|1] series of driver.  But it
worked with DOSLFN 0.3[3|4] series.

Regards,
Juan M. Guerrero

On 21 Nov., 13:56, Jason Hood <jad...@yahoo.com.au> wrote:

I have tested both DOSLFN 0.34d and DOSLFN 0.41c and they work
fine.  I have tested using djdev204.zip, gcc472b.zip gpp472b.zip,
bnu2231b.zip and  CWSDPMI r7 without activated swap file all
from the /beta directory on a VMware (64 MB) with installed
MSDOS 6.22 (german version).
I think it was the first time in 5 or 6 years that I was able to
compile
DJGPP's repository sources and build all packages on MSDOS.

Thank you for fixing this.

Regards,
Juan M. Guerrero
Juan M. Guerrero

I can confirm this behavior on my system:
MS-DOS 6.22, djdev 2.04, gcc 4.7.2, bnu 2.23.1, doslfn 0.41b
the compiled file was crashed after loading doslnf - I can see most binary middle of the file was zero bytes - file was corrupted.
Then I installed updated doslfn 0.41c and problem has gone, the compied exe works fine.
Thx for pointing and fixing this bug.

Am 23.11.2012 04:25, schrieb RayeR:

Only for the record: around September 2011 I pointed out that the libc version
build from DJGPP's cvs repository code did not work on MSDOS with some DOSLFN
drivers.  An inspection of the code showed that for all calls to 0x71XX functions
the carry flag was never set before the call was issued.  It concerned the
following C functions with calls to 0x710D, 0x7160, 0x713B, 0x71A1, 0x7147,
0x713A, 0x71A6, 0x716C, 0x7143, 0x7141, 0x714E, 0x714F, 0x71A8 and 0x71A0:

  src/libc/dos/io/flushdc.c,
  src/libcdos/process/dosexec.c,
  src/libc/posix/sys/stat/fixpath.c,
  src/libc/posix/dirent/opendir.c,
  src/libc/posix/unistd/getcwd.c,
  src/libc/posix/sys/stat/mkdir.c,
  src/libc/posix/unistd/rmdir.c,
  src/libc/posix/unistd/chdir.c,
  src/libc/posix/sys/stat/filelen.c,
  src/libc/posix/sys/stat/lfilelen.c,
  src/libc/posix/sys/stat/fstat.c,
  src/libc/posix/sys/stat/fchmod.c,
  src/libc/dos/io/_open.c,
  src/libc/dos/io/_chmod.c,
  src/libc/dos/io/_creat_n.c,
  src/libc/dos/io/_creat.c,
  src/libc/ansi/stdio/remove.c,
  src/libc/ansi/stdio/findfirs.c,
  src/libc/ansi/stdio/findnext.c,
  src/libc/dos/dos/truename.c,
  src/libc/dos/lfn/lfnshort.c,
  src/libc/dos/lfn/_use_lfn.c,
  src/libc/ansi/stdio/_rename.c

The bug was fixed by the patch presented and committed at thread:
<http://www.delorie.com/archives/browse.cgi?p=djgpp-workers/2011/09/28...>

I have checked with all DOSLFN driver versions available at
<http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/d...>
using stock djdev204.zip from /beta directory and a version of libc compiled
from code of the DJGPP CVS repository.  The table below summarizes the result:

   doslfn(m).com  |               md5sum             | beta | repo
-----------------+----------------------------------+------+------
   doslfnjh-0.33  | 84acdb62077edcf9d2f176b36e8b8b57 |  OK  |  OK
   doslfnm-0.34   | a789c9d75fe09e794577f7cdf931aee7 |  OK  |  OK
   doslfnm-0.34d  | 9287f71e0c466a97be9a34779a5ac00e |  KO  |  OK
   doslfn-0.40    | 9564bf067e1187f74dd6b3f79f3177e3 |  OK  |  OK
   doslfn-0.40a   | 6ff5150d55b7e83891ed3772021c23ef |  OK  |  OK
   doslfn-0.40e   | 2832bf3e79d31f4ca3c61fcf471f387f |  KO  |  OK
   doslfn041      | 9d5b5bad0d78e81cae5f4ab9282bec3d |  KO  |  OK
   doslfn041a     | 648ded3978152ee87aec1bc6fca63808 |  KO  |  OK
   doslfn041b     | e69363d404e5d9466f680f7ddd567d50 |  KO  |  OK
   doslfn041c     | 9a3f1b63951737b892d7ed2ca25c5a53 |  OK  |  OK

beta :  gcc472b, bnu2231b and djdev204 from /beta directory.
repo :  gcc472b from /beta directory and bnu2231b rebuild
         using a freshly compiled libc from cvs repository.
The linker must be recompiled with the fixed library or
broken exe files will be created.  For the test program
it was not necessary neither to replace gcc.exe nor as.exe.
This may be not true for larger programs.

Regards,
Juan M .Guerrero

Please could you upload somewhere the latest binary build of libC for 2.04?