[Distutils] More (Windows) comments on distutils-0.1.2

[Thomas Heller]

> On 13 January 2000, Thomas Heller said:
> > 1. Python extensions for Windows MUST be linked with
> > the /MD switch to use the multithreaded runtime
> > library. Optimizations are also enabled by the following
> > line:
> >
> > > class MSVCCompiler (CCompiler) :
> > >     def __init__ (self,
> > >         [...]
> > >         self.compile_options = [ '/nologo', '/Ox', '/MD', '/GD' ]
>
> I haven't seen any disagreement with this, so I'll take your word for
> it.  I'd feel more comfortable if another Python/Windows extension
> developer would speak up and say, "Yep, that's the Right Thing to do".
> (Mark?  Guido?)
>
> So what are the flags here?  I assume /Ox is for optimization; you said
> /MD selects the multithreaded RT library.  What is /GD for?
>
/GD means 'optimize for DLLs'. Not really sure what it does ;->
Oh, shit: Does nothing.
MS> /GD   (Optimize for Windows DLL)
MS> This optimization option is for future use.

>
> > 2. In build_ext.py I find the following code:
> >
> [...code to deal with .def files elided...]
>
> > Doesn't this belong into msvccompiler.py?
>
> If anywhere at all.  I really, really dislike this whole .def file
> thing, and I don't like them cluttering up the build options dictionary
> or the build_ext command class.  But I don't know how else to do it,
> because I know about as much about Python on Windows as I do about
> skateboarding on Pluto.
>
> > We do not need any stinkin' DEF-files, if we use the link options
> > /EXPORT and /BASE. The following code builds the required arguments:
>
> Hallelujah!  I've been waiting for someone to say this.  Ever since I
> found out what .def files are, I've been wondering why the heck they are
> needed.
DEF files define (at least) the exported functions in a DLL.
Python extensions usually only export the init<module> function,
so this can easily be defined in a linker switch.

>
> > >        if def_file is not None:
> > >            extra_args.append ('/DEF:' + def_file)
> > >        else:
> > >            # if no def file is found, export the init<name> function
> > >            # and calculate a random base address
> > >            extra_args.append ('/EXPORT:init' + extension_name)
> > >            import whrandom
> > >            base = whrandom.randint (0x1000, 0x8000) * 0x10000
> > >            extra_args.append ('/BASE:0x%x' % base)
>
> But this looks weird: a random base address?  What the heck is going on

On windows DLLs are linked to a certain start address.
The linker uses a default of 0x11000000, if not otherwise specified.
The windows loader, when trying to load the DLL, must relocate the DLL
to a different address if a conflict occurrs (which is slow).
Unless we have a central registry of base adresses for python extensions,
we normally cannot avoid these conflicts.

MS says:
#Because there is no way to know what base addresses might be chosen by
other
#in-process components your users might employ, the best practice is to
choose
#an address at random from the indicated range, and round it up to the next
# multiple of 64K.
#If your company produces many in-process components, you may wish
#to randomly calculate the base address of the first, and then arrange
#the others above or below the first, thus guaranteeing at least
#that your company's components will not have memory conflicts.
http://msdn.microsoft.com/library/devprods/vs6/vbasic/vbcon98/vbconsettingba
seaddressesforolecontrolprojects.htm

> here?  Again, could another Python-on-Windows expert speak up?  Nothing
> personal, Thomas, but I don't want to take the word of just one person
> on this code, and I'd like to know what the heck the random base address
> is all about.
It is a try. At least, if you still support .def files, the module
distributor
can select: random base address, or using one from a def file.
Further info, other possibilities to supply a base address:
http://msdn.microsoft.com/library/devprods/vs6/visualc/vccore/_core_.2f.base
.htm

>
> Thanks for the code -- now let's hear from some other voices as to
> whether this is the Right Thing to add to Distutils to compile
> extensions with MSVC.  Anyone?
>
>         Greg
> --
> Greg Ward - software developer                    gward@cnri.reston.va.us
> Corporation for National Research Initiatives
> 1895 Preston White Drive                           voice: +1-703-620-8990
> Reston, Virginia, USA  20191-5434                    fax: +1-703-620-0913
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> http://www.python.org/mailman/listinfo/distutils-sig