py2exe: abnormal program termination

[PyDenis]

Today, I found strange error while using py2exe:

1. I wrote simple program and save as 1.py:
import win32ui
import win32con

win32ui.Message Box('Test messageBox.' , 'Test', win32con.MB_OK |
win32con.MB_TOP MOST )

2. I create 1_setup.py file for py2exe:
[color=blue]
> from distutils.core import setup
> import py2exe
>
> setup(
> version = "0.0",
> description = "",
> name = '',
>
> options = {"py2exe": {"compressed ": 1,
> "optimize": 2,
> "bundle_fil es": 1}},
>
> console = ["1.py"],
> zipfile = None,
> )
>[/color]

3. I run 1.exe and get error:
[code:1:7ea8ce03 ac]
Runtime Error!
Abnormal program termination.
[/code:1:7ea8ce03 ac]
http://img74.imageshac k.us/img74/4212/abnormal5mv.png

Is there a way to fix it?
Common way (python 1.py) works.

Thank you!

[robert]

Re: py2exe: abnormal program termination


PyDenis wrote:[color=blue]
> 3. I run 1.exe and get error:
> [code:1:7ea8ce03 ac]
> Runtime Error!
> Abnormal program termination.
> [/code:1:7ea8ce03 ac]
> http://img74.imageshac k.us/img74/4212/abnormal5mv.png[/color]

which win32ui build and python do you use? which OS? dual core? etc?

( Post a stack trace, if you get one, or if you have a C-debugger
installed )

recent win32ui builds introduced some new types of crashes with certain
python versions, dual cores CPU's, etc.

see https://sourceforge.net/tracker/?gro...18&atid=551954

Maybe use prior builds.

Your crash may have its reason also in the (old) "DestroyWin dow" bug
#1048355 / patch #1449736 as it has no other main gui. This bug raises
often only with certain memory layouts. Only the patch would solve this.

( I remember also little about such error with a messagebox-only program
outside of any mainframe on win98 only (but guess this was fixed; I am
not sure; can be same as #1048355 ) )

Robert

[PyDenis]

details

Python:
ActivePython 2.4.2 Build 10 (ActiveState
Corp.) based on
Python 2.4.2 (#67, Jan 17 2006, 15:36:03) [MSC
v.1310 32 bit (Intel)] on win32
-------------------------
win32ui:
Dont know how to get version info.
Little snippet
[code:1:f18a50c3 32]import win32ui

aa = sorted(dir(win3 2ui))

for i in aa:
print '%s => %r' % (i, getattr(win32ui , i))
print [/code:1:f18a50c3 32]

gives me only

copyright => 'Copyright 1994-2004 Mark Hammond
(mhammond@skipp inet.com.au)'
-------------------------
AFAIK, win32ui is part of pywin32
-------------------------
Pythonwin.exe on about: pythonwin32 build
205
-------------------------
OS: Windows 2000 SP4
Dualcore: NO

[PyDenis]

WORKAROUND

I fixed problem using Atypes:

import ctypes

ctypes.windll.u ser32.MessageBo xA(0, 'test', 'Title',
win32con.MB_ICO NINFORMATION | win32con.MB_OK |
win32con.MB_TOP MOST)


It compiles and runs fine with py2exe.


Dont remember buggy pywin32 :)

[Fredrik Lundh]

Re: WORKAROUND

Could you perhaps use basic netiquette stuff, such as sticking to the same sub-
ject line for followup posts in the same thread, and including a least some trace
of the post you're commenting on ?

(this would be less of a problem if everyone was reading your posts in a news-
reader, but this group is available in many different forms...)

</F>

[PyDenis]

Re: WORKAROUND

> Fredrik Lundhwrote:
Could you perhaps use basic netiquette stuff, such as sticking to the
same sub-[color=blue]
> ject line for followup posts in the same thread, and including a[/color]
least some trace[color=blue]
> of the post you're commenting on ?
>
> (this would be less of a problem if everyone was reading your posts[/color]
in a news-[color=blue]
> reader, but this group is available in many different forms...)
>
> </F>[/color]

Excuse me, please.

I mean, that

1. When I post new message to WEBFORUM (not a Mailing List nor News
Group) not to include even part of message.

2. About subject line: if this forum huge depends from subject line,
this field must be disabled or set to "RE: % "+ (orig_msg.subje ct) by
forum admins. Forum using some webforum engine, and easiest way to
format messages - tune it up accurately instead of messaging about
netiquette.

3. I receive message about topic posts without host name, so could go
in Browser History to find it. I mean, misplaced 'netiquette'
eclipsed by this bug:


Hello,

You are receiving this email because you are watching the topic,
"Re: WORKAROUND" at niXforums. This topic has received
a reply since your last visit. You can use the following link to view
the replies made, no more notifications will be sent until you visit
the topic.

http:///files/forum/viewtopic.php?p=730860#730860

If you no longer wish to watch this topic you can either click the
"Stop watching this topic link" found at the bottom of the
topic above, or by clicking the following link:

http:///files/forum/viewtopic.php?t=...&unwatch=topic

--
Thanks, The Management


Please, sorry for my english.

[PyDenis]

Re: WORKAROUND

> Fredrik Lundhwrote:
Could you perhaps use basic netiquette stuff, such as sticking to the
same sub-[color=blue]
> ject line for followup posts in the same thread, and including a[/color]
least some trace[color=blue]
> of the post you're commenting on ?
>
> (this would be less of a problem if everyone was reading your posts[/color]
in a news-[color=blue]
> reader, but this group is available in many different forms...)
>
> </F>[/color]

Excuse me, please.

I mean, that

1. When I post new message to WEBFORUM (not a Mailing List nor News
Group) not to include even part of message.

2. About subject line: if this forum huge depends from subject line,
this field must be disabled or set to "RE: % "+ (orig_msg.subje ct) by
forum admins. Forum using some webforum engine, and easiest way to
format messages - tune it up accurately instead of messaging about
netiquette.

3. I receive message about topic posts without host name, so could go
in Browser History to find it. I mean, misplaced 'netiquette'
eclipsed by this bug:


Hello,

You are receiving this email because you are watching the topic,
"Re: WORKAROUND" at niXforums. This topic has received
a reply since your last visit. You can use the following link to view
the replies made, no more notifications will be sent until you visit
the topic.

http:///files/forum/viewtopic.php?p=730860#730860

If you no longer wish to watch this topic you can either click the
"Stop watching this topic link" found at the bottom of the
topic above, or by clicking the following link:

http:///files/forum/viewtopic.php?t=...&unwatch=topic

--
Thanks, The Management


Please, sorry for my english.

[PyDenis]

Re: WORKAROUND

> Fredrik Lundhwrote:
Could you perhaps use basic netiquette stuff, such as sticking to the
same sub-[color=blue]
> ject line for followup posts in the same thread, and including a[/color]
least some trace[color=blue]
> of the post you're commenting on ?
>
> (this would be less of a problem if everyone was reading your posts[/color]
in a news-[color=blue]
> reader, but this group is available in many different forms...)
>
> </F>[/color]

Excuse me, please.

I mean, that

1. When I post new message to WEBFORUM (not a Mailing List nor News
Group) not to include even part of message.

2. About subject line: if this forum huge depends from subject line,
this field must be disabled or set to "RE: % "+ (orig_msg.subje ct) by
forum admins. Forum using some webforum engine, and easiest way to
format messages - tune it up accurately instead of messaging about
netiquette.

3. I receive message about topic posts without host name, so could go
in Browser History to find it. I mean, misplaced 'netiquette'
eclipsed by this bug:


Hello,

You are receiving this email because you are watching the topic,
"Re: WORKAROUND" at niXforums. This topic has received
a reply since your last visit. You can use the following link to view
the replies made, no more notifications will be sent until you visit
the topic.

http:///files/forum/viewtopic.php?p=730860#730860

If you no longer wish to watch this topic you can either click the
"Stop watching this topic link" found at the bottom of the
topic above, or by clicking the following link:

http:///files/forum/viewtopic.php?t=...&unwatch=topic

--
Thanks, The Management


Please, sorry for my english.

[Fredrik Lundh]

Re: WORKAROUND

"PyDenis" wrote:
[color=blue]
> 1. When I post new message to WEBFORUM (not a Mailing List nor News
> Group) not to include even part of message.[/color]

comp.lang.pytho n is a newsgroup and the python-list mailing list is a mailing
list. your messages appear in both places.

</F>

[robert]

Re: WORKAROUND &amp; the Python GUI-lib situation ...

PyDenis wrote:
[color=blue]
> I fixed problem using Atypes:
>
> import ctypes
>
> ctypes.windll.u ser32.MessageBo xA(0, 'test', 'Title',
> win32con.MB_ICO NINFORMATION | win32con.MB_OK |
> win32con.MB_TOP MOST)
>
>
> It compiles and runs fine with py2exe.
>
>
> Dont remember buggy pywin32 :)
>[/color]


better use win32api.Messag eBox
win32api/gui/... are flat modules unlikely to have errors.

I tested your 2-liner with build207/py2.4.2 and build205/py2.3.5 with
py2exe and cx_Freeze in each combination and could not reproduce the bug
on XP, W2K and 98.
( The DestroyWindow bug appears only for more complex apps explicitly
using .DestroyWindow from certain Notification Handlers; the dual core
bug does not apply here )

I'm curious what it is?
If you could post a bug - if reproduceable - with all your detailed
context data to pywin32 project/bugs on sf.net, that would be fine.

--- Python GUI situation:

win32ui most probably is responsible for this bug; its a complex beast
with lot of descriptional status (MFC).
win32ui wants a mainframe, a document-template, an all that like until
you can do any simple thing :-( :-) But once settled and maybe hiding
its added complexity in a custom wrapper you can program quite fluid
apps with official Windows look&feel with it.

Yet in my recent tests with wxPython (I tried now 4x over years to get
something stable with wx :-( ), Boa, Kommodo, ... I had so much more
freezes and damages, and fat memory consumption and slowness and
fatigue, and funny appearance, that I'd say, for Windows its better to
live with win32ui for non-trivial GUI's (especially distributable ones),
which appear and behave like real Windows apps - and not like something
copyied from a Donald Duck magazine.

Testing the latest wx and Boa last week (for py2.3) it hit the
high-score: All other old win32api/ui apps - just by starting them -
press magically buttons themslef, raise this and that. Never saw such
behaviour. wx modified something in the libraries. There were new
Windows ctrl-libs in the main Python folder after wx-install (which I
never requested/allowed). But even removing them did not heal the
ghostly behavor of normal win32 apps not having anything to do with wx.
Only after uninstalling wx & boa win32 was stable again...

There are some other (open) things like PyFltk and worse ...

In my opinion the overall situation of Python GUI's (platform
independent) is not in line with and not up to the level of the
wonderful language itself and to its stability.
There is always a fragile TCL or XY-C++ or MFC or this and that in the
middle - and I can't believe, that it is necessary. Python is a best OO
language for GUI programming also and it should glue soon to OS-libs
(win32api/gui../ctypes , gtk, ...) .

I'd believe there is still room for a relly good, platform independent
speedy, flat, python-only OO GUI library - which loads modules with
discipline into memory, allows building distributables below 2MB, raises
only Python exceptions and would even attack Delphi in terms of
stability, endurance, VHL language typing speed - first by Pythons
qualities, and quickly by features (for which people would contribute
very quickly if a good plan is raised).
( But maybe I'm only dreaming ... ? )

Anygui was an academical test.

Some want to see wx as standard Python GUI lib. In my opinion thats
compromising cheaply with a C++ monster for producing clumsy test
in-door apps by carefully avoiding too much stepping with broken builds ..

It is strange, that each of the big python IDE's uses another GUI
toolkit: In an urge they use everything from Tk and to even the 20MB
MozillaWindowin g-Toolkit (Komodo; I dropped 3.5 yesterday from my HD
after it core-dumped on second start and stepped 20x slower in the
debugger than PythonWin, no consistent Interactive Win/history, 100MB in
memory, .. ).

Python first should maybe have a real Python GUI toolkit and unite the
OS'es directly - as good as it does for the os module ?


Robert

[Chris Mellon]

Re: WORKAROUND &amp; the Python GUI-lib situation ...

On 3/15/06, robert <no-spam@no-spam-no-spam.com> wrote:[color=blue]
> PyDenis wrote:
>[color=green]
> > I fixed problem using Atypes:
> >
> > import ctypes
> >
> > ctypes.windll.u ser32.MessageBo xA(0, 'test', 'Title',
> > win32con.MB_ICO NINFORMATION | win32con.MB_OK |
> > win32con.MB_TOP MOST)
> >
> >
> > It compiles and runs fine with py2exe.
> >
> >
> > Dont remember buggy pywin32 :)
> >[/color]
>
>
> better use win32api.Messag eBox
> win32api/gui/... are flat modules unlikely to have errors.
>
> I tested your 2-liner with build207/py2.4.2 and build205/py2.3.5 with
> py2exe and cx_Freeze in each combination and could not reproduce the bug
> on XP, W2K and 98.
> ( The DestroyWindow bug appears only for more complex apps explicitly
> using .DestroyWindow from certain Notification Handlers; the dual core
> bug does not apply here )
>
> I'm curious what it is?
> If you could post a bug - if reproduceable - with all your detailed
> context data to pywin32 project/bugs on sf.net, that would be fine.
>
> --- Python GUI situation:
>
> win32ui most probably is responsible for this bug; its a complex beast
> with lot of descriptional status (MFC).
> win32ui wants a mainframe, a document-template, an all that like until
> you can do any simple thing :-( :-) But once settled and maybe hiding
> its added complexity in a custom wrapper you can program quite fluid
> apps with official Windows look&feel with it.
>
> Yet in my recent tests with wxPython (I tried now 4x over years to get
> something stable with wx :-( ), Boa, Kommodo, ... I had so much more
> freezes and damages, and fat memory consumption and slowness and
> fatigue, and funny appearance, that I'd say, for Windows its better to
> live with win32ui for non-trivial GUI's (especially distributable ones),
> which appear and behave like real Windows apps - and not like something
> copyied from a Donald Duck magazine.
>[/color]

win32gui and wxPython use *exactly* the same controls in almost all
cases. If you're seeing something "donald duck" then you're either
doing something wrong, or you're using a custom control. wx is also in
a far better position for most non-trivial UIs, becuase it has
infrastructure that win32 (pretty much alone among modern UI toolkits)
lacks, like layout algorithms and i18ln support.
[color=blue]
> Testing the latest wx and Boa last week (for py2.3) it hit the
> high-score: All other old win32api/ui apps - just by starting them -
> press magically buttons themslef, raise this and that. Never saw such
> behaviour. wx modified something in the libraries. There were new
> Windows ctrl-libs in the main Python folder after wx-install (which I
> never requested/allowed). But even removing them did not heal the
> ghostly behavor of normal win32 apps not having anything to do with wx.
> Only after uninstalling wx & boa win32 was stable again...
>[/color]

I dont know where you get your wx libs from, or what "press magically
buttons themself" means, but the official wx installer doesn't do any
of this. Whatever you saw had nothing to do with wx.
[color=blue]
> There are some other (open) things like PyFltk and worse ...
>
> In my opinion the overall situation of Python GUI's (platform
> independent) is not in line with and not up to the level of the
> wonderful language itself and to its stability.
> There is always a fragile TCL or XY-C++ or MFC or this and that in the
> middle - and I can't believe, that it is necessary. Python is a best OO
> language for GUI programming also and it should glue soon to OS-libs
> (win32api/gui../ctypes , gtk, ...) .
>
> I'd believe there is still room for a relly good, platform independent
> speedy, flat, python-only OO GUI library - which loads modules with
> discipline into memory, allows building distributables below 2MB,[/color]

Python all by itself is bigger than this unless you totally gut the
standard library, and even then it's just barely under 2MB.
[color=blue]
>raises
> only Python exceptions and would even attack Delphi in terms of
> stability, endurance, VHL language typing speed - first by Pythons
> qualities, and quickly by features (for which people would contribute
> very quickly if a good plan is raised).
> ( But maybe I'm only dreaming ... ? )
>
> Anygui was an academical test.
>
> Some want to see wx as standard Python GUI lib. In my opinion thats
> compromising cheaply with a C++ monster for producing clumsy test
> in-door apps by carefully avoiding too much stepping with broken builds ...
>
> It is strange, that each of the big python IDE's uses another GUI
> toolkit: In an urge they use everything from Tk and to even the 20MB
> MozillaWindowin g-Toolkit (Komodo; I dropped 3.5 yesterday from my HD
> after it core-dumped on second start and stepped 20x slower in the
> debugger than PythonWin, no consistent Interactive Win/history, 100MB in
> memory, .. ).
>
> Python first should maybe have a real Python GUI toolkit and unite the
> OS'es directly - as good as it does for the os module ?
>[/color]

Even a minimal GUI toolkit is an order of magnitude more complicated
than the os module.
[color=blue]
>
> Robert
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>[/color]

[Diez B. Roggisch]

Re: WORKAROUND &amp; the Python GUI-lib situation ...

> wx is also in[color=blue]
> a far better position for most non-trivial UIs, becuase it has
> infrastructure that win32 (pretty much alone among modern UI toolkits)
> lacks, like layout algorithms and i18ln support.[/color]

Qt has all of this. On all platforms. Just for the record.

And layout algorithms - that was something I discovered in tk (using it from
tcl, btw) 10 years ago - but my VB experience some years later didn't
include that. Maybe that has changed - but the straight VB 6.0 GUI builder
certainly encouraged you to use windows UI-units or however these thingies
were called.

Regards,

Diez

[Chris Mellon]

Re: WORKAROUND &amp; the Python GUI-lib situation ...

On 3/15/06, Diez B. Roggisch <deets@nospam.w eb.de> wrote:[color=blue][color=green]
> > wx is also in
> > a far better position for most non-trivial UIs, becuase it has
> > infrastructure that win32 (pretty much alone among modern UI toolkits)
> > lacks, like layout algorithms and i18ln support.[/color]
>
> Qt has all of this. On all platforms. Just for the record.
>[/color]

I know - so do almost all other toolkits, but not the win32 API, which
is what I was comparing it to.
[color=blue]
> And layout algorithms - that was something I discovered in tk (using it from
> tcl, btw) 10 years ago - but my VB experience some years later didn't
> include that. Maybe that has changed - but the straight VB 6.0 GUI builder
> certainly encouraged you to use windows UI-units or however these thingies
> were called.
>[/color]

Dialog units. But thats a mapping mechanism for scaling dialogs to
screen resolution, not a layout mechanism. The traditional mechanism
on win32 (VB and otherwise) is to place your controls in absolute
(dialog unit) coordinates. If you want to scale with window resizes,
you need to do it manually. Even Delphi has better layout support than
that!
[color=blue]
> Regards,
>
> Diez
> --
> http://mail.python.org/mailman/listinfo/python-list
>[/color]

[Diez B. Roggisch]

Re: WORKAROUND &amp; the Python GUI-lib situation ...

>> > a far better position for most non-trivial UIs, becuase it has[color=blue][color=green][color=darkred]
>> > infrastructure that win32 (pretty much alone among modern UI toolkits)
>> > lacks, like layout algorithms and i18ln support.[/color]
>>
>> Qt has all of this. On all platforms. Just for the record.
>>[/color]
>
> I know - so do almost all other toolkits, but not the win32 API, which
> is what I was comparing it to.[/color]

Ah, I misread your statement as win32 _having_ layout algorithms.
[color=blue]
> Dialog units. But thats a mapping mechanism for scaling dialogs to
> screen resolution, not a layout mechanism. The traditional mechanism
> on win32 (VB and otherwise) is to place your controls in absolute
> (dialog unit) coordinates. If you want to scale with window resizes,
> you need to do it manually. Even Delphi has better layout support than
> that![/color]

Yes - and as I knew tk when first seing win32, I thought of it being
archaic.

Sorry for the confusion,

Diez

[robert]

Re: WORKAROUND &amp; the Python GUI-lib situation ...

Chris Mellon wrote:
[color=blue]
>
> win32gui and wxPython use *exactly* the same controls in almost all[/color]

(win32ui or win32gui? the later is almost only a better ctypes replacement )
[color=blue]
> cases. If you're seeing something "donald duck" then you're either
> doing something wrong, or you're using a custom control. wx is also in
> a far better position for most non-trivial UIs, becuase it has
> infrastructure that win32 (pretty much alone among modern UI toolkits)
> lacks, like layout algorithms and i18ln support.[/color]

Yes, wx is of course fat.
But I guess things like a layout algorithm ? is done very quickly in a
clean Python only lib. I can just imagine ...
[color=blue][color=green]
>>Testing the latest wx and Boa last week (for py2.3) it hit the
>>high-score: All other old win32api/ui apps - just by starting them -
>>press magically buttons themslef, raise this and that. Never saw such
>>behaviour. wx modified something in the libraries. There were new
>>Windows ctrl-libs in the main Python folder after wx-install (which I
>>never requested/allowed). But even removing them did not heal the
>>ghostly behavor of normal win32 apps not having anything to do with wx.
>>Only after uninstalling wx & boa win32 was stable again...
>>[/color]
>
>
> I dont know where you get your wx libs from, or what "press magically
> buttons themself" means, but the official wx installer doesn't do any
> of this. Whatever you saw had nothing to do with wx.[/color]

that last test was with py2.3.5 / pywin32 205 /
wxPython2.6-win32-ansi-2.6.2.1-py23.exe

then run a few dialog examples of win32 and the dance begins.

[color=blue][color=green]
>>There are some other (open) things like PyFltk and worse ...
>>
>>In my opinion the overall situation of Python GUI's (platform
>>independent ) is not in line with and not up to the level of the
>>wonderful language itself and to its stability.
>>There is always a fragile TCL or XY-C++ or MFC or this and that in the
>>middle - and I can't believe, that it is necessary. Python is a best OO
>>language for GUI programming also and it should glue soon to OS-libs
>>(win32api/gui../ctypes , gtk, ...) .
>>
>>I'd believe there is still room for a relly good, platform independent
>>speedy, flat, python-only OO GUI library - which loads modules with
>>discipline into memory, allows building distributables below 2MB,[/color]
>
>
> Python all by itself is bigger than this unless you totally gut the
> standard library, and even then it's just barely under 2MB.[/color]


???

This 2-liner hello world 1.py with win32ui(=MFC) of this thread with
py2exe / cx_freeze / py2.3 / win32ui 205 is all compressed 869kB , or
even 700 kB with upx&7zip.


A quite big app (upx'ed) with win32ui, ssl, enc., unicode and all ..

app.zip 683 kB
app.exe 8 kB
_socket.pyd 16 kB
_sre.pyd 18 kB
_ssl.pyd 192 kB
_winreg.pyd 11 kB
datetime.pyd 17 kB
pywintypes23.dl l 39 kB
unicodedata.pyd 167 kB
w9xpopen.exe 3 kB
win32api.pyd 21 kB
win32clipboard. pyd 6 kB
win32gui.pyd 25 kB
win32help.pyd 11 kB
win32task.dll 21 kB
win32ui.pyd 156 kB
zlib.pyd 23 kB
AES.pyd 13 kB
Blowfish.pyd 11 kB
DES3.pyd 9 kB
select.pyd 5 kB
python23.dll 361 kB



... is not more than 1700kB. That competes with Delphi.

A real Python OO GUI lib would be similar in size, maybe even smaller.
you'd hardly get more than 2MB (without docs) after all compressions.

[color=blue][color=green]
>>Python first should maybe have a real Python GUI toolkit and unite the
>>OS'es directly - as good as it does for the os module ?
>>[/color]
>
>
> Even a minimal GUI toolkit is an order of magnitude more complicated
> than the os module.[/color]

Of course its some effort, but with Python you code very very fast.

Once a basic OO message handling system is wired and the first commctrls
of Windows are covered and resembled on the other systems, things would
go very fast. Resembling indispensable things of MFC/wx like
tool/statusbars, docking windows, ... can also be coded quickly with a
clean python GUI system. And soon first professional apps could be built
.... the more I think about it

Most effort would be to have a mature, compatible event system. wx
learned it anyway from Windows (WM_ -> EVT_ ) and resembled it more on
Linux, etc.

That would be principally ok here too, as Windows is quite good in this
(despite the rest of the OS). One could "steal" a few principles,
abstract algs. and even names in less time than gluing the fragile C++.

Robert