sharp@yale.ARPA (Oliver Sharp) (05/04/86)
I grabbed a copy of MicroEmacs 3.5 from net.sources, courtesy of Daniel Lawrence (thanks much for posting it!). Since I use a VT52 device driver for the console, I defined MSDOS and VT52. I also made up a new define called MSC and set it. After going through the code, I made a few minimal changes (needed only where there is a #if MSDOS). I can describe these, if someone needs me to, but I won't bother here. I then compiled it and ran it. Stack overflow. Next I made the stack 60k. Stack overflow, but it took longer. I shelved it for a while, and went back yesterday to figure it out. The problem is the routine ttgetc in termio.c. It currently does DOS call 6 (int 21h, call 6, which is Direct Console I/O) repeatedly, checking the return value of intdos(). Apparently in Lattice, the value intdos() returns is the flags register. In MSC, however, the return value is AX. If the zero flag is set by the DOS call, there is no character waiting. Unfortunately, AX is always zero after the call, so ttgetc thinks it got a character and returns 0. When ttgetc returns a zero, the routine that called it, getkey(), thinks the character typed was Extended ASCII. In Extended ASCII, characters like Home, PgDn, the arrows, etc. are converted into two bytes - a 0 followed by a special code (see Tech Ref or the BASIC manual). getkey() thinks that it needs to call ttgetc() again to get the second part of the character. Here is the problem - it recursively calls itself to get the next character. Personally, I don't think this is really a great idea, but if everything was working it wouldn't cause any harm. This recursive call then invokes ttgetc again, which returns a 0, so getkey() calls itself ... stack overflow. The most obvious solution is to modify the code so it gets the flags properly, right? Surprise ... you can't. In MSC, all the routines that access DOS or the interrupts remember ONLY the carry flag. This is annoying, to say the least, since it means you can't use the old DOS calls. However, for the purposes of this program, the solution is easy. Just make one call to DOS function 7, which is a blocking console input. It is tacky to make all those calls to function 6, anyway, since that will really futz up a multi-tasking DOS and is ugly. Get rid of the while loop, ignore the flags, etc. - just make the one call. This will work with both LATTICE and MSC, so you don't have to bother with more conditional compiles. The only other major change I made was to spawncli() in spawn.c. It calls system() with two arguments, which doesn't make any sense to me. Since I use a different switchar, I didn't want to use system anyway - system(foo) executes the following line: command /c foo. This obviously doesn't work too well for me. My solution was to: spawnlp(P_WAIT,"command",NULL). This just executes command.com, assuming that it is in your path. If you don't like that, for some reason, you can look up the COMSPEC with getenv() and assemble the call directly. You can also use system, if you don't use a different switchar. So far, the editor seems to work well. The code is quite clean, for those of you who might want to hack it - nicely structured with sensible identifiers. I hope this helps some people; if any of it wasn't clear, feel free to drop me a line. Have fun ... Oliver Sharp ...!yale!sharp
jmg@cernvax.UUCP (jmg) (05/13/86)
In article <2468@yale.ARPA> sharp@yale.UUCP writes: > > I grabbed a copy of MicroEmacs 3.5 from net.sources, courtesy of Daniel >Lawrence (thanks much for posting it!). then he managed to get it to work, after various problems. I have been trying to get the bl--dy thing working here, where we have a PC cross-compiler and some awful incompatible assembly-code library. Needless to say, I am stuck. Therefore, if it doesn't upset too many people, including legal beagles, how about an encoded version (yes, I saw all the discussion on sending binaries over the net!)?
caf@omen.UUCP (Chuck Forsberg WA7KGX) (05/17/86)
In article <312@cernvax.UUCP> jmg@cernvax.UUCP (Mike Gerard, DD Division, CERN.) writes: >In article <2468@yale.ARPA> sharp@yale.UUCP writes: >> >> I grabbed a copy of MicroEmacs 3.5 from net.sources, courtesy of Daniel >>Lawrence (thanks much for posting it!). > >then he managed to get it to work, after various problems. >I have been trying to get the bl--dy thing working here, where we have >a PC cross-compiler and some awful incompatible assembly-code library. >Needless to say, I am stuck. Therefore, if it doesn't upset too many >people, including legal beagles, how about an encoded version (yes, I >saw all the discussion on sending binaries over the net!)? I have a copy of an earlier version of emacs.exe compiled large model available for a while in /usr/caf/public/PCDOS/emacs.exe. Use the L.sys entry below for DDD access with a uucp command. Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf CIS:70715,131 Author of Professional-YAM communications Tools for PCDOS and Unix Omen Technology Inc 17505-V NW Sauvie Island Road Portland OR 97231 Voice: 503-621-3406 TeleGodzilla: 621-3746 300/1200 L.sys entry for omen: omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp omen!/usr/spool/uucppublic/FILES lists all uucp-able files, updated hourly