On Fri, 25 May 2001 03:54:31 -0700, Willow Schlanger wrote:
>Then we could actually "staticly translate" it so that we'd _see_ what's
>going to run at CPL 0 and _translate_ it, in advance, to code that we
>can actually run at CPL 0 (_after_ translation).
That's exactly what things like Wine and Odin (a Wine-like environment
for OS/2) do. They effectively relink the applications to run with
libraries built for their environment.
>We could also make it so that calls to the Windows kernel could be
>"trapped" similiar to the way Plex86 traps "bad" instructions. Those
>calls could, if the MultiPlex86 slave PC were runnig Windows, then cause
>the slave PC, which _actually_is_ running Windows, to make a
>corresponding call. The Slave PC would be running Windows
>_inside_Plex86_.
This is *exactly* what Wine and Odin do. The problem here is that it's
not 100% compatible, like running the real OS code would be.
It's also working at a completely different level. Comparing such
technology to Plex86 is like saying, "I don't have an Ethernet link
light. Maybe I should change my TCP/IP settings." Plex86 is like the
link light: a low-level method of converting applications. What
you're describing happens at a *much* higher level. Both are valid
ways of approaching a problem. They have very different goals,
however, and really aren't compatible.
>The changes the slave PC makes to hardware would be noted by the slave
>PC but not told to the guest / host PC. Only the _end_effect_ ("output")
>of a Windows kernel function would be told to the host PC. That PC would
>then simulate those effects.
That's called Citrix WinView or Microsoft Terminal Server. That's
exactly how they work: GDI calls are split between the host and client
machine. Again, a very different process.
>To do this we'd map out the windows kernel functions and emulate
>executing them, like a web crawler. If there were a
>
>MOV EAX,5
>
>instruction that at that place we'd store the _old_ value of EAX so that
>we can walk BACKWORDS, undoing the modification.
Here's the problem. That may work fine for a simple instruction like
you've hilighted. But what about moving a value into real RAM? Or
even worse, writing a value to an I/O port or VGA memory? The amount
of information you need to keep track of on *each* and *every*
instruction is staggering. You would need a complete snapshot of the
*entire* machine before *each* instruction. Things like the complete
status of the VGA card, and every other device within the computer,
etc. etc. Even very simple instructions can have side effects that the
CPU is completely unaware of. Even perusing the source code can only
do so much. Imagine an app that reads from a data file and uses data
within that data file as the target for a memory write? What will that
address be? Who knows?
>All instructions would have 2 inputs: stdin, auxin and one output:
>stdout.
Again, seeing as the exact same instruction can have a *myriad* of
different effects, there is *no* way that such a limited number of
streams would ever be *close* to working.
>Thus we have reverse engineered a function.
Yes, but what about I/O? Or something that *cannot* be divined by the
source, such as code that depends upon data read from the hard drive?
>Award could have called the function with AH = 1, 2, 3, and they know
>what it does, and then said, "what if I call it with 4?"
>
>And they'd get get 2.
>
>Then they'd try all 256 values (actually, just enough to convince them
>it's a linear function, y = x - 3) and then they'd have a table, like
>so:
A **PERFECT** example of what I'm trying to highlight. There's a lot
more that goes on within a BIOS call than just input and return value.
What about what the function actually *does*? That cannot be
determined simply by examining return value. After all, the vast
majority of function calls actually do something *else* besides return
a value!
>Then they _own_the_copyright_ for a 100% compatible function.
But a function that doesn't do anything but return values!!
Anyway, I'm not going through the rest of that document. There's just
too much you've overlooked.
Tim Massey
