🚀 go-pugleaf

In article <5624@zodiac.UUCP> pkahn@ads.com (Phil Kahn) writes:
>But the bad news for me and everyone else oout there doing large
>system development (e.g., research, engineering, etc) is that MacOS
>does not have virtual memory.

Agreed!

>I understand that virtual memory will likely blow away at least 1/3
>of the software commercially available (due to hooks, etc), but it is
>required to do any serious workstation development.

This needn't be so. It would be easy to build a page map that would in
effect leave the old applications seeing exactly what they see now.
One way to differentiate would be to introduce an ABTS (Address BiTS)
resource into the newer software that indicates that 32 bit mode is
okay.

In many regards, a more serious problem to large software developers
is the format of the CODE resource jump table.. For historical reasons
(the 68000 only had 16 bit indirection for branch indirect), CODE
segments are limited to 64K.  More important, the global data segment
is limited to 64K. Both of these facts introduce hassles that are
solved by either

	1. Allocating the big stuff dynamically - loses if you have to
	   initialize it.
	2. Compiling the program to live at a fixed address - loses on
	   compatibility.

In my opinion, it would be desirable to introduce a COD2 resource
whose jump table permits 32 bit offsets (which are supported by the
68020 and 68030). Granted such software would be runnable only on the
Mac II, but that is fundamental - programs that big won't run in 1M.

This imposes a big limitation on things like TeX, LISP, and lots of
other things.

I have looked at it, and ever since the 64K resource bug was fixed I
think it may even be doable compatibly.

Any takers, Apple?  If I can find a way to do it and persuade my
bosses to let it go will you adopt it?

Jon Shapiro
AT&T Bell Laboratories