PB/Win9 with programs written for PB/Win8

[Laurence Jackson]

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.

[Edwin Knoppert]

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

[Wayne Diamond]

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:

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

[jcfuller]

#ALIGN

James

[Wayne Diamond]

#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)

[Barry Erick]

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.

[Laurence Jackson]

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:

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?

[Michael Mattias]

That is, embedding constant binary data into a program by making a SUB entirely made up of !DB statements

???

$CONSTANT_BINARY_DATA = CHR$(first !DB, second !DB, third !DB...)

[Theo Gottwald]

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.

[Bob Zale]

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.

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

[Michael Mattias]

#define  constant_binary_data   101 

constant_binary_data    RCDATA      
BEGIN
   0x00, 0x01,0x02...
END

#define  constant_binary_data   101 

constant_binary_data    RCDATA     constant_binary_data_file_name

[jcfuller]

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.

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

[Michael Mattias]

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

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

[jcfuller]

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

[Michael Mattias]

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

[Paul Dixon]

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:

#align 4
Table:
!DB &H70,&H26,&H00,&H00,&HE1,&H3D,&H00,&H00,&H4F,&H29,&H00 ...

Paul.

[jcfuller]

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.

[jcfuller]

Then use #align like this:

#align 4
Table:
!DB &H70,&H26,&H00,&H00,&HE1,&H3D,&H00,&H00,&H4F,&H29,&H00 ...

Paul.

Exactly what I was saying.

James

[Michael Mattias]

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

[Fred Harris]

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!