Path: utzoo!mnetor!uunet!ndsuvax!ncoverby
From: ncoverby@ndsuvax.UUCP (Glen Overby)
Newsgroups: comp.os.minix
Subject: Re: ELLE vs. MICROEMACS?
Message-ID: <610@ndsuvax.UUCP>
Date: 5 Jan 88 15:45:34 GMT
References: <918@louie.udel.EDU>
Reply-To: ncoverby@ndsuvax.UUCP (Glen Overby)
Organization: North Dakota State University  Fargo, ND
Lines: 35
Summary: 64K text space isn't enough

In article <918@louie.udel.EDU> WANCHO@simtel20.arpa (Frank J. Wancho) writes:
>Has anyone tried porting MICROEMACS into the MINIX environment and

I attempted MicroEmacs 3.6 and MicroGnuEmacs this past June, and was not
successful.  As I remember it, all of 3.6 compiled except for the large
auto-initialised structure, which seemed to cause cg to go into an
infinite loop.  I dont remember what happened to MicroGnu. 

More recenly, Freeman Pascal (also here at NDSU) tried compiling 3.8i
and MicroGnu.  On 3.8i he ran into the same problem with cg as I did,
but did get MicroGnu to compile.  When it ran, there was not enough
stack to come up. 

>I've mentioned this program to Dr. T, and he expressed several
>concerns, including ease of port, small model limitations, linkability
>in the MINIX world, maximum size of files in both individual buffers
>and total, and whether the buffers are cached as ELLE does.  I don't
>have those answers.  Maybe somebody else does?

Both current MicroEmacses are based on the origional MicroEmacs version
30 by Dave Conroy which holds all buffers in main memory.  On Minix this
would be one segment-- not enough when you're tring to edit
kernel/tty.c! MicroEmacs 3.9e will not run under MS C with "compact"
model (<64K text, >64K data), but it does run under the "medium" model,
I believe (I didnt compile it under MS-DOS myself). I dont know if there
was a 64K buffer size restriction on large model or not.

Furthermore, if the file you are editing does not fit into memory, it gets
truncated. There is an error message about not being able to allocate memory
when you load the file, but no protection against clobbering the old copy,
as well as no .bak file.
-- 
Glen Overby
Bitnet: ncoverby@ndsuvax 
UUCP: uunet!ndsuvax!ncoverby