diff options
Diffstat (limited to 'PC/os2emx/README.os2emx')
| -rw-r--r-- | PC/os2emx/README.os2emx | 663 |
1 files changed, 0 insertions, 663 deletions
diff --git a/PC/os2emx/README.os2emx b/PC/os2emx/README.os2emx deleted file mode 100644 index 61872b6b62..0000000000 --- a/PC/os2emx/README.os2emx +++ /dev/null @@ -1,663 +0,0 @@ -This is a port of Python 2.6 to OS/2 using the EMX development tools -========================================================================= - -What's new since the previous release -------------------------------------- - -Another day, another version... - - -Licenses and info about Python and EMX --------------------------------------- - -Please read the file README.Python-2.6 included in this package for -information about Python 2.6. This file is the README file from the -Python 2.6 source distribution available via http://www.python.org/ -and its mirrors. The file LICENCE.Python-2.6 is the text of the Licence -from the Python 2.6 source distribution. - -Note that the EMX package that this package depends on is released under -the GNU General Public Licence. Please refer to the documentation -accompanying the EMX Runtime libraries for more information about the -implications of this. A copy of version 2 of the GPL is included as the -file COPYING.gpl2. - -Readline and GDBM are covered by the GNU General Public Licence. I think -Eberhard Mattes' porting changes to BSD DB v1.85 are also GPL'ed (BSD DB -itself is BSD Licenced). ncurses and expat appear to be covered by MIT -style licences - please refer to the source distributions for more detail. -zlib is distributable under a very free license. GNU UFC is under the -GNU LGPL (see file COPYING.lib). - -My patches to the Python-2.x source distributions, and any other packages -used in this port, are placed in the public domain. - -This software is provided 'as-is', without any express or implied warranty. -In no event will the author be held liable for any damages arising from the -use of the software. - -I do hope however that it proves useful to someone. - - -Other ports ------------ - -There have been ports of previous versions of Python to OS/2. - -The best known would be that by Jeff Rush, most recently of version -1.5.2. Jeff used IBM's Visual Age C++ (v3) for his ports, and his -patches have been included in the Python 2.6 source distribution. - -Andy Zabolotny implemented a port of Python v1.5.2 using the EMX -development tools. His patches against the Python v1.5.2 source -distribution have become the core of this port, and without his efforts -this port wouldn't exist. Andy's port also appears to have been -compiled with his port of gcc 2.95.2 to EMX, which I have but have -chosen not to use for the binary distribution of this port (see item 16 -of the "YOU HAVE BEEN WARNED" section below). - -It is possible to have these earlier ports still usable after installing -this port - see the README.os2emx.multiple_versions file, contributed by -Dr David Mertz, for a suggested approach to achieving this. - - -Software requirements ---------------------- - -This package requires the EMX Runtime package, available from the -Hobbes (http://hobbes.nmsu.edu/) and LEO (http://archiv.leo.org/) -archives of OS/2 software. I have used EMX version 0.9d fix04 in -developing this port. - -My development system is running OS/2 v4 with fixpack 12. - -3rd party software which has been linked into dynamically loaded modules: -- ncurses (see http://dickey.his.com/ for more info, v5.2) -- GNU Readline (Kai Uwe Rommel's port available from Hobbes or LEO, v2.1) -- GNU GDBM (Kai Uwe Rommel's port available from Hobbes or LEO, v1.7.3) -- zlib (derived from Hung-Chi Chu's port of v1.1.3, v1.1.4) -- expat (distributed with Python, v1.95.6) -- GNU UFC (Kai Uwe Rommel's port available from LEO, v2.0.4) - - -About this port ---------------- - -I have attempted to make this port as complete and functional as I can, -notwithstanding the issues in the "YOU HAVE BEEN WARNED" section below. - -Core components: - -Python.exe is linked as an a.out executable, ie using EMX method E1 -to compile & link the executable. This is so that fork() works (see -"YOU HAVE BEEN WARNED" item 1). - -Python26.dll is created as a normal OMF DLL, with an OMF import -library and module definition file. There is also an a.out (.a) import -library to support linking the DLL to a.out executables. The DLL -requires the EMX runtime DLLs. - -This port has been built with complete support for multithreading. - -Modules: - -With the exception of modules that have a significant code size, or are -not recommended or desired for normal use, the standard modules are now -built into the core DLL rather than configured as dynamically loadable -modules. This is for both reasons of performance (startup time) and -memory use (lots of small DLLs fragment the address space). - -I haven't yet changed the building of Python's dynamically loadable -modules over to using the DistUtils. - -See "YOU HAVE BEEN WARNED" item 3 for notes about the fcntl module, and -"YOU HAVE BEEN WARNED" item 10 for notes about the pwd and grp modules. - -This port supports case sensitive module import semantics, matching -the Windows release. This can be deactivated by setting the PYTHONCASEOK -environment variable (the value doesn't matter) - see "YOU HAVE BEEN WARNED" -item 12. - -Optional modules: - -Where I've been able to locate the required 3rd party packages already -ported to OS/2, I've built and included them. - -These include ncurses (_curses, _curses_panel), -GNU GDBM (gdbm, dbm), zlib (zlib), GNU Readline (readline), and GNU UFC -(crypt). - -Expat is now included in the Python release sourceball, and the pyexpat -module is always built. - -I have built these modules statically linked against the 3rd party -libraries. Unfortunately my attempts to use the dll version of GNU -readline have been a dismal failure, in that when the dynamically -linked readline module is active other modules immediately provoke a -core dump when imported. - -Only the BSD DB package (part of the BSD package distributed with EMX) -needs source modifications to be used for this port, pertaining to use -of errno with multithreading. - -The other packages, except for ncurses and zlib, needed Makefile changes -for multithreading support but no source changes. - -The _curses_panel module is a potential problem - see "YOU HAVE BEEN -WARNED" item 13. - -Upstream source patches: - -No updates to the Python 2.6 release have become available. - -Library and other distributed Python code: - -The Python standard library lives in the Lib directory. All the standard -library code included with the Python 2.6 source distribution is included -in the binary archive, with the exception of the dos-8x3 and tkinter -subdirectories which have been omitted to reduce the size of the binary -archive - the dos-8x3 components are unnecessary duplicates and Tkinter -is not supported by this port (yet). All the plat-* subdirectories in the -source distribution have also been omitted, except for the plat-os2emx -subdirectory. - -The Tools and Demo directories contain a collection of Python scripts. -To reduce the size of the binary archive, the Demo/sgi, Demo/Tix, -Demo/tkinter, Tools/audiopy and Tools/IDLE subdirectories have been -omitted as not being supported by this port. The Misc directory has -also been omitted. - -All subdirectories omitted from the binary archive can be reconstituted -from the Python 2.6 source distribution, if desired. - -Support for building Python extensions: - -The Config subdirectory contains the files describing the configuration -of the interpreter and the Makefile, import libraries for the Python DLL, -and the module definition file used to create the Python DLL. The -Include subdirectory contains all the standard Python header files -needed for building extensions. - -As I don't have the Visual Age C++ compiler, I've made no attempt to -have this port support extensions built with that compiler. - - -Packaging ---------- - -This port is packaged as follows: -- python-2.6-os2emx-bin-03????.zip (binaries, library modules) -- python-2.6-os2emx-src-03???? (patches+makefiles for non-Python code) - -As all the Python specific patches for the port are now part of the -Python release tarball, only the patches and makefiles involved in -building external libraries for optional extensions are included in -the source archive. - -Documentation for the Python language, as well as the Python 2.6 -source distibution, can be obtained from the Python website -(http://www.python.org/) or the Python project pages at Sourceforge -(http://sf.net/projects/python/). - - -Installation ------------- - -Obtain and install, as per the included instructions, the EMX runtime -package. - -Unpack this archive, preserving the subdirectories, in the root directory -of the drive where you want Python to live. - -Add the Python directory (eg C:\Python26) to the PATH and LIBPATH -variables in CONFIG.SYS. - -You should then set the PYTHONHOME and PYTHONPATH environment variables -in CONFIG.SYS. - -PYTHONHOME should be set to Python's top level directory. PYTHONPATH -should be set to the semicolon separated list of principal Python library -directories. -I use: - SET PYTHONHOME=F:/Python26 - SET PYTHONPATH=F:/Python26/Lib;F:/Python26/Lib/plat-os2emx; - F:/Python26/Lib/lib-dynload;F:/Python26/Lib/site-packages - -NOTE!: the PYTHONPATH setting above is linewrapped for this document - it -should all be on one line in CONFIG.SYS! - -If you wish to use the curses module, you should set the TERM and TERMINFO -environment variables appropriately. - -If you don't already have ncurses installed, I have included a copy of the -EMX subset of the Terminfo database included with the ncurses-5.2 source -distribution. This can be used by setting the TERMINFO environment variable -to the path of the Terminfo subdirectory below the Python home directory. -On my system this looks like: - SET TERMINFO=F:/Python26/Terminfo - -For the TERM environment variable, I would try one of the following: - SET TERM=ansi - SET TERM=os2 - SET TERM=window - -You will have to reboot your system for these changes to CONFIG.SYS to take -effect. - -If you wish to compile all the included Python library modules to bytecode, -you can change into the Python home directory and run the COMPILEALL.CMD -batch file. - -You can execute the regression tests included with the Python 2.6 source -distribution by changing to the Python 2.6 home directory and executing the -REGRTEST.CMD batch file. The following tests are known to fail at this -time: -- test_mhlib (I don't know of any port of MH to OS/2); -- test_strptime (see "YOU HAVE BEEN WARNED" item 22); -- test_time (see "YOU HAVE BEEN WARNED" item 22); -- test_posixpath (see "YOU HAVE BEEN WARNED" item 23). - -Note that some of the network related tests expect the loopback interface -(interface "lo", with IP address 127.0.0.1) to be enabled, which from my -experience is not the default configuration. Additionally, test_popen2 -expects the "cat" utility (such as found in ports of the GNU tools) to -be installed. - - -Building from source --------------------- - -With the EMX port now checked into Python's CVS repository, the build -infrastructure is part of the Python release sourceball. - -Prerequisites - -First and foremost, you need an operational EMX development installation - -EMX v0.9d with fix04 (the latest at time of writing) & the gcc 2.8.1 -compiler released by Eberhard Mattes is the recommended setup. - -If you have a different version of gcc installed, see "YOU HAVE BEEN -WARNED" item 16. - -Other items of software required:- - -- GNU make (I'm using v3.76.1) -- rm, cp, mkdir from the GNU file utilities package -- GNU find -- GNU sed - -Procedure - -0. all changes mentioned apply to files in the PC/os2emx subdirectory - of the Python release source tree. make is also executed from this - directory, so change into this directory before proceeding. - -1. decide if you need to change the location of the Python installation. - If you wish to do this, set the value of the Makefile variable LIB_DIR - to the directory you wish to use for PYTHONHOME - (eg /usr/local/lib/python2.6). - - If you want Python to find its library without the PYTHONHOME - environment variable set, set the value of the Makefile variable - FIXED_PYHOME to "yes" (uncomment the appropriate line). - -2. If you wish the Python executables (python.exe, pythonpm.exe & pgen.exe) - to be installed in a directory other than the PYTHONHOME directory, set - the value of the Makefile variable EXE_DIR to the appropriate directory. - -3. If you wish the Python core DLL (python34.dll) to be installed in a - directory other than the directory in which the Python executables are - installed (by default, the PYTHONHOME directory), set the value of the - Makefile variable DLL_DIR to the appropriate directory. This DLL must - be placed in a directory on the system's LIBPATH, or that gets set - with BEGINLIBPATH or ENDLIBPATH. - -4. If you have installed any of the libraries that can be used to build - optional Python modules, set the value of the relevant HAVE_<package> - Makefile variable to "yes". The Makefile currently supports: - - library Makefile variable - ........................................ - zlib (1.1.4) HAVE_ZLIB - GNU UltraFast Crypt HAVE_UFC - Tcl/Tk HAVE_TCLTK (not known to work) - GNU Readline HAVE_GREADLINE - ncurses HAVE_NCURSES - GNU gdbm HAVE_GDBM - libbz2 HAVE_BZ2 - OpenSSL HAVE_OPENSSL - - Please note that you need to check that what you have installed - is compatible with Python's build options. In particular, the - BSD DB v1.85 library needs to be rebuilt with a source patch for - multithread support (doesn't change the library's reentrant status - but allows it to be linked to Python which is multithreaded). - Widely available binary packages of other librarys & DLLs are - not built/linked with multithread support. Beware! - - Also note that the Makefile currently expects any libraries to be - found with the default library search path. You may need to add - -L switches to the LDFLAGS Makefile variable if you have installed - libraries in directories not in the default search path (which can - be controlled by the LIBRARY_PATH environment variable used by EMX). - -5. make - - It is usually a good idea to redirect the stdout and stderr streams - of the make process to log files, so that you can review any messages. - -6. make test - - This runs the Python regression tests, and completion is a sign of - a usable build. You should check the list of skipped modules to - ensure that any optional modules you selected have been built; - checking the list of failures against the list of known failures - elsewhere in this document is also prudent. - -7. make install - >>>>>> NOT YET COMPLETE <<<<<< - -8. change to a directory outside the Python source tree and start Python. - Check the version and build date to confirm satisfactory installation. - - -YOU HAVE BEEN WARNED!! ----------------------- - -I know about a number of nasties in this port. - -1. Eberhard Mattes, author of EMX, writes in his documentation that fork() -is very inefficient in the OS/2 environment. It also requires that the -executable be linked in a.out format rather than OMF. Use the os.exec -and/or the os.spawn family of functions where possible. - -2. In the absence of GNU Readline, terminating the interpreter requires a -control-Z (^Z) followed by a carriage return. Jeff Rush documented this -problem in his Python 1.5.2 port. With Readline, a control-D (^D) works -as per the standard Unix environment. - -3. EMX only has a partial implementation of fcntl(). The fcntl module -in this port supports what EMX supports. If fcntl is important to you, -please review the EMX C Library Reference (included in .INF format in the -EMXVIEW.ZIP archive as part of the complete EMX development tools suite). -Because of other side-effects I have modified the test_fcntl.py test -script to deactivate the exercising of the missing functionality. - -4. The readline module has been linked against ncurses rather than the -termcap library supplied with EMX. - -5. I have configured this port to use "/" as the preferred path separator -character, rather than "\" ('\\'), in line with the convention supported -by EMX. Backslashes are still supported of course, and still appear in -unexpected places due to outside sources that don't get normalised. - -6. While the DistUtils components are now functional, other -packaging/binary handling tools and utilities such as those included in -the Demo and Tools directories - freeze in particular - are unlikely to -work. If you do get them going, I'd like to know about your success. - -7. I haven't set out to support the [BEGIN|END]LIBPATH functionality -supported by one of the earlier ports (Rush's??). If it works let me know. - -8. As a result of the limitations imposed by EMX's library routines, the -standard extension module pwd only synthesises a simple passwd database, -and the grp module cannot be supported at all. - -I have written pure Python substitutes for pwd and grp, which can process -real passwd and group files for those applications (such as MailMan) that -require more than EMX emulates. I have placed pwd.py and grp.py in -Lib/plat-os2emx, which is usually before Lib/lib-dynload (which contains -pwd.pyd) in the PYTHONPATH. If you have become attached to what pwd.pyd -supports, you can put Lib/lib-dynload before Lib/plat-os2emx in PYTHONPATH -or delete/rename pwd.py & grp.py. - -pwd.py & grp.py support locating their data files by looking in the -environment for them in the following sequence: -pwd.py: $ETC_PASSWD (%ETC_PASSWD%) - $ETC/passwd (%ETC%/passwd) - $PYTHONHOME/Etc/passwd (%PYTHONHOME%/Etc/passwd) -grp.py: $ETC_GROUP (%ETC_GROUP%) - $ETC/group (%ETC%/group) - $PYTHONHOME/Etc/group (%PYTHONHOME%/Etc/group) - -The ETC_PASSWD and ETC_GROUP environment variables are intended to allow -support for multiple passwd/grp files, where other applications may not -support as wide a variety of input variations (drive remappings, -separators etc). - -Both modules support using either the ":" character (Unix standard) or -";" (OS/2, DOS, Windows standard) field separator character, and pwd.py -implements the following drive letter conversions for the home_directory and -shell fields (for the ":" separator only): - $x -> x: - x; -> x: - -Example versions of passwd and group are in the Etc subdirectory. The -regression tests (test_pwd and test_grp) will fail if valid password and -group files cannot be found, but should pass otherwise. - -Be aware that Python's pwd & group modules are for reading password and -group information only. - -11. EMX's termios routines don't support all of the functionality now -exposed by the termios module - refer to the EMX documentation to find -out what is supported. - -12. The case sensitive import semantics introduced in Python 2.1 for other -case insensitive but case preserving file/operating systems (Windows etc), -have been incorporated into this port, and are active by default. Setting -the PYTHONCASEOK environment variable (to any value) reverts to the -previous (case insensitive) semantics. This can be an issue with some -file management utilities that do not preserve the case of file and -directory names. - -13. Because I am statically linking ncurses, the _curses_panel -module has potential problems arising from separate library data areas. -To avoid this, I have configured the _curses_.pyd (imported as -"_curses_panel") to import the ncurses symbols it needs from _curses.dll -(which is the curses module, but with a .dll extension rather than .pyd -so that the dynamic loader can actually import the symbols from it as a -DLL). - -The site module (Lib/site.py) has code added to tweak BEGINLIBPATH so -that _curses.dll is found when _curses_panel is imported. If you have -problems attempting to use the _curses_panel support please let me know, -and I'll have another look at this. - -14. sys.platform reports "os2emx" instead of "os2". os.name still -reports "os2". This change was to make it easier to distinguish between -the VAC++ build (formerly maintained by Michael Muller) and the EMX build -(this port), principally for DistUtils. - -15. it appears that the %W substitution in the EMX strftime() routine has -an off-by-one bug. strftime was listed as passing the regression tests -in previous releases, but this fact appears to have been an oversight in -the regression test suite. To fix this really requires a portable -strftime routine - I'm looking into using one from FreeBSD, but its not -ready yet. - -16. I have successfully built this port with Andy Zabolotny's ports of -pgcc 2.95 and gcc 3.2.1, in addition to EM's gcc 2.8.1. - -I have not attempted to compile Python with any version of gcc prior to -v2.8.1. - -This release sees the default optimisation change to -"-O3 -fomit-frame-pointer -mprobe". This works fine too for pgcc 2.95 -but not for gcc 3.2.1. - -With gcc 3.2.1, -O3 causes 2 unexpected test failures: test_format and -test_unicode. Both these tests pass if -O2 is instead of -O3 with this -compiler, and the performance difference is negligible (in contrast to -gcc 2.8.1 and pgcc 2.95, where the performance difference between the -2 optimisation settings approaches 10%). - -17. os.spawnv() and os.spawnve() expose EMX's library routines rather -than use the emulation in os.py. - -In order to make use of some of the features this makes available in -the OS/2 environment, you should peruse the relevant EMX documentation -(EMXLIB.INF in the EMXVIEW.ZIP archive accompanying the EMX archives -on Hobbes or LEO). Be aware that I have exposed all the "mode" options -supported by EMX, but there are combinations that either cannot be -practically used by/in Python or have the potential to compromise your -system's stability. - -18. pythonpm.exe used to be just python.exe with the WINDOWAPI linker -option set in the pythonpm.def file. In practice, this turns out to do -nothing useful. - -I have written a replacement which wraps the Python DLL in a genuine -Presentation Manager application. This version actually runs the -Python interpreter in a separate thread from the PM shell, in order -that PythonPM has a functioning message queue as good PM apps should. -In its current state, PythonPM's window is hidden. It can be displayed, -although it will have no content as nothing is ever written to the -window. Only the "hide" button is available. Although the code -has support for shutting PythonPM down when the Python interpreter is -still busy (via the "control" menu), this is not well tested and given -comments I've come across in EMX documentation suggesting that the -thread killing operation has problems I would suggest caution in -relying on this capability. - -PythonPM processes commandline parameters normally. The standard input, -output and error streams are only useful if redirected, as PythonPM's -window is not a console in any form and so cannot accept or display -anything. This means that the -i option is ineffective. - -Because the Python thread doesn't create its own message queue, creating -PM Windows and performing most PM operations is not possible from within -this thread. How this will affect supporting PM extensions (such as -Tkinter using a PM port of Tcl/Tk, or wxPython using the PM port of -WxWindows) is still being researched. - -Note that os.fork() _DOES_NOT_WORK_ in PythonPM - SYS3175s are the result -of trying. os.spawnv() _does_ work. PythonPM passes all regression tests -that the standard Python interpreter (python.exe) passes, with the exception -of test_fork1 and test_socket which both attempt to use os.fork(). - -I very much want feedback on the performance, behaviour and utility of -PythonPM. I would like to add a PM console capability to it, but that -will be a non-trivial effort. I may be able to leverage the code in -Illya Vaes' Tcl/Tk port, which would make it easier. - -19. os.chdir() uses EMX's _chdir2(), which supports changing both drive -and directory at once. Similarly, os.getcwd() uses EMX's _getcwd() -which returns drive as well as path. - -20. pyconfig.h is installed in the Include subdirectory with all -other include files. - -21. the default build explicitly sets the number of file handles -available to a Python process to 250. EMX default is 40, which is -insufficient for the tempfile regression test (test_tempfile) which -tries to create 100 temporary files. - -This setting can be overridden via the EMXOPT environment variable: - set EMXOPT=-h250 -is equivalent to the setting currently used. The emxbind utility (if you -have it installed) can also be used to permanently change the setting in -python.exe - please refer to the EMX documentation for more information. - -22. a pure python strptime module is now part of the Python standard -library, superceding a platform specific extension module. This module -leverages the strftime module, and as a result test_strptime fails -due to the EMX strftime bug in item 20 above. - -23. test_posixpath attempts to exercise various Posix path related -functionality. Most of the sub-tests pass, but the "ismount" and -"samestat" subtests fail: -- EMX provides not satisfactory mount point emulation, so "ismount" - cannot succeed; -- EMX documents that successive stat() calls will produce different - results, so "samestat" cannot succeed. - -test_posixpath should skip these tests on EMX. - -24. I have reports of BitTorrent not working. It appears that the -EMX select() emulation, possibly in concert with bugs in the TCP/IP -stack, runs into problems under the stress imposed by this application. -I think it suffices to say that BitTorrent is a fair stress test of a -system's networking capability. - -25. In the absence of an EMX implementation of the link() function, I've -implemented a crude Python emulation, in the file -Lib/plat-os2emx/_emx_link.py. This is imported into the os module, and -becomes available as os.link() in the normal way. - -The emulation copies the source file in binary mode, and will fail if -disk space is exhausted. The call fails if the target already exists. -There are no guarantees to thread safety with this emulation - beware! - -The emulation was written to support a link() based file locking system -used in GNU Mailman. - -26. AF_UNIX sockets, otherwise known as Unix domain sockets, are now -supported. Unfortunately, there are some traps arising from the -implementation in IBM's TCP/IP stack:- -- the path name must start with '\\socket\\' ('/socket/' won't work!), - with the length of the full path name less than 108 characters; -- unlike Unix, the socket endpoints don't exist in the filesystem; -- by default, sockets are in binary mode. - -27. As of Python 2.4, the mpz, rotor and xreadlines modules have been -dropped from the Python source tree. - -28. The subprocess module was added to the standard library relatively -late in the 2.4 development cycle. Unfortunately I haven't had the -round tuits to adapt the module to the EMX environment yet, and -test_subprocess has a number of failures as a result. - -29. The default stack size for threads has been 64k. This is proving -insufficient for some codebases, such as Zope. The thread stack size -still defaults to 64k, but this can now be increased via the stack_size() -function exposed by the threading & thread modules as well as by defining -THREAD_STACK_SIZE to an appropriate value in the Makefile (which contains -a commented out definition for 128kB thread stacks). I have seen -references to heavy Zope/Plone usage requiring 1MB thread stacks on -FreeBSD and Linux, but doubt that for most likely usage on OS/2 that -more than 256kB is necessary. The size of the required stacks (main -and thread) can vary significantly depending on which version of gcc -is used along with the compiler optimisations selected. Note that the -main thread stack size is set during linking and is currently 2MB. - -... probably other issues that I've not encountered, or don't remember :-( - -If you encounter other difficulties with this port, which can be -characterised as peculiar to this port rather than to the Python release, -I would like to hear about them. However I cannot promise to be able to do -anything to resolve such problems. See the Contact section below... - - -To do... --------- - -In no particular order of apparent importance or likelihood... - -- support Tkinter and/or alternative GUI (wxWindows??) - - -Credits -------- - -In addition to people identified above, I'd like to thank: -- the BDFL, Guido van Rossum, and crew for Python; -- Dr David Mertz, for trying out a pre-release of this port; -- the Python-list/comp.lang.python community; -- John Poltorak, for input about pwd/grp. - -Contact -------- - -Constructive feedback, negative or positive, about this port is welcome -and should be addressed to me at the e-mail addresses below. - -I have a private mailing list for announcements of fixes & updates to -this port. If you wish to receive such e-mail announcments, please send -me an e-mail requesting that you be added to this list. - -Andrew MacIntyre -E-mail: andymac@bullseye.apana.org.au, or andymac@pcug.org.au -Web: http://www.andymac.org/ - -28 January, 2008. |