en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en nl en en en en en en en en en en en en en en en en en en en de fr en en en en nl en en en en en en en en en en fr en en fr pt en en en en en en en nl en en en en en en en en en en en en en en de en en en fr en en en en en en en en en pt en en en en en en
By logging into your account, you agree to our Privacy Policy, personal data processing and storage practices as described therein.
Forgot password or user name?
Search in titles only Search in PowerBASIC for Windows only
You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
PB apps when Windows is out of Resources!
All Time Today Last Week Last Month
All Discussions only Photos only Videos only Links only Polls only Events only
PB apps when Windows is out of Resources!
4 Mar 2000, 01:27 AM
Hello, I had never actually had windows run out of resources before... I’m glad to say though that I was able to save and close everything cleanly, and safely reboot with out a hitch. I guess Win98SE isn’t that bad for stability after all
Any ways, what I did, without realizing it is create a 280MB dynamic array using a user-defined type. I just never occurred to my DOS programming brain that my PB app could ever use up 128MB of ram and 160MB of the swap file. Normally I’d have gotten an out of memory message ages ago.
One of the reasons I am posting this is that what I saw is not what I expected. What I saw was a GPF. I then spent some time stripping my code down trying to find what was causing it. In the end I was able to cause a PGF with just this code:
DIM a(150000, 34, 12) as LONG MSGBOX “DIM OK” a(0, 0, 0) = 1
What I found interesting is that the GPF happened after the MSGBOX. It then finally ran though my thick skull to add up how big this array really was… Well actually it was just for curiosity.
So, what PB does when you run out of memory is nothing. The DIM statement (or REDIM) returns normally with no form of message. Then the first time you try to access the dimensioned variable, you get a GPF.
Help File: “A PowerBASIC array may contain up to 4,294,967,295 elements, and the data may occupy as much as all available memory.”
I realize that PB does not expect us to be filling up all the memory, but a notice in the help file mentioning how PB handles running out of memory would be nice anyway
So, if you are playing with any real amount of data at all, you will probably want to perform a check after each and every DIM or REDIM to confirm that the dimension has been successful. To check this simply look at the return value from VARPTR(array(any element)) If the address returned is 0, then you have to know something is up!
And now my second justification for posting this is the following: Our little tiny PB EXEs are attractive to people with older computers. Let’s say someone with a 486 and 8MB of RAM is running your app on Win95a, do they want to see a GPF from you or a nice message saying “Time to upgrade!”
As for me, I guess I’ll be adding disk-caching-of-large-indexes to my database. To bad, it was moving quick in RAM
And that would be my 20 cents,
Colin Schmidt & James Duffy, Praxis Enterprises, Canada
Join Date: Aug 1998
4 Mar 2000, 03:25 AM
So, if you are playing with any real amount of data at all, you will probably want to perform a check after each and every DIM or REDIM to confirm that the dimension has been successful. To check this simply look at the return value from VARPTR(array(any element)) If the address returned is 0, then you have to know something is up!
In Windows, error testing is predominately the responsibility of the programmer - this is quite different from PB/DOS.
Therefore, if your DIM or REDIM failed, then the ERR, ERRCLEAR and/or the ERRAPI system variables will signal an error condition. May I suggest that you peruse the Errors and Error Trapping chapter in the documentation for PB/DLL.
As you have noted, Windows uses Virtual Memory - this means that your app can just keep expanding it's memory usage until the O/S is unable to grab another [large] chunk of your hard disk to expand the swap file.
Once you start running out of virtual memory (or resources), then Windows often exhibits unexpected and often unpredictable behavior. It is unpredictable because other applications and services that are running at the same time may also fail, and these are likely to have some effect on _your_ application - ie, network redirector software crashing, printer drivers failing, etc.
Windows 95/98/2000 allow you to limit the size of the swap file (I'm not sure about NT4), so by giving it an arbitrary "low" maximum VM limit (say 64Mb), you can easily start to check your app for behavior problems when DIM's start failing - in fact, anytime your app needs to grab a new chunk of memory you can run into problems - for example, dynamic string allocation can be affected (fixed-length and ASCIIZ occupy fixed locations so are less likely to encounter runtime out-of-memory errors.
In practice, unless your app is very likely to use 100's of MB of memory, this could be an unnecessary test - it's up to you, the programmer, to decide how bullet-proof you want your application to be.
Join Date: Nov 1999
4 Mar 2000, 11:42 AM
I realize that PB does not expect us to be filling up all the memory, but a notice in the help file mentioning how PB handles running out of memory would be nice anyway
In Windows, error testing is predominately the responsibility of the programmer - this is quite different from PB/DOS... ...May I suggest that you peruse the Errors and Error Trapping chapter in the documentation for PB/DLL.
Colin now says: Gosh I feel stupid The only section I didn't read.
Colin Schmidt & James Duffy, Praxis Enterprises, Canada
Copyright © 1998-2022 PowerBASIC Tools, LLC - All Rights Reserved.
Powered by vBulletin® Version 5.7.0
Copyright © 2022 vBulletin Solutions, Inc. All rights reserved.
All times are GMT-5. This page was generated at 09:13 PM.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.