Date   : Thu, 11 Mar 2010 23:52:20 +0000
From   : theo@... (Theo Markettos)
Subject: Tube on the Archimedes

In article <4B994ABE.9000809@...> you wrote:
> Mmmm, problem. In driver code archive, /keyboard/KeybPC63.c
> The file is gibberish, with the top looking like:
>    <blah>PKLITE Copr. 1992 PKWARE Inc. All Rights ReservedNot enough
>    memory<blah>
> No "MZ" so not an EXE. Doesn't run as a COM. WinZip and 7Zip don't 
> recognise it as a compressed file (with or without .zip extn).

That says it's a PKLITE archive, which was a DOS compression program.  I'm
not sure if it's the same format as PKZIP.  The typo makes things
interesting - google for "PKLITE Copr." to find various thigns on it.  You
could give a DOS PKLITE executable a try.

> My question is if it would be possible to start up the x86 CPU for 
> running code only, with not only the machine being emulated, but Windows 
> as well.

Should be.  The distributed.net RC5 client had a module which would use the
x86 CPU for fast crypto cracking, which presumably just used the BIOS and
minimal x86 code (with no OS).  But I don't think source is available for
that module.

> I might look into the viability of some sort of app to run a 
> Windows .EXE (one at a time!) which will be drawn into and work 
> alongside the other RISC OS applications. Why? Because I believe it can 
> be done. :-)
> Nothing fancy. Minimal hardware support (PC speaker at best, no SB). No 
> fancy video modes. And certainly nothing sexier than Win3.11 (as little 
> as we can get away with to actually make it start to work!).
> 
> After all, isn't this _vaguely_ how WINE on Linux works? It is faking 
> the whole Windows environment. The only major difference in my plan is 
> we'll be talking two processors as the ARM won't natively do x86 code!
> [great, this means I'll need to learn some icky x86]

I'm not familiar with WINE internals, but running alien binaries is often a
case of emulating their syscalls.  The Tube does a roughly similar thing...
the parasite calls OSWRCH but the OSWRCH goes through to the host rather
than being executed natively.  A RISC OS layer on Linux (various exist)
would trap the OS_WriteC SWI and call the relevant Linux character output
code.  Repeat for dozens, hundreds or thousands of different syscalls.

I think WINE also has to reimplement a lot of the stuff that runs at DLL
level (it can run the native Windows DLLs too, but those are copyright
Microsoft)

Perhaps you could see if there are any similar projects out there for Win
3.1?  Might be neat to reuse some of that code.

Theo