Microsoft isn't exactly making any great leaps and bounds in it's OS's.
The kicker is to have NT-based OS's bootable under Plex86. All new MS
OS's are going to be based on that. And their need for backwards
compatibility will continue to be the opportunity to keep up with the
changes they make to their system. I would think they'd have to make
drastic changes to how they talk to the hardware to escape Plex86's
clutches.
Blue Lizard wrote:
>
> I'm sure kevin would like any help or testing he can get. Although the
> idea is to get away from this secondary windows presence depend, it
> still is a large point of hesitation for many. Here is an announcement
> from May 14 that appeared on the site (plex86.org). It should be
> converted to plain text but the html is so much prettier. I once saw
> this thing on the mandrakesoft.com labs section that said to expect a
> significant and reasonable enduser app by early-mid spring 2001. hehe.
> But at least they finally getting somewhere. Too bad as soon as win98
> is usable through plex with perfect charm and ease XP will be old and
> stale. I go vomit now, too much win talk for me.
> *Phase #1 of DT integration: test release available.
> Monday 14th of May 2001 @ 07:11 pm GMT
>
> *
>
> The first phase of the DT integration is nearly complete.
> FreeDOS/Linux/Win95 all boot again in plex86 using the
> new Dynamic Translation architecture. You won't see
> performance gains until Phase #2. This version is
> for plex86 testers only.
>
> It's available at :
> ftp://plex86.org/source-tarballs/plex86-2001_0514a.tar.gz
>
> Here's a copy of the email I sent to the developers list:
>
> - "Kevin P. Lawton" <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>: Mon
>May 14 14:03:20 EDT 2001
> Integrated a lot of new DT architecture (from dt-testbed/proto4) into
> plex86. Eliminated the previous Software Instruction Virtualization
> layer (SBE). Parts that are now integrated/added:
> - Tcode (translated code) storage/allocation.
> - Guest instruction address to tcode address sparse tables. These
> are on a per-page basis.
> - Reverse tcode address to guest instruction address sparse tables
> for exception handling.
> - Maintenance of two hash tables for high speed lookups. One
> for guest offset (EIP) to tcode address, and one for linear
> page address to page meta info index. These will be more important
> when I integrate the branch translations.
> - Invalidation of tcode based on writes to managed tcode pages.
> - Revalidation of tcode pages across guest OS context switches.
> - Arbitrary code expansion. We're not locked into maintain the
> same page offsets anymore.
> - Updated the 'PERFORMANCE' file with more related ideas/todos.
> Parts not integrated yet. The only thing that wasn't integrated is
> the branch translations. To make debugging easier, for this phase,
> _all_ branches (even static intra-page branches) are translated as
> INT3 and emulated by the monitor. This means performance will suck
> until I add them. The code is prototyped already in dt-testbed/proto4,
> and now the hash table management logic is tested and works. So this
> should be reasonable to add in short time.
> FreeDOS / Pragma Linux (kernel 2.0.33) / Win95 all work again.
> I used 'conf/freedos', 'conf/pragma', and 'conf/win95'.
> This release is for testing only. To decrease noise on the developers
> list, test it only with host = {single processor Linux kernel}, and
> guest = {FreeDOS, Pragma Linux} and guest = {Win95} if you already
> have an installed disk image.
> Performance will be very slow for this phase. This is OK and expected,
> as every guest branch instruction is monitored/emulated. First,
> I need your help to test this code. After a small amount of time
> to shake out bugs, I will integrate the branch translation logic
> from the prototype (phase#2), and things should get fun!
>
> *Written by Kevin Lawton < [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>>*
