
READ THIS HERE
================================================================================

  This is a "release" of the whole python13 source tree. I've been
  compiling it with MSVC++ 4.0 (under NT 3.51), which seems to do a bit
  better than previous releases.  I have not integrated it into the MS
  development environment - which seems to be a big pig in a small box.

  I'm releasing it because I've learned a lot in getting it going, and
  I feel like I want to give something back to the Python community.
  Guido and the whole group have done yeoman work for a long time, and
  I for one am very happy with the results.

  I this working under 1.2, but didn't want to release it until I had
  CVS running correctly so that I could tell what I'd done ("cvs diff"
  is a man's best friend).

  All that said - I don't actually use the NT version for much - I use
  a Unix flavor extended with a module to issue low-level SCSI commands
  for device control - so I there are definitely things I haven't tried
  - the socket module *seems* to work, but all I did was run the
  throughput.py test and noted that data appeared to move.

  ross andrus 
  andrus@chopper.us.dg.com

  1/21/96

INSTALLATION
===============================================================================

  0) Unpack this distribution so you can read this file.

  1) Get and build the Tk-for-NT release. I used tknt40r1a - it 
     works well.

  2) In gnulib, build the little library

  3) In python13, modify makefile.nt.incl with local information.

  4) In python13, type

       nmake -f makefile.nt

     and stand back.

  5) Later, you can try

       nmake -f makefile.nt install

     and

       nmake -f makefile.nt libinstall

     if things seem to be going your way.


SUPPORT
==============================================================================

  You're doing a good job, and your mother and I are very proud of
  you.

  ;)

  I'll be happy to answer simple questions in a time-permitting way.
  I'm not an NT expert, nor a Python expert, though I have aspirations.

RELEASE NOTES
===============================================================================

Python 
------

This source tree is based on the Python-1.3 release, with some elements
of Mark Hammonds excellent work added, and a bit of my own brain
damage. A few highlights:

Issues with dynamic loading

  Of course this is not as straightforward as it might be. Along with
  AIX, NT requires explicit management of the visibility of objects
  (functions and data) in DLLs. This requires an extension of Marks
  work - using his DL_IMPORT() macro to pass special Microsoft stuff to
  the compiler. For various reasons, I needed more items managed than
  he does.

  The reason for that has to do with another "feature", which NT shares
  with some Unixes I've used: dynamic loading is not a symmetrical
  operation with regards to the resolution of references between
  modules - an unresolved reference in a dynamically loaded module
  won't get resolved "back to" the statically linked- and-loaded core.
  Thus, if python.exe contains the function, say, PyErr_SetString(),
  there is no convenient way for a dynamically loaded module to resolve
  its reference to the function.

  The solution I've used in Unix environments, which works here as
  well, is to split the main body of python into a small core, which is
  linked against a DLL which contains the "runtime" - most everything,
  in fact. This allows another module (e.g. tkintermodule.c) to be
  linked against the runtime DLL and, at load-time, the references get
  resolved. This is because the loader notices the references, goes to
  bring in the runtime DLL, notices it is already there, and goes on
  from there.

  The split requires some juggling. Here are some off the top of my
  head:

    * New makefiles

    * More liberal use of DL_IMPORT(), as mentioned above

    * Creation of miscproto.h to capture some prototypes which were either
      missing or infelicitously located.

    * The management of those names exported from the runtime DLL required
      that the DL_IMPORT() macro be overloaded - it gets one meaning in
      the python core, and in dynamically loaded modules, and another
      in the runtime modules.

    * Access to the program name through a global variable had to go - much
      better to use a set/get function pair and call it a day.

    * Dynamically-loaded modules must be compiled as C++ programs. The main
      feature of this seems to be to let us use the address of a
      PyType_Type in an initializer even though PyType_Type is in the
      runtime.

      For tkintermodule.c, this meant fixing up the function
      definitions.

  The runtime-dll uses the ms-standard .DLL extension, whereas the
  dynamically loaded modules (tkinter and socket, so far) use the .pyd
  extension which came from Mark.

Case insensitivity.

  I implemented a bizarre backbend to get so that I could import
  Tkinter, which in turn imports tkinter.

  The backbend is based on the fact that the DOS-derived directory
  scanning routines in WIN32 will report file names as if case
  mattered, whereas the file access routines (open(), etc..) fold the
  case. That means if you walk the PYTHONPATH and check the contents
  for the name you want, rather than just going to fopen() it, you can
  distinguish filenames with different cases.

  They'll never be in the same directory, though.

Long file names

  Forget 8.3. Forget it.

Special for TK

  The __init__() method for class Tk had default value of None for
  screenName and baseName - this causes the tknt initialization to
  fail, so I've made them non- None for the moment.

TKNT 
----

You're going to need to get your own release of the tknt40r1a sources.
There's one change in the Tk sources you *have* to make, and another
one I thought I had to make and I'm not sure if I did or not. Plus,
there are some you might want to make.  I describe these here because
I'm not supplying any sources or diffs - there's not too much to do, so
it shouldn't be a problem.

I'll assume you've got it and figured out how to build it - it's
straightforward. In what follows, file paths are relative to the top of
the tk source tree.

  Have to make:

    src\tk40\tk40.def - the file which controls exporting symbols from
    the .DLL

      Add an export for tk_NumMainWindows just before

      TkComputeTextGeometry

  Probably have to make:

    src\xlib\xdisplay.c

     In function XOpenDisplay(), at about line 100, add a memset() to
     zero out the just-malloc'ed Dptr structure:

     memset((void *)Dptr,0,sizeof(*Dptr));

  Nice to do:

    You have to fiddle with the src\util directory - I think the
    building of the .HLP files is busted.

Misc.  
-----

  MS doesn't provide a "getopt()" cognate that I could find - the GNU
  getopt() works fine.

  I've included a getopt.c I got from, I think, the cvs-1.3
  distribution, in the gnulib directory. You'll have to make it
  yourself.

