Size of EXE compiled with PB/DLL

[Steven Pringels 3]

Tech support...

Is it true that the PB/DLL compiler can't compile files up
to a certain limit. I'm not talking about the source code
file size but the EXE filesize. For some, it seems to happen
for an EXE of 400 KB and they have to resolve the problem
by making DLLs out of subroutines or parts of their program.

Confirmation or clarification please

Steve.

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

[Tom Hanlin]

Where did you get that notion?

PB/DLL imposes no limit on the size of executables or, generally, on the size
of anything else. Source lines are expected to be under 256 characters wide,
the IDE currently has a limit of about 16k lines per file, and there is some
limit on the number of DATA items. Depending on the version of Windows, you may
not be able to use files larger than 2 Gb. There are probably other size limits
but, offhand, I can't think of any...


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

[Guest]

the 16bit compiler does appear to have some issues with available memory limiting the size of a source file it will handle.
http://www.powerbasic.com/support/pb...ead.php?t=3498
my other machine has 96mb memory. the compiler dies at about 9600 lines of source code in the main module. my newer machine has 512mb ram and the compiler hs no problems with the same module after copying/pasting yet another module - 14000 lines+.
(i don't use the ide)
ron

[this message has been edited by ron pierce (edited may 23, 2001).]

[Lance Edmonds]

The compiler itself is (currently) limited by the amount of 16-bit memory that can be allocated to the compiler... typically this is 16Mb, but could be less if there are other 16-bit processes running (esp. in Win9x). Typically WinNT/2K can run 16-bit processes in their own 16Mb address space, so it is possible to compile larger apps on these platforms.

It is also worth noting that if you use a lot of very long symbols (variable names, labels, etc), then reducing the size of the symbols can reduce the size of the symbol table during compilation, and thus allow slightly larger apps to be compiled. There is no specific app or source code size that will cause the compiler to run out of memory, since it is completely source code dependent, but I've seen quite a few apps that compile to over 1Mb (excluding any resources, which means they are pretty HUGE applications!).

It is likely that future versions of the compiler will be able to compile significantly larger applications, (and hopefully) independent of the amount of 16-bit memory that can be allocated.

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

[Steve Hutchesson]

Steve,

As a rough guess, you may have found the source file limit rather
thatn an EXE file limit. I would imagine that to build an EXE
file of 400k, the source may be reasonably large.

I have occasionally found the source limit when I have tried to
do something unusual like embed a very large binary file into an
EXE file with DB notation. This was a source in PowerBASIC that
was about 13.5 meg in size and it was too big for the compiler's
current limit.

I would be inclined to break up a file of this size anyway if its
buiulding around 400k as you can improve the loading speed some by
delegating the less speed critical code that is not needed at
startup to a DLL.

Regards,

[email protected]

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

[Florent Heyworth]

One of my applications 40,000+ lines of code compiles fine
with either PBDLL or PBCC on NT 4.0 - haven't hit that limit
yet...

Cheers

Florent

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

[Tom Hanlin]

The 16bit compiler does appear to have some issues with available memory limiting the size of a source file it will handle.

I'm afraid this is based on unsubstantiated rumors. These folks may be reaching some limit, but it's not clear what kind or where.

My other machine has 96mb memory. The compiler dies at about 9600 lines of source code in the main module. My newer machine has 512mb ram and the compiler hs no problems with the same module after copying/pasting yet another module - 14000 lines+.

This seems a clear demonstration of a Windows limit, not a PowerBASIC limit. What resource might be running low is a good question, though.


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

[Michael Mattias]

This seems a clear demonstration of a Windows limit, not a PowerBASIC limit. What resource might be running low is a good question, though.

Huh? If the compiler, which is desingerd to run on Windows systems, runs OK on a 512 system, but not on a 96Mb system, seems to me the compiler is forgetting to check ERRAPI or whatever it is you are supposed to check.

You know, you had this same problem with PB/DOS 3.2 : the virtual memory never worked right if there was insufficient disk space and went into an endless loop. Never saw this problem after I got a larger-RAM system.

MCM

[Steven Pringels 3]

Thanks everyone,

I got the 'rumor' from someone's post on Chris Boss's website.

now I jnow is just a rumor :-) My app has around 10500 lines
and compiles up to 400 KB now, so no need to worry so far...


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

[Kev Peel]

Steven,

Programmers Rule No #1..

Don't worry until there is a problem.

Regards,

------------------
Kev G Peel
KGP Software, Bridgwater, UK.
mailto:[email protected][email protected]</A> http://www.kgpsoftware.com

[Bernard Chapman]

i came up against a limit a while ago and the discussion that ensued is i think relevant to the current issue.
http://www.powerbasic.com/support/pb...ead.php?t=3007

regards,

bern



------------------
bern

www.insighttrading.com.au

[Chris Boss]

Steve;

I too was a bit surprised by the post you mentioned on the
EZGUI forum , since I never heard of a 400 KB limit.

Likely the individual who posted the message, had some problem
with compiling an app which was limited in size, but failed to
examine the cause of the problem.

I am sure coding styles vary greatly and some coding styles (ie. over use
of extremely long variable names) may push the compiler to its limits.

I know when I write code, I tend to use the shortest variable names
possible. I use simple variable names like T&, I&, X&, Y& a lot and when
I need a little more I use two letter names a lot , like RV&, AX&, AY&.

Only rarely do I use long names and usually they are Globals.

I would think that with proper coding styles, the compiler can
handle some very large apps.

I have at least two apps that are over 10,000 lines of code and they
compile without any problems. One compiles to only 181 KB (11,000 lines)
and the other compiles to 249 KB (10,000 lines).

The computer I am using to compile theses apps is a :

Cyrix 686 - 200 MHZ
4 Gig. HD
32 Meg. Ram.
WIN95

The fact that I am using only 32 Meg Ram and can compile programs with over
10,000 lines of code shows the compiler does quite well with large
apps.


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


[This message has been edited by Chris Boss (edited May 24, 2001).]

[Lance Edmonds]

As a 16-bit process, the compiler only gets allocated a maximum of 16Mb of 16-bit process memory, so on a 32MB system that memory is likely to include some portion of virtual memory. But as you say Chris, even a "lowly" 32Mb system can provide enough resources for PB/DLL and PB/CC to do their thing!

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

[Guest]

Chris, the compiler really doesn't mind how long a variable name is as long as the length doesn't violate any other restrictions such as line length. It also could care less about programming styles. It should care and does about uncompilable code.

In some situations, it can't compile and encounters some fatal error. I am aware of one condition which will always cause it grief and this should be avoided. Do not mistakenly append a numeric to a string using the & operator. The compiler will "gpf" and not give any coding error. This form of string concatenation is supported by VB so non-vb coders will likely not make this mistake.

In my earlier message I stated how I would sometimes encounter an
error on my old machine which has 96mb of ram. This was compiling an app which has 6 modules the largest (main module) being about 9600 lines. When I encountered the compiler error, deleting some commented lines (or sometimes a single line) would permit a successful build. Then adding a single line of code would sometimes cause the strange compiler error to reoccur. This was with over 30mb physical memory available on an NT machine and the only other user app running was UltraEdit (not PBEdit). I thought it was very strange and the error is repeatable on that machine. There's something going awry there. I would recommend burying the 16bit compiler and its side effects
and restrictions (i.e. 8.3 output files names).

[Lance Edmonds]

Thanks for your commentary Ron. Have you ever submitted reports to PowerBASIC on the "&" and other compile-time issues you have described here? I don't recall any reports on an "&" issue coming through?!

Finally, I have to point out (yet again!) that just because the compiler is a 16-bit application does not mean that there are any technical reasons why the compiler cannot be made to compile larger applications or use LFN's...

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

[Chris Boss]

Ron;

While, I am no compiler expert, I assume the compiler "does" get
affected by such things as the length of variable names, the number
of variables used, etc. To compile code, the compiler must track the
names of variables in some kind of table. I would think that things
like Global variable names, procedure names, functions names and
string constants would likely be stored in some kind of table during
the entire compile processed.

Correct me if I am wrong, but I think that coding styles must have
some affect on the compiler. Also the number of include files makes a
difference, since the compiler must remember all the Declared functions
even if they never get called. The win32api.inc file is huge and that
alone puts an extra load on the compiler. The PB compiler is very fast
which likely means it stores all its tables in RAM, rather than a disk
file. These tables could end being huge, especially when using the
API (win32api.inc).

I am sure the people at powerbasic would be able to explain how
our code affects the compiler. Common sense tells me that if some
programmers compile huge apps without a problem and then others
with smaller apps see the compiler choke for some unknown reason
that coding style is a "likely" factor.



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

[Russ Srole]

I'm the guy who told Steven about the problem, not to
discourage his use of PBDLL, but to help him plan ahead.
My app has around 60,000 lines of code and I had to move a lot of
code to dlls to get around the "out of main memory" problem.
Originally when I started the project I was on an NT machine with
32meg, but when the problem showed up I upgraded to 128megs.
Unfortunatly that did not solve it. The only solution was to move
as much as possible to dlls. Since I had not planned for that,
it was a bit of a pain. As Lance as said more then once there is
a limit to the compiler and we all hope the next version will be
32 bit and we can forget about this. In the mean time, if you
think you're going to be making a large program, plan to export as
much as possible.

Russ Srole

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

[Dominic Mitchell]

Common on guys, 10000 lines of code is not a lot of code. I have found that
as an application(minus resources) approaches 1mb(~2 minutes compile time)
one of three things happens
1. the compiler gpf
2. the compiler runs out of main memory
3. the compiler compiles the app but the app gpf when it runs

Also, after 64k lines of code the compiler does not report the correct number
of lines. If I remember correctly I think it starts counting from 32k after
64k.

In my current application there are about 120 code files, some run to more than
20000 lines of code. Most of the sdk dialogs in this app run from 2000 to more
than 5000 lines of code.

The only way I was able to get the application to compile was to break it up into
three code dlls and 4 resource dlls.

But hey, given the level of access to the Windows API the compiler allows I would
not trade it for any other.

So Bob, I ain't complaining just stating my observations.

------------------
Dominic Mitchell

[Lance Edmonds]

Also, after 64k lines of code the compiler does not report the correct number
of lines. If I remember correctly I think it starts counting from 32k after
64k.

I've never seen any reports of this one before... I'll ask R&D about it.

Thanks! (Although I'm surprised that no one has bothered to tell us before...!)



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

[Russ Srole]

I'm with Dominic on this. I don't consider the problem to be
a killer, just something to watch out for. And between PBDll 6
and EzGui, I'm a much happier camper then when I was messing about
with VB 6. The next update may be slow in coming, but I'm sure that
it will be better & I'm sure I'll be buying it.


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