Re: [Freedos-devel] Two remarks about FreeDOS 1.3 RC5
Am Sun, 26 Dec 2021 11:25:22 -0500 schrieb Jerome Shidel : > Hi, > > > The second issue is that the DJGPP port of lynx distributed with > > RC5 is broken. As I have announced in: > > https://www.delorie.com/archives/browse.cgi?p=djgpp/2021/12/02/18:54:50 > > the fixed port is available as: > > http://ftp.delorie.com/pub/djgpp/current/v2tk/l290d10b.zip > > http://ftp.delorie.com/pub/djgpp/current/v2tk/l290d10d.zip > > http://ftp.delorie.com/pub/djgpp/current/v2tk/l290d10s.zip > > Please note the time stamp of 2021-11-30 or later for the zip files. > > Please use the fixed port in your distribution so I do not get bug > > reports about things that have already been fixed. > > > > Kind regards, > > Juan M. Guerrero > > I was going to update our version now. However, the site appears to > be down at present. > > Jerome > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel Hello. I can access the site without any issues at all but anyway an alternative location is: ftp://ftp.fu-berlin.de/pc/languages/djgpp/current/v2tk/l290d10b.zip ftp://ftp.fu-berlin.de/pc/languages/djgpp/current/v2tk/l290d10d.zip ftp://ftp.fu-berlin.de/pc/languages/djgpp/current/v2tk/l290d10s.zip If for some reason this also does not work, then you can check for a set of djgpp mirrors at: http://www.delorie.com/djgpp/getting.html Kind regards, Juan M. Guerrero ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Two remarks about FreeDOS 1.3 RC5
I have been playing with the latestet FreeDOS 1.3 RC5 and I have observed that the line: if exist %dosdir%\LINKS\NUL set PATH=%path%;%dosdir%\LINKS in FDAUTO.BAT does not work because LINKS and all the other network stuff is installed in the C:\NET directory and not into the directory pointed by %dosdir%. E.g.: LINKS is installed in the directory C:\NET\LINKS. Thus the above line in FDAUTO.BAT will never work. Either the NET directory is removed and its content is moved into %dosdir% or the above line is adjusted accordingly so it points to C:\NET. The second issue is that the DJGPP port of lynx distributed with RC5 is broken. As I have announced in: https://www.delorie.com/archives/browse.cgi?p=djgpp/2021/12/02/18:54:50 the fixed port is available as: http://ftp.delorie.com/pub/djgpp/current/v2tk/l290d10b.zip http://ftp.delorie.com/pub/djgpp/current/v2tk/l290d10d.zip http://ftp.delorie.com/pub/djgpp/current/v2tk/l290d10s.zip Please note the time stamp of 2021-11-30 or later for the zip files. Please use the fixed port in your distribution so I do not get bug reports about things that have already been fixed. Kind regards, Juan M. Guerrero ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Broken pipe and file descriptor behavior of the kernel distributed by FreeDOS 1.3 RC1
I have noted that FreeDOS 1.3 RC1 distributes a kernel 2042. This kernel
seems to have serious issues concerning the redirection of file descriptors
and the creation of pipes. I noted this when I tried to use the djgpp
port of Bash 4.17 on FreeDOS 1.2 and later on FreeDOS 1.3 RC1. I use it
to configure gnu packages that I want to port to DOS. An example of a
failing shell script snippet looks like this:
ac_subst_vars='am__EXEEXT_FALSE
am__EXEEXT_TRUE
SHELL'
{
echo "cat >confsubs.awk <<_ACEOF" &&
echo "$ac_subst_vars" | sed 's/.*/&!$&$ac_delim/' &&
echo "_ACEOF"
} >confsubs.sh1
As can be seen the output shall be redirected to a file and certain values
are modified by piping them to sed which output also goes to the output file.
If this script is run by the bash port on MS-DOS 3.2 it looks perfect like
this:
cat >confsubs.awk <<_ACEOF
am__EXEEXT_FALSE!$am__EXEEXT_FALSE$ac_delim
am__EXEEXT_TRUE!$am__EXEEXT_TRUE$ac_delim
SHELL!$SHELL$ac_delim
_ACEOF
but if I do the same on FreeDOS I get the following output:
am__EXEEXT_FALSE
am__EXEEXTam__EXEEXT_FALSE!$am__EXEEXT_FALSE$ac_delim
am__EXEEXT_TRUE!$am__EXEEXT_TRUE$ac_delim
SHELL!$SHELL$ac_delim
_ACEOF
As can be seen input and output streams get mixed and thus no shell scripts
that depend on redirections of file descriptors and on pipe lines can be run
successfully on FreeDOS.
I have attached 2 small programs in pipe_issue.zip that will reproduce the
situation. The b.c program does the bash job by redirecting stdout to a file
and then doing some printing to stdout. Then a pipe is created and the second
program (aka s.c) is spawned. s.c shall do the job of sed, this means read
from stdin that comes from the read end of the pipe, do some changes to lines
read and write the modified lines to stdout and thus into the file created by
b.c. The djgpp compiled versions of these programs write the following text
to the redirected stdout on MSDOS:
= prolog =
first line to stdout
middle line to stdout
last line to stdout
= epilog =
that then is piped to s.c and modified in this way:
= prolog =
1st line to stdout
2nd line to stdout
3rd line to stdout
= epilog =
On all tested FreeDOS versions the absolute identical text get corrupted
in this way:
first line to stdout
middle lin1st line to stdout
2nd line to stdout
3rd line to stdout
= epilog =
Here again the input and the output streams seems to get mixed some how.
Only for the record, neither my sample programs, nor the bash port, nor djgpp
contain any bugs that are responsable for this behavior. This is a FreeDOS bug.
I have tried to fix this issue in the kernel, thus I have download
freedos-svn-r1835-kernel-trunk
and compiled the binaries for 8086 and FAT16. Nothing else tried and I was
absolutely surprised that the compiled kernel did not failed at all. The bash
port worked flawlessly with that new kernel, thus the question arises:
why a broken kernel is distributed with a release candidate? The distributed
kernel version and thus FreeDOS 1.3 is almost useless to run any serious djgpp
applications. Is this intentional? If more information is required, please let
me know.
Regards,
Juan M. Guerrero
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define INPUT "= prolog =\n" \
"first line to stdout\n" \
"middle line to stdout\n" \
"last line to stdout\n"\
"= epilog =\n"
struct pipe_t
{
int fds[3];
char *name;
};
static struct pipe_t dos_pipe;
#define READ_END 0
#define WRITE_END 1
#define BACK_UP2
#define IS_CLOSED(FD)(dos_pipe.fds[READ_END] == -1 && dos_pipe.fds[WRITE_END] == -1 && dos_pipe.fds[BACK_UP] == -1)
#define SWITCH_MODE(FD) (dos_pipe.fds[READ_END] != -1 && dos_pipe.fds[WRITE_END] == -1 && dos_pipe.fds[BACK_UP] == (FD))
#define PIPE_FOUND(FD) (dos_pipe.fds[READ_END] == (FD) || dos_pipe.fds[WRITE_END] == (FD) || (IS_CLOSED((FD)) \
|| (dos_pipe.fds[READ_END] == -1 && dos_pipe.fds[WRITE_END] == -1)) && dos_pipe.name)
struct stream_t
{
char *buffer;
size_t size;
size_t end;
size_t start;
};
static struct stream_t buffered_stream;
int
restore_std_fds(int std_fds[3])
{
int i;
for (i = 0; i < 3; i++)
{
if (std_fds[i] > -1)
{
if (dup2(std_fds[i], i) < 0)
{
fprintf(stderr, "redirection error: cannot restore %d", i);
return -1;
}
close(std_fds[i]);
std_fds[i] = -1;
}
}
return 0;
}
int
save_std_fds(int std_fds[3])
{
int i;
for (i = 0; i < 3; i++)
{
if ((std_fds[i] = fcntl(i, F_DUPFD, 20)) < 0)
{
fprintf(stderr, "redirection error: cannot duplicate %d", i);
return -1;
}
}
return 0;
}
void
remove_pipe(int fd)
{
if (PIPE_FOUND(fd))
{
int
Re: [Freedos-devel] Getting ready for FreeDOS 1.2
Am 22.10.2016 18:08, schrieb Jerome E. Shidel Jr.: Hello Jerome and all the other interested ones, [snip] > What host OS are you using? openSUSE 11.4 > If you booted the CD under VMware and installed FreeDOS, > are you still booting the El Torito CD? Yes. I forgot to unmount it. Now I have disconnected the CD image from the machine and repeated the experiment but the outcomming is the absolutely the same. > Are you running the latest Version of VirtualBox (5.0.28)? No. I have _never_ run any version of VirtualBox. I have used VMware Player 5.0.2 build-1031769 _only_. > Have you made major changes from the default VirtualBox settings? The settings of the WMware Player are: 1 processor 64 MB ram 2 GB HD No CD mounted No floppy mounted Everything else are default settings that the Player selects. I have tried one time using only 4 MB of ram but it had no influence. > Have you modified the boot configuration of FreeDOS and is something > conflicting? No. The only thing I selected was that only the base packages shall be installed. I have used german as installation language all the time. No editing neither of fdconfig.sys nor of autoexec.bat at all. I am using the virtual machine as it is. When the machine is booted, the first boot option is used. I have never tried any other. > Are you sure the actual floppy image is a valid size, exists and is writable > by the host OS? Yes, I can do: dd bs=512 count=2880 if=/dev/zero of=rawfloppy.img or dd if=test.img of=rawfloppy.img rawfloppy.img is the image created by the virtual machine. If test.img has a file system then rawfloppy.img can be read by FreeDOS. The raw floppy image is created by VMware player by selecting the corresponding "create" command. For the VMware Player this is: "Edit virtual machine settings" --> Hardware-tab: floppy --> Connection: "Use a floppy image" --> "Create..." The create command does not allow to select or change the size of the image. Or at least I do not know how. It creates a raw 1.44 MB image. This image can be formated with MSDOS-6.22, Win98SE, Win2K-SP5 and WinXP-SP3. This means that I am running different virtual machines created with the same VMware Player and this Player creates the raw image. If I use the format program from FreeDOS, this is "format /d a:" then the image gets ruined and cannot be formated by any of the previously stipulated microsoft OSes. If I boot the MSDOS-6.22 virtual machine I am capable to mount and fix the image using my old Norton Utilities. After that the image can be formated by MSDOS again. Of course there is nothing particular about Norton, there are certainly thousends of other disk tools that will fix the floppy. > (maybe download the FD12FLOPPY.zip and try formatting it’s image) I have done this and it formats flawlessly. But this is not a surprise at all because it is not a raw floppy but a formated one. For an already formated floppy, the FreeDOS "format /d a:" command always works. But if I take that one and ruin the first couple of sectors with the command: dd bs=512 count=2880 if=/dev/zero of=FLOPPY.img then "format /d a:" fails miserably. It remains a fact, that a raw floppy created by VMware Player 5.0.2 build-1031769 can be formated by any format program of the microsoft OSes I have tested. This means that both "format a:" and "format /u a:" work without problems. But a raw floppy created in the same way by the same virtual machine can only be formated using the "format /u a:" command but not "format a:" command when the FreeDOS format program is used. If the command: dd bs=512 count=2880 if=/dev/zero of=FLOPPY.img is run neither of both MSDOS format nor FreeDOS format program can format the floppy image. This means that "format a:" does not work under this condition. In this case "format /u a:" must be used to get the floppy image fsuccessfully formated by both OSes. The conclusion is "format /u a:" will always work but "format a:" will not. I do not know if it is really worth to continue investing time in this issue. This may be a peculiarity of my installation. I use only VMware Player 5.0.2 build-1031769 and I have never tried VirtualBox. VMware Player 5.0.2 build-1031769 is also quite old and may be a newer version does not exhibit this kind of problem but due to the lincense politics of VMware for private/home users I have stoped to update so I cannot tell. Regards, Juan M. Guerrero -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Getting ready for FreeDOS 1.2
OFYI: I have tried to format a floppy image with a VMware Player 5.0.2 using FreeDOS 1.2-pre23 and I have observed the same issue as described for VirtualBox. If /q/u is used it becomes possible to format the image. I have also tried to format using only /d. See below for the output produced. What surprises me is that the format program from MSDOS 6.22 does not require options like /u/q to format a floppy image on the same virtual machine. Issuing format a: just does the job. For an user that is familiar to MSDOS but not familiar at all to FreeDOS this deviation in program behavior may be confusing and the user may have difficulties in formating an image. Is this different behavior intentional? IMHO, if FreeDOS claims to be MSDOS compatible, the deviation in behavior should be as less as possible. This is not an issue for me personally. When I know that there is a difference in program behavior I can act accordingly but it remains surprising that something that I expected to be compatible is not always compatible conserning its behavior. Regards, Juan M. Guerrero format /d a: [DEBUG] FORMAT 0.91v, selected drive A: [DEBUG] Sector buffer at 1A3F:6770, track buffer at 1A3F:6B70 [DEBUG] Skipped ASSIGN check for diskette drive. [DEBUG] DOS 7+, LOCKing drive Insert new diskette for drive A: Insert new disk please, Press ENTER when the right disk is in drive... [DEBUG] Checking whether we need low-level format. [DEBUG] Test-reading boot sector. Boot sector contents implausible, disk not yet FAT formatted [DEBUG] DOS 7+, FORMAT-LOCKing drive [DEBUG] Current Disk Drive Parameter Table Values at 0070:0119: [DEBUG] [DDPT] Step Rate: 240 msec Head Unload:48 msec DMA Flag Bit: 0 [DEBUG] [DDPT] Head Load: 4 msec Post Rotate: 2035 msec Sector Size: 512 [DEBUG] [DDPT] SECTORS PER TRACK: 18 (Gap: 27 Data: 255 Format Gap: 108) [DEBUG] [DDPT] Fill Char: 0xF6 Head Settle: 15 msec Motor Start: 625 msec Using drive default: 1440k (Cyl=80 Head=2 Sec=18) [DEBUG] Setting geometry with int 13h ah=18h: tracks=80 sectors=18 [DEBUG] Updated INT 1E (DDPT) data at: 0070:0119. [DEBUG] Interleave Map: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [DEBUG] Configured Disk Drive Parameter Table Values at 0070:0119: [DEBUG] [DDPT] Step Rate: 240 msec Head Unload:48 msec DMA Flag Bit: 0 [DEBUG] [DDPT] Head Load: 4 msec Post Rotate: 2035 msec Sector Size: 512 [DEBUG] [DDPT] SECTORS PER TRACK: 18 (Gap: 27 Data: 255 Format Gap: 108) [DEBUG] [DDPT] Fill Char: 0xF6 Head Settle: 15 msec Motor Start: 625 msec [DEBUG] Controller setup 17: [configured type 7] 500 kbps (HD 1xx0k) -- press ENTER to format disk (ESCAPE to abort) -- Cannot find existing format - forcing full format Please enter volume label (max. 11 chars): No label, disk will have no creation timestamp. Full Formatting (wiping all data) [DEBUG] Formatting: Cylinder: 0 Head: 0 Sectors: 18 [DEBUG] Formatting: Cylinder: 0 Head: 1 Sectors: 18 0% [DEBUG] Formatting: Cylinder: 1 Head: 0 Sectors: 18 [DEBUG] Formatting: Cylinder: 1 Head: 1 Sectors: 18 1% [DEBUG] Formatting: Cylinder: 2 Head: 0 Sectors: 18 [DEBUG] Formatting: Cylinder: 2 Head: 1 Sectors: 18 2% [DEBUG] Formatting: Cylinder: 3 Head: 0 Sectors: 18 [DEBUG] Formatting: Cylinder: 3 Head: 1 Sectors: 18 3% [DEBUG] Formatting: Cylinder: 4 Head: 0 Sectors: 18 [DEBUG] Formatting: Cylinder: 4 Head: 1 Sectors: 18 5% [DEBUG] Formatting: Cylinder: 5 Head: 0 Sectors: 18 [DEBUG] Formatting: Cylinder: 5 Head: 1 Sectors: 18 6% [DEBUG] Formatting: Cylinder: 6 Head: 0 Sectors: 18 [DEBUG] Formatting: Cylinder: 6 Head: 1 Sectors: 18 7% [DEBUG] Formatting: Cylinder: 7 Head: 0 Sectors: 18 [DEBUG] Formatting: Cylinder: 7 Head: 1 Sectors: 18 8% [DEBUG] Formatting: Cylinder: 8 Head: 0 Sectors: 18 [DEBUG] Formatting: Cylinder: 8 Head: 1 Sectors: 18 10% [DEBUG] Formatting: Cylinder: 9 Head: 0 Sectors: 18 [DEBUG] Formatting: Cylinder: 9 Head: 1 Sectors: 18 11% [DEBUG] Formatting: Cylinder: 10 Head: 0 Sectors: 18 [DEBUG] Formatting: Cylinder: 10 Head: 1 Sectors: 18 12% [DEBUG] Formatting: Cylinder: 11 Head: 0 Sectors: 18 [DEBUG] Formatting: Cylinder: 11 Head: 1 Sectors: 18 13% [DEBUG] Formatting: Cylinder: 12 Head: 0 Sectors: 18 [DEBUG] Formatting: Cylinder: 12 Head: 1 Sectors: 18 15% [DEBUG] Formatting: Cylinder: 13 Head: 0 Sectors: 18 [DEBUG] Formatting: Cylinder: 13 Head: 1 Sectors: 18 16% [DEBUG] Formatting: Cylinder: 14 Head: 0 Sectors: 18 [DEBUG] Formatting: Cylinder: 14 Head: 1 Sectors: 18 17% [DEBUG] Formatting: Cylinder: 15 Head: 0 Sectors: 18 [DEBUG] Formatting: Cylinder: 15 Head: 1 Sectors: 18 18% [DEBUG] Formatting: Cylinder: 16 Head: 0 Sectors: 18 [DEBUG] Formatting: Cylinder: 16 Head: 1 Sectors: 18 20% [DEBUG] Formatting: Cylinder: 17 Head: 0
Re: [Freedos-devel] Getting ready for FreeDOS 1.2
Hello Jerome and Eric Thank you for your comments. IMHO the issue of having a working keyboard is essential. DOS and its clones appear to their users as TUI thus if the keyboard does not allow to issue commands it makes the OS to become almost useless. An user that has to hit around ten different keys until he finds the backslash key only to be capable to issue a "cd" command will lost interest quite soon. I had to mount the virtual disk to be capable to inspect it without getting crazy due to the keyboard and to figure out how to fix the issue. 30 years ago I used to use MSDOS every day all day long and thus I was suprised how much the directory structure and the available drivers and files differ from old DOS. So trying to fix this was not so straightforward as I expected at a first glance. IMO this issue could be tremendously alleviated by adding to FDCONFIG.SYS and AUTOEXEC.BAT, as comments, those lines that are required to select a particular keyboard layout. Having the required lines at the appropriate places together with some docs will allow those users that are experienced with DOS already to fix the issue by themselfs. Please note that I am not expecting any kind of magic. The MSDOS installer also did never offer any kind of magic but at least it asked the user to specify some locale and deduced from this what keyboard specific lines to add to config.sys and autoexec.bat. Neitherless it should be remembered that outside the US, the US keyboard layout is almost useless because crucial keys like backslash and colon are at different places and thus not easily found frustrating the average user quite soon. Regards, Juan M. Guerrero -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Getting ready for FreeDOS 1.2
I have installed http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/previews/1.2-pre23/FD12CD.iso on a VMware virtual machine. The host is linux. The installation process runs flawlessly so far. But when finished and the machine is rebooted I end up with an US keyboard layout although I have continuosly selected german as lenguage during the complete installation process. I excpected the installation program to be so smart that it concludes that if the user selects all the time certain language he wants later a keyboard layout correspondig to that language. Is this behaviour a bug or a feature? My MS-DOS 6.2 installation program is capable to handle this installation issue without any problems. Regards, Juan M. Guerrero -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
Am 20.07.2014 23:20, schrieb perditi...@gmail.com: On Sun, Jul 20, 2014 at 2:53 PM, Eric Auer e.a...@jpberlin.de mailto:e.a...@jpberlin.de wrote: Hi Juan, ... 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 http://command.com that you can download somewhere? ... Compiled kernels from my git source in both standalone and fdpkg formats including source archive. http://www.fdos.org/kernel/testing/git/ This is a fairly stable location and referenced in my github page (https://github.com/PerditionC/fdkernel). I have a temporary* build of FreeCom at http://www.fdos.org/kernel/command/FreeCom/test/ * where temporary means will be there until a newer version with a fix is released or I otherwise don't see it as needed or I redo my site Jeremy -- 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 OFYI, I have tried the fixed kernel and reading from the NULL device works now. The new command.com still fails in the same way as described before. Regards, Juan M. Guerrero -- 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
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
Am 20.07.2014 20:53, schrieb Eric Auer: 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? May be that the most important issue here is to understand that we are talking about command line arguments of a _batch file_ and we are _not_ talking about command line arguments for a dos program like xcopy.exe or command.com or what ever else shell is used. AFAIK at least for MSDOS 6.22 the only valid argument switch or separating chars are the following ones: space (space also means tab). semicolon ; comma , equal sign = Every of these chars are de-facto replaced by a single space and do limit the argument that may precede or follow it. Neither slash nor backslash nor colon nor question mark are usually separation chars. I do not even know if they are allowed at all. If I start the sample batch file I send in my very first posting like this: test.bat /q/w/e/r/t/z I will get the following output on MSDOS 6.22: test.bat /q/w/e/r/t/z finished with arguments The same applies to the command.com versions of Win98SE and WinXP. Please note that there are neither quoting nor spaces before any of the slashes. Now I start the batch file like this (again MSDOS 6.22): test.bat /q/w=/e/r=/t/z and I get the following output: test.bat /q/w /e/r /t/z finished with arguments Again no quoting but this time I have inserted equal signs so that the initial sequence has become split into 3 different arguments. If I do the same with stock FreeDOS 1.1 distribution I get the following output: test.bat /q /w= /e /r= /t /z finished with arguments I do not want to bore the people here with this issue any more. I can fix it either using 4dos or by telling the user to quote the arguments. [snip] 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. IMHO it should work as MSDOS works. But this is now the case, it has been fixed. Please see: http://sourceforge.net/p/freedos/mailman/message/31764688/ The only reason why I had mentioned that issue again, was the fact that I did not known how to get a copy of the fixed kernel. But now I know how to get a fixed kernel and a fixed FreeCom. I will give it a try the next days. [snip] Please do not get me wrong but all this is not an inconvenience to me. But it may become an inconvenience for a newbie or even average DJGPP user. I have been porting GNU software to DOS using DJGPP since at least 8 years and joined the DJGPP developer group even a couple of years before. When Rugxulo uploads a port of bzip2 or lua to http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files he uploads ports that I have produced and made available at ftp.delorie.com. So again, I have a very fine working environment to produce software packages using DJGPP. But what shall I tell an user that asks me what OS he shall use to compile the sources of the ports I am making available? I have to admit that during all my years of porting I have never cared about FreeDOS. I have done all developing work on WinXP and not checked the port with any other OS. Again if an user asks me what OS shall he use to compile some port sources, shall I tell him, go to ebay and buy WinXP or shall I tell him to give FreeDOS a chance? To recommend FreeDOS I must be able to configure and compile every single port I have released over the years. The very first step to configure the source of a port is to cd into the building directory usually called either _build.204 or _build.203 and from there start the batch file that will configure the sources. This batch file located in the /djgpp directory must be started like this: ..\djgpp\config.bat ./.. [and all the other optional arguments] The first argument, and this argument cannot be omitted, is the unix-style path to the sources. The path may be followed by optional arguments. It becomes clear that this batch file will not work correctly with the current FreeDOS distribution due to the FreeCom behavior that strongly deviates from command.com and cmd.exe behavior. The observation of this different behavior was my initial and only motivation to send the first posting that initiated this thread. Regards, Juan M. Guerrero -- Want fast and
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
Am 19.07.2014 12:43, schrieb Rugxulo: Hi, On Sat, Jul 19, 2014 at 12:00 AM, Mateusz Viste mate...@viste.fr wrote: I think this problem goes beyond path separators. As I understand it, any argument including a slash character will get exploded. So yes, this might be used as path separator, but not only. For eg. sed expects slash delimited values inside a single argument. sed can use other delimiters, if slash is too prohibitive. Sometimes that makes things easier to read and write. Just for silly example (tested under Cygwin): echo $PATH | sed -e '/.*\(\/cygdrive\/c\/rugxulo\/watcom19\/BINNT\).*/s//\1/' ... vs. ... echo $PATH | sed -e '\,.*\(/cygdrive/c/rugxulo/watcom19/BINNT\).*,s,,\1,' Oops. Or did you mean that this bug in FreeCOM might break sed invocations? I doubt it, the double quotes after -e probably protect it from munging. No, this is not a sed issue. The issue I reported concerns the treating of the arguments passed to a batch file by FreeCom. As shown by the small sample batch file, the behavior of the current version of FreeCom is different from the behavior of command.com and 4dos.com. I have made a clean installation of FreeDOS 1.1 and I am not aware of having break something during installation. But anyway this is not a problem to me anymore because I have replaced FreeCom with 4dos. @Juan - you also write about other different issues and limitations - could you please post us a list? Even if FreeCom is semi-maintained nowadays, it would still be interesting to know what kind of quirks you found there.. 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 To clarify the issue. I was playing with the idea to release an .iso image containing a full DJGPP installation for 2.03, 2.04 and with libc.a build from DJGPP's CVS repository. The goal here was to have a reference DJGPP installation so that users that may have difficulties building some projects can try this installation. For me the question arised if this image should be bootable or not. If bootable then the only possible OS that would make sense would be FreeDOS. It was clear to me that if the image would be bootable then certainly some users would ask if it would be possible to compile their gnu projects on FreeDOS. Most of the user nowadays have Win8 instead as WinXP as default OS. So it becomes necessary to test if FreeDOS can be used as OS to configure and compile projects of such complexity. Until now I have used MSDOS 6.22 instead of FreeDOS. If I get it working on MSDOS I try FreeDOS. If it does not work with MSDOS I assume that it also does not work with FreeDOS. 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. I was not able to configure any of the contemporaneous GNU programs like m4, bison or grep. Trying to configure and compile GNU programs on FreeDOS have revealed at least the following issues: 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 kernels too or they are not really full compatible. Of course, how compatible the FreeDOS kernel shall be is a design decision that must be taken by the maintainers. 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 will certainly not install one compiler more (aka OW) and try to become familiar with a compiler I have never used in my life only to compile a fixed kernel. I would expect a pointer to a zip file that contains a fixed kernel so I can replace the broken one. 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. 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
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
Am 19.07.2014 00:37, schrieb Ralf Quint: On 7/18/2014 3:09 PM, Juan Manuel Guerrero wrote: This is not really disappointing. I was only testing for the possibility to recommend the FreeDOS 1.1 distribution as an alternative to WinXP and/or Win98SE to build DJGPP ports but this seems not really be possible due to different issues and limitations. Regards, Juan M. Guerrero DOS internally should work with both back and forward slashes. Yes, I am aware of this. Any DOS command shell, including MS-DOS 6.22 should not except the forward slashes even in a batch file as you claim, unless the switch char has been deliberately been changed to something else via INT21H, function 37h... I have installed FreeDOS 1.1 9 or 10 months ago. I have played with it some days and not used it again until yesterday. I have certainly not recompiled any components of the distribution. I have also not installed any other program that should change the switch char. No other programs have been installed except those installed by the distribution proper. All this means that I am not aware of having deliberately changed the switch char. May be it is worth to inspect the FreeCom sources to check what switch char has been selected and what does change it if at all. Regards, Juan M. Guerrero -- 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
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
Am 19.07.2014 07:35, schrieb Steve Nickolas: On Sat, 19 Jul 2014, Mateusz Viste wrote: Hi all, I think this problem goes beyond path separators. As I understand it, any argument including a slash character will get exploded. So yes, this might be used as path separator, but not only. For eg. sed expects slash delimited values inside a single argument. @Juan - you also write about other different issues and limitations - could you please post us a list? Even if FreeCom is semi-maintained nowadays, it would still be interesting to know what kind of quirks you found there.. command.com should not be splitting the strings at all, but should send the parameters in the raw, terminated (iirc) by a newline. It is for the libc to parse them; if otherwise, that is a serious flaw. There *is* the option of 4DOS. Thanks to pointing me to 4DOS. It was the shell I used everyday in the 80s when I worked on DOS. I had completely forgotten about it but it is nice to see that it is still available. It solves the problem. Regards, Juan M. Guerrero -- 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
[Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
I do not know if this is the right place to report this FreCom issue and I do not know if this issue is already well known but I would like to report it anyway. Please inspect the following batch file: @echo off @echo %0 :loop @echo %1 shift if not %1 == goto loop @echo finished with arguments command.com on MSDOS 6.22, Win98SE and WinXP and also cmd.exe of WinXP will produce the following output: test.bat ./.. ../. if the batch file is started like this: test.bat ./.. ../. If I use FreeCom 0.84-pre2 XMS_Swap [August 28 2006 00:32:15] shipped with FreeDOS 1.1 and start the batch file in exactly the same way I get the following output: test.bat . /.. .. /. As can be seen, FreCom seems to interpret any slash as an option marker like in /? to get help. All microsoft command.com versions and also cmd.exe do interpret the slash as an option marker only if it is preceded by some kind of blank character. This makes it necessary to quote paths written in unix-style like: ../foo/bar/. if they shall be passed as arguments to a batch file to be processed by FreCom. Is this behavior a bug or a feature? Regards, Juan M. Guerrero -- 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
Re: [Freedos-devel] Difference between command.com and frecom.com when parsing command line arguments of a batch file.
Am 18.07.2014 22:30, schrieb Rugxulo: Hi, On Fri, Jul 18, 2014 at 2:00 PM, Juan Manuel Guerrero juan.guerr...@gmx.de wrote: I do not know if this is the right place to report this FreCom issue Dunno, not sure it's actively maintained by anyone anymore. I feared this. I do not know if this issue is already well known but I would like to report it anyway. If I use FreeCom 0.84-pre2 XMS_Swap [August 28 2006 00:32:15] shipped with FreeDOS 1.1 and start the batch file in exactly the same way I get the following output: As can be seen, FreCom seems to interpret any slash as an option marker like in /? to get help. All microsoft command.com versions and also cmd.exe do interpret the slash as an option marker only if it is preceded by some kind of blank character. This makes it necessary to quote paths written in unix-style like: ../foo/bar/. if they shall be passed as arguments to a batch file to be processed by FreCom. Is this behavior a bug or a feature? I definitely reported this same quirk to somebody a few years ago. Obviously it was never fixed. It was probably just an unintentional flaw or too obscure to worry about. I mean, most DOS programs don't use *nix slashes as path separators. I wish I had better news for you like, I made a fix, but it's not really that easy. (Not impossible, just very annoying.) This is not really disappointing. I was only testing for the possibility to recommend the FreeDOS 1.1 distribution as an alternative to WinXP and/or Win98SE to build DJGPP ports but this seems not really be possible due to different issues and limitations. Regards, Juan M. Guerrero -- 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
