WinShowWindow and WM_PAINT - OS2

This is a discussion on WinShowWindow and WM_PAINT - OS2 ; After trying many times to upload a whole system image with my development environment I gave up and decided to try a different approach. Since the main stepping stone for people to help me is the need of VAC++ 4.0 ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: WinShowWindow and WM_PAINT

  1. WinShowWindow and WM_PAINT

    After trying many times to upload a whole system image with my
    development environment I gave up and decided to try a different
    approach. Since the main stepping stone for people to help me is the
    need of VAC++ 4.0 I decided to continue the work on the Watcom branch
    created sometime ago.

    After some work, I was finally able to compile the whole SWT port
    under Watcom + ant 1.5.4 + Java 1.3.1 . After that I began testing the
    testcases. The first one works, meaning the JNI interface works. The
    second test doesn't. The test creates a main frame and a client
    window, but it only draws the window's borders and then it enters in a
    loop where there is a WM_PAINT message being sent. The machine becomes
    on the verge of freezing and it takes some luck to get it back. The
    same test, using the DLL created with VAC++ 4.0 works just fine. The
    Java sources are the same and so it's the C code.

    The problem starts with a call to WinShowWindow. I'm pretty lost,
    since I don't know where to start to look for answers. Maybe a
    compilers option?, simply I can't imagine why I get a different
    behavior from the same code on different compilers.

    Here is the compilers options being used:

    !include

    objects=editcol.obj structs.obj swt.obj callback.obj
    CFLAGS=-w4 -e25 -zq -od -d2 -bd -6r -bt=os2 -mf

    $(SWT_LIB) : $(objects)
    wlink name $@ SYS os2v2 dll initi termi op m, maxe=25, q, symf, many
    file { $(objects) }
    wlib -q -n -b $*.lib +$*.dll
    copy $(SWT_LIB) $(SWT_LOCATION)

    all : $(SWT_LIB)

    clean:
    -del *.obj *.err *.dll *.lib *.map $(SWT_LOCATION)\$(SWT_LIB)

    editcol.obj : editcol.c .AUTODEPEND
    wcc386 editcol $(CFLAGS)

    structs.obj : structs.c .AUTODEPEND
    wcc386 structs $(CFLAGS)

    swt.obj : swt.c .AUTODEPEND
    wcc386 swt $(CFLAGS)

    callback.obj : "..\..\..\Eclipse SWT\common\library
    \callback.c" .AUTODEPEND
    wcc386 "..\..\..\Eclipse SWT\common\library\callback.c" $(CFLAGS)

    Thanks

  2. Re: WinShowWindow and WM_PAINT

    On Wed, 23 Jul 2008 01:07:12 UTC lpino wrote:

    > After trying many times to upload a whole system image with my
    > development environment I gave up and decided to try a different
    > approach. Since the main stepping stone for people to help me is the
    > need of VAC++ 4.0 I decided to continue the work on the Watcom branch
    > created sometime ago.
    >
    > After some work, I was finally able to compile the whole SWT port
    > under Watcom + ant 1.5.4 + Java 1.3.1 . After that I began testing the


    Watcom 1.7?

    > The problem starts with a call to WinShowWindow. I'm pretty lost,
    > since I don't know where to start to look for answers. Maybe a
    > compilers option?, simply I can't imagine why I get a different
    > behavior from the same code on different compilers.
    >
    > Here is the compilers options being used:
    >
    > !include
    >
    > objects=editcol.obj structs.obj swt.obj callback.obj
    > CFLAGS=-w4 -e25 -zq -od -d2 -bd -6r -bt=os2 -mf
    >
    > $(SWT_LIB) : $(objects)
    > wlink name $@ SYS os2v2 dll initi termi op m, maxe=25, q, symf, many
    > file { $(objects) }


    You compile with -d2 (debugging), but don't link with debug all
    option, so the debugging info is lost.
    You could try -6s for stack based default.
    Perhaps you get some help from the openwatcom newsgroup
    openwatcom.users.c_cpp on server news.openwatcom.org.

    CU/2
    --
    Frank Beythien fBeythien AT gmx.de

  3. Re: WinShowWindow and WM_PAINT

    On 23 jul, 06:28, "Frank Beythien" wrote:
    > On Wed, 23 Jul 2008 01:07:12 UTC lpino wrote:
    >
    > > After trying many times to upload a whole system image with my
    > > development environment I gave up and decided to try a different
    > > approach. Since the main stepping stone for people to help me is the
    > > need of VAC++ 4.0 I decided to continue the work on the Watcom branch
    > > created sometime ago.

    >
    > > After some work, I was finally able to compile the whole SWT port
    > > under Watcom + ant 1.5.4 + Java 1.3.1 . After that I began testing the

    >
    > Watcom 1.7?


    Yes

    >
    > > The problem starts with a call to WinShowWindow. I'm pretty lost,
    > > since I don't know where to start to look for answers. Maybe a
    > > compilers option?, simply I can't imagine why I get a different
    > > behavior from the same code on different compilers.

    >
    > > Here is the compilers options being used:

    >
    > > !include

    >
    > > objects=editcol.obj structs.obj swt.obj callback.obj
    > > CFLAGS=-w4 -e25 -zq -od -d2 -bd -6r -bt=os2 -mf

    >
    > > $(SWT_LIB) : $(objects)
    > > * *wlink name $@ SYS os2v2 dll initi termi op m, maxe=25, q, symf, many
    > > file { $(objects) }

    >
    > You compile with -d2 (debugging), but don't link with debug all
    > option, so the debugging info is lost.
    > You could try -6s for stack based default.
    > Perhaps you get some help from the openwatcom newsgroup
    > openwatcom.users.c_cpp on server news.openwatcom.org.
    >
    > CU/2
    > --
    > Frank Beythien * fBeythien AT gmx.de


    Thanks, I'll try that

  4. Re: WinShowWindow and WM_PAINT

    In <7be5a223-c2cb-4957-822e-0f11c1b6a5c8@m45g2000hsb.googlegroups.com>, on
    07/22/2008
    at 06:07 PM, lpino said:

    Hi,

    >approach. Since the main stepping stone for people to help me is the need
    >of VAC++ 4.0 I decided to continue the work on the Watcom branch created
    >sometime ago.


    Excellent plan. This way you will not run up against uncorrectable
    compiler defects.

    >but it only draws the window's borders and then it enters in a loop where
    >there is a WM_PAINT message being sent. The machine becomes on the verge
    >of freezing and it takes some luck to get it back. The same test, using
    >the DLL created with VAC++ 4.0 works just fine. The Java sources are the
    >same and so it's the C code.


    >The problem starts with a call to WinShowWindow.


    This makes sense since it is going to fire off a lot of messages, some of
    which are probably failing for some reason.

    >I'm pretty lost, since I
    >don't know where to start to look for answers. Maybe a compilers option?,
    >simply I can't imagine why I get a different behavior from the same code
    >on different compilers.


    >Here is the compilers options being used:


    >!include


    >objects=editcol.obj structs.obj swt.obj callback.obj
    >CFLAGS=-w4 -e25 -zq -od -d2 -bd -6r -bt=os2 -mf


    A couple of comments here. VAC defaults to 4 byte structure alignment.
    OpenWatcom defaults to byte alignment. If you build with the OpenWatcom
    tooklit headers or the IBM Toolkit headers, this should be handled for
    you. However, other headers might not have all the required #pragma pack
    statements. You could try using -zp4 to force OpenWatcom to match the VAC
    default alignment.

    OpenWatcom command line options are very sensitive to ordering. For
    example, turning on debug data turns off some optimization options. If
    you really want these options on, the need to be specfied after the debug
    options.

    >$(SWT_LIB) : $(objects)
    > wlink name $@ SYS os2v2 dll initi termi op m, maxe=25, q, symf, many
    >file { $(objects) }
    > wlib -q -n -b $*.lib +$*.dll
    > copy $(SWT_LIB) $(SWT_LOCATION)


    Is there a reason you are not building with

    system os2v2_dll

    >editcol.obj : editcol.c .AUTODEPEND
    > wcc386 editcol $(CFLAGS)


    I would recommend defining an implicit rule of the form

    ..c.obj: .AUTODEPEND
    $(CC) $(CFLAGS) $*.c

    This will greatly simplify your makefiles.

    Steven

    --
    --------------------------------------------------------------------------------------------
    Steven Levine MR2/ICE 3.00 beta 11pre14 #10183
    eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
    --------------------------------------------------------------------------------------------


  5. Re: WinShowWindow and WM_PAINT

    On 23 jul, 15:13, Steven Levine wrote:
    > Hi,
    >
    > >approach. Since the main stepping stone for people to help me is the need
    > >of VAC++ 4.0 I decided to continue the work on the Watcom branch created
    > >sometime ago.

    >
    > Excellent plan. *This way you will not run up against uncorrectable
    > compiler defects.
    >
    > >but it only draws the window's borders and then it enters in a loop where
    > >there is a WM_PAINT message being sent. The machine becomes on the verge
    > >of freezing and it takes some luck to get it back. The same test, using
    > >the DLL created with VAC++ 4.0 works just fine. The Java sources are the
    > >same and so it's the C code.
    > >The problem starts with a call to WinShowWindow.

    >
    > This makes sense since it is going to fire off a lot of messages, some of
    > which are probably failing for some reason.


    What do you mean by failing messages?. As I see it, for some reason,
    something is generating WM_PAINT messages in a loop. The program
    removes messages from the queue, the problem is that they keep coming.

    >
    > >I'm pretty lost, since I
    > >don't know where to start to look for answers. Maybe a compilers option?,
    > >simply I can't imagine why I get a different behavior from the same code
    > >on different compilers.
    > >Here is the compilers options being used:
    > >!include
    > >objects=editcol.obj structs.obj swt.obj callback.obj
    > >CFLAGS=-w4 -e25 -zq -od -d2 -bd -6r -bt=os2 -mf

    >
    > A couple of comments here. *VAC defaults to 4 byte structure alignment.
    > OpenWatcom defaults to byte alignment. *If you build with the OpenWatcom
    > tooklit headers or the IBM Toolkit headers, this should be handled for
    > you. *However, other headers might not have all the required #pragma pack
    > statements. *You could try using -zp4 to force OpenWatcom to match the VAC
    > default alignment.
    >
    > OpenWatcom command line options are very sensitive to ordering. *For
    > example, turning on debug data turns off some optimization options. *If
    > you really want these options on, the need to be specfied after the debug
    > options.
    >

    One of the reasons I used VAC++ 4.0 was that one didn't have to worry
    too much about these things, kind of precompilers for dummies. I
    really dislike to get into these details. Anyway, since there is no
    one else to do it for me I'm getting into it.
    > >$(SWT_LIB) : $(objects)
    > > * *wlink name $@ SYS os2v2 dll initi termi op m, maxe=25, q, symf, many
    > >file { $(objects) }
    > > * *wlib -q -n -b $*.lib +$*.dll
    > > * *copy $(SWT_LIB) $(SWT_LOCATION)

    >
    > Is there a reason you are not building with
    >
    > * system os2v2_dll
    >


    Someone else wrote this CMD and I have no idea (beyond the references
    to specific paths or files), what those options do. If you send me the
    file with the changes you suggest I can test it really quickly.

    > >editcol.obj : editcol.c .AUTODEPEND
    > > * *wcc386 editcol $(CFLAGS)

    >
    > I would recommend defining an implicit rule of the form
    >
    > .c.obj: .AUTODEPEND
    > * $(CC) $(CFLAGS) $*.c
    >
    > This will greatly simplify your makefiles.
    >
    > Steven
    >


    Thank you Steven, I'm going to try everything

  6. Re: WinShowWindow and WM_PAINT

    lpino schrieb:
    > After trying many times to upload a whole system image with my
    > development environment I gave up and decided to try a different
    > approach. Since the main stepping stone for people to help me is the
    > need of VAC++ 4.0 I decided to continue the work on the Watcom branch
    > created sometime ago.
    >
    > After some work, I was finally able to compile the whole SWT port
    > under Watcom + ant 1.5.4 + Java 1.3.1 . After that I began testing the
    > testcases. The first one works, meaning the JNI interface works. The
    > second test doesn't. The test creates a main frame and a client
    > window, but it only draws the window's borders and then it enters in a
    > loop where there is a WM_PAINT message being sent. The machine becomes
    > on the verge of freezing and it takes some luck to get it back. The
    > same test, using the DLL created with VAC++ 4.0 works just fine. The
    > Java sources are the same and so it's the C code.
    >
    > The problem starts with a call to WinShowWindow. I'm pretty lost,
    > since I don't know where to start to look for answers. Maybe a
    > compilers option?, simply I can't imagine why I get a different
    > behavior from the same code on different compilers.


    Have you been testing these 2 differently compiled versions on the same
    OS/2 version (same fixpak level etc.) ?
    I have some feeling that you have a recursion somewhere and that maybe
    some API behaviour was changed from one fixpak to the other.
    WinShowWindow might now send a WM_PAINT message where it did not before.
    So maybe you are calling WinShowWindow from within WM_PAINT or such.
    And the behaviour of WinShowWindow on one specific OS version is
    certainly not influenced by the different compilers you use. If it has
    to do with the development environment you use, it would be some RTL
    function that differs in implementation from one RTL to the next.


    Lars

  7. Re: WinShowWindow and WM_PAINT

    On 24 jul, 14:38, Lars Erdmann wrote:
    > lpino schrieb:
    >
    >
    >
    > > After trying many times to upload a whole system image with my
    > > development environment I gave up and decided to try a different
    > > approach. Since the main stepping stone for people to help me is the
    > > need of VAC++ 4.0 I decided to continue the work on the Watcom branch
    > > created sometime ago.

    >
    > > After some work, I was finally able to compile the whole SWT port
    > > under Watcom + ant 1.5.4 + Java 1.3.1 . After that I began testing the
    > > testcases. The first one works, meaning the JNI interface works. The
    > > second test doesn't. The test creates a main frame and a client
    > > window, but it only draws the window's borders and then it enters in a
    > > loop where there is a WM_PAINT message being sent. The machine becomes
    > > on the verge of freezing and it takes some luck to get it back. The
    > > same test, using the DLL created with VAC++ 4.0 works just fine. The
    > > Java sources are the same and so it's the C code.

    >
    > > The problem starts with a call to WinShowWindow. I'm pretty lost,
    > > since I don't know where to start to look for answers. Maybe a
    > > compilers option?, simply I can't imagine why I get a different
    > > behavior from the same code on different compilers.

    >
    > Have you been testing these 2 differently compiled versions on the same
    > OS/2 version (same fixpak level etc.) ?
    > I have some feeling that you have a recursion somewhere and that maybe
    > some API behaviour was changed from one fixpak to the other.
    > WinShowWindow might now send a WM_PAINT message where it did not before.
    > So maybe you are calling WinShowWindow from within WM_PAINT or such.
    > And the behaviour of WinShowWindow on one specific OS version is
    > certainly not influenced by the different compilers you use. If it has
    > to do with the development environment you use, it would be some RTL
    > function that differs in implementation from one RTL to the next.
    >
    > Lars


    Unfortunally this is not the case( same OS/2, same machine. The system
    is the same, the Java code is the same, even the compiled java code is
    the same. The only difference is the DLL. One is compiled with Watcom
    and the other with VAC++. In fact the Watcom code works, since I can
    make API calls and they return just fine.

    The difference is on this behaviour when the windows are being
    drawn,,, weird and hard to trace. There is a loop where the code makes
    a call to WinPeekMsg, removing messages from the queue, but tracing it
    shows nothing wrong.

    Thanks

  8. Re: WinShowWindow and WM_PAINT

    On Wed, 23 Jul 2008 20:44:37 UTC, lpino wrote:
    > Someone else wrote this CMD and I have no idea (beyond the references
    > to specific paths or files), what those options do.
    >

    This is my doing, and I haven't done much with Open Watcom either. I
    played with the Open Watcom IDE and then tried creating something that
    would make. I'd really be interested in seeing the proper compiler and
    linker commands posted here.

    --
    Lee W. Riemenschneider
    GO BOILERS!
    Running eComStation (eCS)(the latest incarnation of OS/2)
    Buy eCS everyone! Buy it now! http://www.ecomstation.com

  9. Re: WinShowWindow and WM_PAINT

    In , on 07/24/2008
    at 11:11 PM, "Lee Riemenschneider" said:

    Hi,

    >This is my doing, and I haven't done much with Open Watcom either. I
    >played with the Open Watcom IDE and then tried creating something that
    >would make. I'd really be interested in seeing the proper compiler and
    >linker commands posted here.


    What you have so far must be pretty close. What I am recommending is just
    tuning.

    I tried pull the brance with

    http://svn.netlabs.org/repos/swt/bra..._ant17_java141

    but my guessing hat must be broken. What the correct URL?

    FWIW, it would be good if this was listed at

    http://svn.netlabs.org/swt/wiki

    Steven

    --
    --------------------------------------------------------------------------------------------
    Steven Levine MR2/ICE 3.00 beta 11pre15 #10183
    eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
    --------------------------------------------------------------------------------------------


  10. Re: WinShowWindow and WM_PAINT

    On Fri, 25 Jul 2008 00:36:18 UTC, Steven Levine
    wrote:
    > What you have so far must be pretty close. What I am recommending is just
    > tuning.
    >
    > I tried pull the brance with
    >
    > http://svn.netlabs.org/repos/swt/bra..._ant17_java141
    >
    > but my guessing hat must be broken. What the correct URL?
    >

    That is the correct one, but you'll need access from Adrian Gschwend.

    > FWIW, it would be good if this was listed at
    >
    > http://svn.netlabs.org/swt/wiki
    >

    You can follow the "Browse Source" tab to get there. Here's the path
    to the actual build script.
    http://svn.netlabs.org/swt/browser/b..._java141/src/p
    lugins/org.eclipse.swt/Eclipse%20SWT%20PI/pm/library/make_openwatcom.m
    ak


    --
    Lee W. Riemenschneider
    GO BOILERS!
    Running eComStation (eCS)(the latest incarnation of OS/2)
    Buy eCS everyone! Buy it now! http://www.ecomstation.com

  11. Re: WinShowWindow and WM_PAINT

    On 24 jul, 19:11, "Lee Riemenschneider" wrote:
    > On Wed, 23 Jul 2008 20:44:37 UTC, lpino wrote:
    > > Someone else wrote this CMD and I have no idea (beyond the references
    > > to specific paths or files), what those options do.

    >
    > This is my doing, and I haven't done much with Open Watcom either. I
    > played with the Open Watcom IDE and then tried creating something that
    > would make. I'd really be interested in seeing the proper compiler and
    > linker commands posted here.
    >
    > --
    > Lee W. Riemenschneider
    > GO BOILERS!
    > Running eComStation (eCS)(the latest incarnation of OS/2)
    > Buy eCS everyone! *Buy it now! *http://www.ecomstation.com


    Hi Lee, glad to see you here. Do you have time to do some work on
    this?. Let me tell you that I created a new branch, that I haven't
    upload, where I can experiment with different things.
    The only difference is that I dropped the Java 1.4.1 and the ant 1.7
    (i'm using java 1.3.1 and the patch ant 1.5.4), since I couldn't make
    it work (more of an ant problem, it seems). As result I was able to
    compile the whole project and I created the needed DLL. I went over
    your reports and I knew I was doing the right thing, since I came
    across the same problems you reported back then. Everything seemed to
    work fine all the way up to testcase #2, where I discovered this weird
    problem.
    Right now, I'm short on time and my computer is becoming unstable, but
    I really want to finish this work.

    Thanks


+ Reply to Thread