Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 exptools; site laidbak.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!laidbak!brad From: brad@laidbak.UUCP (Bradley Bosch) Newsgroups: net.micro.6809 Subject: Re: Can someone explain this? Message-ID: <218@laidbak.UUCP> Date: Tue, 24-Sep-85 13:50:20 EDT Article-I.D.: laidbak.218 Posted: Tue Sep 24 13:50:20 1985 Date-Received: Thu, 26-Sep-85 06:23:38 EDT References: <279@sask.UUCP> Reply-To: brad@laidbak.UUCP (Bradley Bosch) Distribution: net Organization: LAI Chicago Lines: 212 Keywords: OS-9 Shell Summary: Memory problem with full path name execution under OS-9? How much memory was required for the stack (data segment) for your program? I have noticed a similar problem which seems to be related to using full path names to execute a program instead of executing them from the execution directory with just the program name. The program I was trying to execute was very large. Data and code together amounted to about 20 pages less than the memory available. If I changed the execution directory to the directory containing the program, it worked fine. If instead, I executed the program with the full path name, I got an out of memory error. I tried this with more than one large program with the same results. If I write a small machine code program which just exec's the larger program using the full path name, and then execute the smaller program, the larger program would run ok. This to me would seem to indicate a problem with the shell, but I suppose it could be more complicated. I called the Color Computer support group at Fort Worth, but all they could tell me was that they couldn't help me. The person I talked to tried to tell me that it was because of the memory required to hold the buffers for the directories in the path. I would be surprised if a full path name required more than one extra buffer page. Why would they open the directory for the next element in the path before they closed the last one? I tried to explain to him that it couldn't possibly require 20 extra pages, but he didn't seem to follow my reasoning. I goaded him in to promising to check on the problem for me and call me back, but of course he never did. Does Microware have a support number? Perhaps if I call Microware I might be able to talk to someone who knows what they are talking about. The small program I mentioned above is the way I use to get around the limitations of the space available on a 40 track double sided disk. I have more programs than will fit on my system disk. I have a program which generates these small programs from a template. I call it link.ex. Happily Hacking at OS-9, Brad Bosch ...!ihnp4!laidbak!brad Newsgroups: net.micro.6809 Subject: Re: Can someone explain this? Summary: Memory problem with full path name execution under OS-9? Expires: References: <279@sask.UUCP> Sender: Reply-To: brad@laidbak.UUCP (Bradley Bosch) Followup-To: Distribution: net Organization: Lachman Associates, Inc., Westmont Il. Keywords: OS-9 Shell How much memory was required for the stack (data segment) for your program? I have noticed a similar problem which seems to be related to using full path names to execute a program instead of executing them from the execution directory with just the program name. The program I was trying to execute was very large. Data and code together amounted to about 20 pages less than the memory available. If I changed the execution directory to the directory containing the program, it worked fine. If instead, I executed the program with the full path name, I got an out of memory error. I tried this with more than one large program with the same results. If I write a small machine code program which just exec's the larger program using the full path name, and then execute the smaller program, the larger program would run ok. This to me would seem to indicate a problem with the shell, but I suppose it could be more complicated. I called the Color Computer support group at Fort Worth, but all they could tell me was that they couldn't help me. The person I talked to tried to tell me that it was because of the memory required to hold the buffers for the directories in the path. I would be surprised if a full path name required more than one extra buffer page. Why would they open the directory for the next element in the path before they closed the last one? I tried to explain to him that it couldn't possibly require 20 extra pages, but he didn't seem to follow my reasoning. I goaded him in to promising to check on the problem for me and call me back, but of course he never did. Does Microware have a support number? Perhaps if I call Microware I might be able to talk to someone who knows what they are talking about. The small program I mentioned above is the way I use to get around the limitations of the space available on a 40 track double sided disk. I have more programs than will fit on my system disk. I have a program which generates these small programs from a template. I call it link.ex. Happily Hacking at OS-9, Brad Bosch ...!ihnp4!laidbak!brad Newsgroups: net.micro.6809 Subject: Re: Can someone explain this? Summary: Memory problem with full path name execution under OS-9? Expires: References: <279@sask.UUCP> Sender: Reply-To: brad@laidbak.UUCP (Bradley Bosch) Followup-To: Distribution: net Organization: Lachman Associates, Inc., Westmont Il. Keywords: OS-9 Shell How much memory was required for the stack (data segment) for your program? I have noticed a similar problem which seems to be related to using full path names to execute a program instead of executing them from the execution directory with just the program name. The program I was trying to execute was very large. Data and code together amounted to about 20 pages less than the memory available. If I changed the execution directory to the directory containing the program, it worked fine. If instead, I executed the program with the full path name, I got an out of memory error. I tried this with more than one large program with the same results. If I write a small machine code program which just exec's the larger program using the full path name, and then execute the smaller program, the larger program would run ok. This to me would seem to indicate a problem with the shell, but I suppose it could be more complicated. I called the Color Computer support group at Fort Worth, but all they could tell me was that they couldn't help me. The person I talked to tried to tell me that it was because of the memory required to hold the buffers for the directories in the path. I would be surprised if a full path name required more than one extra buffer page. Why would they open the directory for the next element in the path before they closed the last one? I tried to explain to him that it couldn't possibly require 20 extra pages, but he didn't seem to follow my reasoning. I goaded him in to promising to check on the problem for me and call me back, but of course he never did. Does Microware have a support number? Perhaps if I call Microware I might be able to talk to someone who knows what they are talking about. The small program I mentioned above is the way I use to get around the limitations of the space available on a 40 track double sided disk. I have more programs than will fit on my system disk. I have a program which generates these small programs from a template. I call it link.ex. Happily Hacking at OS-9, Brad Bosch ...!ihnp4!laidbak!brad Newsgroups: net.micro.6809 Subject: Re: Can someone explain this? Summary: Memory problem with full path name execution under OS-9? Expires: References: <279@sask.UUCP> Sender: Reply-To: brad@laidbak.UUCP (Bradley Bosch) Followup-To: Distribution: net Organization: Lachman Associates, Inc., Westmont Il. Keywords: OS-9 Shell How much memory was required for the stack (data segment) for your program? I have noticed a similar problem which seems to be related to using full path names to execute a program instead of executing them from the execution directory with just the program name. The program I was trying to execute was very large. Data and code together amounted to about 20 pages less than the memory available. If I changed the execution directory to the directory containing the program, it worked fine. If instead, I executed the program with the full path name, I got an out of memory error. I tried this with more than one large program with the same results. If I write a small machine code program which just exec's the larger program using the full path name, and then execute the smaller program, the larger program would run ok. This to me would seem to indicate a problem with the shell, but I suppose it could be more complicated. I called the Color Computer support group at Fort Worth, but all they could tell me was that they couldn't help me. The person I talked to tried to tell me that it was because of the memory required to hold the buffers for the directories in the path. I would be surprised if a full path name required more than one extra buffer page. Why would they open the directory for the next element in the path before they closed the last one? I tried to explain to him that it couldn't possibly require 20 extra pages, but he didn't seem to follow my reasoning. I goaded him in to promising to check on the problem for me and call me back, but of course he never did. Does Microware have a support number? Perhaps if I call Microware I might be able to talk to someone who knows what they are talking about. The small program I mentioned above is the way I use to get around the limitations of the space available on a 40 track double sided disk. I have more programs than will fit on my system disk. I have a program which generates these small programs from a template. I call it link.ex. Happily Hacking at OS-9, Brad Bosch ...!ihnp4!laidbak!brad