Executor 2.0/executorv2.0.iso/pc/dos/extra/docs/maillist/text/archive.96/text0244.txt

Text File | 1996-07-25 | 23.3 KB | 579 lines

The FAQ says that in default configs, lpr should work, and if you want
one can write a script executor_filter that works like so:

executor_filter < faff.ps


So I wrote a script

#! /bin/sh
lpr #1

That does what the FAQ say it should. The problem is that I get a text
printout of the postscript output file at the printer.

TexEdit adds an extra % sign in front of %! PS-Adobe-3.0 to make it like
%%! PS-Adobe-3.0

AFAIK, any line with a prepended %% is a comment in postcript. Thus
the whole file is seen by the drivers-lpr-printers as text and not
postscript. How can one remedy this?

Thanks
--
Greetings,                       __            [e-mail]
                      __________/ F
                    c'____---__=_/
Naresh _______________o_____o___________http://is.twi.tudelft.nl/~sharma/


From owner-paper Fri Jan 26 01:14:14 1996
Return-Path: <owner-paper>
Received: by ftp.ardi.com (Smail3.1.29.1 #3)
    id m0tfjIS-0007qGa; Fri, 26 Jan 96 01:14 MST
Sender: owner-paper
Received: from ardi.com by ftp.ardi.com
    (Smail3.1.29.1 #3) id m0tfjHf-0007qIn; Fri, 26 Jan 96 01:13 MST
Newsgroups: comp.emulators.mac.executor
Path: sloth.swcp.com!tesuque.cs.sandia.gov!ferrari.mst6.lanl.gov!newshost.lanl.gov!ncar!news.internetMCI.com!newsfeed.internetmci.com!howland.reston.ans.net!news.nic.surfnet.nl!tudelft.nl!dutiwy!sharma
From: [e-mail] (Naresh Sharma )
Subject: Printing problems with E/L
Message-ID: <[e-mail]>
Date: Wed, 24 Jan 1996 10:59:40 GMT
X-Nntp-Posting-Host: dutiee.twi.tudelft.nl
Organization: Technische Universiteit Delft,
X-Newsreader: TIN [version 1.2 PL0]
Lines: 24
To: [e-mail]
X-MailNews-Gateway: From newsgroup comp.emulators.mac.executor
Sender: [e-mail]
Precedence: bulk

Hi Folks,

I have located the source of error in printing under linux (it is
the executor generated ps file). The solution is as follows:

create an executor_filter like:

#! /bin/sh
awk '{if (/%%!PS-Adobe-3.0/) print "%!PS-Adobe-3.0\n"; else if \
        (/%%%%/) print "%%"; else print}' $1 | lpr



This works partly, and to make printing work ardi must do something
to their filter which generates excessive % characters.

Thanks

--
Greetings,                       __            [e-mail]
                      __________/ F
                    c'____---__=_/
Naresh _______________o_____o___________http://is.twi.tudelft.nl/~sharma/


From owner-paper Fri Jan 26 02:14:30 1996
Return-Path: <owner-paper>
Received: by ftp.ardi.com (Smail3.1.29.1 #3)
    id m0tfkEg-0007qIa; Fri, 26 Jan 96 02:14 MST
Sender: owner-paper
Received: from ardi.com by ftp.ardi.com
    (Smail3.1.29.1 #3) id m0tfkE2-0007qHn; Fri, 26 Jan 96 02:13 MST
Path: sloth.swcp.com!usenet
From: Clifford T. Matthews <[e-mail]>
Newsgroups: comp.emulators.mac.executor
Subject: Re: Floppy Disk Drive read/write problems
Date: 26 Jan 1996 02:05:53 -0700
Organization: ARDI
Lines: 22
Message-ID: <[e-mail]>
References: <4dshl1$[e-mail]>
    <[e-mail]>
    <[e-mail]> <4e8oaj$[e-mail]>
NNTP-Posting-Host: ftp.ardi.com
In-reply-to: Kyle Silfer's message of 25 Jan 1996 20:14:10 GMT
X-Newsreader: Gnus v5.0
To: [e-mail]
X-MailNews-Gateway: From newsgroup comp.emulators.mac.executor
Sender: [e-mail]
Precedence: bulk

>>>>> "Kyle" == Kyle Silfer <[e-mail]> writes:
In article <4e8oaj$[e-mail]> Kyle Silfer <[e-mail]> writes:


    Kyle> Clifford T. Matthews <[e-mail]> wrote:
    >>  Apparently we introduced a serious bug in 1.99q.  It's a very
    >> high priority bug and I hope to have something fixed by this
    >> weekend.

    Kyle> I ran into this problem _before_ 1.99q. I wasn't sure about
    Kyle> it, though, so I did not post about the problem. It was
    Kyle> somewhere after 1.99p7 (which still works fine) and before
    Kyle> 1.99q.

Aha.  That helps significantly.  Sounds like it was introduced in
1.99p8 or 1.99p9.  I'll take a look at what we did differently between
1.99p7 and those two versions.  Thanks.

    Kyle> --Kyle [e-mail]

--Cliff
[e-mail]

From owner-paper Fri Jan 26 02:14:45 1996
Return-Path: <owner-paper>
Received: by ftp.ardi.com (Smail3.1.29.1 #3)
    id m0tfkEw-0007qHa; Fri, 26 Jan 96 02:14 MST
Sender: owner-paper
Received: from ardi.com by ftp.ardi.com
    (Smail3.1.29.1 #3) id m0tfkDx-0007qGn; Fri, 26 Jan 96 02:13 MST
Path: sloth.swcp.com!tesuque.cs.sandia.gov!ferrari.mst6.lanl.gov!newshost.lanl.gov!ncar!elroy.jpl.nasa.gov!swrinde!howland.reston.ans.net!nntp.coast.net!torn!news.bc.net!news.sfu.ca!quinlan
From: [e-mail] (Brian Quinlan)
Newsgroups: comp.emulators.mac.executor
Subject: Re: Speedometer Results Overrated?
Date: 24 Jan 1996 20:47:57 GMT
Organization: Simon Fraser University
Lines: 17
Message-ID: <4e65tt$[e-mail]>
References: <4e1aoj$[e-mail]> <[e-mail]>
NNTP-Posting-Host: fraser.sfu.ca
X-Newsreader: NN version 6.5.0 #5 (NOV)
To: [e-mail]
X-MailNews-Gateway: From newsgroup comp.emulators.mac.executor
Sender: [e-mail]
Precedence: bulk

Clifford T. Matthews <[e-mail]> writes:

>In addition, Executor has to be aware of self-modifying code.  After
>all, if it memorizes that a particular set of m68k instructions map
>into a set of x86 instructions, if the original m68k instructions are
>changed then Executor needs to throw away the mapped instructions and
>do another recompile.  I don't know how MACCHESS 2.0 works, but if it
>dynamically builds board evaluators and then jumps into them, then
>Executor's performance will suffer for that.

Why do you support instruction modification? The 040 and PPC Macs won't
always run programs which use instruction modification due to their
caches.

--
Brian Quinlan    "Never ask what sort of computer a guy drives. If he's a Mac
[e-mail]    user, he'll tell you. If not, why embarrass him?" - Tom Clancy

From owner-paper Fri Jan 26 03:14:14 1996
Return-Path: <owner-paper>
Received: by ftp.ardi.com (Smail3.1.29.1 #3)
    id m0tflAS-0007qJa; Fri, 26 Jan 96 03:14 MST
Sender: owner-paper
Received: from ardi.com by ftp.ardi.com
    (Smail3.1.29.1 #3) id m0tfl9j-0007qGn; Fri, 26 Jan 96 03:13 MST
Path: sloth.swcp.com!usenet
From: Clifford T. Matthews <[e-mail]>
Newsgroups: comp.emulators.mac.executor
Subject: Re: true color executor/D
Date: 26 Jan 1996 02:14:02 -0700
Organization: ARDI
Lines: 50
Message-ID: <[e-mail]>
References: <4e3p87$[e-mail]> <4e4neq$[e-mail]>
    <4e5gg2$[e-mail]> <4e6gsj$[e-mail]>
NNTP-Posting-Host: ftp.ardi.com
In-reply-to: [e-mail]'s message of 24 Jan 1996 23:54:59 GMT
X-Newsreader: Gnus v5.0
To: [e-mail]
X-MailNews-Gateway: From newsgroup comp.emulators.mac.executor
Sender: [e-mail]
Precedence: bulk

>>>>> "Gerald" == Gerald Luther Graef <[e-mail]> writes:
In article <4e6gsj$[e-mail]> [e-mail] (Gerald Luther Graef) writes:


    Gerald> In article <4e5gg2$[e-mail]>
    Gerald> [e-mail] (William Magro) writes:
    >> The catch here is that the 256 colors of VGA are chosen from a
    >> palette of 256k (or fewer) colors with standard VGA cards.
    >> Since each gray must have equal components of red, green, and
    >> blue, this reduces the effective number of true grays to 64
    >> [=262144^(1/3)].  It takes a 24-bit D/A converter (8-bits in
    >> each channel) to generate 256 grays.
    >>
    >> In the end, the number of grays you can generate depends on the
    >> bitness of your DAC and the smarts of the video driver.

    Gerald> Does this mean that with the right video card it is
    Gerald> possible to get 256 grayscale on executor now?  I ask
    Gerald> because I am thinking about getting a new video card
    Gerald> (leading contender, #9 771).

I've answered this in another post, but with news lag and the
importance of the subject, here's the same story:

Bill's right, the number of bits that your DAC uses is indeed
important, but right now, Executor *won't* do the right thing even if
you have a 24 bit DAC.  That's because we don't yet have a machine
in-house that has a 24 bit DAC *and* a VBE 2.0 driver that will let us
access that DAC.

Because PCs come in so many different configurations, Executor relies
heavily on standards, like the VESA VBE 2.0 standard to access
"special features".  To support 24 bit DACs we'll need to use a VBE
2.0 extension, but to test it we either need to have such a DAC+driver
in house or rely on an Executor Enthusiast to help us test the code.

I believe we do have some video cards in house with 24-bit DACs, so if
the soon to be released new version of UniVBE gives us access to
these, we'll add the functionality and test it in house.  If the new
version of UniVBE *doesn't* support it for our cards, then we'll ask
for help.  Either way we should support this feature by the time
Executor 2 ships, although to use it you'll need a card with a 24-bit
DAC *and* VBE 2.0 extensions to allow us to access it.

Sorry things get so confusing, but that's the way it is in the PC biz.

    Gerald> Thanks...Gerry

--Cliff
[e-mail]

From owner-paper Fri Jan 26 03:14:25 1996
Return-Path: <owner-paper>
Received: by ftp.ardi.com (Smail3.1.29.1 #3)
    id m0tflAj-0007qGa; Fri, 26 Jan 96 03:14 MST
Sender: owner-paper
Received: from ardi.com by ftp.ardi.com
    (Smail3.1.29.1 #3) id m0tfl9n-0007qIn; Fri, 26 Jan 96 03:13 MST
Path: sloth.swcp.com!usenet
From: Clifford T. Matthews <[e-mail]>
Newsgroups: comp.emulators.mac.executor
Subject: Re: Printing problems with E/L
Date: 26 Jan 1996 02:34:10 -0700
Organization: ARDI
Lines: 61
Message-ID: <[e-mail]>
References: <[e-mail]>
NNTP-Posting-Host: ftp.ardi.com
In-reply-to: [e-mail]'s message of Wed, 24 Jan 1996 09:01:12 GMT
X-Newsreader: Gnus v5.0
To: [e-mail]
X-MailNews-Gateway: From newsgroup comp.emulators.mac.executor
Sender: [e-mail]
Precedence: bulk

>>>>> "Naresh" == Naresh Sharma <[e-mail]> writes:
In article <[e-mail]> [e-mail] (Naresh Sharma ) writes:


    Naresh> The FAQ says that in default configs, lpr should work, and
    Naresh> if you want one can write a script executor_filter that
    Naresh> works like so:

    Naresh> executor_filter < faff.ps


    Naresh> So I wrote a script

    Naresh> #! /bin/sh lpr #1

    Naresh> That does what the FAQ say it should. The problem is that
    Naresh> I get a text printout of the postscript output file at the
    Naresh> printer.

    Naresh> TexEdit adds an extra % sign in front of %! PS-Adobe-3.0
    Naresh> to make it like %%! PS-Adobe-3.0

Nope, it's not TexEdit that is doing it, but a bug in Executor 1.99q.
This bug has been fixed internally (and in Executor/NEXTSTEP 1.99q2)
but I didn't realize it was causing problems, so I haven't yet made a
1.99q3 for Linux, but I can probably do so in the next 24 hours.

    Naresh> AFAIK, any line with a prepended %% is a comment in
    Naresh> postcript. Thus the whole file is seen by the
    Naresh> drivers-lpr-printers as text and not postscript. How can
    Naresh> one remedy this?

Revert to 1.99p9, wait for 1.99q3 or write a shell script that filters
out our botch.

Programming commentary follows -- feel free to skip this:

Although many of our bugs are incredibly esoteric and not worth
explaining to the programmers out there, what happened is that when we
adjusted our PostScript printing code to work again under NEXTSTEP we
changed a line that used to say (approximately):

fprintf (printer, PROLOG_STRING);

to

fprintf (printer, "%s%s%s", PROLOG_STRING_1, PROLOG_STRING_2, PROLOG_STRING_3);

since we had to break the prolog into different parts (under NEXTSTEP
we only need part 2, I think).  However if you do such a thing,
breaking the initial string into three pieces isn't sufficient, since
the original string had to have %% for each % since it was the format
argument to printf, rather than a literal argument to be printed by
%s.

Pretty embarrassing.  It slipped by our testing because our printer
doesn't auto-detect PostScript, we just use a variant that always
expects PostScript.

--Cliff
[e-mail]

From owner-paper Fri Jan 26 03:14:49 1996
Return-Path: <owner-paper>
Received: by ftp.ardi.com (Smail3.1.29.1 #3)
    id m0tflB1-0007qIa; Fri, 26 Jan 96 03:14 MST
Sender: owner-paper
Received: from ardi.com by ftp.ardi.com
    (Smail3.1.29.1 #3) id m0tfl9l-0007qHn; Fri, 26 Jan 96 03:13 MST
Path: sloth.swcp.com!usenet
From: Clifford T. Matthews <[e-mail]>
Newsgroups: comp.emulators.mac.executor
Subject: Re: Speedometer Results Overrated?
Date: 26 Jan 1996 02:25:08 -0700
Organization: ARDI
Lines: 43
Message-ID: <[e-mail]>
References: <4e1aoj$[e-mail]> <[e-mail]>
    <4e65tt$[e-mail]>
NNTP-Posting-Host: ftp.ardi.com
In-reply-to: [e-mail]'s message of 24 Jan 1996 20:47:57 GMT
X-Newsreader: Gnus v5.0
To: [e-mail]
X-MailNews-Gateway: From newsgroup comp.emulators.mac.executor
Sender: [e-mail]
Precedence: bulk

>>>>> "Brian" == Brian Quinlan <[e-mail]> writes:
In article <4e65tt$[e-mail]> [e-mail] (Brian Quinlan) writes:


    Brian> Clifford T. Matthews <[e-mail]> writes:
    >> In addition, Executor has to be aware of self-modifying code.
    >> After all, if it memorizes that a particular set of m68k
    >> instructions map into a set of x86 instructions, if the
    >> original m68k instructions are changed then Executor needs to
    >> throw away the mapped instructions and do another recompile.  I
    >> don't know how MACCHESS 2.0 works, but if it dynamically builds
    >> board evaluators and then jumps into them, then Executor's
    >> performance will suffer for that.

    Brian> Why do you support instruction modification? The 040 and
    Brian> PPC Macs won't always run programs which use instruction
    Brian> modification due to their caches.

I wasn't clear.  On an '040 with both caches enabled, whenever new
instructions are loaded into memory (including when a new program is
loaded), the caches need to be flushed.  This is done either by
directly accessing the cache control register or by calling one of a
few different OS calls that Apple provides for this purpose.

Executor detects when the cache control register is modified or when
these calls are made and then has to figure out which, if any,
recompiled pieces of code need to be discarded.  This can be a
substantial performance penalty.

Programs that properly flush the cache after they self-modify, or
build code on the fly should work properly with '040s with the cache
on and should work fine with Executor.  Programs that don't properly
flush the cache may indeed break on '040s with the cache enabled and
under Executor.

Again, I have no idea whether or not MACCHESS 2.0 actually creates
code on the fly and jumps to it, but it is indeed a legitimate thing
to do, as long as the program flushes the cache before making the
jump.  If it *does* do that, then it would explain the major
discrepancy between Speedometer numbers and MACCHESS 2.0.

--Cliff
[e-mail]

From owner-paper Fri Jan 26 04:14:39 1996
Return-Path: <owner-paper>
Received: by ftp.ardi.com (Smail3.1.29.1 #3)
    id m0tfm6v-0007qJa; Fri, 26 Jan 96 04:14 MST
Sender: owner-paper
Received: from ardi.com by ftp.ardi.com
    (Smail3.1.29.1 #3) id m0tfm6C-0007qHn; Fri, 26 Jan 96 04:13 MST
Path: sloth.swcp.com!usenet
From: Clifford T. Matthews <[e-mail]>
Newsgroups: comp.sys.mac.advocacy,comp.emulators.mac.executor
Subject: Re: Can Quix save Apple?
Date: 26 Jan 1996 03:33:58 -0700
Organization: ARDI
Lines: 58
Message-ID: <[e-mail]>
References: <1996Jan14.170950.1@ugsc2a> <[e-mail]>
NNTP-Posting-Host: ftp.ardi.com
In-reply-to: [e-mail]'s message of Wed, 24 Jan 96 19:43:33 GMT
X-Newsreader: Gnus v5.0
Xref: sloth.swcp.com comp.sys.mac.advocacy:83091 comp.emulators.mac.executor:910
To: [e-mail]
X-MailNews-Gateway: From newsgroup comp.emulators.mac.executor
Sender: [e-mail]
Precedence: bulk

>>>>> "Kevin" == Kevin Hayes <[e-mail]> writes:
In article <[e-mail]> [e-mail] (Kevin Hayes) writes:

    >>  Personally, I think there are irreversible aspects of such a
    >> decision, because once the System 7 brought to Intel machines,
    >> the customer will no more rely on Apple's hardware, but on the
    >> other side, is not too much risky a move, becaus of the
    >> possibility to have the Copland running only on true Macs, or
    >> other similar arrangements.
    >>

    Kevin> MacOS is a stupid idea on Wintel machines - it'd be slower
    Kevin> and there would be mountains of work involved to getting it
    Kevin> to run on all Wintel systems - you're forgetting in the
    Kevin> Wintel world there's no such thing as standards.

MacOS on PC hardware could run very fast via dynamic recompilation*
and could run blazingly fast if compiler tools were available** to
allow CPU intensive routines to be compiled into 80x86 code by the
software author.

There are many standards in the PC world that would be very useful to
a port of MacOS to PCs, for instance the VESA 2 extensions.

We wrote Executor, a Macintosh emulator that allows PCs to run much
68k Macintosh software, and it does so faster on entry level Pentiums
than any 68k based Macintosh Apple ever released.

We did this all without any help from Apple and we do not use any of
Apple's ROMs or System file, nor have we disassembled any of Apple's
ROM or System file.  By doing it this way we have not been able to
support all of System 7, much less support post System 7 features like
QuickTime.  In addition, there are still enough compatbility problems
that many programs do not work.  *However*, if we could license System
7.5, we could fairly easily get a very large degree of compatibility,
since we'd be using Apple's code with all its quirks, rather than our
rewrite from incomplete and inaccurate documentation.

See http://www.ardi.com for more information about Executor.
There is also an Executor newsgroup:  comp.emulators.mac.executor.

We continue on a day to day basis assuming that Apple is not
interested in embracing our technology, and that is their decision,
but MacOS 7.5 could run very quickly indeed on PCs.

What we have done is *much* more difficult than what QUIX has done,
and infinitely more useful if Apple ever wants to reward their
software developers and potentially take on Microsoft on Intel based
PC hardware.

Intel is not the enemy.

--Cliff
[e-mail]

__________________
*We've done this already.
**We will do this in '96

From owner-paper Fri Jan 26 05:13:45 1996
Return-Path: <owner-paper>
Received: by ftp.ardi.com (Smail3.1.29.1 #3)
    id m0tfn2D-0007qIa; Fri, 26 Jan 96 05:13 MST
Sender: owner-paper
Received: from eexi.gr by ftp.ardi.com with smtp
    (Smail3.1.29.1 #3) id m0tfmyS-0007qGC; Fri, 26 Jan 96 05:09 MST
Received: from 193.92.44.70.eexi.gr ([e-mail] [193.92.44.70]) by eexi.gr (8.6.12/8.6.9) with SMTP id OAA06881 for <[e-mail]>; Fri, 26 Jan 1996 14:18:08 +0200
Message-ID: <[e-mail]>
Date: Fri, 26 Jan 1996 14:07:50 +0200
From: Dimitris Alexandris <[e-mail]>
Organization: EverCom Inc.
X-Mailer: Mozilla 2.0b5 (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Can Quix save Apple?
References: <1996Jan14.170950.1@ugsc2a> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Clifford T. Matthews wrote:
> There are many standards in the PC world that would be very useful to
> a port of MacOS to PCs, for instance the VESA 2 extensions.

Indeed, there's hell of a lot of standards in the PC world, contrary to what
many Mac users are led to believe by official Apple policy!

> We wrote Executor, a Macintosh emulator that allows PCs to run much
> 68k Macintosh software, and it does so faster on entry level Pentiums
> than any 68k based Macintosh Apple ever released.

Indeed, Cliff, and you are worth many many congratulations for that!

> We continue on a day to day basis assuming that Apple is not
> interested in embracing our technology, and that is their decision,
> but MacOS 7.5 could run very quickly indeed on PCs.

I believe Apple has definitely lost the game because they simply followed the
wrong marketing policy from day one back in 1984/1985 when the first Mac was
released. Although an exceptional machine with an exceptional & robust OS it
finally fell short of establishing a wide user base such as this of PCs
because of the short-sighted marketing policy from Apple.

> Intel is not the enemy.It certainly isn't ;-)

Dimitris
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Tel/Fax: [phone]               Internet E-Mail: [e-mail]
Data:    [phone]                               [e-mail]
         [phone]                WWW http://www.eexi.gr/~evercom
---------------------------------------------------------------------
      EverCom Inc., 25 Kresnas Str., Athens, Greece GR-113 63
\\\  Network Maintenance and Internet Communications Consultants  ///
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

From owner-paper Fri Jan 26 05:13:56 1996
Return-Path: <owner-paper>
Received: by ftp.ardi.com (Smail3.1.29.1 #3)
    id m0tfn2Q-0007qGa; Fri, 26 Jan 96 05:13 MST
Sender: owner-paper
Received: from ardi.com by ftp.ardi.com
    (Smail3.1.29.1 #3) id m0tfn1t-0007qHn; Fri, 26 Jan 96 05:13 MST
Path: sloth.swcp.com!tesuque.cs.sandia.gov!lynx.unm.edu!fg1.plk.af.mil!news.zynet.com!imci2!newsfeed.internetmci.com!news.msfc.nasa.gov!bcm.tmc.edu!newshost.convex.com!news.dfw.net!sol.wf.net!usenet
From: [e-mail] (Chuck Bell)
Newsgroups: comp.emulators.mac.executor
Subject: Executor error message
Date: Wed, 24 Jan 1996 03:41:23 GMT
Organization: Wichita Falls Internet
Lines: 16
Message-ID: <4e4bi6$[e-mail]>
NNTP-Posting-Host: ppp16.wf.net
X-Newsreader: Forte Free Agent 1.0.82
To: [e-mail]
X-MailNews-Gateway: From newsgroup comp.emulators.mac.executor
Sender: [e-mail]
Precedence: bulk

Now I'm getting the following error message:

dosdisk.c:264; fatal error in 'dosdisk_seek': failed assertion '0'
Can't open system file

Doesn't sound too good! I got Executor running on my desktop PC, a
486SX/25 with 16MB RAM, under Windows 95. The error I'm getting is
when trying to run Executor on my IBM ThinkPad 500 with 4MB RAM. It
has a 486DLC/25 processor. I set FILES=30 and played around with the
STACKS setting, but can't get it to work. I'm just dying to get this
thing on the laptop so I can swap files in my MAC-only office.

Thanks for any help.

Chuck Bell