Announcement

**Matthew Berg** · 11 Mar 2000, 01:06 AM

perhaps these threads will be useful: largest program that can be compiled?, large application.

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

**Lance Edmonds** · 11 Mar 2000, 03:38 AM

In general, the size of the EXE is "relative"... the compilation limit is determined by what is IN your code, rather than an explicit limit to source code size.

I've heard of some EXE's approaching 2Mb without resources, but I've not seen the source code to these apps.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**George Bleck** · 11 Mar 2000, 08:48 AM

I know PB does not like to comment on up-comming products, but could we forsee an eventual 32bit compiler in the future as opposed to the current 16bit ones?

**Michael Mattias** · 11 Mar 2000, 10:46 AM

Is it possible that PB is working on a method to load DLL's explicit instead of implicit?
I know the CALL DWORD function but it's easier with ordinary declares.

See the Windows API under LoadLibrary and LoadLibraryEx. Those are "explicit" loads.

But...if you DECLARE a procedure with a LIB statement, Windows (or maybe it's PB) will load the DLL for you automatically and there is no need for CALL DWORD etc...

------------------
Michael Mattias
Racine WI USA
[email protected]

**Siamack Yousofi** · 11 Mar 2000, 09:26 PM

For the benefit of those who are only visiting PB forums and considering joining PB community...

Both PB/CC and PB/DLL generate full 32 bit Windows executables. The compiler itself is a 16 bit application but this does not affect the size and performance of the generated code.

PB beats anything under the sun except the assembler.

Greg

IMHO If they are not already too far down the 32-bit road, then its best to start working on a 64 bit version!

Siamack

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

[This message has been edited by Siamack Yousofi (edited March 11, 2000).]

**Tim Wisseman** · 19 Mar 2000, 05:48 PM

I have written a large program.
The program uses no resources at all. The compiler begin running out of memory while trying to compile the thing when it hit 40,000 lines of source code.

At that point the program was broken up into one 602K main EXE file (32,000 lines of source) and two support DLL's of 221k and 164k.

To pass data to the support DLL's the main program passes a pointer to a UDT that itself is made up of pointers to any global data that needs to be accessed.

A far bigger program than this could be written. Other than the problem with arrays in UDT's. I have had no problems at all building large programs with PB DLL.

Tim

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

**Lance Edmonds** · 19 Mar 2000, 08:46 PM

I'll reiterate this again: the source code size "limit" depends on a couple of factors:

1. How much 16-bit memory is available to PB/CC at compile time - under Windows 95/98 (which are hybrid 16/32-bit O/S's) you'll hit the "limit" earlier than if you use Windows NT.

2. The compiler uses quite a bit of memory during the two-pass compilation process - this consumption depends on *what* is in your code and how you have constructed the app.

As a result, we cannot provide an exact specification of the limit.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**E B Knoppert** · 20 Mar 2000, 12:40 AM

Tim, did you use the 16bit version or 32?

There are differences ($SEGMENT missery for example)

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

**Lance Edmonds** · 20 Mar 2000, 01:25 AM

It was the 32-bit version - to be clear, Tim identified a problem when using a *large global* UDT array containing an array as a UDT member. The matter was verified to be a problem, and is in the hands of R&D (to be corrected).

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Semen Matusovski** · 20 Mar 2000, 01:54 AM

Lance, Tim --
I remember this story.
What means *large global* UDT array, containing an array as a UDT member ?
"large" - quantity of elements, total length ? And how much (approx.) ?
(my wife always says - buy the bread, milk, eggs - but never, how much)
PS. Troubles with global UDT only or with local too ?

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

**Tim Wisseman** · 20 Mar 2000, 04:29 PM

Yes, it was the 32 bit version of PB DLL 6.0

I have had this UDT cause a GPF.

Type bufftype
vA(1 To 2) As Long
End Type

I will never use an array in a UDT, until the PB guys
get the problem fixed. PB DLL 5.0 also has the very same defect.
So the problem has been around for over 2 years.

I was having unexplainable random GPF errors for pop up in the
large program that I was working with. No matter what I did I could not get rid of the errors.

Back at the beginning of the year when I removed all the arrays from my UDT's the problems just vanished, not a single
GPF error since.

It turned out my program did not have any out of bound arrays or bad pointers as was suggested over and over again. . .

Tim

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

**Lance Edmonds** · 20 Mar 2000, 04:40 PM

Come-on Tim, at least report the problem accurately please.

The UDT itself may have been small, but the array of these structures was large and GLOBAL. LOCAL UDT arrays did not have any problems.

Semen, I cannot give you any exact UDT array size that triggered the GPF because it appeared to depend on the UDT structure - the problem was dynamic.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Tim Wisseman** · 20 Mar 2000, 04:49 PM

Yes, the problem was only with Global UDT's. The sample code that I sent in to PB tech support shows a failure in a UDT of size 320 bytes. I would not exactly call that large

Tim
[email protected]

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

**Tim Wisseman** · 20 Mar 2000, 05:21 PM

Lance,

I have an instance of my huge program that uses 1 global instance of the type:

Type bufftype
vA(1 To 2) As Long
End Type

It GPFs, if I replace the type with this:

Type bufftype
sA As String * 8
End Type

It does not GPF. All that I have to do is change that one line.
This is real world code that you have never seen.

In the sample that I sent in this fails:

Type testtype
vA1(1 To 2) As Long
vA2(1 To 2) As Long
vA3(1 To 2) As Long
vA4(1 To 2) As Long
vA5(1 To 2) As Long
vA6(1 To 2) As Long
vA7(1 To 2) As Long
vA8(1 To 2) As Long
vA9(1 To 2) As Long
vA10(1 To 2) As Long
vA11(1 To 2) As Long
vA12(1 To 2) As Long
vA13(1 To 2) As Long
vA14(1 To 2) As Long
vA15(1 To 2) As Long
vA16(1 To 2) As Long
vA17(1 To 2) As Long
vA18(1 To 2) As Long
vA19(1 To 2) As Long
vA20(1 To 2) As Long
vA21(1 To 2) As Long
vA22(1 To 2) As Long
vA23(1 To 2) As Long
vA24(1 To 2) As Long
vA25(1 To 2) As Long
vA26(1 To 2) As Long
vA27(1 To 2) As Long
vA28(1 To 2) As Long
vA29(1 To 2) As Long
vA30(1 To 2) As Long
vA31(1 To 2) As Long
vA32(1 To 2) As Long
vA33(1 To 2) As Long
vA34(1 To 2) As Long
vA35(1 To 2) As Long
vA36(1 To 2) As Long
vA37(1 To 2) As Long
vA38(1 To 2) As Long
vA39(1 To 2) As Long
vA40(1 To 2) As Long
End Type

Global tt1 As TestType
Global tt2 As TestType
Global tt3 As TestType
Global tt4 As TestType
Global tt5 As TestType
Global tt6 As TestType
Global tt7 As TestType
Global tt8 As TestType
Global tt9 As TestType
Global tt10 As TestType

The sample code casts a large sure-fire "net" and triggers the problem every time with brute force. The compiler is forced to make the mistake on demand.

The real world source code that was failing was just an unlucky array in a UDT that just happen to compiled at just the wrong time. If there just happen to be an extra line or slight
different line before the line that uses the UDT with the array the GPF might never have been compiled into the program.

I would get a GPF, tweek the program a little and the problem will go away. Add a little more code and the problem would come back.

Has anyone written a program that is at least 700K in size that uses global UDT's with arrays that does not have spooky GPF problems? If you have please speak up.

Tim Wisseman
[email protected]
http://www.vgaplanets.com/v4beta.htm

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

**Tim Wisseman** · 20 Mar 2000, 06:02 PM

I think that the problem has nothing to do with the size of the UDT, sure, the more you have, the more likely your are to be hit with the problem, but the size of the UDT may not be the problem.

The problem has EVERYTHING to do with what state the compiler is in when it compiles a line that uses an array in a UDT. If something happens to be just so, the compiler compiles a value into the program that causes a GPF.

Very small programs might not stress the compiler enough to have it even reach that magic state of failure.

A large program might be stressing the compiler enough that it flips into that state every so offen, but 99.99 times out of 100 it is NOT compiling a line of code that uses an array in a UDT.

For example: the error might only strike when the SI register equals FFFE, but the compiler works perfectly if the SI is some other value.

Tim Wisseman

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

**Chris Boss** · 20 Mar 2000, 06:41 PM

First let me say that I am "confident" PowerBasic will fix the problem with arrays in UDTs in the next release and also that there are relatively easy "work arounds" to the problem, so none of us who us PB should be overly concerned about the reliablity of the compiler. The PB compiler is an "extremely" solid compiler and I consider it "more reliable than any Microsoft product" (I have VB 5 and once I installed the Service pack 3 it now GPFs when I compile to native code).

Now as far as the array in UDT problem is concerned, based on my testing, the problem is not based on the size of the UDT but is based on the size of the entire program. Small PB programs seem to be not affected by the problem. As the programs get larger , then the problem begins to appear. Adding new code will move the GPF to different places.

Also it should be emphasized that the problem does not affect Local UDTs, but only Global and Static.

Now as I mentioned, we should not be overly concerned about this (it is in good hands with R&D), since PB is such a powerful language and there are easy work arounds.

Here is some simple code that demonstrates how to "emulate" an array of fixed length strings within a UDT:

Code:

TYPE UDT1
    Items AS STRING*3200    ' instead of Items(1 to 100) as string*32
END TYPE

GLOBAL MyVar AS UDT1

SUB SetArrayItem(BYVAL N&, BYVAL D$)
LOCAL P&, L&, Last&
L&=32       ' length of each item within fixed length string
Last&=100   ' Last Item within fixed length string
D$=LEFT$(D$+STRING$(L&," "), L&)
IF N&>=1 AND N&<=Last& THEN
   P&=(N&-1)*L&
   POKE$ VARPTR(MyVar.Items)+P&, D$
END IF
END SUB

FUNCTION GetArrayItem(BYVAL N&) AS STRING
LOCAL D$, L&, P&, Last&
L&=32
Last&=100
D$=""
IF N&>=1 AND N&<=Last& THEN
   P&=(N&-1)*L&
   D$=PEEK$(VARPTR(MyVar.Items)+P&,L&)
END IF
FUNCTION=D$
END FUNCTION

Likely there are otherways to accomplish this, like using pointers. Just think of it ! VB doesn't support Poke$, Peek$ or Pointers like PB, so there would never have been a work around if this was VB.

The important thing about a compiler is the richness of the language. No compiler can be absolutely bug free. Sure, we would like bugs to be as rare as possible (and with PB this is so), but in the rare instance when a bug does exist, is the language rich enough for us to create a simple work around ? With PB it is !

Speaking of bugs in other compilers, I know of a "super" C++ programmer who has found serious bugs in the MFC code in the Microsoft C compiler. He had to write his own memory management code to compensate for the bugs in the MS code.

When it comes to reliability in a compiler, nothing can hold a candle to PB !

And if one does occur, at least PB will fix it (unlike some bigger software companies who seem to add more bugs for every bug they fix).

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

**Colin Schmidt** · 20 Mar 2000, 10:48 PM

Hello,

I can vouch that *most* people have nothing to worry about when it comes to large programs. I have played with some of my own very large arrays of UDTs with very large arrays in them and have had no problem. Before I posted this I did some more checks and wrote a large program using a lot of cutting, pasting, “search and replacing”, that did the following:

I took Tim Wisseman’s UDT as is, added some code to iterate the values and it ran just fine with no GPF. I then continued to expand it gradually trying to pull a GPF until I finally had the following program:

A type testtype contained 40 arrays of LONG as did Tim’s, and I bumped the number of elements all the way up to 400 in each. I then created 10 arrays of this type, each with 100 elements each. At this point I am using just under 64MB of RAM.

I then did many direct assignment of = 1 for each of these 1.6 million elements. I then also did many DECR, an INCR and an “element = another element * 3.3 * count” on about one-third of the elements. I also stepped though in different ways using different values for STEP each time. In the end program, I had 13,649 lines of code in a single source file that produced a single 700KB EXE.

The compiler ran out of memory if I added another block of 415 lines to it and I found PBEdit to max out at 16,000 lines. (Note incase you missed what others have said before, if you are working with a larger program, divide your code across multiple DLLs that may be compiled individually.)

The program at this point was assigning or retrieving over 2 billion values. While the test app was running I had Win98SE also run IE5, Explorer, Word97, Access97, WordPerfect9, and PBEdit. It took just under 9 minutes to execute the 2billion+ statements. I’m also glad to say that it took all of 1.2 seconds to compile.

During the entire process I was not able to make PB produce a single GPF. I am not saying that people are not getting GPFs in large programs. I’m just letting people know that what Tim Wisseman said is true: PB is not going to blow up on them every time they use global UDTs in a large program.

Also, just as a side note, since I have seen some concern about large strings in the older compilers, I have also played extensively with very large strings (300MB+) and have had no problems other than having Win98 itself run out of resources. (If PB had any memory management problems, I’d be there most dreaded customer I’m glad to say they don’t)

Then finally, if anyone has any ideas as to what type of statements or circumstances might cause the GPFs, let me know. I now already have a large chunk of code to play with. Or, if you’d like the code to play with yourself, email me and I’ll mail it back to you. Do keep in mind though what others have said: there is a very good chance that it takes a lot of little different things that we can’t trace to cause the GPF, so the chances of someone other than PB R&D finding it are probably slim.

Colin Schmidt
[email protected]

------------------
Colin Schmidt & James Duffy, Praxis Enterprises, Canada

**Chris Boss** · 21 Mar 2000, 03:39 AM

I thoroughly tested Tims code and even wrote some of my own and I was able to verify Tims concerns.

The problem with this one, is likely that "certain" circumstances must be met for the error to show up. Its one of those 99% of the time it won't show up type of problem.

I am sure that the PB R&D have it under control and if a problem does exist, they can find it.

My feeling is, if you aren't experiencing any GPFs then "don't worry about it". If you do experience a bunch of seemly unexplainable GPFs, that seem to "move when you add more code", then first exhaust every effort to find a bug in "your code first". If all else fails, then remove the arrays within UDTs and write some emulation code, like I did above, and see if the problem disappears. If the problem does not disappear after that, then you have a bug in your own code.

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

**Lance Edmonds** · 21 Mar 2000, 03:55 AM

Sigh... it's like deja-vu all over again.

Folks, we've covered this some months ago already... PowerBASIC R&D have several examples that clearly demonstrate the specific problem of using an array inside a GLOBAL UDT, and the problem will be fixed.

Please: be patient for the next update. If you don't use arrays inside your GLOBAL UDT structures then you have nothing to worry about.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

Announcement

What's the biggest 32bits PB-app yet?

What's the biggest 32bits PB-app yet?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment