[Coco] OS-9 Pascal

[Frederick D Provoncha]

On Thu, 17 Feb 2005 10:36:43 -0500 John Donaldson
<jadonaldson at charter.net> writes:
> Fred,
>    Looking at a printout of the source code, I found that it Hard 
> Codes 
> directories. In this day and
> age, that is not good. Since it does look for the editor and 
> Ramdrive in 
> QP.INIT, this is a good place
> to also add CMD directory. That way you don't have to put everything 
> in 
> /DD/CMDS. After a while
> things start to get messy. For example take a look at the SYSTEM and 
> 
> SYSTEM32 Directories on
> a MSDOS machine. Programs put everything there. If I want to move a 
> 
> program package from one
> machine to another, chances are it will fail, because you don't know 
> 
> which DLL's belong to what
> program package. Even MSDOS will load DLL's from the working 
> directory, 
> but a lot of programmers
> still want to stuff evrything into either SYSTEM or SYSTEM32. One 
> day 
> this bit us in the rear. We bought
> a program package that had customized a DLL and the installtion 
> routine 
> put the DLL into SYSTEM
> directory. Well it over-wrote another DLL of the same name. As 
> result 
> some of our propriety software
> stopped working. I contacted the dealer and he agreed that that was 
> a 
> problem. He sent us a new
> install routine that put the DLL in the working directory.
>   Hard coding used to be OK when we had floppies. You just made a 
> boot 
> disk for Pascal another for
> C and ect. Today with hard drives, you don't do that, so hard coding 
> is 
> not the way to go now. I have
> found the same with screen sizes. Many packages used only 32 
> character 
> screens. Today we use 80
> column screens and sometimes the old package doesn't work with a 80 
> 
> column screen.
>   I glad yours is working for you. I am going to see if I can get 
> rid of 
> the Hard Coding and make it more
> robust. I also found that if an error poped for any reason before it 
> got 
> to displaying the menu, it would
> cause the routine to start over. I'm going to see about fixing that 
> too. 
> That seems to be what is happing
> with mine.
>    I'll post email if I get everything working for my system. 
> NitrOS9 
> with Term_80,  80T drives and
> Hard Disk.
> 
> John Donaldson
> 
> 
> Frederick D Provoncha wrote:
> 
> >On Wed, 16 Feb 2005 13:22:31 -0500 John Donaldson
> ><jadonaldson at charter.net> writes:
> >  
> >
> >>  I have gotten a little farther. I copied PascalErrs to the 
> /DD/CMDS 
> >>
> >>directory. It now get pass that
> >>and looks like it does the directery listing of /R0. At least I 
> >>think it 
> >>does. It clears the screen and the
> >>listing is displayed then the screen clears again and it starts 
> the 
> >>
> >>excuting  "qp.startup" over and over.
> >>  According to the docs, it is suppose to display the contents of 
> 
> >>/R0 
> >>and then prompt you for the name
> >>of the source code file. So it is almost working.
> >>   Is the Basci09 source for the modules in "QP" avaible. I 
> suppect 
> >>the 
> >>problem may be in one of these or
> >>there is something else I'm not doing correctly.
> >>
> >>John Donaldson

John,

I totally agree with you about the hard-coding. It's not a good thing to
do. Remember, I didn't write this program. It was written by Tony
Schountz, who I corresponded with for a little while by email when I
first started using the program. He may be still lurking around this
list. My own programs do not hard code any pathlists. Mandel09 uses the
current execution directory and the current data directory for
everything, and the user sets those before the program is run. The
install program that accompanies Mandel09 asks the user where to install
all the executable files and where to install all the data files, and
builds a Multi-Vue compatible AIF file according to the user
specifications. No hard-coding of any pathlists anywhere, at least as far
as I can remember ;-)

I too had to make some changes to the source file 'qp.b09' in order for
it to run successfully on my system. I took out some of the hard-coded
pathlists and changed some others. Luckily that's easy to do since all
the hard-coded pathlists are defined all together at the beginning of
program. Are you using Quick Pascal 0.6 or 0.8b? 0.8b doesn't use a
ramdisk, which is better for me since I have a fast hard drive.

By the way, I'm running NitrOS-9 and Quick Pascal in 80-column windows.

So how do you avoid throwing all your executables into one '/dd/CMDS'
directory? Do you have separate CMDS directories for each application? Do
you have to do a CHX every time you want to run a new program? I always
found that a little cumbersome, especially when using Multi-Vue, though I
agree with you that having dozens and possibly hundreds of files in your
/dd/CMDS directory is also a problem. I once thought I had found a
solution by setting up separate CMDS directories for every application
and then have one /dd/CMDS directory that contained little executable
procedure files (one for each application program) that changed the
execution directory for me when I wanted to run a new application. I
eventually abandoned that idea though, because it didn't work well with
Multi-Vue (basically, I couldn't launch an application by double-clicking
on a file that uses that application, a handy feature I really wanted to
continue using). Nowadays I keep all executables in '/dd/CMDS', but I
keep backup copies in individual applications' CMDS directories. So that,
for example, the executable 'Dynacalc' is located in /dd/CMDS as well as
/dd/APPS/DYNACALC/CMDS. I also try to keep my 'helpmsg' file in my SYS
directory updated to include entries for all files in /dd/CMDS, so if I
get confused as to which application a file in /dd/CMDS belongs to, I can
use the 'help' command to find out. If I want to know all the executable
files that an application uses, I can just look in that application's
individual CMDS directory to find out. This system seems pretty
redundant, but redundancy is necessary when dealing with 20 year old
computer equipment that can fail at any time :-) Anyway, my solution
doesn't solve the problem of a burgeoning /dd/CMDS directory, but at
least I'm keeping things reasonably organized. I don't claim my solution
is the best. 

I'm really interested to hear from others how you address the problem of
a burgeoning /dd/CMDS directory on a Coco hard drive. Comments anyone?
Any solutions that don't require having to do a CHX command every time
you want to run a new application?

Fred Provoncha
Stansbury Park, UT