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> 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: Subject: Re: Difficulties using DJGPP 2.04 together with DOSLFN 0.41 on MSDOS 6.22 From: Juan Manuel Guerrero Injection-Date: Tue, 13 Nov 2012 20:00:15 +0000 Content-Type: text/plain; charset=ISO-8859-1 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. :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