This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: MSVC 7.0 compiler support
Type: Stage:
Components: Distutils Versions:
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: jhylton Nosy List: djohnanderson, jhylton, loewis, theller, tim.peters
Priority: normal Keywords: patch

Created on 2002-09-26 03:09 by djohnanderson, last changed 2022-04-10 16:05 by admin. This issue is now closed.

File name Uploaded Description Edit
DistutilsPatch djohnanderson, 2002-09-26 21:38 MSVC 7.0 support for distutils
Messages (23)
msg41242 - (view) Author: John Anderson (djohnanderson) Date: 2002-09-26 03:09
Distutils doesn't work with the current shipping
version of the Microsoft compiler (7.0). I've got a
patch that fixes it (context diffs of
against the latest code in CVS).
msg41243 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-09-26 04:30
Logged In: YES 

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )
msg41244 - (view) Author: John Anderson (djohnanderson) Date: 2002-09-26 21:38
Logged In: YES 

Opps, I guess I forgot to check that little box. Sorry about
msg41245 - (view) Author: John Anderson (djohnanderson) Date: 2002-09-26 21:38
Logged In: YES 

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )
msg41246 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-10-07 11:43
Logged In: YES 

Can you report whether this patch works with MSVC 5?
msg41247 - (view) Author: John Anderson (djohnanderson) Date: 2002-10-07 15:27
Logged In: YES 

It's been so long since I had a copy of MSVC 5 -- I think it
became obsolete about 6 or 7 years ago. None of my changes
should have any impact on the operation of MSVC 5, but of
course you never know unless you try it. Also, the MSVC 6
support in distutils is currently broken -- although it
finds the compiler, the code to find the include paths is
totally broken. I have MSVC 6 (latest service pack) and 7
and would be willing to make both those work. Anyone who's
using 5 is going to have lots of other problems to deal with
besides distutils. Wouldn't surprise me if the MSVC 6 code
for finding paths would differ in each service pack -- since
it depends upon unsupported registry entries.
msg41248 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-10-08 09:21
Logged In: YES 

I'm asking because you are not looking into
Software\\Microsoft\\Devstudio anymore to find the most
recent version. Not supporting MSVC5 anymore is probably

I never noticed that support for MSVC6 is broken - it works
fine for me... However, if you think you can improve that
somehow, please do - please elaborate what changes solve
what problems, though. It seems that a number of changes are
not strictly necessary (e.g. creation of new functions), to
really evaluate the patch, I have to know why you propose
these changes.
msg41249 - (view) Author: John Anderson (djohnanderson) Date: 2002-10-08 15:51
Logged In: YES 

Thanks Martin for taking the time to review my proposed changes.

I think your comments about looking in
Software\Microsoft\VisualStudio instead of
Software\Microsoft\DevStudio is a good point. I decided to
two look only in VisualStudio because that works for both
the version 6 and 7 compiler I tested with. I don't know if
the version 5 compiler also stores the version in DevStudio.
Another alternative, which would of course complicate code,
would be two look in both places and choose the highest
version. Let me know if that's what you'd prefer and I'll
upload a new patch.

The problem I'm having with the version 6 compiler (latest
service Pack 5) is that
SOFTWARE\Microsoft\Devstudio\6.0\Build System\ doesn't
exist. Instead it looks like it's been moved to
SOFTWARE\Microsoft\Shared Tools\Build System\, but in that
new location, SOFTWARE\Microsoft\Shared Tools\Build
System\Components\Platforms\Win32 (x86)\Directories doesn't
exist. This has the effect of not getting the correct
include directories for builds.

This also points out a serious flaw in looking at
undocumented registry entries to find information for the
build -- there's no guarantee that the registry information
won't change even within the same version of the compiler. I
don't have a good solution for this problem, but I'd rather
distutils reported an error when it couldn't find the
registry entries it expected -- rather than silently
ignoring it as it does now. In a few places I added code to
report unexpected missing registry entries, but not all. I
could if you're interested add error code in all cases.

Fixing the problem I'm having with the version 6 compiler
seems difficult, since it seems to work for you and doesn't
work for me -- apparently are registries are different.
Personally I'm content with leaving the version 6 compiler
broken since it isn't obvious how to fix it and it
apparently works for some people and I only intend to use
the version 7 or newer compilers.

I added three new functions: convert_mbcs, read_key, and by
far the largest: expand_macros. The first two make the code
simpler, easier to read, avoid unnecessary duplications, and
minimize the risk that someone would forget to deal with
mbcs. It would be difficult to understand the bug fix
without these two functions. My hope was that these changes
would make it easier for the next person who needs to learn
the code. The last, expand_macros, is necessary because the
version 7 compiler introduces macros which didn't exist in
previous versions of the compiler. It would be awkward to
implement the macros without having adding a new function.
msg41250 - (view) Author: Thomas Heller (theller) * (Python committer) Date: 2002-10-15 17:13
Logged In: YES 

I've tried out the patch, and it works for me, at least with 
simple extensions - both with MSVC 6 and with MSVC 7, 
freshly installed.

I don't know the service pack level of my MSVC6, Help-
>About doesn't show it.

I'm not sure if using 7.0 (if available) should be the default. 
Python itself is still built with MSVC6 AFAIK.
msg41251 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2002-10-15 21:01
Logged In: YES 

Thomas, I'm just curious here:  if we were to create the 
Windows Python distribution with VC7, would the DLLs be 
compatible with extensions compiled by VC6?  In return for 
your answer to that <wink>, here's how to determine your 
MSVC6 service pack level:


and look at key "latest".
msg41252 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-10-16 08:20
Logged In: YES 

The biggest problem is that VC.NET uses a new C library,

I have not fully studied all issues, but it appears that,
for purposes of Python, you cannot mix extensions, atleast
not in the general case. In particular, you cannot pass
FILE* between both C libraries. This is particularly
annoying, since MS has managed that struct _iobuf (aka FILE)
has identical layout in both compilers. Nevertheless, it
crashes in the following scenario:

VC: fputs

The problem is that fputs wants to lock the file. For that,
it tests whether the pointer comes from its own _iob
(_file.c:_lock_file). If the pointer comes from the _iob of
the other C library, it concludes that this must be a _FILEX
(which it isn't), and crashes :-(

So it appears that one *must* build extension modules with
the Visual Studio that also has built Python.
msg41253 - (view) Author: Thomas Heller (theller) * (Python committer) Date: 2002-10-16 08:50
Logged In: YES 

It seems Martin is correct.

I made the following experiment:
Compile pythoncore, python and pythonw with MSVC7, and 
the remaining extension modules with MSVC6 (all, except 
bsddb and _tkinter).

Now the test-suite crashes hard in test_parser.

When everything is built with MSVC7, the test-suite runs fine.
msg41254 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-11-11 15:09
Logged In: YES 

It seems clear that the patch is unacceptable in its current
form: distutils *must* use the compiler that was used to
compile Python.

Would you be willing to revise your patch in that direction?
msg41255 - (view) Author: John Anderson (djohnanderson) Date: 2002-11-11 16:19
Logged In: YES 

I'm a bit confused by the question. On my computer, I
installed the current Microsoft compiler (7.0), compiled
Python, installed distutils with my patch, and built several
extensions. So distutils did use the same compiler as was
used to build Python.

If you want to use the same compiler that someone else built
Python with, then you'll need to get the same compiler they
used, to make sure it's the only version that's installed,
and distutils works fine.

Perhaps you mean that there is some way to determine which
compiler was used by Python from examining something in
Python itself. If this is possible, please let me know how
to do it. In this case I'd propose modifying the patch to
write out of warning when a different compiler was used to
run distutils than was used to compile Python. In the case
of the Microsoft compiler not all versions have been

Or perhaps you mean distutils should have a generalized way
to specify which version of compiler to use when more than
one is installed on your computer.

msg41256 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-11-11 17:07
Logged In: YES 

The typical distutils user does use a Python binary compiled
by somebody else, and may have multiple MSVC versions
installed, or may have the wrong version installed.

I was hoping that you can find the MSVC version from
sys.version, but that only tells you that it is MSC (or that
it isn't). I would suggest to modify the compiler
identification in sys.version to include the MSC version.
Perhaps we could eliminate the identification of Win32-Alpha
at the same time.

IOW, the compiler string should read
[MSC v.12 32 bit]
or perhaps v.1200 if that makes it easier.

Then, distutils should look into sys.version for the
compiler revision, and assume v.1200 (i.e. MSVC6) if no
version indication is found.
msg41257 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2002-11-11 19:38
Logged In: YES 

Martin, assuming the tests pass, I'm about to check in a 
change so that, under 2.3,

>>> import sys
>>> sys.version
'2.3a0 (#29, Nov 11 2002, 14:23:17) [MSC v.1200 32 bit 

under MSVC 6.  Also gets rid of the _M_ALPHA code.  
Those are good changes regardless of the fate of the issue 
here, but at least poor John won't have to figure out how to 
trick the preprocessor into stringizing the value of 
_MSC_VER (that's not easy, alas).
msg41258 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-12-06 09:56
Logged In: YES 

John, given Tim's recent changes: Are you willing to revise
your patch?
msg41259 - (view) Author: John Anderson (djohnanderson) Date: 2002-12-06 16:03
Logged In: YES 

I think Tim's change which makes it possible to correctly
identify the compiler used to build Python makes a lot of
sense. So I'm happy to include this in the patch. I'll also
remove the Alpha code. I will test it with the version 6 and
7 compilers using python 2.3. I'm very busy these days so it
may take me awhile.

On a slightly different subject, I think you guys should
consider switching over to the version 7 compiler. Version 6
is over 6 years old. The version 7 compiler is nearly a year
old and a new version is on the horizon. Since I've been
building Python with the version 7 compiler I've identified
and f ixed the few problems necessary to get it to work and
would be happy to provide Version 7 project files. This
would make it easy for people to use either compiler, which
in turn would make it easier for you to eventually make the
transition to a newer compiler.
msg41260 - (view) Author: Thomas Heller (theller) * (Python committer) Date: 2002-12-06 16:37
Logged In: YES 

I want to support John's comment about MSVC 7. Not that I 
like it, but I'm forced to to use it. Seriously, what would be 
required to release the (official) 2.3 Python windows build with 
msg41261 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2002-12-06 17:34
Logged In: YES 

Nobody at PLabs has MSVC7, nor time to work on this even 
if we did.  So it would require people outside of PLabs to do 
all the work.  Incompatibility with MSCV6 needs to be 
addressed too, as I doubt Guido would be willing to say that 
anyone with an extension module on Windows *has* to use 
MSVC7 if they want their extension to run with Python 2.3.
msg41262 - (view) Author: Jeremy Hylton (jhylton) (Python triager) Date: 2003-05-01 22:44
Logged In: YES 

I ran into this problem today, so I think I'll spend some
time to fix it.
msg41263 - (view) Author: Jeremy Hylton (jhylton) (Python triager) Date: 2003-05-09 16:07
Logged In: YES 

Applied variant as rev 1.54 of
Tested with MSVC 7 for 2.3 and MSVC6 for 2.2 and 2.3.
msg41264 - (view) Author: John Anderson (djohnanderson) Date: 2003-06-08 21:33
Logged In: YES 

I just got the 7.1 version of the microsoft compiler and
read over the code jhylton submitted and it looks like there
is a problem with  get_msvc_paths, which hard codes the
registry path:


it needs to be:

for the 7.1 compiler.

Although, there may be other problems with 7.1, I suspect
they are minor, so it would probably be pretty easy to
include minor changes to support 7.1

Date User Action Args
2022-04-10 16:05:42adminsetgithub: 37221
2002-09-26 03:09:16djohnandersoncreate