Questions

Low memory error after last WinXP update (Clipper app)

Tags:
+
0 Votes
Locked

Low memory error after last WinXP update (Clipper app)

lund
After the last update provided for Windows XP a client started to complain that his application (developed in Clipper and growing with the company since 1988) is running out of memory and refusing to operate. This did not occur before this last Windows update. He reversed the update on some terminals and the system is working flawlessly again on these. Obviously not the ideal situation...

Can anybody cast a beam of light on what could possibly be going on in this matter? And on how this problem could be solved, or even circumvented?

Any contributions will be thankfully received.
  • +
    0 Votes
    OH Smeg

    That has to be the starting point here isolate the update in question and work from there.

    +
    0 Votes
    lund

    It was the update released last week. Somehow it seems to have reduced available memory for DOS-based applications. I won't be able to tell which one of the fixes released caused the problem, as the restoration point was established before installing the whole update package.

    +
    0 Votes
    rwsulli

    Appeared on a few machines in the last two weeks. Do not know if this has anything to do with your problem, but increasing the available memory corrected the problem. Sort of strange that out of the blue separate machines gave the same warning, when there was never a problem in the past. (XP Pro OS)

    +
    0 Votes
    lund

    The problem is not a Low Virtual memory Warning, but low standard memory that kicks the app out with a Low Memory Error. Doing some more research into the matter, I found that the loadhigh (lh) command in the AUTOEXEC.NT file for some reason seems not to work anymore. I tried to remark out the following AUTOEXEC.NT commands:

    - lh %SystemRoot%\system32\mscdexnt.exe
    - lh %SystemRoot%\system32\redir
    - lh %SystemRoot%\system32\dosx
    - SET BLASTER=A220 I5 D1 P330 T3

    These apparently have no influence on the app, which now seems to work better, with more memory at it's disposal.

    +
    0 Votes
    L1A1

    What is the actual error message, and where is it coming from? (Is it a message generated by Win XP, or the DOS box, the application itself, or the application runtime?)
    lh will fail and load low if there are no UMBs. UMBs are generally a function of the EMS driver, which is loaded by config.nt (did something change there?)
    Do you know which version of Clipper is being used, and is the app a regular DOS app, or a DOS extended app (linked with Exospace or Blinker)?

    +
    0 Votes
    lund

    The error message, in the sense of "Conventional memory exhausted", is generated by the program itself, which then quits to DOS (in the dosbox).

    The CONFIG.NT file contains the following instructions that should configure high memory (nothing has changed recently):

    - dos=high, umb
    - device=%SystemRoot%\system32\himem.sys
    - files=50

    As far as I can remember, the LH command used to work correctly and load the AUTOEXEC.NT commands (see above) in high memory. The app itself runs in conventional memory and has no runtime file. It is a regular self-contained executable compiled with Clipper 5.2e and linked normally with RtLink.

    +
    0 Votes
    L1A1

    While not performing exhausive testing, I cannot seem to get UMBs or EMS memory working in a DOS box here under XP.

    As a result, MEM /C gives me 580,000 bytes free, and all drivers are loaded low. What does MEM/C give you on systems that do and do not run the program?

    +
    0 Votes
    lund

    With the AUTOEXEC.NT instructions (see above) included, I get 574.928 bytes free. Without them 614.240 bytes. In both cases the drivers are loaded low, and considering maximum executable program size. There seems to be no chance to load any drivers high, as traditionally been the case. I believe it is something MS modified for worse...

  • +
    0 Votes
    OH Smeg

    That has to be the starting point here isolate the update in question and work from there.

    +
    0 Votes
    lund

    It was the update released last week. Somehow it seems to have reduced available memory for DOS-based applications. I won't be able to tell which one of the fixes released caused the problem, as the restoration point was established before installing the whole update package.

    +
    0 Votes
    rwsulli

    Appeared on a few machines in the last two weeks. Do not know if this has anything to do with your problem, but increasing the available memory corrected the problem. Sort of strange that out of the blue separate machines gave the same warning, when there was never a problem in the past. (XP Pro OS)

    +
    0 Votes
    lund

    The problem is not a Low Virtual memory Warning, but low standard memory that kicks the app out with a Low Memory Error. Doing some more research into the matter, I found that the loadhigh (lh) command in the AUTOEXEC.NT file for some reason seems not to work anymore. I tried to remark out the following AUTOEXEC.NT commands:

    - lh %SystemRoot%\system32\mscdexnt.exe
    - lh %SystemRoot%\system32\redir
    - lh %SystemRoot%\system32\dosx
    - SET BLASTER=A220 I5 D1 P330 T3

    These apparently have no influence on the app, which now seems to work better, with more memory at it's disposal.

    +
    0 Votes
    L1A1

    What is the actual error message, and where is it coming from? (Is it a message generated by Win XP, or the DOS box, the application itself, or the application runtime?)
    lh will fail and load low if there are no UMBs. UMBs are generally a function of the EMS driver, which is loaded by config.nt (did something change there?)
    Do you know which version of Clipper is being used, and is the app a regular DOS app, or a DOS extended app (linked with Exospace or Blinker)?

    +
    0 Votes
    lund

    The error message, in the sense of "Conventional memory exhausted", is generated by the program itself, which then quits to DOS (in the dosbox).

    The CONFIG.NT file contains the following instructions that should configure high memory (nothing has changed recently):

    - dos=high, umb
    - device=%SystemRoot%\system32\himem.sys
    - files=50

    As far as I can remember, the LH command used to work correctly and load the AUTOEXEC.NT commands (see above) in high memory. The app itself runs in conventional memory and has no runtime file. It is a regular self-contained executable compiled with Clipper 5.2e and linked normally with RtLink.

    +
    0 Votes
    L1A1

    While not performing exhausive testing, I cannot seem to get UMBs or EMS memory working in a DOS box here under XP.

    As a result, MEM /C gives me 580,000 bytes free, and all drivers are loaded low. What does MEM/C give you on systems that do and do not run the program?

    +
    0 Votes
    lund

    With the AUTOEXEC.NT instructions (see above) included, I get 574.928 bytes free. Without them 614.240 bytes. In both cases the drivers are loaded low, and considering maximum executable program size. There seems to be no chance to load any drivers high, as traditionally been the case. I believe it is something MS modified for worse...