Announcement

Collapse
No announcement yet.

Minor upgrade for Prostart Code Generator

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

  • Minor upgrade for Prostart Code Generator

    I have just posted a very minor upgrade to my Prostart code generator at
    the following address. The minor changes are related to the code output
    from Prostart.
    http://www.pbq.com.au/home/hutch/pbdll50.htm

    There are 4 code generation tools posted on this page, Prostart for window
    style applications, Dialog Builder for dialog style applications, SUBCLASS
    for creating control subclass functions and MAKEWIN for creating add on
    windows for an application.

    This collection of code generating tools should make a reasonable dent in
    getting true API style code up and running in a hurry.

    The tools are all freeware for PowerBASIC programmers.

    Regards,

    [email protected]

    ------------------
    hutch at movsd dot com
    The MASM Forum

    www.masm32.com

  • #2
    Steve,

    I visited your site and I had some recommendations for your
    "PB File to ASM Converter." I like the idea very much, you should
    Incorporate a simple compression/decompression algorithm. I think
    a Huffman algorithm would work or the many source code's on this
    bbs. Just a suggestion.

    Thanks,


    ------------------
    -Greg
    -Greg
    [email protected]
    MCP,MCSA,MCSE,MCSD

    Comment


    • #3
      Greg,

      Thanks for the suggestion, the binary to db conversion program needs
      a little modernisation as it was originally written for PBDLL50. I
      need to change the code that obtains the address of the DB sequence
      from runtime (LEA) to compile time CodePtr().

      The compression algo I like for general purpose work is LZ77 but I
      already have licence to Joergen Ibsen's APLIB package which is fast
      enough in compression and very fast in decompression. I use the library
      in MASM and the DLL in PowerBASIC.

      Problem is I don't think I have enough brain left at the moment to do
      an LZ77 algorithm, I have never really liked working in bit manipulation
      and to get a competitive LZ77 algo going means a lot of work at a bit
      level.

      I may get a chance to have a go at it one day but the mountain is too
      big at the moment.

      Regards,

      [email protected]

      ------------------
      hutch at movsd dot com
      The MASM Forum

      www.masm32.com

      Comment


      • #4
        Steve,

        With your permission I would like to expand on your idea and
        maybe incorporate a simple compression scheme. I don't want
        to violate any copyright laws that you have on this product.

        Thanks

        ------------------
        -Greg
        -Greg
        [email protected]
        MCP,MCSA,MCSE,MCSD

        Comment


        • #5
          Greg,

          Its not that type of problem, if you write a compression based binary
          conversion utility, its your program. Just make sure you post the URL
          for the finished version so I can download it.

          It sounds like a utility that does the compression on the fly as it does
          the conversion then a seperate decompression algorithm in the code to
          decompress it at runtime.

          With the current versions of PowerBASIC compilers being 16 bit, if you try
          to compress very large binary sources, you will run into the absolute
          memory limit imposed by 16 bit applications. Depending on the compression
          ratios you can get, you can extend this some.

          With uncompressed conversions, a binary source of about 1 meg or so was the
          limit as the resulting file started to become too big for the compiler.

          My choice of technique for very large files was to append them to the end
          of the PowerBASIC EXE file using a utility that I posted here about 6 months
          ago and a function that read the size data from the section of the DOS header
          that the utility wrote th size data to.

          Sounds like an interesting idea you have in mind, let us know how you get on
          with it.

          Regards,

          [email protected]

          ------------------
          hutch at movsd dot com
          The MASM Forum

          www.masm32.com

          Comment


          • #6
            I have just posted an upgraded version of FILE2ASM on my Australian site,
            http://www.pbq.com.au/home/hutch/pbdll50.htm

            It has been rebuilt in PBDLL60 and has had some minor changes in the code
            output so that the start address of the DB sequence that holds the data is
            determined at compile time rather than at runtime with LEA. It is marginally
            faster but probably not enough to notice and it has an extra function on the
            Edit menu to select and copy the complete function onto the clipboard.

            Regards,

            [email protected]

            ------------------
            hutch at movsd dot com
            The MASM Forum

            www.masm32.com

            Comment


            • #7
              Steve,

              I'll keep you posted on my modifications. I originally thought
              simply including any sized file would work but I think the
              16 bit limitation is coming true.

              I know I could simply copy the file to the end of the exe and
              modify the PE header to point to the area if I am correct.

              What I am wanting to do is, have a EXE/DLL wrapper. So I can
              create a program and include all the DLLs that I wish to use and
              someone just runs one EXE file and it will run without fail.

              I think this would be an awesome solution to this.



              ------------------
              -Greg
              -Greg
              [email protected]
              MCP,MCSA,MCSE,MCSD

              Comment


              • #8
                Greg,

                Encapsulating both EXE and DLL files is one of the things I designed the
                original to do and it has always worked well. If you can get a high enough
                compression ratio, you will be able to put more into the EXE file before the
                16 bit compiler limit comes into effect.

                Appending very large files to the end of the EXE also works well, this was my
                solution for installations where the resource size limit of win95 did not allow
                files over about 1 meg. I did a routine that returned the starting address of
                the appended file from an unused area of the DOS file header at the front of a
                PE file and i6 has been very reliable.

                Let me know how you get on with the idea.

                Regards,

                [email protected]

                ------------------
                hutch at movsd dot com
                The MASM Forum

                www.masm32.com

                Comment

                Working...
                X