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