earleh@dartvax.UUCP (05/17/87)
I have received a number of requests for microemacs 3.8 for the Mac,
which I do have running and have tested, at least casually, on all
of the following machines: 512k, 512KE, Mac+, SE, Mac II. (Let me
say that I was impressed with the performance on the Mac II.)
I have been considering posting this again (a previous post apparently
never made it to the moderator of comp.binaries.mac.) There are two reasons
which I have declined to do so.
a) The present implementation uses a keymap resource that uses
the keycode returned by GetNextEvent to look up the ASCII
value corresponding to a key. Doing it this way allows use
of the option key as a META key, and allows patching two
shortcomings of the Mac and Mac+ keyboards: no escape key,
broken cursor keys. Apparently, the new Macs do something
sensible regarding cursor keys, and since I do not know
the keycodes for either the cursor keys or the escape key,
these keys do not work with the program on the SE or Mac II.
So, here is the key situation briefly: The keymap used by
microemacs for the Mac can be reconfigured using ResEdit,
without recompiling the program, but I can not do this
just because I don't know the keycodes yet! I don't want
to post a program that does not work COMPLETELY on all
machines, because then you would think I was a sloppy
programmer. I do not have time to find out the keycodes
by experimentation, because the Mac II and SE are in my dealer's
showroom, surrounded by people dying to try them out, and
because I have other things to do. Maybe someone will send
me a short note giving the keycodes for SE and Mac II keyboards.
Better yet, post this information, so we all can know.
b) Based on the following:
>>In article <1953@husc6.UUCP>, stew@endor.harvard.edu (Stew Rubenstein) writes:
>>>
>>> All programs compiled with LightSpeed C WILL BREAK, GUARANTEED 100%,
>>> when Apple comes out with a 32 bit operating system for the Mac II or
>>Is this a general compiler problem, or is it, rather, specific to some
>>of the runtime libraries?
>
>When I said "all" I meant "all." Even if you don't even include MacTraps.
>The problem is in that little bit of code in segment 1 that gets prepended
>to all (that means every one without exception) applications.
I decided to look at the offending segment with a disassembler,
and I was NOT PLEASED with what I saw. I have mailed a source
disk to Dave Burnard, who collaborated with me on this project,
and who has MPW C. Perhaps he will get the program running
with the MPW C compiler and post the results. I can assure you
that the version I have now runs without flaw on the Mac II,
except for the unknown keycodes and the as-yet-dreamed-of 32-bit
operating system.
So, now you know the facts, as much as I do. I can post the program
if I get the keycodes and if I get enough positive response to this
article. However, I would much rather have someone get a disk from me
and build the program using a C compiler we all can trust. I don't
like the idea of posting a program that may break eventually and give
someone grief.
If you simply MUST HAVE this program, then mail me a disk and a
post-paid mailer, and I will send it to you right away. You will get
three copies of the program:
1) The "slow" version, that works with the Macintosh Memory
Manager and can return memory to the operating system if
needed.
2) The medium speed, safe version, which keeps all the memory it
gets but only grabs RAM as needed. This version is the most
extensively tested, and the one I recommend for daily use.
In this version of the program, buffer memory is never
returned to the OS.
3) The "fast" version, still in the experimental stage. This
version loads all of its code and resources, makes them
non-purgeable, then grabs from the operating system the
biggest chunk of RAM it can safely get for buffer space.
This version is the most fun to use, but requires a MEGA-
byte to run well in and crashes the Mac II at present.
(Question: does the 68020 use a bigger stack space than
the 68000?)
I do not want any of these programs posted or archived anywhere
until the two problems mentioned above are resolved. If I mail you
a disk, you are on your honor not to do either. Giving it to friends
is of course OK, since they can blame you rather than me if they have
problems.
Mail:
Earle R. Horton
23 Fletcher Circle
Hanover, NH 03755
--
****************************************************************************
* Dot seegnachur? I don' got to show you no steenkeen dot seegnachur!! *
****************************************************************************