The problem with the .EXE is when you try to call out to the graphics and
file syscalls.  Symbian has (or "have" in the UK) provided a console
interface and most of libc for quick porting of UNIX-ish code, but the .EXE
route was intended specifically for "server engines" that do calculations and
data manipulations on behalf of "real" apps constructed in the awful way EPOC
expects.  There is a way to do things more easily than that, but it still
requires removing the static variables (i.e., I don't have to rewrite the
interpreter as a C++ program except for a trivial "jacket") which may turn
out to be useful for other platforms anyway.

Even going directly to the hardware is a problem, if you were thinking that
way - besides, I'd like it to work on Tim's Netbook in addition to my S5, so
it should be constructed as a more-or-less well-behaved EPOC app.  I won't
have to worry about fonts, cut-and-paste, keyboard decoding and pen input,
either.  And, if Tim likes Squeak on the Netbook, it would be easier to
convince my wife to let me buy one.

Ed

Dean_Swan at Mitel.COM wrote:

> From:  Dean Swan at MITEL on 10/03/2000 12:18 PM
>
> Tim,
>
> >That sounds pretty good; wish it had been in that state when we needed
> >it for the Interval pad work! Note that they support ARM - which might
>
> >    And maybe even the new ARM powered gamboy-thingy.
>
>   I think the OSKit would be substantial overkill for the ARM based
>   gameboy.  All the hardware is custom, so you won't exactly be able
>   to re-use device drivers, and probably won't want to "pay" for the
>   extra overhead either.  I suspect the same would have been true for
>   the Interval Pad, unless you were using PC-ish hardware for your
>   peripherals.
>
>   While on the topic of Squeak on ARMs, I was looking over the dreaded
>   EPOC32 SDK this weekend, and based on comments you and/or Ed have made,
>   I'm wondering, why wouldn't you just target the port for an EXE rather
>   than an APP?  EXEs don't have any restrictions regarding writeable
>   statics, and they run in their own process, which is the case for
>   nearly every OS I can think of (except EPOC, of course).
>
>   It just seems like EXEs are the most straight-forward way to port
>   existing code to EPOC.  Am I missing something?  I'm sure I could be
>   since the EPOC documentation is "a little" hard to follow.
>
>   I also started looking through the generated code for 'interp.c' to
>   see if I could find where the static variables declared in it come
>   from.  I'm guessing that class variables and anything in the System
>   Dictionary would be candidates?
>
>   I was thinking that Squeak on an 18.432 MHz ARM 710 on the S5 would
>   give a very good idea of how it would perform on the 16.78 MHz
>   ARM 710T in the new Gameboy.
>
>                                          -Dean
>
> Tim Rowledge <tim at sumeru.stanford.edu> on 10/02/2000 01:22:10 PM
>
> Please respond to squeak at cs.uiuc.edu
>
> To:   squeak at cs.uiuc.edu
> cc:    (bcc: Dean Swan/Ogd/Mitel)
>
> Subject:  Re: SqueakOnLinuxFramebuffer getStatus.
>
> Jecel Assumpcao Jr <jecel at mail.merlintec.com> is widely believed to have
> written:
>
> > You can borrow drivers from Linux and BSD using the OSKit:
> >
> >       http://www.cs.utah.edu/flux/oskit/index.html
> >
> That sounds pretty good; wish it had been in that state when we needed
> it for the Interval pad work! Note that they support ARM - which might
> just make it interesting for something on the compaq handheld. And maybe
> even the new ARM powered gamboy-thingy.
>
> tim
> --
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Strange OpCodes: SDL: Shift Disk Left