home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / dos / extra / docs / maillist / text / archive.95 / text0615.txt < prev    next >
Encoding:
Internet Message Format  |  1996-03-31  |  2.9 KB
  1. Received: from sloth.swcp.com (sloth.swcp.com [198.59.115.25]) by nacm.com (8.6.10/8.6.9) with ESMTP id DAA09801 for <executor@nacm.com>; Thu, 27 Apr 1995 03:47:31 -0700
  2. Received: from iclone.UUCP (uucp@localhost) by sloth.swcp.com (8.6.9/8.6.9) with UUCP id EAA05662; Thu, 27 Apr 1995 04:50:34 -0600
  3. Received: from beaut.ardi.com by mailhost  with smtp
  4.     (nextstep Smail3.1.29.0 #11) id m0s4R5p-000YbDC; Thu, 27 Apr 95 04:46 MDT
  5. Received: by beaut.ardi.com (linux Smail3.1.28.1 #5)
  6.     id m0s4R5p-00000BC; Thu, 27 Apr 95 04:46 MDT
  7. Message-Id: <m0s4R5p-00000BC@beaut.ardi.com>
  8. Date: Thu, 27 Apr 95 04:46 MDT
  9. From: ctm@ardi.com (Clifford Thomas Matthews)
  10. To: Tim Cutts <tjrc1@mole.bio.cam.ac.uk>
  11. Cc: executor@nacm.com
  12. Subject: Re: How's 1.99m doing?
  13. In-Reply-To: <9504270834.AA11683@mole.bio.cam.ac.uk>
  14. References: <9504270834.AA11683@mole.bio.cam.ac.uk>
  15. Sender: owner-executor@nacm.com
  16. Precedence: bulk
  17.  
  18. >>>>> "Tim" == Tim Cutts <tjrc1@mole.bio.cam.ac.uk> writes:
  19.  
  20.     Tim> How is 1.99m coming along?
  21.  
  22. We still have a little ways to go.  However, this week I've been
  23. working on paperwork for some new investors, which is one of the
  24. reasons for the delay.
  25.  
  26.     Tim> I tried the DOS version of 1.99l, and I'd dearly love to get
  27.     Tim> the new file manager bit for my registered Linux copy!  Is it
  28.     Tim> possible for me to copy the file manager from my DOS demo to
  29.     Tim> my Linux version?
  30.  
  31. Yes, you can do that, although you'll then have to run the browser by
  32. hand, since 1.99k doesn't automatically detect it and run it.
  33. Probably easier to wait for 1.99m, though.  In addition, the 1.99l
  34. browser will not properly cross filesystem mount points which can be
  35. quite annoying (that's already fixed over here).
  36.  
  37.     Tim> Can the linux version read .hfv files, or will I have to go
  38.     Tim> via a Mac floppy?
  39.  
  40. E/L can read .hfv files.  You can either copy them into Executor's
  41. library directory (probably /usr/local/lib/executor, or you set the
  42. MacVolumes environment variable to give the complete path of the
  43. directory containing the .hfv files, perhaps like this:
  44.  
  45.     export MacVolumes=/dos/executor
  46.  
  47.  
  48.     Tim> Also, the SVGA Linux version sounds like a good idea... the
  49.     Tim> Linux version is certainly measurably slower than the DOS
  50.     Tim> version and the DOS version updates the screen more
  51.     Tim> accurately, although that is doubtless due to X, so should
  52.     Tim> disappear with an SVGAlib version.
  53.  
  54. The screen update speed is something we can't do much about under X.
  55. We use the shared memory extensions when we can, and that helps things
  56. out a bit, but there's just no way to get directly at the frame buffer
  57. in X.  So you're right, SVGAlib will greately speed things up.
  58.  
  59. However, the screen color accuracy should be the same under X and DOS
  60. *if* you use the -private-cmap flag when running Executor/Linux.  That
  61. flag will also make some graphic accesses faster, the fade up in
  62. Lemmings, for example.
  63.  
  64.     --Cliff
  65.     ctm@ardi.com
  66.  
  67.  
  68.