[NTLK] Future Newton directions (very long)

From: Jim Witte (jswitte_at_bloomington.in.us)
Date: Sat Sep 11 2004 - 19:10:15 PDT


(note the subject change from Einstein)

On Sep 11, 2004, at 7:58 AM, Jon Glass wrote:
>> Porting to a "desktop OS" makes possible
>> explorations of what NewtonOS would really be like on a desktop, and
>> the *possibility* of bring more developers (as Simon Bell said in his
>> paper, "my goal is to have Mail V running on the desktop").
> You mean like running "rootless" in OS X? (i.e. no backdrop app... each
> app in its own window, like the rest of OS X?) Would then the HWR be
> accessible everywhere? (not that it's necessary...) or how about the
> soup structure? The whole thing gets confusing after a while, when you
> think "desktop"...

   Quoting Simon Bell, I was referring to a draft of his paper on his
Newtonscript Interpreter implementation. I don't know what exactly was
said at the conference..

   As to what "NOS on the desktop" would mean, I have no real concrete
ideas, but a few vague ones (see Part II). I'm just thinking - what if
the NOS were ported to something like an iMac? How would it work?
What would have to change? Those are the questions that would need to
be explored answered. My chain of thought is as follows. Be warned
though, as I've revised this while writing it, is has become basically
a draft for what might be a longer paper for WWNC 2005 :) So it reads
a lot like one. There are some spots marked with asterisks where I
have specific questions. Reviewers are welcome.. <g>)

Part I. What makes a Newton a Newton?

1. Things that Make the Newton unique (or almost unique)

        We all pretty much agree that part of what makes a Newton a Newton
aside from the physical things (form factor) are modularity,
"task-orientation", tight integration between all the "apps", and of
course the HWR and pen interface. The HWR of course is integral to the
Newton "concept", but it is also available (in varying degrees of
completeness) on desktop OS's, so it's not *unique* to the Newton.

2. Modularity

        The Newton doesn't force you to have everything and the kitchen sink.
Of course, MacOSX doesn't really either (you can choose not to use
things if you don't want to), but they're still there, and I think
their presence (used or not) still affects the apparent "complexity" of
the OS (from an human-computer-interface POV). I'd say that Newton is
much closer to the OpenDoc idea than MacOS.

3. Task-orientation

        The Newton is task-centric - you put something into your address book,
and then can access Eudora (or whatever mail program) from the *routing
button* - not by double clicking on an app. But the concept is not
that you think of accessing the *email program* - you think of
accessing a particular task via the routing button. Tasks are
emphasized, individual programs are not. Now, there are plenty of
exceptions to this - Mapper, ViewFrame, games, emulators. But notice
that Apple chose to call the extras drawer "Extras" and not "Programs"
or "Applications". I think Palm made a similar decision (I don't know
what they call their "extras drawer", but I don't think it's called
"programs")

        Along with this idea of being task-centric (and document-centric)
rather than application-centric. In Notepad, you don't think of
opening documents - you think of a "note roll" as being a collection of
objects (which also is exactly how the Newton organizes things
internally) Again, OpenDoc was designed to be document-centric.

3.5 An aside on task-centricity and the relation of HCI and programming
models:

        Related to this I think (although I'm not quite sure how - this had
been an idea of mine for a long time), is this idea that the
human-computer interaction and the underlying programming model of a
system are linked together in some way. The Newton's HCI is document
centric: you think in terms of tasks (or "parts" of your daily "PDA
routine") instead of discrete applications. You think in terms of
objects being part of these tasks rather than discrete documents. You
think about all the information in the PDA as being kind of all mixed
together heterogeneously rather than placed into discrete (and
homogenous) units of documents and (less homogeneous) databases of
various kinds.

        Now, look at the programming interface - on the lowest level, you do
have 'tasks' (although there is no real right correspondence between an
OS-task and something in the NewtonScript (NS interface you see). But
Apple decided to call them 'tasks' rather than 'threads' as is the the
standard in CS parlance (in engineering docs, they referred to them as
'light-weight threads', but not in the released programming docs. Why?

        You think of "parts" instead of applications, and objects instead of
documents. The programming model reflects this. You think of
information as being in a heterogeneous mixture - the programming
interface gives you the idea of soups, and objects. There *is* no such
think as a document - the closest thing is a template frame that goes
in a soup. There are only data entries, grouped into frames. This
idea of objects forming the basis for things rather than discrete
documents of necessarily extends down into the OS and the physical
storage media.

        I've wondered for a while about this seeming correspondence between
HCI and "programmer-computer interface" (PCI) as embodied in the
programming interfaces for the system. This is shown in computer
history a bit by the LISP machines: although I know very little of the
history of LISP, I believe the general idea was to think about "atoms"
of language and data rather than rather linear-organized streams
(files). So in the programming, you have atoms and lists (which can be
easily manipulated, as opposed to a linear bit-file). In the Symbolics
machines, these ideas were even carried down to the hardware level.

        With the general paradigm of a 'windowed-computer' interface, the HCI
is to have different windows (objects) that the user can interact with
at once. Inside the windows, you have smaller objects (controls) that
the user interacts with instead of typed-in commands. To varying
degrees, this object-orientation is reflected in the programming
interfaces; the original MacOS had "implicit" object-orientation (as
opposed to modern OO programming) - using structures such as GrafPorts
and WindowRecords and functions that worked on them. In the Windows
world, you have the Microsoft Foundation Classes, which (whatever else
you think of them) ARE object-oriented. The BeOS was thoroughly OO -
everything was an object. Two examples of this difference between OO
programming and non-OO programing environments are CoreGraphics vs.
QuickDraw, and OpenGL (at least OpenGL 3 or 4 years ago when I looked
at code snippets in MacTech) vs Quickdraw3D, although I am not sure how
much OpenGL has moved in the direction of more "OO-ness" in recent
years (*). I will not talk discuss these at length here as they are
not particularly germane (as this whole section 3.5 is not particularly
germane) to the discussion of the Newton and it's future directions.
The NewtonOS is quite the same way. Is was object-oriented from the
get-go.

(Now, back to the "user-land" discussion..)

4. Tight integration

        You add an address to the address book. Immediately it is available
to your email "app" (or task), your fax app, phone logger, meeting
planner, whatever. MacOSX is I think just beginning to get to this
level of integration (you go to the Address Book, and from there can
access Mail, iChat, etc. In Mail you can go to iChat, etc) OSX (like
NextStep before it) has Services, which let you integrate a great deal.
  Although, IMO, the potential for integration allowed by services is
"overshadowed" by the general appliciation-centricity of the MacOS,
making them slow for developers to adopt, and for users to use. It's
interesting that Jaguar added the "routing (action) button" to the
Finder (even though it really isn't - it's just the contextual menu).
One wonders what it could (and will) become in future MacOS's (if
anything more than just a contextual menu button)

        As another aside back to section 3.5, this tight integration on the
HCI level I believe is also reflected in the programming interface -
there are none of the typical "protection" boundaries afforded by files
or even C++ objects ('private' and 'protected' fields) present in the
NS layer. Any "part" can access the data of ANY other part on the
system if it knows how to get to it (the object's path). Or perhaps
"of the system" is a better way to put it? Linguistic metaphors change
too: applications are *on* a computer, parts of pieces *of* a larger
system. If you talk about "applications of the computer" you are
*already* implying a task-centric viewpoint - "What are the
applications of that specialized system you just bought?" - you're not
talking about the actual *programs*, but about what you *do* with them)
  This lack of protection has been criticized somewhere (* anybody know
where?) as a weak point of the NOS.

5. Handwriting recognition and pen interface

        HWR is central to the Newton, as is the pen-interface ("users should
be able to operate all controls and input all data solely with a pen."
[User Interface Guidelines 2.1]) But the Newton was built with this in
mind from the beginning, unlike Microsoft's TabletPC OS (* what is is
called?), onto which a pen-interface was kind of "shoe-horned" into the
design. By shoe-horned, I don't mean that the interface will not
*work* with a pen - it will. But it is not designed primarily with a
pen, and a pen-based user, in mind. For example, one criticism made in
comparing the Newton to the PocketPC (* reference) was that on the
early PocketPC OS (at least), all the menus were at the top of the
screen, which is slightly harder to get to with a pen. On the Newton,
most of the explicit menus and buttons (the main exception being
pickers) are at the bottom of the screen. This is a small detail, but,
as Apple interfaces often show, it is the *small* details that can make
the difference between a truly easy-to-use interface, and one which is
slightly-to-moderately clumsy (as evidence by a recent comparison
between the iPod and the new Sony disk-based ATRAC walkman (* somewhere
in the Wall Street Journal).

Part II. Where might the Newton have to go to be a viable desktop OS?
(This is where this psudo-paper really gets in need of red-ink and
revision..)

1. What do people expect in a modern desktop OS, in terms of
functionality.

        Notice that I said functionality. People want the ability to switch
between tasks and have the computer respond immediately, not after the
current app decides to give up some processor time. And so we have
preemptive multitasking instead of cooperative multitasking. But the
user does not *care* how the system actually implements it.

        That said, what people expect from a desktop OS does (and must, to
some extent) affect how the system is implemented underneath. To have
multiple apps that can do things at the same time requires some kind of
multi-tasking. The NS environment is basically a single-task
environment, but co-operative multi-tasking is possible with the FFork
functions (* bowels note).

        What else do people expect? I don't know - so I'll list what *I*
would expect. I'll start with hardware, and then move to software:

a. Communications protocols: Ethernet and Wifi at least, with Bluetooth
becoming more important all the time, and possibly WiMax. This is
mostly already done (or at least started).

b. Modern printer communication is a must, as is network interchange.

c. Ability to write to standard formats, logical (Word, RTF, PDF, XML)
as well as physical (ATA media of various formats).

d. Web support for forms (X-Forms in the future) and SSH are necessary.

        In terms of a "modern HCI", I would expect:

a. Ability to run multiple apps/tasks if I want to, and to be able to
switch between them. Ability to have things running in the background.

        I don't know what *else* goes on these lists. That's why I said at
the beginning that I have no real concrete ideas.

2. Which of these can already be done or easily implemented on Newton,
and what can't..

        The communications pieces mentioned above can be done relatively
easily, as p-classes, or at worst as C++ extensions to NS programs.

        As mentioned before, cooperative multitasking in the NS layer is
possible. This will work, but may be undesirable, as the FFork
interface is rather primitive. The OS underneath is preemptive, but
there are problems with taking this up to the user layer (I think).
First, it is not clear that the Newton object reference system (the
object heap) is designed to deal with having multiple preemptive
threads all having claims on the same object. The garbage collector
would probably have to be modified. And a suitable NS-layer
programming interface for dealing with true preemptive threads would
have to be made, as well as a way of dealing with variable
synchronization/locking issues.

        Perhaps the biggest problem concerns how to make the graphics
environment work in a preemptive user-level environment: Mac
Quickdraw, on which NewtonQD is based, is not reentrant - it does not
deal well with having one call being made, then interrupted (by the
preemptive scheduler), and another call (possibly) the same one, made
(* references)

        There is some locking of the QD done while drawing is being performed,
although I am not certain yet whether it is consistent, and when it is
absolutely necessary (the first QD demo I made for instance did not use
any kind of locking, and yet never did anything strange when I ran it
many times, even though the OS displayed the BusyBox in the middle of
its operation). If a second interpreter is added to the system,
running preemptively alongside the Newtonscript interpreter, an
arbitration layer to deal with how which of the two systems would use
Quickdraw would be required.

        But it is all together possible that in the software future of the
Newton, the original QuickDraw layer will be replaced - all the calls
formerly made to QD will be shunted to some other layer using
CoreGraphics, X-Windows, OpenGL, or something else. This may even be
desirably (as it allows easier use of color, 3D graphics, etc),
although it does limit somewhat the ability to port to hardware for
which such a "host graphics environment". Although, an x-windows
environment could be added, for instance from a FreeBSD distribution.

3. What differences to the programming environment(s) on the Newton
would have to be made or would be made in time?

        This is the question that interests me the most. As mentioned above,
if user-level preemptive multitasking was added somehow, the NS
programming language would have to grow to accommodate it. There are
no hints that I know from released documentation of how this would be
done, or if it was even planned by the time the Newton was shut down.

        The Newtonscript Guide has an appendix explaining how to approximate
traditional class-based OO programming within the Newton's
parent-prototype OO system. In "NewtonScript 3.0", true class-based
programming would likely be a reality, as it is in Java. If a
user-level preemptive-multitasking system is created somehow, some way
to access that from the NS layer would have to be invented. This would
most likely take the route of Java, where different objects implement
the Runnable interface, and then can be put into Thread objects (excuse
me if this terminology is wrong - it's been a while since I've looked
at Java), or the POSIX threading model. But how does Newtonscript
expand to allow thread-based programming, while maintaining it's
simplicity?

4. New Toolchains

        There are two main toolchains for doing Newton program on the Mac -
Newton Toolkit for producing frame-based packages, and Newton C++ Tools
for making C++ and assembly extensions to NTK projects, and writing
p-classes, ROM extensions, and probably other things as well. There is
an option in the Packer tool for processing -frame files - it is
conceivable that it is possible to create entire packages inside the
MPW environment. There may even be a NewtonScript compiler MPW tool
somewhere in Apple's "vault". This option of the Packer tool may have
been explored.

        However, both NTK and MPW have one main weakness on the Mac - they
only run under Classic in MacOSX, and even then, NTK is somewhat buggy.
  On the PC, WinNTK will work (although I am told it is buggy). There
is no easy way to compile C++ code on x86 platforms into Newton format,
although it *is* possible - Roger Milne made his own packer tool to do
just this when he compiled the core of ModPlayer in assembly on the PC.
  The file formats for MacNTK and WinNTK are not interoperable. Beyond
this, there is no close integration between MPW for C++ development and
NTK for package development - meaning that one program can be used to
do both types.

        There is an project to create xCode/GNU-compiler compatible NCT tools,
as well as a project to create a Cocoa NTK builder, which would
interoperate with the GNU tools. However, this does not address the
x86 platforms.

        In a "desktop NOS" scheme, cross-development with another machine
makes little sense. Something similar to an expanded version of
NewtDevEnv would be needed. This addresses NS development, but does
not address C++ development. It is possible that the GNU/ARM C++
compiler could be ported to the Newton in C++. However, as both of
these probably make heavy use of POSIX threading, as well as extensive
use of "traditional" (rather than object-based) file systems, this
could be problematic. Is is conceivable that traditional file
operations could be based out of VBOs. Another route is to discover
how to use file-based operations inside the NOS itself - all the
routines for the standard C library are there, as well a number of
functions appearing to relate to file I/O as well as input streams
(though curiously, apparently no output streams).

III. Conclusion

        The possibility of Newton on a desktop, which perhaps not a
particularly exciting idea, is one that should bear some thought as the
software future of the Newton is decided. One downside to a
"desktop-NOS" is obvious - that the NOS was *not* designed as a desktop
OS. But, can the eMate be considered a desktop computer? Certainly
not in terms of speed, but what about the planned 'bMate' which would
use the faster StrongARM processor? Had the Newton program been
continued, would Apple have made eMates (or bMates) with larger
screens? These are questions that don't have answers (though perhaps
speculations by certain people under NDA..) Another downsides to a
desktop-NOS are that it would siphon resources away from porting NOS to
other PDAs - although, many of the features I outlined above that are
desirable in a desktop computer are *also* desirable in a a modern PDA,
though not all. A third downside is that there are alrady a number of
"alternative" desktop OS's out there (I consider 'dominant' OSs to be
Windows and MacOS, and MacOSX). However, as pointed out in one post to
Slashdot about the "Acorn" nano-kernel OS (* reference), there are a
great many small, little used, "micro-OS's" out there. It is not clear
then that the addition of one more is any great downside.

        One possible benefit of a "desktop NOS" (this is kind of proportional
to how accepted "desktop-NOS" becomes among users) is that it might
possibly that it could attract more developers. That depends on
whether there is a larger market for small, niche desktop-OS developers
or small, niche PDA-OS developers. I don't know the answer to that
question either.

   Perhaps the best place to end this (very long) essay is where it
began, and to ask Simon Bell, "Why do you want to run Mail V on your
desktop?".

Jim Witte

-- 
This is the NewtonTalk list - http://www.newtontalk.net/ for all inquiries
Official Newton FAQ: http://www.chuma.org/newton/faq/
WikiWikiNewt for all kinds of articles: http://tools.unna.org/wikiwikinewt/


This archive was generated by hypermail 2.1.5 : Mon Sep 13 2004 - 09:30:01 PDT