1. something is wrong
Dear Eu users:
I'm playing with the clock.exw program - one of
the win32lib demos (v0060.03).
It is 1603 bytes at all. It works OK if it is interpreted,
both in English & in Russian, but doesn't show the current
time if translated to C and compiled with Open Watcom v1.2
compiler, both in English & in Russian, (on Win95).
It gives 77 files of C source code (3,487,386 bytes at all)
and the compiled clock.exe is huge - 1,368,064 bytes.
(It just outputs a small window with just 6 digits
of the current system time, if works normally).
There is something wrong somewhere in the World,
for both English & Russian, IMHO. 8-0
Regards,
Igor Kachan
kinz at peterlink.ru
2. Re: something is wrong
Hi Igor,
you wrote:
> I'm playing with the clock.exw program - one of
> the win32lib demos (v0060.03).
>
> It is 1603 bytes at all. It works OK if it is interpreted,
> both in English & in Russian, but doesn't show the current
> time if translated to C and compiled with Open Watcom v1.2
> compiler, both in English & in Russian, (on Win95).
>
> It gives 77 files of C source code (3,487,386 bytes at all)
> and the compiled clock.exe is huge - 1,368,064 bytes.
>
> (It just outputs a small window with just 6 digits
> of the current system time, if works normally).
>
> There is something wrong somewhere in the World,
> for both English & Russian, IMHO. 8-0
I have Win32Lib 0.60.1 here (on Windows 98), and just tested its
'clock.exw' program. The results are pretty much the same than yours:
- Interpreted with 'exw.exe' 2.4 (Complete Edition), it runs as
expected. That is, it shows a window, that only consists of a title
bar, which displays the system time.
- Translated to C with 'ecw.exe' 2.4, and compiled with the Open Watcom
compiler 1.0, an EXE file with a size of 1384448 bytes is produced.
Running this EXE file shows the same window, but its title bar doesn't
display anything.
- Translated to C with 'ecw.exe' 2.4, and compiled with the Borland
compiler 5.5, an EXE file with a size of 1376256 bytes is produced.
Running this EXE file shows the same window, but its title bar doesn't
display anything.
Strange.
Regards,
Juergen
3. Re: something is wrong
Juergen Luethje wrote:
>
> Hi Igor,
>
> you wrote:
>
> > I'm playing with the clock.exw program - one of
> > the win32lib demos (v0060.03).
> >
> > It is 1603 bytes at all. It works OK if it is interpreted,
> > both in English & in Russian, but doesn't show the current
> > time if translated to C and compiled with Open Watcom v1.2
> > compiler, both in English & in Russian, (on Win95).
> >
> > It gives 77 files of C source code (3,487,386 bytes at all)
> > and the compiled clock.exe is huge - 1,368,064 bytes.
> >
<snip>
>
> I have Win32Lib 0.60.1 here (on Windows 98), and just tested its
> 'clock.exw' program. The results are pretty much the same than yours:
>
> - Interpreted with 'exw.exe' 2.4 (Complete Edition), it runs as
> expected. That is, it shows a window, that only consists of a title
> bar, which displays the system time.
>
> - Translated to C with 'ecw.exe' 2.4, and compiled with the Open Watcom
> compiler 1.0, an EXE file with a size of 1384448 bytes is produced.
> Running this EXE file shows the same window, but its title bar doesn't
> display anything.
>
> - Translated to C with 'ecw.exe' 2.4, and compiled with the Borland
> compiler 5.5, an EXE file with a size of 1376256 bytes is produced.
> Running this EXE file shows the same window, but its title bar doesn't
> display anything.
It also doesn't seem to run correctly when bound. It simply opens up
and displays "Clock". I think the problem is that using the forms and
the w32Start.ew methodology (with which I am not familiar), you end
up with calls to routine_id() using a variable, which means that
all routines must be kept, so you basically end up with all of Win32Lib.
Converting to the 'old' style of actually creating controls and using
setHandler(), bind works fine (exe goes from about 340K to 230K).
Translated and compiled with OpenWatcom 1.2, I go from about 1.3M to
940K, plus it works now.
When binding, I get the message that AppCallback is renamed, because it
conflicts with an earlier symbol. In w32Start.ew, changing it to
AppCallback1 fixed the problem when binding. I can't find where it's
previously defined, however, so this appears to be a bug in the binder.
This doesn't fix the translated version, where changing the name of the
procedure doesn't make any difference.
So, the bound version can't find the procedure AppCallback, because it
gets renamed for some reason, but once it finds that, it runs fine. The
translated version doesn't have any problem finding this, but does have
problem finding the event handlers' routine ids. It finds them just fine
from within clock.exw, but not from within w32Start.ew. It can call the
procedures, but can't get their routine_ids. The only thing I can think
of is that routine_id has an error testing whether the routine is really
in scope (it is).
Matt Lewis
4. Re: something is wrong
> It gives 77 files of C source code (3,487,386 bytes at all)
> and the compiled clock.exe is huge - 1,368,064 bytes.
Tired of using a huge cantankerous bulldozer to plant that tulip bulb ?
Try George's dialog box wrapper instead !
...anyway's, here's my 'dating' demo, as a simple winGUI.
http://www.king.igs.net/~wolfritz/dating.zip under 4k.
5. Re: something is wrong
- Posted by Robert Craig <rds at RapidEuphoria.com>
Aug 24, 2004
-
Last edited Aug 25, 2004
I set up Win32Lib 0.60.4 and tried the clock.exw example.
With both the 2.4 binder and the 2.4 translator
I saw the problem where the time does not appear,
only the word "Clock".
With both the 2.5 (alpha) binder and the 2.5 (alpha) translator,
clock.exw worked fine. I also tried Win32Lib 0.59.1 and
everything worked fine with 2.5.
I noticed with 0.60.4 the .exe size produced by the
translator was more than double, 1443K vs 602K. This is
likely due to w32start.ew which has a call to routine_id()
using a general expression, parms[1], rather than the
usual hard-coded string naming a specific routine.
What happens in this case is that the Translator
(and also the binder) must mark every earlier global routine
(plus the local routines in the same file) as being a possible target
of routine_id(). This prevents these routines from ever being
deleted. Maybe there is a way to avoid this, such as moving the
general call to routine_id() to a place much earlier in the source.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. Re: something is wrong
On Tue, 24 Aug 2004 14:51:40 -0400, Wolf <wolfritz at KING.IGS.NET>
wrote:
>Tired of using a huge cantankerous bulldozer to plant that tulip bulb ?
>Try George's dialog box wrapper instead !
>
>...anyway's, here's my 'dating' demo, as a simple winGUI.
>http://www.king.igs.net/~wolfritz/dating.zip under 4k.
Why was line 204 of dlgbox.ew (free( pTemplate )) commented out?
Pete
7. Re: something is wrong
Robert Craig wrote:
>
> I set up Win32Lib 0.60.4 and tried the clock.exw example.
>
> With both the 2.4 binder and the 2.4 translator
> I saw the problem where the time does not appear,
> only the word "Clock".
>
> With both the 2.5 (alpha) binder and the 2.5 (alpha) translator,
> clock.exw worked fine. I also tried Win32Lib 0.59.1 and
> everything worked fine with 2.5.
This is good news.
> I noticed with 0.60.4 the .exe size produced by the
> translator was more than double, 1443K vs 602K. This is
> likely due to w32start.ew which has a call to routine_id()
> using a general expression, parms[1], rather than the
> usual hard-coded string naming a specific routine.
> What happens in this case is that the Translator
> (and also the binder) must mark every earlier global routine
> (plus the local routines in the same file) as being a possible target
> of routine_id(). This prevents these routines from ever being
> deleted. Maybe there is a way to avoid this, such as moving the
> general call to routine_id() to a place much earlier in the source.
I don't think that's possible. The whole idea of having this call to
routine_id at the end of the program's source is so it can 'find' any
global routine anywhere in the entire source file(s). If we routine_id()
could do forward referencing at run-time, then this would not be
a problem.
--
Derek Parnell
Melbourne, Australia
8. Re: something is wrong
Matt Lewis wrote:
> Juergen Luethje wrote:
<snip>
>> - Translated to C with 'ecw.exe' 2.4, and compiled with the Open Watcom
>> compiler 1.0, an EXE file with a size of 1384448 bytes is produced.
>> Running this EXE file shows the same window, but its title bar doesn't
>> display anything.
>>
>> - Translated to C with 'ecw.exe' 2.4, and compiled with the Borland
>> compiler 5.5, an EXE file with a size of 1376256 bytes is produced.
>> Running this EXE file shows the same window, but its title bar doesn't
>> display anything.
>
> It also doesn't seem to run correctly when bound. It simply opens up
> and displays "Clock".
This is, what also happens with my translated/compiled progtams, of
course. "doesn't display anything" was wrong, sorry.
> I think the problem is that using the forms and
> the w32Start.ew methodology (with which I am not familiar), you end
> up with calls to routine_id() using a variable, which means that
> all routines must be kept, so you basically end up with all of Win32Lib.
>
> Converting to the 'old' style of actually creating controls and using
> setHandler(), bind works fine (exe goes from about 340K to 230K).
> Translated and compiled with OpenWatcom 1.2, I go from about 1.3M to
> 940K, plus it works now.
>
> When binding, I get the message that AppCallback is renamed, because it
> conflicts with an earlier symbol. In w32Start.ew, changing it to
> AppCallback1 fixed the problem when binding. I can't find where it's
> previously defined, however, so this appears to be a bug in the binder.
> This doesn't fix the translated version, where changing the name of the
> procedure doesn't make any difference.
>
> So, the bound version can't find the procedure AppCallback, because it
> gets renamed for some reason, but once it finds that, it runs fine. The
> translated version doesn't have any problem finding this, but does have
> problem finding the event handlers' routine ids. It finds them just fine
> from within clock.exw, but not from within w32Start.ew. It can call the
> procedures, but can't get their routine_ids. The only thing I can think
> of is that routine_id has an error testing whether the routine is really
> in scope (it is).
Duuh, strange things going on behind the scenes ...
Fortunately, Rob wrote that with both the 2.5 (alpha) binder and the 2.5
(alpha) translator, 'clock.exw' works fine.
Regards,
Juergen
9. Re: something is wrong
Hi Juergen, Matt, Rob, Wolf, Pete, Derek:
Thanks for reply!
Juergen Luethje wrote:
[snip]
> Duuh, strange things going on behind the scenes ...
Nothing strange, I think.
Just a bug.
The process of programming is very simple and clear thing:
bug-fix, bug-fix, bug-fix, bug-fix, bug-fix,
bug-fix ... without the end :
while 1 do
bug_fix()
end while
> Fortunately, Rob wrote that with
> both the 2.5 (alpha) binder and the 2.5
> (alpha) translator, 'clock.exw' works fine.
OK, let us wait for 2.5.
Good Luck To All !
Regards,
Igor Kachan
kinz at peterlink.ru
