• C

Very old program: Runtime Error R6009

I am using a very old C Program - it might be written with Microsoft C 5.0 or 6.0. (I have no Source code) On one PC I get the Error: Runtime Error R6009 - Not enough space in environment
It is NOT the conventional DOS Memory that is too small
What does that Error mean?
PLEASE DO NOT ANSWER THIS QUESTION, IF YOU DON'T KNOW WHAT IT IS. I HAD A LOT OF HINTS WHAT IT COULD BE, THAT DOES NOT HELP ME. You'll get the 400 Points only, if you really can solve the problem.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Ulrich060397Author Commented:
Edited text of question
Ulrich060397Author Commented:
Adjusted points to 400
It's to complex to say anything without more details knowledge. For example is this problem appears only on one PC? Can you send this program in purpose to experiment with it?
Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

This is a guess, so I am not putting it in as an answer.

Environment space is allocated from the system memory by the command shell you are using to start the program from. By default you get 256 bytes to put your environment variables in.
To make this space larger you must supply the /E:nnnn option on the SHELL= line in your config.sys file for command.com. You can define upto 32k for the environment. See th help for 'command' for a full explanation of this option and some examples.

You don't say what the OS is that you are using. You also say that this happens on one PC. Is that the only machine that you have tried?
If you are running on a DOS machine, command.com can be modified in the config.sys file as follows...

COMMAND [[drive:]path] [device] [/E:nnnnn] [/P] [/C string] [/MSG]

My dos machine contains the line...

  [drive:]path    Specifies the directory containing COMMAND.COM file.
  device          Specifies the device to use for command input and output.
  /E:nnnnn        Sets the initial environment size to nnnnn bytes.
  /P              Makes the new command interpreter permanent (can't exit).
  /C string       Carries out the command specified by string, and then stops.
  /MSG            Specifies that all error messages be stored in memory. You
                  need to specify /P with this switch.
emmons: thank you for using my comment as your answer :-(

msmits: I apologize if my answer looks like theft. The response was not as a result of your comment, since your comment did not appear to me until after I submitted the answer. I suspect that there is a caching issue here somewhere, and I shall try to be more careful in my responses.
Hmmmm.... strange how the wording of emmons' 'answer' is identical to msmits' comment.
Ulrich060397Author Commented:
No need to discuss about the points at the moment!
The comment of msmits and the proposed answer of emmons sounds good but it still doesn't work.
The problem I have is only on one computer, on two others where it works is no "shell=" line in config.sys at all
But on the PC with the problem I had before
shell=c:\windows\command.com c:\windows /p
I tried
shell=c:\windows\command.com c:\windows /E:32768 /p
and I tried without this line - still the same problem!
All other lines in config.sys are identical

Some more information: The PC is running under Win95, the problem occurs in a Dos task as well, as when the computer is put to Dos mode from Win95.

I typed mem /D with the second (/E:32768) try, and got

                        512    (1K)               BUFFERS=30
   005D5                 80    (0K)  MSDOS        Systemprogramm
   005DA                 32    (0K)  WIN          Daten
   005DC                336    (0K)  WIN          Umgebung
   005F1              3'488    (3K)  WIN          Programm
   006CB                 48    (0K)  vmm32        Daten
   006CE                800    (1K)  vmm32        Programm
   00700                352    (0K)  COMMAND      Daten
   00716              5'728    (6K)  COMMAND      Programm
   0087C             33'824   (33K)  COMMAND      Umgebung
   010BE                368    (0K)  MEM          Umgebung
   010D5             90'400   (88K)  MEM          Programm
   026E7            496'000  (484K)  MSDOS        -- Frei --

Small German Lesson:
Umgebung ... Environmet
Frei     ... Free

So here I am - any other suggestions?

Thank's for your help so far!
I`m not quite firm with the Runtime errors if MSC but as I see you tried to change the amount of enviroment space. Maybe this isn't the right way and the problem isn't the the low enviroment space. As I see from your mem /D command you have only 30 buffers for file handles. Have you tried to increase this number?
Ulrich060397Author Commented:
Dear rbr!
Sorry, that one didn't help
I increased the Buffers to 100 and have still the same problem!
So the complete config.sys is now:
device=c:\windows\emm386.exe noems
device=c:\windows\COMMAND\display.sys con=(ega,,1)
What about your autoexec.bat? Try remarking out all SET statements that are not absolutely necessary and see if it helps. The /E:xxxx parameter only affects the primary command processor, so the environment size can still be the error.
Ulrich060397Author Commented:
I remarked out all SET statements and now it works!

THANKS A LOT TO y96andha

Please check in anything as your answer, and I would be happy to quote you!

The environment is full with SET variables. Remove some of them and it will work.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Ulrich060397Author Commented:
Thank's a lot, once again!
The real problem is that when an application is spawned, the env. is shrunk to the size of the current contents rounded to 16 bytes.  In removing some of the variables, what you have done os change the free space in the process copy of the env because it no longer uses as near to the next 16 byte boundary as it did previously.

You could have achieved the same result by ADDING small env viriables, like SET A=B until you get enough space (try B, BB, BBB, etc).

The best solution, however, is to specifically reserve space for the variable that your program is going to use.  It, for example, it sets the env. variable FOO, than put SET FOO=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
In the autoexec,bat.  This is then overwritten by your program, and you are _guaranteed_ to have enough space (assuming you left enough X's).

This is the only solution guaranteed to work in all situations.


Ulrich060397Author Commented:
The problem is, that I don't know, which variable is going to be used by the program, because I don't have the source code. I have no idea how I could find it out then.

Thank you anyway!

cdms: I'm not sure what you say is right. I always believed that the default size was something like 256 bytes, and whenever a new command processor is started, the largest of the default size and the current size of all strings is used as the new environment size, unless the /E:xxxx option is specified. Thus, removing SET variables until the total size is below 256 bytes makes space available every time.

The /E:xxxx specified in config.sys is only valid for the command processor used to process autoexec.bat, not for the one used when exiting to DOS or starting a DOS prompt from Win95.

Thus, you could try entering "command /e:2048" in the DOS prompt before you start the old program, and it might work. This should create a new command processor with more environment space. I tried it with NT, but here it makes no difference, the environment is always large enough for all variables.

Ulrich060397Author Commented:
I tried entering command /e:2048 before executing the program, but this one didn't help.
Ulrich060397Author Commented:
BUT: The problem is solved for me - thank you all!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.