ugetcwd / uchdir freakiness

ugetcwd / uchdir freakiness

[Pawel Szymczykowski]

Not sure where the problem is exactly, but I can't seem to get ugetcwd
and uchdir to work.. in fact, they have some pretty weird results.

I am running dosemu 1.1.4 as an unprivledged user along with the
dosemu-freedos-b8p-bin.tgz from the stable.. is it another issue of
outdated stuff (in the fs tarball?)

uchdir seems to do nothing at all..

C:\>uchdir dosemu

C:\>unix pwd
Effective commandline: pwd
/home/pawel

What's worse is that I run ugetcwd it seems to suck up memory or trample
over some protected memory or something..

C:\>ugetcwd
/home/pawel

C:\>ls

ls: insufficient memory

C:\>mem /u

mem: insufficient memory

Not sure if the binaries were included in that freedos tarball or not,
but I don't think so. Has anyone seen this before?

-Pawel

Re: ugetcwd / uchdir freakiness

[Stas Sergeev]

Hello.

Pawel Szymczykowski wrote:
> Not sure where the problem is exactly, but I can't seem to get ugetcwd
> and uchdir to work.. in fact, they have some pretty weird results.
Well, you are not alone. Since the
dosemu utilities were ported to so
called "coopthreads", various people
are reporting the weird problems
(but for me and most others everything
works OK).
I think sooner or later we'll have
to return back to the known-good
standalone-style tools:(
I was thinking about re-implementing
the coopthreads idea based on a
do_call_back() functionality, but at
least for the comcom it won't work.
I was asking the appropriate people
several times about dropping the comcom
(which itself makes more problems than
the coopthreads do) but so far there
were only a very inconclusive responses.

For now: type "make dosbin" which
will create a standalone-style tools
for you, which shouldn't have any
problems.

Re: ugetcwd / uchdir freakiness

[Bart Oldeman]

On Mon, 21 Apr 2003, Stas Sergeev wrote:

> Pawel Szymczykowski wrote:
> > Not sure where the problem is exactly, but I can't seem to get ugetcwd
> > and uchdir to work.. in fact, they have some pretty weird results.
> Well, you are not alone. Since the
> dosemu utilities were ported to so
> called "coopthreads", various people
> are reporting the weird problems
> (but for me and most others everything
> works OK).
> I think sooner or later we'll have
> to return back to the known-good
> standalone-style tools:(

the problem with those (well partly) is that we'd need to rely on third
party compilers ("invoke tcc via dosemu").

With "make dosbin" you get some but not all. However, uchdir is only
problematic when you invoke it inside "comcom" -- then it behaves like an
internal command.

There was an oversight from Hans I think here: "uchdir" eats heap but
isn't placed in that category.

Try this patch:

diff -urN dosemu-1.1.4.15/src/plugin/commands/comcom.c dosemu-1.1.4.16/src/plugin/commands/comcom.c
--- dosemu-1.1.4.15/src/plugin/commands/comcom.c	Tue Apr 15 23:11:02 2003
+++ dosemu-1.1.4.16/src/plugin/commands/comcom.c	Sat Apr 19 00:14:46 2003
@@ -2881,11 +2881,11 @@
 	{"ecpuon",	ecpuon_main, 1},
 	{"eject",	eject_main, 1},
 	{"emumouse",	emumouse_main, 1},
-	{"ugetcwd",	ugetcwd_main, 1},
 	{"vgaoff",	vgaoff_main, 1},
 	{"vgaon",	vgaon_main, 1},

 #ifdef USE_HEAP_EATING_BUILTINS
+	{"ugetcwd",	ugetcwd_main, 1},
 	{"lredir",	lredir_main, 1},
 	{"unix",	unix_main, 1},
 	{"dosdbg",	dosdbg_main, 1},
diff -urN dosemu-1.1.4.15/src/plugin/commands/commands.c dosemu-1.1.4.16/src/plugin/commands/commands.c
--- dosemu-1.1.4.15/src/plugin/commands/commands.c	Tue Apr 15 23:11:02 2003
+++ dosemu-1.1.4.16/src/plugin/commands/commands.c	Sat Apr 19 00:17:09 2003
@@ -148,7 +148,7 @@
 	struct com_starter_seg  *ctcb = owntcb->params;
 	char *s = lowmem_alloc(256);

-	LWORD(ecx) = 1024;
+	LWORD(ecx) = 256;
 	LWORD(edx) = COM_OFFS_OF(s);
 	do_doshelper(DOS_HELPER_GETCWD, 0);
 	com_printf("%s\n", s);


Bart

Re: ugetcwd / uchdir freakiness

[Stas Sergeev]

Hello.


"Bart Oldeman" <bart.oldeman@bristol.ac.uk> wrote:
>> I think sooner or later we'll have
>> to return back to the known-good
>> standalone-style tools:( 
>  the problem with those (well partly) is that we'd need to rely on third
>  party compilers ("invoke tcc via dosemu").
That's why I have put a backward smiley there.
I mean it would no doubt be much better
to keep using the builtin ones, and to
get rid of all the problems alltogether
only the comcom must be dropped in favour
of the much better FreeCOM. If this is
done, besides getting rid of all the
comcom's problems, 4/5 of the convoluted
coopthreads code can be simply thrown away
and the rest can be greately simplified.

Re: ugetcwd / uchdir freakiness

[Bart Oldeman]

Stas Sergeev wrote:
> "Bart Oldeman" <bart.oldeman@bristol.ac.uk> wrote:
> >> I think sooner or later we'll have
> >> to return back to the known-good
> >> standalone-style tools:(
> >  the problem with those (well partly) is that we'd need to rely on third
> >  party compilers ("invoke tcc via dosemu").
> That's why I have put a backward smiley there.
> I mean it would no doubt be much better
> to keep using the builtin ones, and to
> get rid of all the problems alltogether
> only the comcom must be dropped in favour
> of the much better FreeCOM. If this is
> done, besides getting rid of all the
> comcom's problems, 4/5 of the convoluted
> coopthreads code can be simply thrown away
> and the rest can be greately simplified.

that's a bit of a rigorous move and quite an overstatement -- FreeCOM may
be better in that is has TAB completion and does some of the DOS batch
file handling (the space problem we discussed with Clarence) a little
better; on the other hand comcom is better in that it has a persistent
command history (between DOSEMU sessions), the X title display, and
doesn't need to swap itself to XMS to be lean on DOS memory.

Also FreeCOM of course has the same problem as lredir here in that it can
also only be compiled with tcc. Well of course kernel.sys has the same
issues, but anyway.

All in all, I think that comcom is good enough as the basic command
interpreter, and those who want to use FreeCOM (or 4DOS or whatever)
instead know where to find it.

Bart

Re: ugetcwd / uchdir freakiness

[Stas Sergeev]

Hello.

Bart Oldeman wrote:
>> done, besides getting rid of all the
>> comcom's problems, 4/5 of the convoluted
>> coopthreads code can be simply thrown away
>> and the rest can be greately simplified.
>  that's a bit of a rigorous move
Yes but without it you'll never be able
to close the coopthreads' and comcom's -
related bugs on SF, which will mean the
1.2 will again have the bunch of an
unresolved severe problems.

> on the other hand comcom is better in that it has a persistent
> command history (between DOSEMU sessions)
Many shell programs like DosNavigator
adds this ability a dosemu-independant
way. Users who needs this, generally use
a dosemu-independant way for that.
I guess this can be easily implemented
as an option in a freecom as well.

> the X title display
Will take less than 5 minutes to implement
in a comcom-independant way - wanna see the
patch, just let me know:)

> doesn't need to swap itself to XMS to be lean on DOS memory.
What's the problem with this given
that this is how the things works in
an absence of dosemu?

> Also FreeCOM of course has the same problem as lredir here in that it 
> can also only be compiled with tcc.
No, it can be included in a dosemu-freedos
package.

> Well of course kernel.sys has the same
Exactly. The helper tools are dosemu-specific
so building them inside dosemu is logical -
they need to talk to dosemu anyway.
OTOH command.com is just a part of a
DOS distribution, just like the kernel.sys.
Handling these two differently is not
justified. We could just as well write an
internal NortonCommander etc...

> All in all, I think that comcom is good enough as the basic command
> interpreter, and those who want to use FreeCOM (or 4DOS or whatever)
> instead know where to find it.
Doesn't look like a real reason for
keeping such a headache with us (both the
comcom and coopthreads are known to be
problematic and there will be nothing
changed in the near future here, while
all the other problematic areas are
getting extensively patched). The freedos
package is required to run dosemu out-of-box
anyway, so the comcom's presense doesn't
help a lot also here.
So there might be other reasons I guess,
probably they are less technical though...