Announcement

Collapse
No announcement yet.

PB/Win9 with programs written for PB/Win8

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • PB/Win9 with programs written for PB/Win8

    Received 9 today and started by making sure that it was safe to let it loose on my existing PB/Win8 projects. I'm pleased to say that most compiled with 9 with no apparent problems at all. All showed a very slight increase in size, but nothing to worry about (example, 1,085,440 to 1,106,432 bytes). #OPTIMIZE seemed to make very little difference.

    The only problem I ran into was where I was using an undocumented technique. That is, embedding constant binary data into a program by making a SUB entirely made up of !DB statements, then setting the base pointer to the table like this:

    TablePtr = CODEPTR(TableData) + 20

    where TableData is the name of the SUB. With PB/Win8 the start of the table was at CODEPTR + 20 (as shown), with PB/Win9 it is at CODEPTR + 25.
    - LJ

  • #2
    What an unpredictable result.
    It's common practise to use a label just above the !db statements.
    No offsets required.
    hellobasic

    Comment


    • #3
      Originally posted by Laurence Jackson View Post
      The only problem I ran into was where I was using an undocumented technique. That is, embedding constant binary data into a program by making a SUB entirely made up of !DB statements, then setting the base pointer to the table like this:

      TablePtr = CODEPTR(TableData) + 20

      where TableData is the name of the SUB. With PB/Win8 the start of the table was at CODEPTR + 20 (as shown), with PB/Win9 it is at CODEPTR + 25.
      Instead of using CODEPTR(Function) you should use CODEPTR(Label) of a label within that function, eg:
      Code:
      SUB Blah
       CodeStartsHere:    '// <-- Point CODEPTR here
       ! db &h90
      END SUB
      However, you can't use CODEPTR outside a function to retrieve an internal label address, but that's no problem - simply put some code before the label.

      It would be great if CODEPTR could be expanded in future to allow the returning of labels within internal subs. An optional parameter to CODEPTR would do the trick ...
      -

      Comment


      • #4
        #ALIGN

        James

        Comment


        • #5
          #ALIGN wont help with his particular problem though of "CODEPTR + <fixed number of bytes>". His problem is to do with the change in the size of header code in procedures from PB8 to PB9 (20 to 25 bytes apparently)
          -

          Comment


          • #6
            The RTL has had to increase counting for the increase in size. And paramater passing convention changes makes for the offset being different. Always, change the version to earlier or later and that offset can and will change.
            Barry

            Comment


            • #7
              Actually, posting that message made me realize that relying on undocumented parameters of the compiler isn't very bright (the original value of 20 was determined by trial and error I remember).

              I've now changed the SUB to a FUNCTION like this:

              Code:
              FUNCTION TableData () AS DWORD
              
              FUNCTION = CODEPTR(Table)
              EXIT FUNCTION
              
              Table:
              !DB &H70,&H26,&H00,&H00,&HE1,&H3D,&H00,&H00,&H4F,&H29,&H00 ...
              
              END FUNCTION
              which hopefully is compiler-independent.

              But has anyone else run into unexpected gotchas with existing code?
              - LJ

              Comment


              • #8
                That is, embedding constant binary data into a program by making a SUB entirely made up of !DB statements
                ???
                Code:
                $CONSTANT_BINARY_DATA = CHR$(first !DB, second !DB, third !DB...)
                Michael Mattias
                Tal Systems Inc. (retired)
                Racine WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  They take binary code, maybe - created by an assembler - and converted into ! DB statements. And put them into a SUB.

                  That could make sense in PB 8 for example to emulate ASM Mnemonics which have not been there.

                  Actually we have all (?) menmonics in PB 9 so the only reason do to so actually would be to just use given ASM code without having to convert it to PB Syntax.

                  I guess this is mostly interesting for ASM Programmers.
                  --Theo Gottwald
                  ------------------------------------------------
                  76706 Dettenheim * Germany * [email protected]
                  ------------------------------------------------
                  Joses Forum * Theo's Link Site * IT-Berater.org

                  Comment


                  • #10
                    Actually, the point of a construct of this sort is to create constant, literal data for use by ASM code. Laurence's new code is the close to "perfect" situation, as it readily gives you the Table address very easily (just call the function TableData). One important addition, though, would be to add the new "#DEBUG CODE OFF" metastatement. This will guarantee correct execution while debugging.

                    Best regards,

                    Bob Zale
                    PowerBASIC Inc.

                    Code:
                    FUNCTION TableData () AS DWORD
                    #DEBUG CODE OFF
                    FUNCTION = CODEPTR(Table)
                    EXIT FUNCTION
                    
                    Table:
                    !DB &H70,&H26,&H00,&H00,&HE1,&H3D,&H00,&H00,&H4F,&H29,&H00 ...
                    END FUNCTION

                    Comment


                    • #11
                      Code:
                      #define  constant_binary_data   101 
                      
                      constant_binary_data    RCDATA      
                      BEGIN
                         0x00, 0x01,0x02...
                      END
                      Code:
                      #define  constant_binary_data   101 
                      
                      constant_binary_data    RCDATA     constant_binary_data_file_name
                      Michael Mattias
                      Tal Systems Inc. (retired)
                      Racine WI USA
                      [email protected]
                      http://www.talsystems.com

                      Comment


                      • #12
                        Originally posted by Bob Zale View Post
                        Actually, the point of a construct of this sort is to create constant, literal data for use by ASM code. Laurence's new code is the close to "perfect" situation, as it readily gives you the Table address very easily (just call the function TableData). One important addition, though, would be to add the new "#DEBUG CODE OFF" metastatement. This will guarantee correct execution while debugging.

                        Best regards,

                        Bob Zale
                        PowerBASIC Inc.

                        Code:
                        FUNCTION TableData () AS DWORD
                        #DEBUG CODE OFF
                        FUNCTION = CODEPTR(Table)
                        EXIT FUNCTION
                        
                        Table:
                        !DB &H70,&H26,&H00,&H00,&HE1,&H3D,&H00,&H00,&H4F,&H29,&H00 ...
                        END FUNCTION
                        This is fine for this example but if the data happened to be an in memory dialog template the data has to be dword aligned.

                        James

                        Comment


                        • #13
                          This is fine for this example but if the data happened to be an in memory dialog template the data has to be dword aligned
                          What kind of "programmer" (quotes intentional) would use "! DB ..." to create a dialog template?

                          If you are defining a dialog template at compile time (which DB certainly does!) you'd use...
                          Code:
                          ABOUT DIALOG 10, 10, 200, 120
                          STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE
                          FONT 8, "MS Sans Serif"
                          CAPTION "About EBD2ASC Converter"
                          BEGIN
                              CTEXT           "EBD2ASC Converter v 2.1.0",          , -1, 10, 10, 180, 14
                              CTEXT           "Copyright (c) 2001 Michael C. Mattias "  , -1, 10, 25, 180, 14
                              CTEXT           "Racine WI USA",                          , -1, 10, 40, 180, 14
                              CTEXT           "Free for personal use. May be freely distributed ", -1, 10, 55, 180,14
                              CTEXT           "for non-commercial purposes."            , -1, 10, 70, 180, 14
                              CTEXT           "Contact author at [email protected]" , -1,10, 85, 180, 14
                              PUSHBUTTON      "&OK", IDOK,                              , 81, 101, 40, 14
                          END
                          Sheesh.

                          MCM
                          Michael Mattias
                          Tal Systems Inc. (retired)
                          Racine WI USA
                          [email protected]
                          http://www.talsystems.com

                          Comment


                          • #14
                            I see someone removed the do not feed sign so I'll respond.
                            Before DDT was available, I had translated some "c" code to create in memory dialogs. I thought it might speed it up a bit to use !db to store the template. This is where I first encountered the alignment problem.

                            James

                            Comment


                            • #15
                              Then you translated some hack C code. Checking the current length of your template and adding enough $NUL bytes so the size is evenly divisible by four is not really all that hard.

                              There's examples here how to do this with PB: do finds on CreateDialogIndirect and DialogboxIndirect.

                              MCM
                              Michael Mattias
                              Tal Systems Inc. (retired)
                              Racine WI USA
                              [email protected]
                              http://www.talsystems.com

                              Comment


                              • #16
                                This is fine for this example but if the data happened to be an in memory dialog template the data has to be dword aligned.
                                Then use #align like this:
                                Code:
                                #align 4
                                Table:
                                !DB &H70,&H26,&H00,&H00,&HE1,&H3D,&H00,&H00,&H4F,&H29,&H00 ...
                                Paul.

                                Comment


                                • #17
                                  Originally posted by Michael Mattias View Post
                                  Then you translated some hack C code. Checking the current length of your template and adding enough $NUL bytes so the size is evenly divisible by four is not really all that hard.

                                  There's examples here how to do this with PB: do finds on CreateDialogIndirect and DialogboxIndirect.

                                  MCM
                                  I know how to build a dialog template! You can add all the $NUL bytes you want and it will still fail if the first byte is not on a dword boundry.

                                  Comment


                                  • #18
                                    Originally posted by Paul Dixon View Post
                                    Then use #align like this:
                                    Code:
                                    #align 4
                                    Table:
                                    !DB &H70,&H26,&H00,&H00,&HE1,&H3D,&H00,&H00,&H4F,&H29,&H00 ...
                                    Paul.
                                    Exactly what I was saying.

                                    James

                                    Comment


                                    • #19
                                      know how to build a dialog template! You can add all the $NUL bytes you want and it will still fail if the first byte is not on a dword boundry.
                                      So you allocate your memory for the template on a DWORD boundary using HeapAlloc. (I think OLE strings also allocate on DWORD boundaries, but that's just empirical, I can't find doc for that).
                                      Michael Mattias
                                      Tal Systems Inc. (retired)
                                      Racine WI USA
                                      [email protected]
                                      http://www.talsystems.com

                                      Comment


                                      • #20
                                        Back To The Original Question

                                        When I first got the new compiler a few days back I tried a few of my simple template programs and they seemed to work fine. However, for the past several days I've been trying to get a really major app running (15000 + lines my code and about 20 includes) and its going slow. Havn't got it working yet. The app is heavily COM oriented and of course that is where many changes occurred. I expect I'll get it soon, but still working on it. Since getting the new compilers I've pretty much been on brain overload!

                                        Added Later:

                                        Just got my main PowerBASIC app running with PB9. The app makes heavy use of COM and I re-did the *.inc files produced by the COM Browser and had to make some changes there. The app makes rather heavy use of MS Word and MS Excel. The PB8 compiled size was 648K and PB9 is 680K. About 5% larger. I'm still in awe about this. Its some rather interesting upgrade!
                                        Last edited by Fred Harris; 20 Aug 2008, 09:50 AM.
                                        Fred
                                        "fharris"+Chr$(64)+"evenlink"+Chr$(46)+"com"

                                        Comment

                                        Working...
                                        X