Announcement

**Guest** · 8 Jul 2001, 06:20 PM

break the module up into 2 files and include the 2nd at the end of the first file.

**Mike Jenkins** · 8 Jul 2001, 11:39 PM

<<break the module up into 2 files and include the 2nd at the
end of the first file.>>

Thanks, Ron, but I had already broken the code into 10 modules,
and all the new code I'd added today that caused the compiler to
hang was in one of the small modules.

In fact, after deleting section after section of the newly-added
code I'd written today, I finally got the compiler to compile OK
again, but then adding back even a couple of lines ANYwhere in
the program caused the "Destination file write error" message
again.

Looks like some kind of absolute limit on the amount of code
that can be compiled, and I've reached it.

Only solution looks to be to move a lot of the code to a second
program, although it would be awkward in the extreme to share
about 300k of text and string data between the two, with almost
constant updating of the data. It's a simulation, and every
part of it draws on, and modifies the database of info for
1600 stocks, so breaking it in two isn't very feasible.

Time to retire, I think, and say 'adios' to the software biz,
or wait for the next update of PB, to see if it can handle larger
amounts of code.

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

**Semen Matusovski** · 8 Jul 2001, 11:51 PM

Mike --
Do you have many DATA statements ?

------------------
E-MAIL: [email protected]

**Guest** · 9 Jul 2001, 04:54 AM

Mike, what is your os? I encountered this before under NT. One line of code added would kill the compiler. Have you tried moving the function you are adding code to into a smaller module?
Do you have tons of comments? Try using #if 0 ...#endif around comments.

I was going crazy for a while with a module of about 8500 lines.

Ron

**Lance Edmonds** · 9 Jul 2001, 05:05 AM

Hmmm... usually you can compile slightly larger programs under NT because it can allocate the whole 16Mb 16-bit process space to the compiler, whereas under Win9x/ME the compiler has to share this other 16-bit processes and sub-systems.

Semen makes a valid point here... there is a confirmed issue/limitation with the volume of DATA statements - currently it is limited to around 28-30kb and exceeding this can cause an Error 496.

Also, how about string literals? If you #IF 0 / #END IF the latest section of code added, what are the compile-time statistics for your code?

The best advice for extremely large programs is to break them up into an EXE and one or more DLL's. If you need to manipulate large volumes of data, pass pointers to the DLL code and the DLL can manipulate the data directly through pointers.

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

**Michael Mattias** · 9 Jul 2001, 06:52 AM

There is definitely some kind of untested (i.e., not edited) limit on source code size in PB/DLL.

I just went through this last week with the support department.

Strangly enough, I deleted a bunch a code between #IF 0 ... #ENDIF and the problem went away!

Of course, now I am scared silly of adding any more source code to that module.

Maybe some day PB will release a 32-bit compiler. Better, a compiler which tests for insufficient memory. The twelve-and-one-half microsecond compile time saving looks pretty puny next to the two hours I spent bleeping around putting files together to send to PB Support just to figure out what the problem was. Just think if I had gotten one of those little error messages, "Insufficient Memory to Compile. Break your program into pieces." I would have had that done in twenty minutes, AND I would not have a reason to complain about the PB product.

MCM
(Yes, this was PBDLL.EXE which GPF'd, not the editor!)

**mark smit** · 9 Jul 2001, 08:13 AM

I dont know if this helps any but here is the log from my project.

Code:

PowerBasic DLL/32 Compiler
PB/DLL  Version 6.0 
Copyright (c) 1996-99 by PowerBasic Inc.
Carmel, California, USA
All Rights Reserved 

Primary source:  STRATA.BAS   {32177 total lines}
Compile time:  1.7 seconds, at 1135658 lines/minute
 
121616 bytes compiled code, 24808 bytes RTLibrary,
2460 bytes string literals, and 11524 bytes dgroup.
Executable stack size:  1048576 bytes.
Disk image: 500224 bytes   Memory image: 38792 bytes.

I have about 71 files in my project and it compiles fine. I have run into some strange compiler problems after my project became quite large. For example.

Code:

strValue = format$(val(strValue)+0.25)

This needed to be changed to the following before I could compile again.

Code:

lValue = val(strValue)
lValue = (lValue + 0.25)
strValue = format$(lValue)

There were many other instances that required the line to be broken up like the above example. I never did get a "Statement to complex" error but I found all sorts of strange values returned and compile time GPF's. It seems as thought the compiler gets a bit confused with larger projects, I dunno...

------------------
Cheers!

[This message has been edited by mark smit (edited July 09, 2001).]

**Mike Jenkins** · 9 Jul 2001, 02:18 PM

[QUOTE]Originally posted by Semen Matusovski:
[B]Mike --
Do you have many DATA statements ?

No, Semen. I have one SUB that has DATA statements, a list of
50 country names, and another with about 10 lines of text, but
that's all.

My program does have hundreds of places where it has a sentence
or two of text, though, either in the form of MSGBOX or INPUTBOX
questions/warnings/statements, or else where I'm inserting "news"
strings into a constantly updated 60-element string array, each
limited to 70 characters in length. All the major blocs of text
utilized by the program are read, as needed, from a data file,
but I'm wondering if all the short strings scattered through
the program, and lots of documentation (comments) I've peppered
throughout the code could be running up against something like an
over-all limit of 64k of string memory? (Other than string
arrays, of which I have a couple of 1600-element arrays --
company names and stock symbols for 1600 companies.)

All of which is only a modest increase over what I had in the
older PowerBasic DOS version of my simulation. I didn't expect
such limitations would prevent me from writing a Windows program
that's only about 750k in size (.EXE), at the point where I
ceased to be able to compile it.

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

**Mike Jenkins** · 9 Jul 2001, 02:26 PM

<<Mike, what is your os? I encountered this before under NT.
One line of code added would kill the compiler. Have you tried
moving the function you are adding code to into a smaller module?
Do you have tons of comments? Try using #if 0 ...#endif around
comments.

I was going crazy for a while with a module of about 8500 lines.

Ron >>

Thanks, Ron, I'm using Win 98 (and get the same problem trying to
compile on my Win 95 laptop). But thanks for the suggestion
about the comments -- my code is pretty heavily commented, as I
didn't realize the compiler did anything but skip over the
comments. I'll try the #If ... #endif approach for longer
comments, although there's no way I can slim the program down
enough to finish adding in all the necessary features.

Oddly, I tried removing about 60k of source code, which I'll
try to make into a separate EXE, and found that only reduced the
size of my main .EXE by about 24k, not a big reduction, and hard
to understand.

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

**Lance Edmonds** · 9 Jul 2001, 02:28 PM

Looking at the compile-time stats, the app itself is quite small, but the disk image is huge! Are you linking in some very large resources?

Can you submit the files (at the point where the compile errors occur) and I'll take a look for you? Thanks!

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

**Eric Pearson** · 9 Jul 2001, 02:31 PM

Mike --

Are you using the IDE? If so, it protects you from using source code lines that are longer than 255 characters. But if you are using UltraEdit or something else, you have to watch that limit yourself. No lines -- even comments or lines in $IF 0 blocks -- can be longer than 255 characters, or you can get unexpected and hard-to-find errors.

Just a thought...

-- Eric

------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[This message has been edited by Eric Pearson (edited July 09, 2001).]

**Mike Jenkins** · 9 Jul 2001, 02:32 PM

<<The best advice for extremely large programs is to break them
up into an EXE and one or more DLL's. If you need to manipulate
large volumes of data, pass pointers to the DLL code and the
DLL can manipulate the data directly through pointers.>>

Thanks, Lance, I thought that DLL's might be the only solution.
Unfortunately, I'm more of a logician than a techie, and don't
really have a clue about manipulating data thru pointers, and
other such elegant programming methods. So it's back to the
drawing board, perhaps breaking the one large program up into
a half-dozen .EXEs, to be on the safe side, as I'm still getting
odd errors, even after removing 60k of source code, wherever I
put in MSGBOXes. Example from one SUB:

A$="Blah, blah, blah...."
X=1030
TESTCODE$="100"
Msgbox A$
TESTCODE$="101"

After the MSGBOX appears, and I click on OK, I get a run-time
error in my errortrap routine, of Error #9, Testcode$="100", so
that it appears the next line of code (Testcode$="101") is where
the out-of-bounds error occurred, before it executed, which makes
no sense, since there are no array variables accessed in the SUB
in question. Apparently some sort of memory limitation again,
although this is from a small SUB, of 50 lines or so, so it's
probably some kind of overall program limit I've exceeded, rather
than in that specific SUB. (If I remove the MSGBOX, the routine
proceeds w/o error, I find. Hmmmm.....)

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

[This message has been edited by Mike Jenkins (edited July 09, 2001).]

**Eric Pearson** · 9 Jul 2001, 02:35 PM

> don't really have a clue about manipulating data thru pointers

That's not always necessary. In fact in my experience it is rarely necessary.

Do you have any subs or functions that do not use any GLOBAL variables and that do not call other functions? Or can you create a "group" of subs/functions that is self-contained from a GLOBAL and cross-calling standpoint? If so, that code can be moved 100% painlessly to a DLL.

Things like self-contained parsing functions, utility functions... lots of things can be moved to a DLL without using any advanced techniques at all.

-- Eric

------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[This message has been edited by Eric Pearson (edited July 09, 2001).]

**Mike Jenkins** · 9 Jul 2001, 02:58 PM

<<Originally posted by Eric Pearson:
Mike --

Are you using the IDE? If so, it protects you from using source
code lines that are longer than 255 characters. But if you are
using UltraEdit or something else, you have to watch that limit
yourself. No lines -- even comments or lines in $IF 0 blocks --
can be longer than 255 characters, or you can get unexpected and
hard-to-find errors.

Just a thought...

-- Eric
>>

Eric --

Yup, I've written everything but my data files with the IDE.
Thanks, anyway. I know what you mean. I have run into that
problem where I tried piecing together a string of over 256
characters, to display in a MSGBOX, which created some
unpredictable results. (Learned that lesson the hard way, too.)

-- Mike

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

**Michael Mattias** · 9 Jul 2001, 04:11 PM

If you find yourself in a situation where you cannot conveniently eliminate GLOBAL variables when moving functions to a DLL, you can always write a function in the DLL which does noting but SET or GET global variables from the other module.

That is

Code:

#COMPILE DLL


...

GLOBAL a, b, c, d, e     ' will be GLOBAL in the DLL

FUNCTION SetGlobal (VarNumber, Value) AS LONG

   IF VarNumber = %Set_A THEN
         a = Value
   ELSEIF VarNumber = %Set_B THEN
         b = Value
    etc etc
END FUNCTION

 =======

#COMPILE EXE

....

DECLARE FUNCTION SetGlobal LIB "MYDLL.DLL" ALIAS "SETGLOBAL" (Varnum, Value)
....

'(change global variable A, and need to notify the DLL)
  CALL SetGlobal (%Set_A, newAValue)

Nope, I do not recommend this if you are starting from a clean sheet of paper, but it could get you past the current situation.

MCM

**Bern Ertl** · 9 Jul 2001, 07:24 PM

i have been reading this thread with some interest as i have already
experienced most of these problems myself.

mike jenkins wrote:

no longer able to compile it. i keep getting a "destination
file write error, line 10111" error message.
i've seen that error message before when a copy of my program
was still in memory, but that isn't the case this time.

both times this has happened to me, i've split off a ton of code into
a dll and everything worked again. check out the following for more
help on passing globals between the exe & dll:

http://www.powerbasic.com/support/pb...ead.php?t=3825

mike jenkins wrote:

oddly, i tried removing about 60k of source code, which i'll
try to make into a separate exe, and found that only reduced the
size of my main .exe by about 24k, not a big reduction, and hard
to understand.

not really. there is not a one to one correspondence between source
code and executable (compiled) code. consider that :

Code:

areallyreallyreallyreallylongvariablename& = anotherlongvariablename&

occupies roughly 70 bytes of source code. this should compile into
just a few bytes of executable code while:

Code:

a& = ceil((b&^3+95)/23)*450

occupies roughly 30 bytes of source code and should compile into many
more bytes than the previous variable assignment.

mike jenkins wrote:

a half-dozen .exes, to be on the safe side, as i'm still getting
odd errors, even after removing 60k of source code, wherever i
put in msgboxes. example from one sub:

a$="blah, blah, blah...."
x=1030
testcode$="100"
msgbox a$
testcode$="101"

after the msgbox appears, and i click on ok, i get a run-time
error in my errortrap routine, of error #9, testcode$="100", so

i started a thread a while back when i found a similar problem in my code:

http://www.powerbasic.com/support/pb...ead.php?t=3850

i would strongly suggest checking your code for out of bounds array
assignments. sometimes your app will continue running for a while
before the error becomes noticable/problematic.

------------------
bernard ertl

**jeroen brouwers** · 10 Jul 2001, 07:22 AM

I can confirm the same problems to some extend.

Mike, I don't know your code but another limitation is "there can be only so many 'if elseif' constructions in a sub or function". Breaking them up into several subs / functions does work OK.
I can also agree with the idea of having seperate Dlls for common functions. You can just declare the dlls or load them when needed and pass the info needed back and forth from your main app (dll or exe) to these dlls. From a point of maintenance, this is also very advisable.

Good luck with it.

Greetings
Jeroen

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

[This message has been edited by jeroen brouwers (edited July 10, 2001).]

**Brent Boshart** · 10 Jul 2001, 07:38 AM

I have a program with over 41,000 lines of codes with modules over 10,000 lines and it compiles fine to a single exe about 582k in size.

Brent Boshart

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

**Iain Johnstone** · 10 Jul 2001, 11:56 AM

I hit the same problem last year with a limit at 820K EXE. Since
then, all the new code goes into DLLs. These are not so bad once
you get used to them - I use a skeleton program to avoid rewriting
the initial code. DLLs are the only way out of this problem ( I think!!)
Iain Johnstone

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

Announcement

Limit on size of PBDLL programs?

Limit on size of PBDLL programs?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment