Hi Juan, It is still not fully clear to me how different DOS differs regarding the "arguments passed to batch" situation... Even if 4DOS solves it, what exactly is the difference in style?
>> The only one I'm aware of is the "read from NUL" bug, which Jeremy >> already fixed in his unofficial Git snapshots. (Yes, for some reason, >> DJGPP insists on reading from that, heh.) >> >> http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-workers/2014/03/28/16:38:35 Interesting. > Until now I was not able to compile any DJGPP port of GNU projects except > for ed-110s.zip. The reason for this is that it is probably the last GNU > project that does not use the AUTOCONF/AUTOMAKE generated configure scripts. It is quite normal that you have to adjust things when making a port: It is rare that a Linux tool source code simply compiles in DJGPP to make a working DOS port... > I was not able to configure any of the contemporaneous GNU programs like m4, > bison or grep. If you cannot find a sufficiently up to date autoconf or automake, you can start by porting one or, probably often easier, manually adapt makefiles instead of autoadapting. > 1) The "read from NUL" bug. > Yes this is a bug due to 2 reasons. > a) If a command like this: > program.exe < NUL > is not forbidden it is allowed. AFAIK, microsoft has not published > any documentation that states that reading from NUL is not defined. > b) If it works with microsoft dos kernels it should work with FreeDOS So what is the desired behaviour of program.exe < NUL and what is the current FreeDOS behaviour? I remember that the topic had some ambiguity but I think as long as it is not breaking something else, mimicking Microsoft sounds better. > Last but not least it is not DJGPP that insists on reading from NUL. > DJGPP is only used to run script/programs developed for posix. > > Please note I am very happy to know that this issue has already been fixed > but as a newbie to FreeDOS is it of no practical use to me to know that > the > fix is in some local GIT repository. As a newbie or average FreeDOS user I assume Jeremy has some "daily build" style pre-compiled kernels and command.com that you can download somewhere? > 2) Long file name support. > LFN support is an absolute must-have for contemporaneous software > development. > The times of 8+3 file name restrictions are long gone. In any case, many GNU source codes use long file names to name the source files, so LFN is a very good thing to have. > Of course, I am aware of the existence of DOSLFN-like TSRs and I have > installed DOSLFN 0.41c on my MSDOS 6.22 machine and also on the FreeDOS > installation. Neither less this is of no practical use except for the > fact the TSR creates LFNs. IMHO, if the LFN support would be integrated > into the kernel it would become much faster and thus of real practical > use. Not really: Many of the tricks used by Microsoft to make LFN fast, such as keeping most of the data in RAM while Windows is running, or specific algorithms, are patented, which probably prevented the DOSLFN authors to use those. > For the checks I am using my Thinkpad T60 with MSDOS 6.22 installed on a > 2G > partition formatted with FAT. On another partition WinXP SP3 is > installed (NTFS). > I have unzipped on both operating systems the DJGPP port of binutils (aka > bnu224sr2.zip). On WinXP it tooks 2:22 minutes and on MSDOS it tooks > 52:30 minutes. I think FreeDOS users (having modern hardware) often use the trick to compile in a RAMDISK or in a DOSEMU window in Linux, to have much faster filesystem access. Also, it is not necessary to load extra drivers for LFN in DOSEMU as far as I remember, as it makes Linux directories show up in DOS as magic "network" drives with long file names. An idea: Have you checked if LFNDOS is faster than DOSLFN? > On MSDOS I was not able neither to configure nor to compile the binutils > port. Unfortunately, GNU software now often has a focus on Linux, so people neglegt maintaining their ifdefs for DOS, if they had them at all in the first place. Even autoconf/automake itself obviously has this issue. > It was clear to all DJGPP developers in those days when Win2K and WinXP > rised > that DOS was dead and that if DJGPP should survive the primary target had > to > be NTVDM and no longer pure DOS. Not really - to compile for Windows, MinGW / Cygwin are more obvious choices. So while for writing the DJGPP compiler, it was convenient to use Windows, DJGPP itself has the clear aim to produce programs that you can run in DOS, quite well :-) > I am aware that introducing LFN support into the kernel may break backward > compatibility with MSDOS. But in that case the backward compatibility has > already been broken long time ago by the introduction of FAT32 support. Not necessarily. Also, you can compile FreeDOS without FAT32, which also makes the kernel a few kilobytes smaller. As said, making LFN fast is the complicated part, in particular if you do not want to buffer possibly megabytes of data to speed up. By the way, I hope you did already use UIDE or LBACACHE or in MS DOS SMARTDRV with sensible settings to gain speed? LFN with no disk cache at all is expected to have very bad performance. > 4) The AUTOTOOLS generated configure scripts try to execute bash and the > script > like this: > exec /dev/c/djgpp-2.03/bin/sh ../configure > --disable-dependency-tracking --disable-nls --enable-install-bfd > --enable-install-libiberty --with-mpc=/dev/env/DJDIR > --with-mpfr=/dev/env/DJDIR --with-gmp=/dev/env/DJDIR > --enable-build-warnings=-Wimplicit,-Wcomment,-Wformat,-Wparentheses,-Wpointer-arith > This line fails for DJGPP 2.03 and 2.04. I still have not figured out > what The line is longer than DOS itself supports, so it only works if one of the DJGPP or other mechanisms to transport longer command line arguments works out inside your autotools script. If your script is a BASH script instead of a BATCH script, or if it is a CMD file, other factors may apply here. > is failing here. On Win98SE and WinXP this works flawlessly. Also with COMMAND.COM or only with CMD.EXE? > Although I will continue investigating all these and future issues I have > conclude that it will be very unlikely that FreeDOS can be recommended as > a substitute for WinXP and/or Win98SE to porting contemporary GNU software > to DOS. Using a cross-compiler will be the more efficient approach although > debugging will become difficult. Sure. If you have other systems, you can easily use them and still use the resulting binaries in DOS. For example you can also have multiple text editor windows open while working on the source code in Windows or Linux. Debugging can still take place in a DOS window or VM. If you do want to do 32 bit, protected mode, debugging in plain pure DOS: 386SWAT might be a nice and free tool for you :-) Also, a special debugger is provided as part of Bochs and Dosemu. Regards, Eric ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
