[Date Prev][Date Next][Subject Prev][Subject Next][ Date Index][ Subject Index]

Re: Nota Bene, XY on Linux



Patricia M Godfrey wrote:

>     I'm not quite clear about why XyWrite would have to be rewritten in
> another language. Apparently the basic hardware hasn't changed that much,
> since we can still run XyW's Assembler routines on today's hardware, even
> with the overhead of MS's various GUIs. So why couldn't it stay as it is,
> an Assembler program, with the addition of hooks to make it visible to
> Linux?

At some point (a couple years ago ?), Intel announced the upgrade path for its
projected CPU development. The '686 (I'm unclear as to whether we are still
in the '586 or the '686 era . . . ) was supposed to be the last backwards compatible

CPU family. As of the '786 series, they would be moving to a chip design that
was **not** backwards compatible -- this may or may not have had something to
do with moving from a CISC architecture to a RISC chip architecture -- with the
almost certain result that a great many "legacy" (read _previous_) app.s would
no longer run on this family of CPUs. Ergo, a major fork in the road, no turning
back. In stark contrast to this, chip maker AMD decided that they *would* retain
the 'x86 backwards compatibility in their future chip development. The lines
appeared to be clearly drawn.

Had this expected future materialized by now, and as fiercely devoted as I am to
Xy, I would have switched to an AMD cpu and AMD-supported motherboard,
*for no other reason.* (O.K., there would be plenty of other reasons, but this is
a sufficient deal-killer, all by itself.) Obviously, it has not happened yet. I
haven't
heard much about this for the last couple years. For all I know, Intel might have
found themselves staring into the abyss and reconsidered their plans.

> Of course, the different file system under Linux is a big problem,
> along with the Unix convention of making everything branch off the root,
> which I HATE. I have four logical drives on my PC, and that's the way I
> want them.

Here's another option to factor in. VPC has a line of emulators that allow you
to run another OS (and the app.s that run under it) *as a client inside the OS
of your choice.* So, you could run Linux inside of Win-whatever, switching
back & forth to the host OS as you wish. In this example, all the Linux stuff
is fooled into believing it is running under a real, independent iteration of
Linux. Which might be a way of getting around the issues you don't care for.
The downside: these flavors of VPC client will probably run around $300.
each, and there is a speed penalty from emulation. I've been told the latter
pretty much disappears with faster hardware -- an 800 mhz. P-III or faster,
with at least 512M of RAM. My recent round of h/w upgrades was guaged to
accomodate this, as I'm looking foward to running Win-32 stuff inside OS/2,
with a better, more comprehensive solution than has so far been provided by
Project ODIN.


Jordan