Minor upgrade for Prostart Code Generator

[Steve Hutchesson]

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]

------------------

[Gregery D Engle]

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

[Steve Hutchesson]

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]

------------------

[Gregery D Engle]

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

[Steve Hutchesson]

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]

------------------

[Steve Hutchesson]

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]

------------------

[Gregery D Engle]

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

[Steve Hutchesson]

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]

------------------