[futurebasic] Re: [FB] FBII->3 Source Conversions Success!

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : September 1999 : Group Archive : Group : All Groups

From: Derek Smith <dereksmi@...>
Date: Sun, 19 Sep 1999 00:20:01 -1000
On Sat, 18 Sep 1999, Mel Patrick wrote:

> >jonathan said,
> >
> >function even under 8.6, this doesn't worry me. The problem is not with
> >FB^3, I hasten to add, but with me!
> I just managed to convert one of my smaller projects (3 include 
> files, one global and a main) and got it working in FB3! Aw the sweet 
> smell of success.

Congrats Mel!
> One of my errors was naming the DIM RECORD and DIM RECORD END with 
> the same variable. It didn't flag it as an error during compiles or 
> anything else (contrary to what the conversion docs say) and it let 
> me shove stuff into the records in a function, but once outside of 
> the function it was gone. Somplace. Very far away. Never to be seen 
> again.

Yikes!  A user on the beta team found this error actually, but quite
recently.  It may not be in the conversion docs.  I highly reccomend
changing DIM RECORDS to BEGIN RECORDs and changing DIMs from x.something
to x As Something when dealing with records.  It makes a big difference.

> I compiled my corrected app as a 68K application (since it has a fair 
> bit of inline assembler in it). It works exactly the same as the 
> original FBII project. But...well it needs to go on a serious size 
> diet.
>     FBII App                  FB3 App
> Size : 203,652            Size : 330,552

Its not your code itself, but the runtimes.  The runtimes are a lot bigger
than 45k now.  You can manually edit the FB II Rntm file and remove a
couple of INCLUDE statements to cut out stuff you don't use.  As has been
said, keep a clean copy! (Best case here is to copy it into your project
folder, FB will use the one in there before checking the headers folder)

> The FB3 compiled app runs....slower. But only during the display 
> portion of the program. Ie. drawing a bunch of data text lines to a 
> window. FBII is significantly faster. Perhaps the inline asm code 
> slows it down slightly (anyone got a native PPC TRUNCSTRING laying 
> around?).

I could sweaar TruncString is a toolbox call??  If possible, ditch your
register statements from the assembler.  Its a lot slower than it used to
be. (in fact, register is on its way out sooner or later)


register(a1) = ptr&   to  `   move.l   ptr&,a1

That's right, no more ^ needed by variable names, although it won't hurt

> So how do I cut 126,900K from the finished FB3 application?

I noticed about 30k or so of small resources like a SICN and a TEXT
resource you can toss. YMMV

> FB3 took it on itself to change the "suggested memory size" to a 
> number I didn't put in my size resource. Matter of fact I don't know 
> where it found the number but its almost twice the suggested size 
> FBII used. So why put a size in a resource if the compiler is going 
> to make its own suggestions? Odd bird this one.

No idea.

> I know there's a lot of beta users here, so how do you get the 
> references to your functions like the old project manager did? i.e. 
> click on a function name and the next reference to it pops up in the 
> editor window.

They are slated for another release than release 0.  Its too early yet.
Believe me its not gone for good.
> Do you actually "need" all that extra function stuff in the FBIIrntm 
> header file?

Andy had a list of the barest functions but FB would be pretty helpless
without the runtime statements.  You can try remarking out INCLUDE "Subs
DEF.incl" and "Subs USR.incl" if you don't use any DEF or USR functions.

> Or do you just need the library references?

Trust me, you really need those.

> Whats the difference between the lite, regular or fat free run time?

The lite runtime is missing all the GUI statements such as BUTTON, EDIT
FIELD and WINDOW.  It is the equivalent of the SIOUX shell in CodeWarrior.
The FB II Rntm (regular?) is a made from scratch runtime that is meant to
be compatible with FB2's.  The other ones are not complete yet......you
could with a bit of effort make a brand new one altogether.  I would leave
that to Staz and Andy though.

> Is there a list of what ToolBox commands the compiler supports (help 
> only has a few)?

The file Toolbox Standard.incl in the headers folder contains the majority
of what's defined.  I think don't a cross referenced list exists though.

> How come in a compiled PPC app only, the main part of the code 
> doesn't end up in the datafork as other compiled languages do? And 
> does anyone see this as a problem?

Andy's 'loader' mechanism is what is in the datafork.  The program itself
get stuffed into the FCOD resource.  I don't see how this would be a
problem unless the code compiled to a large size such as 16 megs, which
would mess up the resource manager...but the ppc instruction set can't
handle a program any bigger anyhow.

> If the compiler is going to write in its own resources, can we get a 
> list of them so we don't try and create the same ones?

Check the folder called 'runtimes'.  The shell applications contain all
the resources that are installed by default when your program is built.

> How come window names can't be longer than about 6 or 7 characters? 
> Mine all get chopped off. And it changed something in my OS since ALL 
> my windows won't go beyond 6 or 7 characters now. I hope restarting 
> will fix it.

New one to me?
> Disclaimer, I am not bashing FB3. Rather to the contrary, I think its 
> going to be great in future releases. But it's got one mean learning 
> curve for us FBII vets and the sooner I get a handle on it and manage 
> to learn to stay out of its way, the better. Which means I get to ask 
> a lot of dumb questions about how it works so I can best use it for 
> my own programming style.

Like Jim said, FBII knowledge is what will mess you up....you just keep
wanting to do things because that's how FB2 always wanted it and it takes
a while for it to set in that *it just doesn't work that way anymore*.

Once you do a conversion or two successfully, it will become second