Postit Self Extractor

[Walt Decker]

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)

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

[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.

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>

[Walt Decker]

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]

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

[Michael Mattias]

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

[Thomas Gohel]

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

[Walt Decker]

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).]

[Tom Hanlin]

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

Nope.

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