comcom.com

comcom.com

[Jan Willem Stumpel]

When I use freedos, the command interpreter (in my system
/usr/lib/dosemu/commands/comcom.com) has several bugs. Should they
  be reported to the freedos people or to the dosemu people? This
program announces itself as

   DOSEMU built-in command.com version  1.0

which suggests it belongs to dosemu.

I have this program still from my original 1.0.2.1 installation.
New versions are not built when I compile newer versions of
dosemu; however, in src/plugin/commands I find a comcom.c, -.d,
and -.o. I'm a bit confused. Is this built into newer versions of
dosemu.bin itself? But if I do not have my old comcom.com (or a
link to it) in the dos boot directory, dosemu complains of a
missing command interpreter.

Anyway the bugs I found are:

1) changing directory:
C:\>cd\ws\text
cd\ws\text: file not found

A space is needed. This is unexpected (MS-DOS command.com does not
need it) and therefore (IMHO) a bug.

2) running a program in a directory above the present one:
C:\>cd \ws\text
C:\WS\TEXT>..\ws
..\ws: file not found

The file extension is needed: the command ..\ws.exe succeeds.

3) Problems with a TSR
C:\WS\TEXT>cd\
cd\: file not found

Same as bug 1): but now I install a TSR and do the same:

C:\WS\TEXT>\oldc\tsr\minimon
MiniMon Version 1.0 installed. Activate with <Ctrl-Alt-M>
C:\WS\TEXT>cd\
cd\: insufficient memory

Not "file not found" this time, but "insufficient memory",
apparently caused by the TSR (even though freedos "mem" shows 619
k free at this point).

Regards, Jan

Re: comcom.com

[Bart Oldeman]

On Fri, 3 Jan 2003, Jan Willem Stumpel wrote:

> When I use freedos, the command interpreter (in my system
> /usr/lib/dosemu/commands/comcom.com) has several bugs. Should they
>   be reported to the freedos people or to the dosemu people?

dosemu, preferrably in the SF bug tracker.
it is built into dosemu.bin indeed.

> New versions are not built when I compile newer versions of
> dosemu; however, in src/plugin/commands I find a comcom.c, -.d,
> and -.o. I'm a bit confused. Is this built into newer versions of
> dosemu.bin itself? But if I do not have my old comcom.com (or a
> link to it) in the dos boot directory, dosemu complains of a
> missing command interpreter.

comcom.com is the DOS stub. It itself hasn't changed, but several bugs
in the dosemu.bin part of comcom have been fixed in the mean time (and it
shows the title of the DOS prog in the X title bar now). Anyway, if you
don't like it then you can always use another command interpreter
such as the FreeDOS command.com (FreeCOM) or 4DOS.

> 1) changing directory:
> C:\>cd\ws\text
> cd\ws\text: file not found

yes, this is a known bug.

> 2) running a program in a directory above the present one:
> C:\>cd \ws\text
> C:\WS\TEXT>..\ws
> ..\ws: file not found
>
> The file extension is needed: the command ..\ws.exe succeeds.

this one I haven't observed before. Thanks.

> 3) Problems with a TSR
> C:\WS\TEXT>cd\
> cd\: file not found
>
> Same as bug 1): but now I install a TSR and do the same:
>
> C:\WS\TEXT>\oldc\tsr\minimon
> MiniMon Version 1.0 installed. Activate with <Ctrl-Alt-M>
> C:\WS\TEXT>cd\
> cd\: insufficient memory

well, first fix bug 1 and then look again :)

Bart

Re: comcom.com

[Jan Willem Stumpel]

Bart Oldeman wrote:
> comcom.com is the DOS stub. It itself hasn't changed, but
> several bugs in the dosemu.bin part of comcom have been fixed
> in the mean time (and it shows the title of the DOS prog in the
> X title bar now).

Ah, yes, indeed it does. Nice!

> Anyway, if you don't like it then you can always use another
> command interpreter such as the FreeDOS command.com (FreeCOM)
> or 4DOS.

Or, I suppose, MS-DOS's command.com. So comcom.com is just
something for passing command line input to the 'real', built-in,
command interpreter? Does this mean that when 'alternative'
interpreters are used, the 'built-in' command interpreting code is
completely bypassed? BTW where would a new user (only having, say,
a 1.1.4.0 source package) find his/her comcom.com?

>> 3) Problems with a TSR [..]
>> C:\WS\TEXT>cd\
>> cd\: insufficient memory
>
> well, first fix bug 1 and then look again :)

OK, I'll have a go.. In the meantime I found another one:

4) Sidekick refuses to load
C:\>\oldc\tsr\sk
Sorry, unknown PCDOS version. Please report to BORLAND.

Regards, Jan

Re: comcom.com

[Bart Oldeman]

On Fri, 3 Jan 2003, Jan Willem Stumpel wrote:

> Or, I suppose, MS-DOS's command.com. So comcom.com is just
> something for passing command line input to the 'real', built-in,
> command interpreter? Does this mean that when 'alternative'
> interpreters are used, the 'built-in' command interpreting code is
> completely bypassed?

yes

> BTW where would a new user (only having, say,
> a 1.1.4.0 source package) find his/her comcom.com?

for 1.1.4.0, after a "make install" it is, by default, at
/usr/local/share/dosemu/freedos/dosemu/comcom.com
just like lredir, exitemu and friends.

When you first run dosemu it is symlinked using
~/dosemu/freedos/dosemu/comcom.com ->
/usr/local/share/dosemu/freedos/dosemu/comcom.com

Note that Debian's dosemu package uses a slightly different setup, using a
readonly C: drive.

Bart

Re: comcom.com

[Stas Sergeev]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

Hello.

Clarence Dang wrote:
> If you CC me comcom or joystick bug reports they will get fixed faster 
> (as opposed to probably not at all :)) since I don't read every single 
> email that comes up on MLs.
Hmm, how about updating the doc/DPR
then?

> BTW, Stas, I'm looking into the comcom problem at sourceforge.
OK, I just wanted to finally give a
comcom a try, but it appeared to be
completely useless for me:(
At first, it simply crashes my dosemu
without the attached hack: for some
reasons the duplicate_env() is called
when ctcb->envir_frame==0, hence the
crash. Do you know why is this happens?
Then, with the hack applied, it started
to complain on using "lh" in autoexec.
That was enough of trying it for now:)

[-- Attachment #2: comcom.diff --]
[-- Type: text/plain, Size: 797 bytes --]

--- comcom.c.old	Sat Jan 11 05:44:58 2003
+++ comcom.c	Sun Jan 12 20:07:03 2003
@@ -3514,15 +3514,20 @@
 static int duplicate_env(int size)
 {
 	struct com_starter_seg  *ctcb = CTCB;
-	struct com_MCB *mcb = (void *)((ctcb->envir_frame-1) << 4);
 	char *newenv;
-	int oldsize = mcb->size << 4;
+	struct com_MCB *mcb = NULL;
+	int oldsize = 0;
 
+	if (ctcb->envir_frame) {
+	    mcb = (void *)((ctcb->envir_frame-1) << 4);
+	    oldsize = mcb->size << 4;
+	}
 	size = (size+15) & -16;
 	if (size <= oldsize) size = oldsize;
 	newenv = (char *)com_dosallocmem(size);
 	if ((int)newenv < 0) return oldsize;	/* giving up */
-	memcpy(newenv, ((char *)mcb)+16, oldsize);
+	if (oldsize)
+	    memcpy(newenv, ((char *)mcb)+16, oldsize);
 	ctcb->envir_frame = ((unsigned int)newenv) >> 4;
 	return size;
 }

Re: comcom.com

[Clarence Dang]

On Sun, 12 Jan 2003 05:15 pm, Stas Sergeev wrote:
> Hello.
>
> Clarence Dang wrote:
> > If you CC me comcom or joystick bug reports they will get fixed faster
> > (as opposed to probably not at all :)) since I don't read every single
> > email that comes up on MLs.
>
> Hmm, how about updating the doc/DPR
> then?
>
I think it would be too miserable since there are so few people working on 
dosemu nowadays :(

> > BTW, Stas, I'm looking into the comcom problem at sourceforge.
>
> OK, I just wanted to finally give a
> comcom a try, but it appeared to be
> completely useless for me:(
> At first, it simply crashes my dosemu
> without the attached hack: for some
> reasons the duplicate_env() is called
> when ctcb->envir_frame==0, hence the
> crash. Do you know why is this happens?
Absolutely no idea.

> Then, with the hack applied, it started
> to complain on using "lh" in autoexec.
> That was enough of trying it for now:)
Comcom has always worked for me...
Have you been using any more kernel patches, Stas? :)

Clarence

Re: comcom.com

[Jochen Reinwand]

On Wednesday 15 January 2003 13:50, Clarence Dang wrote:
> On Sun, 12 Jan 2003 05:15 pm, Stas Sergeev wrote:
> > Hello.
> >
> > Clarence Dang wrote:
> > > If you CC me comcom or joystick bug reports they will get fixed faster
> > > (as opposed to probably not at all :)) since I don't read every single
> > > email that comes up on MLs.
> >
> > Hmm, how about updating the doc/DPR
> > then?
>
> I think it would be too miserable since there are so few people working on
> dosemu nowadays :(

Is that really true? Has the interest in a DOS emulation dropped so much?

Btw: I came across an interesting project a few days ago. It is called dosbox 
(http://dosbox.zophar.net/) and it seems to be a DOS emulator for Linux _and_ 
Windows. It seems like there is done a lot of work for it. Does anybody know 
more about it?
Why have they started a new project? DOSemu is much better at the moment. So 
why spending time for implementing things already done?

regards
Jochen

Re: comcom.com

[Clarence Dang]

[-- Attachment #1: Type: text/plain, Size: 1778 bytes --]

On Fri, 3 Jan 2003 06:24 pm, Bart Oldeman wrote:
> On Fri, 3 Jan 2003, Jan Willem Stumpel wrote:
> > When I use freedos, the command interpreter (in my system
> > /usr/lib/dosemu/commands/comcom.com) has several bugs. Should they
> >   be reported to the freedos people or to the dosemu people?
>
> dosemu, preferrably in the SF bug tracker.
> it is built into dosemu.bin indeed.
>
If you CC me comcom or joystick bug reports they will get fixed faster (as 
opposed to probably not at all :)) since I don't read every single email that 
comes up on MLs.  Just don't deliberately stress-test comcom because it's 
known to be buggy.

>
> > 1) changing directory:
> > C:\>cd\ws\text
> > cd\ws\text: file not found
>
> yes, this is a known bug.
>
Bart, I've recycled your 1.1.3.8 comcom patch and moved it to com_argparse in 
coopthreads to make comcom-space.patch which should solve the problem once 
and for all (argument parsing in comcom is still far from perfect but good 
enough for the time being).  I checked for the possibility of an introduced 
buffer overrun but it shouldn't happen since 256 is much larger than the 
maximum command line length of about 128.

> > 2) running a program in a directory above the present one:
> > C:\>cd \ws\text
> > C:\WS\TEXT>..\ws
> > ..\ws: file not found
> >
> > The file extension is needed: the command ..\ws.exe succeeds.
>
> this one I haven't observed before. Thanks.
>
comcom-exist-exec.patch

> > C:\WS\TEXT>\oldc\tsr\minimon
> > MiniMon Version 1.0 installed. Activate with <Ctrl-Alt-M>
> > C:\WS\TEXT>cd\
> > cd\: insufficient memory
>
> well, first fix bug 1 and then look again :)
>
Does it still happen after the attached patches have been applied?

Clarence

BTW, Stas, I'm looking into the comcom problem at sourceforge.

[-- Attachment #2: comcom-space.patch --]
[-- Type: text/x-diff, Size: 1412 bytes --]

--- 1141pr/src/plugin/coopthreads/coopthreads.c	2002-03-18 21:58:14.000000000 +0000
+++ comhack/src/plugin/coopthreads/coopthreads.c	2003-01-10 15:37:03.000000000 +0000
@@ -1734,6 +1734,20 @@
    }
    else s[1+(unsigned char)s[0]] = 0;
    s++;
+
+   /* transform:
+    *    dir/p to dir /p
+    *    cd\ to cd \
+    *    cd.. to cd ..
+    */
+   p = s;
+   while (isalnum(*p)) p++;
+   if (*p == '\\' || *p == '/' || (*p == '.' && p[1] == '.')) {
+      memmove(p+1, p, s [-1] - (p - s) + 1/*NUL*/);
+      *p = ' ';
+      s[-1]++; /* update length */
+   }
+
    maxarg --;
    for ( ; *s; s++) {
       if (!mode) {
--- 1141pr/src/plugin/commands/comcom.c	2002-12-21 01:27:13.000000000 +0000
+++ comhack/src/plugin/commands/comcom.c	2003-01-10 15:17:29.000000000 +0000
@@ -1324,6 +1324,7 @@
 		i = replen - (s - replbuf);
 		memcpy(p, s, i+1);
 		callbuf[0] = p - (callbuf+1) + i;
+		/* WARNING! callbuf may be modified by com_argparse */
 		j = com_argparse(callbuf, argv+arg0_new, MAXARGS - (argc-arg0_new) -1);
 		saved_dta = PSP_DTA;
 		SET_CHILD_ARGS(arg0_new);
@@ -3276,6 +3277,7 @@
 		if (!bdta.mode) com_doswrite(2, "\r\n", 2);
 
 		memcpy(argbuf, &LEN0A, LEN0A+2); /* save contents */
+		/* WARNING! argbuf may be modified by com_argparse */
 		argc = com_argparse(argbuf, argv, MAXARGS -1);
 		bdta.argcsub = bdta.argc = argc; /* save positional variables */
 		bdta.argvsub = bdta.argv = argv;

[-- Attachment #3: comcom-exist-exec.patch --]
[-- Type: text/x-diff, Size: 947 bytes --]

--- 1141pr/src/plugin/commands/comcom.c	2002-12-21 01:27:13.000000000 +0000
+++ comhack/src/plugin/commands/comcom.c	2003-01-11 19:05:10.000000000 +0000
@@ -1016,10 +1016,20 @@
 	int i;

 	if ((len >4) && (file[len-4] == '.')) {
-		for (i=0; i<3; i++)
-			if (!strncasecmp(file+len-3, extlist[i], 3))
-				if (com_exist_file(file)) return i+1; 
-		return 0;
+		/* '..\ws' does _not_ mean a file with extension '\ws' */
+		boolean isext = TRUE;
+		for (i = len - 3; i < len; i++) {
+			if (!isalnum (file[i])) {
+				isext = FALSE;
+				break;
+			}
+		}
+		if (isext) {
+			for (i=0; i<3; i++)
+				if (!strncasecmp(file+len-3, extlist[i], 3))
+					if (com_exist_file(file)) return i+1;
+			return 0;
+		}
 	}
 	*p++ = '.';
 	for (i=0; i<3; i++) {
@@ -1164,7 +1175,7 @@
 	char *p;

 	if (!expand || (expand && com_doscanonicalize(buf, path)))
-							strcpy(buf, path);
+		strcpy(buf, path);
 	p = basename_of(buf,0);
 	*p = 0;
 	return p - buf;

Re: comcom.com

[Jan Willem Stumpel]

Clarence Dang wrote:
> Does it still happen after the attached patches have been applied?

The 3 bugs have now disappeared. Thanks!

For some reason the fourth bug which I mentioned to Bart Oldeman
("Sidekick refuses to install") has now also disappeared. I cannot
explain this. It is not due to your patches because I cannot even
reproduce the bug now with earlier versions. It must have been
some of my messing about with dosemu.conf, maybe config.sys which
did this.

I still have some problems with Sidekick which suggest that the
freedos algorithms for finding files are not yet 100 %. Part of
Sidekick is a program SKINST.COM. This aborts with a message:

*** FATAL ERROR: Message file SKINST.MSG not found

although SKINST.MSG is in the Sidekick directory. Similarly,
though SK now installs, one of its functions ("Help") does not
work; it complains of the file SK.HLP not being present (but it
is). Finally, Sidekick's "Notepad" function. The existing NOTES
file is not found, and trying to save a (new) notepad, Sidekick
gives an error message:

*** Directory full. Press <ESC>

These things do not happen with dosemu-dos6 or dosemu-dos98.

Regards, Jan

Re: comcom.com

[Clarence Dang]

On Sun, 12 Jan 2003 10:26 am, Jan Willem Stumpel wrote:
(...)
> I still have some problems with Sidekick which suggest that the
> freedos algorithms for finding files are not yet 100 %. 
It might not be FreeDOS...
It could be COMCOM or DOSEMU (MFS among other things).

> Part of
> Sidekick is a program SKINST.COM. This aborts with a message:
>
> *** FATAL ERROR: Message file SKINST.MSG not found
>
> although SKINST.MSG is in the Sidekick directory. Similarly,
> though SK now installs, one of its functions ("Help") does not
> work; it complains of the file SK.HLP not being present (but it
> is). Finally, Sidekick's "Notepad" function. The existing NOTES
> file is not found, and trying to save a (new) notepad, Sidekick
> gives an error message:
>
> *** Directory full. Press <ESC>
>
Where can I get Sidekick (legally)?

> These things do not happen with dosemu-dos6 or dosemu-dos98.
>
Ok, try running FreeDOS with dos 7.1's command.com (replace the command.com 
link to comcom.com with a link to MS' command.com).  Then try running real 
dos 7.1 with comcom.com instead of MS' command.com (of course, you'll have to 
rename comcom.com to command.com, but you get the idea).

Clarence

Re: comcom.com

[Stas Sergeev]

Hello.

Clarence Dang wrote:
>> when ctcb->envir_frame==0, hence the
>> crash. Do you know why is this happens?
>  Absolutely no idea.
But then, to (hopefully) reproduce
that, you need to add the line like
this to your config.sys:
SHELL=G:\COMCOM.COM /E:2048 /k call autoexel.bat
It crashes exactly when it goes to
parsing an autoexel.bat (my alternative
autoexec.bat).

>> to complain on using "lh" in autoexec.
>  Comcom has always worked for me...
Does the "lh" command work for you?

> Have you been using any more kernel patches, Stas? :)
Yes, my kernel is always patched in
some ways (and sometimes it turns out
to be usefull also for dosemu:), but
since 2.4.20 I don't have any dosemu-
specific patches here, so I doubt
the kernel can be the problem in that
case.

Re: comcom.com

[Clarence Dang]

On Wed, 15 Jan 2003 02:57 pm, Stas Sergeev wrote:
> Hello.
>
> Clarence Dang wrote:
> >> when ctcb->envir_frame==0, hence the
> >> crash. Do you know why is this happens?
> >
> >  Absolutely no idea.
>
> But then, to (hopefully) reproduce
> that, you need to add the line like
> this to your config.sys:
> SHELL=G:\COMCOM.COM /E:2048 /k call autoexel.bat
> It crashes exactly when it goes to
> parsing an autoexel.bat (my alternative
> autoexec.bat).
>
No crash here with "autoexel.bat".
BTW, you realise that you should use /P ...of course you'd have to drop the 
"call" bit of /K.

> >> to complain on using "lh" in autoexec.
> >
> >  Comcom has always worked for me...
>
> Does the "lh" command work for you?
>
No, but LOADHI does :)
LH doesn't seem to exist

Clarence

Re: comcom.com

[Stas Sergeev]

Hello.

Jochen Reinwand wrote:
>  I think it would be too miserable since there are so few people 
>  working on
>  > dosemu nowadays :(
>  Is that really true? Has the interest in a DOS emulation dropped so 
>  much?
At least for dosemu it is true.
Most developers are gone, as well
as the most distributors.
My personal opinion is that this
is more because dosemu always failed
to achieve the necessary level of
stability and security in order the
users and distributors to trust it
any longer after it crossed the 1.0
boundary.
Now we are finally approaching that,
but I think the loses were fatal.
But at least I know two distributors
who decided to give it a chance once
again, packaging 1.1.4+.

> Btw: I came across an interesting project a few days ago. It is called 
> dosbox 
> (http://dosbox.zophar.net/) and it seems to be a DOS emulator for Linux 
> _and_ Windows. It seems like there is done a lot of work for it.
It is intended to run games and only
games. This is official. Dosemu is
intended to do *much* more, actually
the games were never (until recently)
the main goal of dosemu, so that
projects cannot be compared.

> Does anybody know more about it?
Yes. At least people here:
http://sourceforge.net/forum/forum.php?forum_id=174313
should know much more about it.

> Why have they started a new project? DOSemu is much better at the 
> moment. So why spending time for implementing things already done?
There were reasons:
1. Dosemu isn't portable (very bad).
2. Dosemu was *dead* (not any more)
3. Dosemu didn't have a sound support,
so it was useless for games (not any
longer, the sound support is much better
than anywhere else now, except probably
the bochs, but the bochs have so many
developers...)
4. I don't think DOSbox is intended
to compete with dosemu at all.
I think most users of DOSbox are the
WinNT/2000 users. That people always
suffered a horrible DOS support.
Now I think WinXP have somewhat better
DOS support (including sound, VESA and
DPMI, but I may be misleaded as I am
not a Windows user). Let's see what
DOSbox can offer in exchange.
As for linux, dosemu is unbeatable
here, that's for sure (IMHO), but
with such a few developers this can
be eventually changed.

Re: comcom.com

[Jochen Reinwand]

Hello,

On Friday 17 January 2003 19:47, Stas Sergeev wrote:
> >  Is that really true? Has the interest in a DOS emulation dropped so
> >  much?
>
> At least for dosemu it is true.
> Most developers are gone, as well
> as the most distributors.
> My personal opinion is that this
> is more because dosemu always failed
> to achieve the necessary level of
> stability and security in order the
> users and distributors to trust it
> any longer after it crossed the 1.0
> boundary.

And in our days the interests in running old DOS software has also dropped 
dramatically. When dosemu started there was much interest in running DOS 
software to make Linux more powerful. But now...

> Now we are finally approaching that,

Really fascinating the amount of improvements made over the last few months!

> but I think the loses were fatal.

What a pity that I don't have the time nor the abilities to contribute to the 
development :(

> But at least I know two distributors
> who decided to give it a chance once
> again, packaging 1.1.4+.

Sounds great!

> > Btw: I came across an interesting project a few days ago. It is called
> > dosbox
> > (http://dosbox.zophar.net/) and it seems to be a DOS emulator for Linux
> > _and_ Windows. It seems like there is done a lot of work for it.
>
> It is intended to run games and only
> games. This is official. Dosemu is
> intended to do *much* more, actually
> the games were never (until recently)
> the main goal of dosemu, so that
> projects cannot be compared.

I believe that what I said above about DOS software does not apply to games! I 
have a lot of old DOS games I'd really like to play "forever". With every new 
computer I got the number old games running on it, even under plain DOS, got 
smaller. The next 64 bit generation will make things even worse...

> > Why have they started a new project? DOSemu is much better at the
> > moment. So why spending time for implementing things already done?
>
> There were reasons:
> 1. Dosemu isn't portable (very bad).
> 2. Dosemu was *dead* (not any more)
> 3. Dosemu didn't have a sound support,
> so it was useless for games (not any
> longer, the sound support is much better
> than anywhere else now, except probably
> the bochs, but the bochs have so many
> developers...)

And they have a really SLOW emulator. On the other hand processors won't 
become slower over the next few years...
The only remaining problem about bochs is the difficult usage. This special 
container files for harddrives are definitively not as comfortable as the 
dosemu way of simply using directory! Always wanted my DOS data on a drive 
with journaling and support for symlinks :-)

> 4. I don't think DOSbox is intended
> to compete with dosemu at all.
> I think most users of DOSbox are the
> WinNT/2000 users. That people always
> suffered a horrible DOS support.
> Now I think WinXP have somewhat better
> DOS support (including sound, VESA and
> DPMI, but I may be misleaded as I am
> not a Windows user).

It's a bit better.
A wanted to play a quick Duke 3D network game with my notebook. The only 
available OSs on it are XP and Linux. I wasn't able to run Duke with network 
support under XP, so I tried dosemu. I was not able to get network running 
with dosemu either (have not tried hard enough, of course), but I got 
interested in the "new" dosemu capable of running Duke with sound. Thanx for 
your patches!
I compared dosemu to WinXP DOS support with a few games. They are nearly 
equally capable of running the games! dosemu was a little bit better ;-)

Keep on the good work!

regards
Jochen