mark@digi-g.UUCP (Mark Mendel) (11/01/84)
Apparently kermit is supposed to be compiled with IBM's MASM, not Micro-softs. I have fixed the incompatablitiy that generates compile errors and it runs. However, perhaps it is responsible for the problems I still have: None of the `sub-process' commands work: DIR, RUN, etc. I end up in a sub-COMMAND processor that complains `Ilegal COMMAND path' or some such. The environment is not being passed. I have traced through the bloody thing to the EXEC command. And it looks IDENTICAL to calls that work in some of my programs. Does anyone have it working? Does anyone have a version that compiles with Microsoft MASAM and works? ---Mark Mendel ---ihnp4!umn-cs!digi-g!mark
rde@ukc.UUCP (R.D.Eager) (11/07/84)
The IBM PC version of Kermit can be assembled with Microsoft MASM
with no trouble. However, later versions of MASM (I have 1.25) make
more stringent checks on the source, and fault the use of LEA on a code
label. Version 1.00 (and presumably the IBM assembler) let it through.
In fact the correct code is generated so you can ignore the error.
A more sanitary solution to the assembly-time errors is to replace
the LEAs with what they should have been to start with. Since the
references are not modified or indexed, just the OFFSET will be
correct. So:
Replace LEA reg,xxx by MOV reg,OFFSET xxx
I have done this and it all checks out OK.
Now, the DIR/COMMAND bug. Although the documentation doesn't say
so, it is critical in which order the segments are linked (segments, not
files). The DEC Rainbow Kermit-MS has a dummy file which should be
linked first to do the job; I wrote a similar one from memory which
works fine. Here it is:
name msxdmb
datas segment public 'datas'
datas ends
code segment public
code ends
stack segment para stack 'stack'
stack ends
ends
I haven't tried the Rainbow one since it was on a distant (non-Kermit)
machine at the time, although I am pretty sure that the important thing
is to have the stack segment last. To use this, simply assemble it and
give it to LINK as the first object module; this will force ordering of
later modules into the correct sequence.
The explanation is that Kermit determines how much memory it is
using so that the excess can be returned to DOS before the EXEC call (I
am not sure if this is necessary; different documents give conflicting
stories). The memory determination is done by subtracting the address of
the Program Segment Prefix from that of the end of the stack. If the
stack isn't the last segment, DOS loads COMMAND.COM right over Kermit,
trashing the code, the data areas and even the parameters passed to
COMMAND.COM!
It may be that Kermit was developed with a linker (IBM's?) that
orders segments differently. Anyway, there it is. It works for me.
Bob Eager (University of Kent, UK)
(...!mcvax!ukc!rde)