X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
MIME-Version:	1.0
Newsgroups:	comp.os.msdos.djgpp
Date:	Tue, 13 Nov 2012 12:00:15 -0800 (PST)
Complaints-To:	groups-abuse AT google DOT com
Injection-Info:	k20g2000vbj.googlegroups.com; posting-host=149.172.142.54; posting-account=OsAajgoAAADdKJnkJkmhzqP0jo6I_P_0
NNTP-Posting-Host:	149.172.142.54
References:	<509FE38A DOT 9030207 AT gmx DOT de> <ace3a982-aef0-4e96-a282-c7ab0a587238 AT googlegroups DOT com>
User-Agent:	G2/1.0
X-HTTP-UserAgent:	Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.0,gzip(gfe)
Message-ID:	<c2a983a4-59fe-4e3c-86e4-2b91702bdbd5@k20g2000vbj.googlegroups.com>
Subject:	Re: Difficulties using DJGPP 2.04 together with DOSLFN 0.41 on MSDOS 6.22
From:	Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
Injection-Date:	Tue, 13 Nov 2012 20:00:15 +0000
X-Received-Bytes:	5154
Bytes:	5306
Lines:	87
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

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

> > If more information is need, please contact me.
>
> 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


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

- Raw text -