[GEM Development] DayDream (was NextGem..)

[John Elliott]

: If you want to use liunx, perhaps you could make a tightwound linux with =
: 386 options.
: You'd use X and a GEM/WM (which would look similar to the latest TOS).
: Then you could make a WINE style API-Hook and run multi-threaded GEM =
: apps.

  The problem is that the internals of GEM are, to put it bluntly, ugly. 
Quite a lot of the API is designed around the assumption that the programs,
accessories, AES and VDI all share an address space - which makes it very
efficient on a 512k XT, but starts biting you as soon as you get into 
protected mode. I met some of this with my DJGPP experiments, but at least
there you could share the lower 640k of memory.
  I think I've got the AES/VDI connection sorted now; it supports using a 
16-bit VDI in DOSEMU and a 32-bit AES running natively. It should even be 
possible to make it work between computers over TCP/IP. But how can 
rsrc_load() be handled sanely? 
 
: I reckon it'd also be tops to get a GEM-VM like a java VM.
: Nice and easy to port I'd say..

  Please explain. A GEM VM that runs existing (x86 GEM) programs on a
hypothetical future 32-bit GEM? Or a VM that runs Java bytecode - or some 
other bytecode - inside an existing GEM?

------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott           |BLOODNOK: "But why have you got such a long face?"
                       |SEAGOON: "Heavy dentures, Sir!"    - The Goon Show 
:-------------------------------------------------------------------------)