Re: RE: Tk for Windows (also NT)

Hammond, Mark (MHammond@jm.cmutual.com.au)
Thu, 23 Mar 95 18:37:00 PST

>After that came the python integration.
>I found that I had problems using Tk/Tcl/lxlib in dll form. For
>some reason my Tk routines weren't being properly mapped into
>memory. I decided that I would create static libraries instead.
>This almost worked.
What problems here? I am more than happy to help with this sort of stuff.
I have done this sort of stuff before (eg, Python_extension_dll ->
other_3rd_party.dll).

>It seems that the NT stuff uses the main in Python/frozenmain.c
>instead of config_nt.c
Nope. It certainly uses config_nt.c

config_nt.c has some #ifdef magic in it. 1/2 of the code is used for
Python.EXE, and the other 1/2 is used for Python.dll (ie, config_nt.c is
compiled twice with different macro defs)

>tkintermodule.c has a problem where it calls getprogramname in
>Tkinter_Create as a parameter to strrchr. Because of the
>compilation of config.c into two separate objects, argv0 isn't
>defined in the scope that Tkinter_Create is calling from, and
>thus is null. So, it passes a NULL pointer to strchr, which
>proceeds to "dump core".

Yes - this is an interesting point.

Python.DLL is basically all of Python. Python.exe is largely a stub with
main(), then calls into the dll. Any other programs that use Python use
Python.DLL.

This means that getprogramname is not a function of the DLL itself, but
should be provided by the calling .EXE.

The same thing is true for functions like fatal()/abort() - ideally, the
calling EXE should define this, rather than Python.DLL.

The only practical way to handle this (to avoid circular dependencies) may
be to install function handlers - ie, Python.DLL has a default, and the EXE
can "override" this. As Python stands, it may be possible to perform this
with the linker, but Im not sure at all.

I'll look into getprogramname, but the general issue may be worth looking
at?

>I finally managed to get windows to be opened on the screen by
>adding some initialization routines to PyInit_Tkinter which
>registered the window classes needed for TkNt with windows (NT).

I take it you are using the standard console version of Python (Python.exe)
rather than the GUI version Pythonwin.exe?

If so, you are probably in for some strife. Having a program with "main()",
then creating windows may wreak havoc. I think the problem would be in the
C RTL - depending on the entry point - main() or WinMain(), the RTL will
init differently.

If using Pythonwin.exe - this could work. I know almost nothing about Tk.

Does TK create the main application window, or just sub-windows? If the
former, then you will almost certainly want a new, special .EXE file for the
Tk version. This would have a WinMain entry point, and have really basic C
init code, deferring to Python ASAP.
>
>The problem now is that the window sizing is wrong. The windows
>are as small as they can be, and can't be resized.

Not sure what you mean by this...
>
>Has anyone managed to get Tkinter running under NT before? If
>so, I could use any suggestions you have.
I have seen requests for this before, and never an affirmative reply! You
may be the trail blazer people have been waiting for :-)

Mark.