Using python23 to develop an extension for an application that has python22 embedded

Discussion in 'Python' started by John Underwood, Apr 5, 2004.

  1. Can I use python23_d and python23 to develop an extension for a
    commercial application uses python22.dll? (Providing that I do not use
    any new features found only in 2.3.)

    I would bulld version 2.2 but I am having trouble doing this with
    Visual Studio .NET Standard. (There is a well documented problem with
    version 2.2 (involving largeint.h) and VS.NET but none of the
    solutions that I found have worked.)

    On the other hand, I have successfully built release and debug
    versions of pythoncore with VS.NET.

    Thanks
    John Underwood, Apr 5, 2004
    #1
    1. Advertising

  2. John Underwood wrote:
    > Can I use python23_d and python23 to develop an extension for a
    > commercial application uses python22.dll? (Providing that I do not use
    > any new features found only in 2.3.)
    >
    > I would bulld version 2.2 but I am having trouble doing this with
    > Visual Studio .NET Standard. (There is a well documented problem with
    > version 2.2 (involving largeint.h) and VS.NET but none of the
    > solutions that I found have worked.)
    >
    > On the other hand, I have successfully built release and debug
    > versions of pythoncore with VS.NET.


    Why don't you just install the binary version of 2.2? That would be easier.
    You can have 2.2 and 2.3 installed on the same machine with no problem.

    http://www.python.org/2.2.3/

    If 2.3 is the version you use most often, you may want to reinstall it after
    installing 2.2, so that your Windows file associations point to it. You can
    just reinstall 2.3 on top of your previous 2.3 installation. (Or maybe
    there's an easier way to do this.)

    -Mike
    Michael Geary, Apr 5, 2004
    #2
    1. Advertising

  3. On Mon, 5 Apr 2004 12:56:14 -0700, "Michael Geary"
    <> wrote:

    >John Underwood wrote:
    >> Can I use python23_d and python23 to develop an extension for a
    >> commercial application uses python22.dll? (Providing that I do not use
    >> any new features found only in 2.3.)
    >>
    >> I would bulld version 2.2 but I am having trouble doing this with
    >> Visual Studio .NET Standard. (There is a well documented problem with
    >> version 2.2 (involving largeint.h) and VS.NET but none of the
    >> solutions that I found have worked.)
    >>
    >> On the other hand, I have successfully built release and debug
    >> versions of pythoncore with VS.NET.

    >
    >Why don't you just install the binary version of 2.2? That would be easier.
    >You can have 2.2 and 2.3 installed on the same machine with no problem.
    >
    >http://www.python.org/2.2.3/
    >
    >If 2.3 is the version you use most often, you may want to reinstall it after
    >installing 2.2, so that your Windows file associations point to it. You can
    >just reinstall 2.3 on top of your previous 2.3 installation. (Or maybe
    >there's an easier way to do this.)
    >
    >-Mike
    >


    I have both 2.2 and 2.3 installed on my computer. My problem has to do
    with Visual Studio .NET which will build 2.3 but will not build 2.2.
    (MS removed largeint.h which is required by pythoncore in 2.2 when
    they went from Visual C++ 6 to VS.NET. I tried supplying largeint.h to
    VS.NET but that did not work.)

    Since I cannot build 2.2, I do not have python22.dll or python22_d.dll
    (the debug version). (They are not shipped with python you have to
    produce them yourself.)

    The commercial application to which I need to add an extension has
    python22.dll in its runtime folder. I have no control over this
    application and have to use whichever version they have chosen.

    Since I do have python23.dll and python23_d.dll (from a successful
    build of 2.3), can I use these to develop an extension for the
    aforementioned commercial application if I stay away from any new
    features in 2.3 (but not in 2.2)?

    -John
    John Underwood, Apr 5, 2004
    #3
  4. John Underwood wrote:
    > I have both 2.2 and 2.3 installed on my computer. My problem has to do
    > with Visual Studio .NET which will build 2.3 but will not build 2.2.
    > (MS removed largeint.h which is required by pythoncore in 2.2 when
    > they went from Visual C++ 6 to VS.NET. I tried supplying largeint.h to
    > VS.NET but that did not work.)
    >
    > Since I cannot build 2.2, I do not have python22.dll or python22_d.dll
    > (the debug version). (They are not shipped with python you have to
    > produce them yourself.)


    The executable Python installer for Windows does install pythonXX.dll. You
    should find python22.dll and python23.dll in your Windows system32
    directory.

    Do you need python22_d.dll at all? I would think you'd need it only if you
    were actually debugging the Python interpreter itself. I've never needed a
    debug version of the Python DLL to debug ordinary Python code.

    > The commercial application to which I need to add an extension has
    > python22.dll in its runtime folder. I have no control over this
    > application and have to use whichever version they have chosen.


    Paint Shop Pro?

    > Since I do have python23.dll and python23_d.dll (from a successful
    > build of 2.3), can I use these to develop an extension for the
    > aforementioned commercial application if I stay away from any new
    > features in 2.3 (but not in 2.2)?


    Are you talking about source code compatibility only? Sure, as long as you
    use only language features available in both the old and new versions. You
    can't use .pyc bytecode files from one version with a different version.

    Anyway, I must be missing something here, because I would think you could
    simply develop with your installed Python 2.2 and run the code under your
    target application. You shouldn't have to be worrying about any of the stuff
    you're dealing with.

    -Mike
    Michael Geary, Apr 6, 2004
    #4
  5. Re: Using python23 to develop an extension for an application thathas python22 embedded

    On Mon, 5 Apr 2004, John Underwood wrote:

    > Since I do have python23.dll and python23_d.dll (from a successful
    > build of 2.3), can I use these to develop an extension for the
    > aforementioned commercial application if I stay away from any new
    > features in 2.3 (but not in 2.2)?


    You can do the development, but you won't be able to directly distribute
    the resulting extension because it will have been linked with python23.dll
    when it needs to be linked with python22.dll.

    To make things easier to fudge later, you make sure that your extension is
    Distutils'ified from the beginning.

    You can then use another compiler supported by the Distutils (MS CL
    non-optimising compiler, MinGW, Borland etc) to build the distributable
    extension in either a Python 2.2 or 2.3 installation, without risking
    mixing C runtime library mismatches (VS.NET uses a different CRT than
    VS6 I understand). If using a 2.3 installation, you'll need to substitute
    a 2.2 import library when building the final distributable version.

    The Distutils setup.py script can then provide the installation harness.

    --
    Andrew I MacIntyre "These thoughts are mine alone..."
    E-mail: (pref) | Snail: PO Box 370
    (alt) | Belconnen ACT 2616
    Web: http://www.andymac.org/ | Australia
    Andrew MacIntyre, Apr 6, 2004
    #5
  6. On Mon, 5 Apr 2004 17:44:55 -0700, "Michael Geary"
    <> wrote:

    >John Underwood wrote:
    >> I have both 2.2 and 2.3 installed on my computer. My problem has to do
    >> with Visual Studio .NET which will build 2.3 but will not build 2.2.
    >> (MS removed largeint.h which is required by pythoncore in 2.2 when
    >> they went from Visual C++ 6 to VS.NET. I tried supplying largeint.h to
    >> VS.NET but that did not work.)
    >>
    >> Since I cannot build 2.2, I do not have python22.dll or python22_d.dll
    >> (the debug version). (They are not shipped with python you have to
    >> produce them yourself.)

    >
    >The executable Python installer for Windows does install pythonXX.dll. You
    >should find python22.dll and python23.dll in your Windows system32
    >directory.
    >
    >Do you need python22_d.dll at all? I would think you'd need it only if you
    >were actually debugging the Python interpreter itself. I've never needed a
    >debug version of the Python DLL to debug ordinary Python code.
    >
    >> The commercial application to which I need to add an extension has
    >> python22.dll in its runtime folder. I have no control over this
    >> application and have to use whichever version they have chosen.

    >
    >Paint Shop Pro?


    Curious Labs - Poser 5

    >
    >> Since I do have python23.dll and python23_d.dll (from a successful
    >> build of 2.3), can I use these to develop an extension for the
    >> aforementioned commercial application if I stay away from any new
    >> features in 2.3 (but not in 2.2)?

    >
    >Are you talking about source code compatibility only? Sure, as long as you
    >use only language features available in both the old and new versions. You
    >can't use .pyc bytecode files from one version with a different version.
    >


    Yes, although I'll have to check into the .pyc bytecode issue - which
    I don't think is a problem.

    >Anyway, I must be missing something here, because I would think you could
    >simply develop with your installed Python 2.2 and run the code under your
    >target application. You shouldn't have to be worrying about any of the stuff
    >you're dealing with.
    >


    May be it comes down to the approach taken to debug an extension. (I'm
    new to Python - as you've probably guessed - and debugging mixed
    language situations.)

    To use the dubugging features of Visual Studio to debug my extension
    code, I thought I needed to use python22_d.dll (the debug version fo
    python22.dll). Is this correct? If so, I have not been able to produce
    it with Visual Studio .NET because of the problems VS has with 2.2.

    On the other hand, would it be better to debug the extension without
    the Python interface (in other words, debug the internals of the
    extension that are not dependent on Python) before attempting to test
    the Python interface (which could be performed with python22.dll)?

    -John
    John Underwood, Apr 6, 2004
    #6
  7. > Michael Geary wrote:
    > > Anyway, I must be missing something here, because I would think
    > > you could simply develop with your installed Python 2.2 and run
    > > the code under your target application. You shouldn't have to be
    > > worrying about any of the stuff you're dealing with.


    John Underwood wrote:
    > May be it comes down to the approach taken to debug an extension.
    > (I'm new to Python - as you've probably guessed - and debugging
    > mixed language situations.)
    >
    > To use the dubugging features of Visual Studio to debug my extension
    > code, I thought I needed to use python22_d.dll (the debug version fo
    > python22.dll). Is this correct? If so, I have not been able to produce
    > it with Visual Studio .NET because of the problems VS has with 2.2.
    >
    > On the other hand, would it be better to debug the extension without
    > the Python interface (in other words, debug the internals of the
    > extension that are not dependent on Python) before attempting to test
    > the Python interface (which could be performed with python22.dll)?


    Oh! I think I just realized what I was missing. Is your Poser extension part
    Python and part C/C++? I was assuming it was pure Python.

    If it was pure Python, then of course it wouldn't matter if you had the
    debug version of python22.dll. You'd use the debugging facilities that the
    Python interpreter provides for Python code, which don't depend on having
    the debug version of the interpreter.

    If you were debugging code in the Python interpreter itself, then you would
    certainly need the debug version of python22.dll.

    But are you are developing both some Python code and an extension DLL
    written in C/C++? In that case, it still wouldn't be necessary to have the
    debug version of python22.dll, any more than you need a debug version of the
    Windows DLLs such as kernel32.dll and user32.dll. You would just build a
    debug version of *your* DLL. Set the Debugging options in your VS.NET
    project properties to run Poser, and you'll be good to go. You can set
    breakpoints in your DLL, trace through the code, etc. The only limitation
    will be that you can't trace through the code inside python22.dll. Only if
    you need to do that would you need a debug version of that DLL.

    -Mike
    Michael Geary, Apr 6, 2004
    #7
  8. On Tue, 6 Apr 2004 08:40:57 -0700, "Michael Geary"
    <> wrote:

    >> Michael Geary wrote:
    >> > Anyway, I must be missing something here, because I would think
    >> > you could simply develop with your installed Python 2.2 and run
    >> > the code under your target application. You shouldn't have to be
    >> > worrying about any of the stuff you're dealing with.

    >
    >John Underwood wrote:
    >> May be it comes down to the approach taken to debug an extension.
    >> (I'm new to Python - as you've probably guessed - and debugging
    >> mixed language situations.)
    >>
    >> To use the dubugging features of Visual Studio to debug my extension
    >> code, I thought I needed to use python22_d.dll (the debug version fo
    >> python22.dll). Is this correct? If so, I have not been able to produce
    >> it with Visual Studio .NET because of the problems VS has with 2.2.
    >>
    >> On the other hand, would it be better to debug the extension without
    >> the Python interface (in other words, debug the internals of the
    >> extension that are not dependent on Python) before attempting to test
    >> the Python interface (which could be performed with python22.dll)?

    >
    >Oh! I think I just realized what I was missing. Is your Poser extension part
    >Python and part C/C++? I was assuming it was pure Python.


    There is a Python front-end (using tkinter). This is not implemented
    as an extension but is simply a script that runs in Poser. It imports
    the extension part (which is coded in C/C++).

    >
    >If it was pure Python, then of course it wouldn't matter if you had the
    >debug version of python22.dll. You'd use the debugging facilities that the
    >Python interpreter provides for Python code, which don't depend on having
    >the debug version of the interpreter.
    >
    >If you were debugging code in the Python interpreter itself, then you would
    >certainly need the debug version of python22.dll.
    >
    >But are you are developing both some Python code and an extension DLL
    >written in C/C++? In that case, it still wouldn't be necessary to have the
    >debug version of python22.dll, any more than you need a debug version of the
    >Windows DLLs such as kernel32.dll and user32.dll. You would just build a
    >debug version of *your* DLL. Set the Debugging options in your VS.NET
    >project properties to run Poser, and you'll be good to go. You can set
    >breakpoints in your DLL, trace through the code, etc. The only limitation
    >will be that you can't trace through the code inside python22.dll. Only if
    >you need to do that would you need a debug version of that DLL.
    >


    I tried a small extension DLL as a test using your suggestion. I could
    debug in VS.NET without the need of python22_d.dll which is all I
    need.

    Many thanks for the help.

    Regards,
    -John
    John Underwood, Apr 6, 2004
    #8
  9. John Underwood wrote:
    > I tried a small extension DLL as a test using your suggestion.
    > I could debug in VS.NET without the need of python22_d.dll
    > which is all I need.
    >
    > Many thanks for the help.


    Great! Glad it worked out.

    Talk with you later,

    Mike
    Michael Geary, Apr 6, 2004
    #9
  10. On Tue, 6 Apr 2004 22:02:49 +1000 (EST), Andrew MacIntyre
    <> wrote:

    >On Mon, 5 Apr 2004, John Underwood wrote:
    >
    >> Since I do have python23.dll and python23_d.dll (from a successful
    >> build of 2.3), can I use these to develop an extension for the
    >> aforementioned commercial application if I stay away from any new
    >> features in 2.3 (but not in 2.2)?

    >
    >You can do the development, but you won't be able to directly distribute
    >the resulting extension because it will have been linked with python23.dll
    >when it needs to be linked with python22.dll.
    >
    >To make things easier to fudge later, you make sure that your extension is
    >Distutils'ified from the beginning.
    >
    >You can then use another compiler supported by the Distutils (MS CL
    >non-optimising compiler, MinGW, Borland etc) to build the distributable
    >extension in either a Python 2.2 or 2.3 installation, without risking
    >mixing C runtime library mismatches (VS.NET uses a different CRT than
    >VS6 I understand). If using a 2.3 installation, you'll need to substitute
    >a 2.2 import library when building the final distributable version.
    >
    >The Distutils setup.py script can then provide the installation harness.


    Thanks for the advice. I have a Borland compiler that I'll try with
    Disutils.
    John Underwood, Apr 7, 2004
    #10
  11. Andrew MacIntyre wrote:
    > You can then use another compiler supported by the
    > Distutils (MS CL non-optimising compiler, MinGW,
    > Borland etc) to build the distributable extension in
    > either a Python 2.2 or 2.3 installation, without risking
    > mixing C runtime library mismatches (VS.NET uses a
    > different CRT than VS6 I understand). If using a 2.3
    > installation, you'll need to substitute a 2.2 import
    > library when building the final distributable version.


    Do I understand you correctly? It sounds like you are saying there is a
    problem using a DLL built with VC6 and another DLL built with VS.NET in the
    same application, but if you were to use a Borland or other compiler, then
    you would avoid this problem.

    That's not right at all. It's commonplace to have multiple DLLs loaded into
    a Windows application, all built with different compilers and all using
    different C runtimes. You can have one built with VC6, another with VS.NET,
    and another with Borland or any other compiler. You certainly don't need to
    build a DLL with Borland instead of VS.NET to avoid conflicts with another
    DLL that was built with VC6.

    If python22.dll has some incompatibility with other DLLs that are built with
    VS.NET, then there is something seriously wrong with python22.dll.

    If I misunderstood you, let me know what it was that you were getting at
    here.

    BTW, if you're distributing a DLL or application built with VS.NET, you do
    need to make sure that the appropriate C runtime is available on the target
    system. In many cases, the best way to do this is to compile and link with
    the static C runtime instead of the DLL C runtime. If you use the DLL
    version of the C runtime, you need to distribute it with your app or DLL.

    To be sure of what other DLLs (C runtimes or whatever) your DLL or app
    depends on, the best tool is Dependency Walker:

    www.dependencywalker.com

    -Mike
    Michael Geary, Apr 7, 2004
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Travis Oliphant
    Replies:
    2
    Views:
    292
    Seo Sanghyeon
    Aug 6, 2003
  2. Thomas Heller
    Replies:
    1
    Views:
    390
    Thomas Heller
    Aug 19, 2003
  3. Gary
    Replies:
    0
    Views:
    282
  4. Anand
    Replies:
    3
    Views:
    891
    Tim Daneliuk
    Nov 8, 2003
  5. Martin Schneider

    Using python22.dll with Python 2.5?

    Martin Schneider, Oct 22, 2008, in forum: Python
    Replies:
    3
    Views:
    538
    John Machin
    Oct 22, 2008
Loading...

Share This Page