home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Spezial / SPEZIAL2_97.zip / SPEZIAL2_97.iso / ANWEND / EDITOR / NVI179B / README.OS2 < prev   
Text File  |  1997-07-29  |  5KB  |  107 lines
  1. nvi for OS/2 (probably works on obsolete PC OSes)
  2. ------------
  3.  
  4. You need EMX 0.9c to run this (earlier versions untested).  I personally prefer
  5. true native code, but it'll have to wait.  (If you want to know why, have a
  6. look at the hacks needed to get the titlebar stuff working....)
  7.  
  8. Everything seems to work in my relatively limited testing, except for an
  9. oddity in ":script":  when you start it, you get only the initial banner
  10. from the shell.  Enter a command on a blank line ("odir/w" <Return> will do)
  11. and it starts working.  I dunno, I'm just a transplanted Unix hack....  :-)
  12. Also, it leaves a garbage file in TMPDIR when it's done because libdb thinks
  13. it can open a file and immediately delete it --- no, it doesn't memorize the
  14. file name, so we can't catch it on close.  I may rework the included libdb a
  15. bit to fix this.
  16.  
  17. vi has been built expecting the following:
  18. (C:\GNU is where I put EMX-based programs, excluding EMX itself)
  19. - recover.cmd lives in C:\GNU\SHARE\VI
  20. - the recovery directory is C:\TMP\RECOVER.VI
  21. - recover.cmd requires ksh527rt, sh-utils, and awk
  22. - the global ex/vi configuration file is C:\GNU\ETC\VI.EXRC
  23.  
  24. You can override the recovery directory by changing recover.cmd and by
  25. adding a "set recdir=..." to the vi.exrc or environment %EXINIT% or %NEXINIT%.
  26. You can get rid of the need for ksh, etc. by rewriting recover.cmd in REXX;
  27. as I worked to maintain compatibility with the Unix sources, I did not do so.
  28. You can't change the location of recover.cmd or vi.exrc at runtime, although
  29. you can use %[N]EXINIT% or %HOME%/.[n]exrc instead of vi.exrc.  Of course,
  30. recover.cmd is fairly useless on a PC anyway and almost certainly is a lost
  31. cause on non-OS/2 systems.
  32.  
  33.  
  34. Changes from initial release
  35. ----------------------------
  36.  
  37. The biggest problem was EMX's restricting file limit.  This one knows how to
  38. use emxbind to fix that.
  39.  
  40. There were a few glitches in the OS/2-specific add-ons, in particular suspend
  41. (translated to a subshell) didn't work quite right.  It now works properly;
  42. the window title remains "vi.exe", as a reminder that you are shelled out.
  43.  
  44.  
  45. Notes on building nvi for OS/2
  46. ------------------------------
  47.  
  48. * You need emx 0.9c development system with emxfix02 or later.
  49. * You also need most if not all of the GNU utilities for OS/2, plus pdksh or
  50.   some other shell clone.
  51. * You also need HPFS to build it.  (The runtime is smart enough to adapt to
  52.   FAT systems, but the source uses Unix long names.)
  53. * WARNING!!!!!
  54.   NFS for OS/2 includes an LN.EXE.  If you (or, more likely, "configure" or
  55.   "make install") try to run it when portmap and/or nfsctl aren't running,
  56.   the session will hang and be unkillable.  I strongly suggest renaming it
  57.   before running configure.
  58. * You need to set some environment variables before running configure or make:
  59.   - set CC=gcc
  60.   - set CONFIG_SHELL=d:/path/to/sh.exe
  61.   - set MAKE_SHELL=d:/path/to/sh.exe
  62.   - set EMX_FIX_CMD="emxbind -a \$@ ..."
  63.     (e.g. to increase the number of file handles; default adds -h60)
  64. * configure should be run from the os2 directory, as it expects to find the
  65.   additional library there.
  66. * You will need to (manually, because there are no portable facilities to
  67.   add this to the Makefile only for OS/2 and I want this package to continue
  68.   to build on Unix) run "emximp -o settitle.a settitle.def" from the os2
  69.   directory.  This creates an import library for the undocumented function to
  70.   change the titlebar contents.  To build this with EMX on a non-OS/2 system,
  71.   remove -lsettitle from the generated Makefile and remove the marked sections
  72.   of cl/cl_funcs.c:  you aren't likely to be able to get away with the OS/2
  73.   API calls involved in updating the titlebar.
  74. * I haven't tried to build with --disable-re; --disable-curses produces a
  75.   binary which fails to update the screen properly, and --disable-db produces
  76.   one which can't read its database.
  77.  
  78. You do *not* have apply os2\diffs.os2 to the provided source; they are included
  79. in case a new version of nvi is released and some adventurous soul wishes to
  80. try to build it.  Apply it to the new sources with "patch -p0 < os2\diffs.os2"
  81. after copying the os2 directory to the new tree, then re-configure and re-make.
  82. (Do a "make clean" before the configure.)
  83.  
  84.  
  85. Credits
  86. -------
  87.  
  88. Thanks to Jeffrey Altman, jaltman@watsun.cc.columbia.edu, for the Win16SetTitle
  89. API.  Mixed thanks to Eberhard Mattes for EMX --- "mixed" because figuring
  90. out how to thunk the Win16SetTitle call took a look at the source and a bit of
  91. experimentation (it would be nice if it were documented that the "_16_" prefix
  92. is magic!  I couldn't find any mention of it.).  And thanks to Keith Bostic and
  93. the rest of the BSD crew for nvi, and to Bill Joy for the original vi.
  94.  
  95.  
  96. The future
  97. ----------
  98.  
  99. I'm trying to figure out why the perl binding sends gcc off a cliff.  I'm also
  100. thinking about a REXX binding; this shouldn't trip over the EXE vs. DLL issue
  101. because it will use RexxStart() and callbacks (communication will be by
  102. ADDRESS, as with EPM, and will be via ex commands).
  103.  
  104. The chances of my making this a multiwindow application are about zero, since
  105. I would have to rewrite it as a PM application --- you can't have multiple
  106. VIO windows.  "I Don't Think So...."
  107.