Announcement

Collapse
No announcement yet.

Postit Self Extractor

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

  • Postit Self Extractor

    I'm in the process of writing a new ABC Reader. The reader has code to automatically create Postit (mod 86) encoded files. With PB 3.5 I've run into a small problem, actually a couple:

    1 - PB appears to have a 64k limit on string literals, is there any way around that?
    2 - PB has a problem with the following code (PBCC/PBWIN and QB/PDS does not)

    Code:
    SUB U(Work as string)
    
    FOR I = 1 TO LEN(Work$)
      C = ASC(MID$(Work$,I, 1)) - 37
      IF C < 0 THEN C = 91 + C * 32
      IF K < 4 THEN
        K = C + 243
      ELSE
        PRINT #OutHndl,CHR$(C + (K MOD 3) * 86);
        K = K \ 3
        B = B + 1
      END IF
      S = (S + C) AND 255
    NEXT I
    
    END SUB
    The above code is embedded in the self extracting Postit file.
    It appears to skip the adjustment for C < 0 or somehow misinterprets the extraction of characters. C can have a negative value of only either -1 or -2.
    Given the exact same data, PBCC/PBWIN, QB/PDS work properly.

    Thank you.


    ------------------
    Walt Decker
    ABC Archives
    Walt Decker

  • #2
    The limit on string literals is easily remedied - store them in a disk file and load them into strings in memory as required. BTW, this is equivalent to using a string table in a resource file in Windows, but without the added overhead of Unicode->Ansi conversion as each string is read.

    As far as the code problem goes, can you post a compilable example that demonstrates the problem, as it is not clear what data types you are using here, nor what the data actually looks like, and whether you have any error testing enabled ($ERROR ALL ON).

    Thanks!


    ------------------
    Lance
    PowerBASIC Support
    mailto:[email protected][email protected]</A>
    Lance
    mailto:[email protected]

    Comment


    • #3
      Originally posted by Lance Edmonds:
      The limit on string literals is easily remedied - store them in a disk file and load them into strings in memory as required. BTW, this is equivalent to using a string table in a resource file in Windows, but without the added overhead of Unicode->Ansi conversion as each string is read.
      I figured you'd say that. Doing so makes the code to create the self extractable considerably more complicated.
      As far as the code problem goes, can you post a compilable example that demonstrates the problem, as it is not clear what data types you are using here, nor what the data actually looks like, and whether you have any error testing enabled ($ERROR ALL ON).

      Thanks!

      In the self extractable, there is no code for error trapping. The files are 156K or larger. I can e-mail an example, for PBCC/PBWIN and PB35, plus the code that creates the postit self extracting file, if you'd like.



      ------------------
      Walt Decker
      ABC Archives
      Walt Decker

      Comment


      • #4
        Although I think I one of the problems, I've decided to abandon creating POSTIT self-extracting files in PB-DOS. It appears that the IDE does not allow chaining to another *.BAS, so the point is really moot.

        ------------------
        Walt Decker
        ABC Archives
        Walt Decker

        Comment


        • #5
          It appears that the IDE does not allow chaining to another *.BAS, so the point is really moot.
          ??? AFAIK PB never supported CHAINing to a source code file.. but you can CHAIN to a PBU file ($COMPILE UNIT or PBU, I forget)... and that works fine..always has...

          I used to test multi-unit applications all the time using another DOS session under Windows.. compile, switch to, C:\dir\>progname<enter>

          MCM
          C:\DOS
          C:\DOS\RUN
          RUN\DOS\RUN


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

          Comment


          • #6
            on 26 apr 03, in article "postit self extractor", walt decker wrote:

            hello walt,

            > i'm in the process of writing a new abc reader. the reader has code
            > to automatically create postit (mod 86) encoded files. with pb 3.5
            > i've run into a small problem, actually a couple:
            >
            > 1 - pb appears to have a 64k limit on string literals, is there any
            > way around that? 2 - pb has a problem with the following code
            > (pbcc/pbwin and qb/pds does not)

            it's already ported to pb/dos 3.5 and pb/cc. ;-)

            moved to source code forum by administrator. see:
            http://www.powerbasic.com/support/pb...ad.php?t=23817


            regards,

            --------------
            / h o m a s
            ------------------
            email : [email protected] / mailto:[email protected][email protected]</a> (pgp-key available)
            www : www.gohel.de / http://pbsound.basicguru.com (powerbasic)
            fax/bbs: +49-30-47300910 (vfc, v34+, x75, isdn, ccb, 9600-128000bps)
            ## crosspoint [xp2] v3.31.003 beta dos/16 r/c2478, via pbnews v0.18g
            http://www.gohel.de - http://www.gohel.net - http://www.pbhq.com

            Comment


            • #7
              Michael,

              The way I worked around the 64K string literal limit is by breaking
              up a ZIP/BINARY into multiple source code sections, each section
              having it's own decoder. Each section opens the original as
              a sequential file in APPEND mode so that the decoding always starts
              at the end of a file. Having to compile each section defeats the
              concept. I suspicion that most folks who have PB-DOS also have either
              PBCC or PBWIN/DLL. There is an option in my system to produce code
              for those systems based on conditonal #IF statements embedded in the
              self extracting code.

              Thomas,
              As for a decoder ported to PB-DOS, I have that PB-DOS code, but
              having a seperated decoder defeats the concept of a self extracting
              file.

              The problem I was having with the original decoding sub (SUB U) in the
              original post seems to be related to a call to a sub similar to this:

              U"eadfqwerqcvvaefujw;e230[dsnvslckvf[ewurjmnlkasdnfo;wweoiiwer

              Notice that there is no closing quote. PDCC/PBWIN/DLL/QB/PDS handles
              that fine, however, PB-DOS does something else, like adding a NULL
              to the end.

              ------------------
              Walt Decker
              ABC Archives

              [This message has been edited by Walt Decker (edited April 29, 2003).]
              Walt Decker

              Comment


              • #8
                however, PB-DOS does something else, like adding a NULL
                to the end.
                Nope.

                ------------------
                Tom Hanlin
                PowerBASIC Staff

                Comment

                Working...
                X