Announcement

Collapse
No announcement yet.

Size of EXE compiled with PB/DLL

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Lance Edmonds
    replied
    So you did. However that thread title stated PB/DLL 5.0, and at that time, the 6.0 update had out for a while.

    Anyway, I've passed a note to R&D, so hopefully it will get fixed for the next update.

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

    Leave a comment:


  • Dominic Mitchell
    replied
    i first reported the 64k error on july 05, 2000. http://www.powerbasic.com/support/pb...ead.php?t=2429

    ------------------
    dominic mitchell

    Leave a comment:


  • Russ Srole
    replied
    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.


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

    Leave a comment:


  • Lance Edmonds
    replied
    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>

    Leave a comment:


  • Dominic Mitchell
    replied
    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

    Leave a comment:


  • Russ Srole
    replied
    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

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

    Leave a comment:


  • Chris Boss
    replied
    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.



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

    Leave a comment:


  • Lance Edmonds
    replied
    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>

    Leave a comment:


  • Guest's Avatar
    Guest replied
    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).

    Leave a comment:


  • Lance Edmonds
    replied
    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>

    Leave a comment:


  • Chris Boss
    replied
    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).]

    Leave a comment:


  • Bernard Chapman
    replied
    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

    Leave a comment:


  • Kev Peel
    replied
    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

    Leave a comment:


  • Steven Pringels 3
    replied
    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...


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

    Leave a comment:


  • Michael Mattias
    replied
    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


    Leave a comment:


  • Tom Hanlin
    replied
    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

    Leave a comment:


  • Florent Heyworth
    replied
    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

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

    Leave a comment:


  • Steve Hutchesson
    replied
    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]

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

    Leave a comment:


  • Lance Edmonds
    replied
    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>

    Leave a comment:


  • Guest's Avatar
    Guest replied
    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).]

    Leave a comment:

Working...
X